Tag Archives: botnet

Operation Tovar: The Latest Attempt to Eliminate Key Botnets

| By | Threat Intelligence, Threat Research |
Comments
0

Coordinated botnet disruptions have increased in pace and popularity over the last few years as more private companies work with international law enforcement agencies to combat malware infections on a grand scale. Operation Tovar, announced on June 2 2014, is the latest to make headlines. The target of the investigation, Evgeniy Mikhailovich Bogachev, was indicted by the Department of Justice and is wanted by the FBI for his role as alleged leader of the Gameover ZeuS and CryptoLocker botnets. Four other defendants were indicted using their pseudonyms. Though Bogachev’s current activities aren’t known, the Operation Tovar task force has maintained control of the botnet infrastructure and remediation efforts are ongoing.

While new malware strains are released with increasing frequency, it’s easy to forget why Gameover and CryptoLocker are worthwhile targets for takedown operations. Both offered more advanced features than their peers and typified the increasingly sophisticated cybercriminal enterprises behind botnets.

Gameover ZeuS

Since the ZeuS source code was released in 2011, several new variants have appeared in the wild. Citadel, KINS, ICE IX, and Gameover have all improved upon the basic ZeuS model by introducing new features, using better encryption, and modifying command and control (C2) communication methods.

Gameover uses a peer-to-peer (P2P) system for C2 communication. Though other P2P botnets such as Kelihos exist, Gameover is notable for its use of proxy nodes to introduce complexity into the standard P2P infrastructure. These proxy nodes are specific machines designated as relay points through which the botnet operators send commands and receive stolen information. This minimizes the number of systems that actually communicate with C2 servers. C2 commands are signed using RSA-2048 and encrypted with RC4 making it very difficult to tamper with the botnet.

Additionally, Gameover maintains a failsafe mechanism: a domain generation algorithm (DGA) that produces 1,000 domains each week. This feature enables the operators to maintain control of their botnet even if the P2P infrastructure is compromised. The DGA produces long, nonsensical strings at one of six top-level domains: .com, .net, .org, .biz, .info, and .ru that can be registered and used to send commands to the botnet.

ZeuS and all its variants are information-stealing trojans. We refer to them as banking trojans because that’s where they excel and Gameover is no exception. Gameover is able to trick the user into handing over personal information and can even defeat two-factor authentication. It accomplishes this by injecting custom code into the browser when a victim visits certain websites. Gameover’s arsenal of bank account takeover tools includes 1,500 web injections that were custom-made to target the websites of more than 700 financial institutions worldwide.

In addition to its exceptional abilities as a banking trojan, Gameover is capable of a wider variety of data theft activities. An Operation Tovar task force member, speaking to Brian Krebs on the condition of anonymity, said they have evidence of additional harvested data and that Gameover targeted proprietary information.

CryptoLocker

Not content with merely engaging in widespread banking credential and information theft, the Gameover criminal operators decided to maximize returns by infecting systems with CryptoLocker. It is a type of ransomware that encrypts the files on infected machines and then demands a ransom of hundreds of dollars in order to receive a decryption key. Typically, victims were given 72 hours to pay the ransom in bitcoins or risk losing their data.

Unwilling to miss out on any opportunity to generate revenue, the criminal operators set up a website to assist victims in paying the ransom in bitcoins. Through this website, victims could complete the transaction and track the status of their “order” – the ransom payment in exchange for the decryption key. Some victims, unwilling or unable to pay the ransom, missed the 72-hour deadline only to see the ransom demand increase fivefold.

Law enforcement officials discouraged people from paying the ransom since it would fund a criminal organization, but without back ups many victims had little choice but to pay. A US police department paid $750 for two Bitcoins as ransom after CryptoLocker was installed on a system used for police reports and booking photos. CryptoLocker encrypts files using asymmetric encryption, making use of a public and a private key. Without the private key, located on the criminals’ servers, infected files probably cannot be decrypted.

The Target

Operation Tovar’s investigation began with a server in the UK. A trail of wire transfers, money mules, criminal servers, and at least one confidential source led investigators to Bogachev. He is a Russian citizen wanted on charges of conspiracy to participate in racketeering activity, bank fraud, conspiracy to violate the Computer Fraud and Abuse Act, conspiracy to violate the Identity Theft and Assumption Deterrence Act, aggravated identity theft, conspiracy, computer fraud, wire fraud, and money laundering. The FBI estimates the financial toll of Gameover at over $100 million and another estimate is that more than $27 million in ransom payments were made in the first two months of CryptoLocker’s distribution.

Obtaining an indictment against a Russian national who will likely never be extradited to the United States isn’t sufficient to put an end to a criminal organization. In 2011, Russian citizen Aleksandr Andreevich Panin was indicted in the US on 23 counts related to the development and distribution of SpyEye but was not arrested until 2013 when he flew through Hartsfield-Jackson Atlanta International Airport. The Russian government, in a travel warning to its citizens, specifically mentions Panin and recommends that Russians facing legal action in the US should refrain from travelling internationally.

The Takeover

Drawing on the technical expertise of its members, the Operation Tovar task force was able to exploit flaws in the design of Gameover’s P2P network to manipulate the peer list and redirect traffic to nodes under its control. The specific technical details have not been released to the public in order to prevent the criminals from regaining control.

Gameover’s failsafe mechanism, the DGA that was supposed to have allowed the criminals to maintain control in the event of a P2P disruption, was reverse engineered by task force members. The FBI then obtained a restraining order to redirect any attempts to register those domains to a government-run server. Furthermore, US service providers are required to block connections to the Russian .ru domains generated by the DGA since the US has no jurisdiction to prevent their registration.

CryptoLocker also used a DGA for determining C2 locations. The algorithm was reverse engineered and the C2 servers were identified and seized by the Operation Tovar task force. Due to the use of an asymmetric key algorithm, CryptoLocker victims whose files remain encrypted currently have no avenue of remediation.

Operation Tovar’s success can be measured by two factors: (1) Have the criminals regained control of their botnets and (2) Is the malware being removed from infected machines? While we can’t say for certain that the people responsible for Gameover and CryptoLocker have ceased all criminal activity, they have not regained control of the network disrupted by Operation Tovar. Based on this fact alone, the task force should be commended. Successful botnet disruptions are very challenging. Attempted takeovers over Kelihos have been undone after only two weeks.

The remediation of infected machines is an even more difficult task. US-CERT has published a list of recommended actions and resources, and a number of the private companies involved in Operation Tovar have released scanning tools. The onus remains on individuals and organizations to use these resources to determine if they are infected and take the appropriate steps to remediate the problem. Statistics published by The Shadowserver Foundation show the number of machines infected with Gameover has remained essentially flat since the takeover. There are simply not enough people taking advantage of the resources available to remediate their systems.

tovar1

The task force has taken control of the C2 network and now some people may believe that the malware is neutered and no further action is required. It is important to remember that any malware is unauthorized code running on a computer. The integrity of the system is still compromised, regardless of who is in control of the botnet.

A Not-So Civic Duty: Asprox Botnet Campaign Spreads Court Dates and Malware

| By and | Advanced Malware, Botnets, Threat Intelligence, Threat Research |
Comments
0

Executive Summary

FireEye Labs has been tracking a recent spike in malicious email detections that we attribute to a campaign that began in 2013. While malicious email campaigns are nothing new, this one is significant in that we are observing mass-targeting attackers adopting the malware evasion methods pioneered by the stealthier APT attackers. And this is certainly a high-volume business, with anywhere from a few hundred to ten thousand malicious emails sent daily – usually distributing between 50 and 500,000 emails per outbreak.

Through the FireEye Dynamic Threat Intelligence (DTI) cloud, FireEye Labs discovered that each and every major spike in email blasts brought a change in the attributes of their attack. These changes have made it difficult for anti-virus, IPS, firewalls and file-based sandboxes to keep up with the malware and effectively protect endpoints from infection. Worse, if past is prologue, we can expect other malicious, mass-targeting email operators to adopt this approach to bypass traditional defenses.

This blog will cover the trends of the campaign, as well as provide a short technical analysis of the payload.

Campaign Details

fig1

Figure 1: Attack Architecture

The campaign first appeared in late December of 2013 and has since been seen in fairly cyclical patterns each month. It appears that the threat actors behind this campaign are fairly responsive to published blogs and reports surrounding their malware techniques, tweaking their malware accordingly to continuously try and evade detection with success.

In late 2013, malware labeled as Kuluoz, the specific spam component of the Asprox botnet, was discovered to be the main payload of what would become the first malicious email campaign. Since then, the threat actors have continuously tweaked the malware by changing its hardcoded strings, remote access commands, and encryption keys.

Previously, Asprox malicious email campaigns targeted various industries in multiple countries and included a URL link in the body. The current version of Asprox includes a simple zipped email attachment that contains the malicious payload “exe.” Figure 2 below represents a sample message while Figure 3 is an example of the various court-related email headers used in the campaign.

fig2

Figure 2 Email Sample

fig3

Figure 3 Email Headers

Some of the recurring campaign that Asporox used includes themes focused around airline tickets, postal services and license keys. In recent months however, the court notice and court request-themed emails appear to be the most successful phishing scheme theme for the campaign.

The following list contains examples of email subject variations, specifically for the court notice theme:

  • Urgent court notice
  • Notice to Appear in Court
  • Notice of appearance in court
  • Warrant to appear
  • Pretrial notice
  • Court hearing notice
  • Hearing of your case
  • Mandatory court appearance

The campaign appeared to increase in volume during the month of May. Figure 4 shows the increase in activity of Asprox compared to other crimewares towards the end of May specifically. Figure 5 highlights the regular monthly pattern of overall malicious emails. In comparison, Figure 6 is a compilation of all the hits from our analytics.

fig4

Figure 4 Worldwide Crimeware Activity

fig5

Figure 5 Overall Asprox Botnet tracking

fig6

Figure 6 Asprox Botnet Activity Unique Samples

These malicious email campaign spikes revealed that FireEye appliances, with the support of DTI cloud, were able to provide a full picture of the campaign (blue), while only a fraction of the emailed malware samples could be detected by various Anti-Virus vendors (yellow).

fig7

Figure 7 FireEye Detection vs. Anti-Virus Detection

By the end of May, we observed a big spike on the unique binaries associated with this malicious activity. Compared to the previous days where malware authors used just 10-40 unique MD5s or less per day, we saw about 6400 unique MD5s sent out on May 29th. That is a 16,000% increase in unique MD5s over the usual malicious email campaign we’d observed. Compared to other recent email campaigns, Asprox uses a volume of unique samples for its campaign.

fig8

Figure 8 Asprox Campaign Unique Sample Tracking

fig9

Figure 9 Geographical Distribution of the Campaign

fig10

Figure 10 Distribution of Industries Affected

Brief Technical Analysis

fig11

Figure 11 Attack Architecture

Infiltration

The infiltration phase consists of the victim receiving a phishing email with a zipped attachment containing the malware payload disguised as an Office document. Figure 11 is an example of one of the more recent phishing attempts.

fig12

Figure 12 Malware Payload Icon

Evasion

Once the victim executes the malicious payload, it begins to start an svchost.exe process and then injects its code into the newly created process. Once loaded into memory, the injected code is then unpacked as a DLL. Notice that Asprox uses a hardcoded mutex that can be found in its strings.

  1. Typical Mutex Generation
    1. “2GVWNQJz1″
  2. Create svchost.exe process
  3. Code injection into svchost.exe

Entrenchment

Once the dll is running in memory it then creates a copy of itself in the following location:

%LOCALAPPDATA%/[8 CHARACTERS].EXE

Example filename:

%LOCALAPPDATA%\lwftkkea.exe

It’s important to note that the process will first check itself in the startup registry key, so a compromised endpoint will have the following registry populated with the executable:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Exfiltration/Communication

The malware uses various encryption techniques to communicate with the command and control (C2) nodes. The communication uses an RSA (i.e. PROV_RSA_FULL) encrypted SSL session using the Microsoft Base Cryptographic Provider while the payloads themselves are RC4 encrypted. Each sample uses a default hardcoded public key shown below.

Default Public Key

—-BEGIN PUBLIC KEY—-

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCUAUdLJ1rmxx+bAndp+Cz6+5I’

Kmgap2hn2df/UiVglAvvg2US9qbk65ixqw3dGN/9O9B30q5RD+xtZ6gl4ChBquqw

jwxzGTVqJeexn5RHjtFR9lmJMYIwzoc/kMG8e6C/GaS2FCgY8oBpcESVyT2woV7U

00SNFZ88nyVv33z9+wIDAQAB

—-END PUBLIC KEY—-

First Communication Packet

Bot ID RC4 Encrypted URL

POST /5DBA62A2529A51B506D197253469FA745E7634B4FC

HTTP/1.1

Accept: */*

Content-Type: application/x-www-form-urlencoded

User-Agent: <host useragent>

Host: <host ip>:443

Content-Length: 319

Cache-Control: no-cache

<knock><id>5DBA62A247BC1F72B98B545736DEA65A</id><group>0206s</group><src>3</src><transport>0</transport><time>1881051166</time><version>1537</version><status>0</status><debug>none<debug></knock>

C2 Commands

In comparison to the campaign at the end of 2013, the current campaign uses one of the newer versions of the Asprox family where threat actors added the command “ear.”

if ( wcsicmp(Str1, L”idl”) )

{

if ( wcsicmp(Str1, L”run”) )

{

if ( wcsicmp(Str1, L”rem”) )

{

if ( wcsicmp(Str1, L”ear”)

{

if ( wcsicmp(Str1, L”rdl”) )

{

if ( wcsicmp(Str1, L”red”) )

{

if ( !wcsicmp(Str1, L”upd”) )

C2 commands Description
idl This commands idles the process to wait for commands
run Download from a partner site and execute from a specified path
rem Remove itself
ear Download another executable and create autorun entry
rdl Download, inject into svchost, and run
upd Download and update
red Modify the registry

C2 Campaign Characteristics

fig13

For the two major malicious email campaign spikes in April and May of 2014, separate sets of C2 nodes were used for each major spike.

April

May-June
94.23.24.58 192.69.192.178
94.23.43.184 213.21.158.141
1.234.53.27 213.251.150.3
84.124.94.52 27.54.87.235
133.242.134.76 61.19.32.24
173.45.78.226 69.64.56.232
37.59.9.98 72.167.15.89
188.93.74.192 84.234.71.214
187.16.250.214 89.22.96.113
85.214.220.78 89.232.63.147
91.121.20.71
91.212.253.253
91.228.77.15

Conclusion

The data reveals that each of the Asprox botnet’s malicious email campaigns changes its method of luring victims and C2 domains, as well as the technical details on monthly intervals. And, with each new improvement, it becomes more difficult for traditional security methods to detect certain types of malware.

Acknowledgements:

Nart Villeneuve, Jessa dela Torre, and David Sancho. Asprox Reborn. Trend Micro. 2013. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-asprox-reborn.pdf

Grum—New segement came and gone

| By | Botnets

Back in July, with the help of Spamhaus and CERT-GIB, FireEye took down Grum, one of the world's largest spam botnets. The whole shutdown operation was like a roller coaster ride and is explained in my previous blog posts here and here. Apart from an unsuccessful recovery attempt made by the bot herders a few days after the takedown, we never noticed any movement from the opposite side. Apparently the Grum guys had given up their botnet.

Continue reading »

The Story Behind Backdoor.LV

| By | Botnets

From May of this year, we have seen a sudden uptick in the number of samples of an interesting malware we call Backdoor.LV. We have seen this malware primarily using websites hosting .exes to propagate. The HTTP header below shows one such example from which the malware was downloaded. A quick look up on the location of the IP in the HTTP header "94.129.29.233" shows that the IP is located in Kuwait.

Continue reading »

Grum—The Money Factor

| By | Botnets

As expected, the operators behind Grum are trying their best to reclaim their botnet. In the absence of any built-in fallback mechanisms, the bot herders used another fallback mechanism that is called money. Over the weekend we found that the Ukrainian ISP SteepHost removed the null route on three CnCs that were taken down last week. We suspect the bot herders must have paid a large amount of money in order to get access to these servers. We immediately noticed this change and contacted SteepHost once again. After hours of negotiations, they eventually shut down these CnCs once more. During this time there was a short burst of spam sent by Grum, but it has disappeared as of this morning. 

Grum.1d

Figure 1. Spam volume during this recovery attempt (Source: SpamHaus)

Continue reading »

Grum Recap

| By | Botnets

For a quick recap, here is a list of Grum CnCs. Some of these IPs were mentioned in my previous posts (1, 2, and 3), but I would like to summarize everything in one table.

Based on the data from the last 30 days, below are the Grum CnC IPs along with their ISP information.

Continue reading »

Grum CnCs—Just a few more to go

| By | Botnets

This post was updated on July 17, 2012, at 3:15 PM.

Last week, I wrote an article covering various aspects of a large spam botnet named Grum. This article mainly covered the current command and control (CnC) coordinates of this botnet. The intention behind this article was not only to share this information for a general awareness, but also to invite the research community to come forward to take down this spam beast. I can see that this strategy is really working. Dutch authorities have pulled the plug on two of the CnC servers pointing to IP addresses 94.102.51.226 and 94.102.51.227.1 Thanks to the Dutch authorities for swift action.

Continue reading »

Killing the Beast - Part 5

| By | Botnets

Back in 2009, I started writing a series of articles called "Killing the Beast." These articles were primarily focused on the command and control (CnC) coordinates of popular spam botnets. These articles not only provided readers greater visibility into these spam botnets, but also served as the basis for two botnet takedowns. So far, four articles under this series have been published. After a long time, I have decided to write the fifth one.

For a refresher, older posts can be accessed using the links shown below:

Part 1, Part 2, Part 3, and Part 4.

In recent years, we have seen the fall of many spam botnets including Srizbi, Rustock, Mega-D, Pushdo.A, Storm, and Waledac. But one botnet that has kept itself well under the radar is the Grum botnet. When I look into my Botnet Lab logs, I can see traces of Grum's earlier versions recorded around February 2008. That means that, as of today, this botnet is more than four years old. Readers who have been following the evolution of different botnets would agree that keeping a botnet active and alive for this many years is an achievement in itself.

Based on the latest statistics from M86Security, Grum is currently responsible for 17.4% of worldwide spam traffic, making it the world's third most active spam botnet after Cutwail and Lethic. Interestingly, Grum, which was once the world's number one spam botnet around January 2012 (at that time, Grum was responsible for 33.3% of worldwide spam), is already on its decline after losing its position to the Cutwail botnet.

Continue reading »

More Flame/sKyWIper CNC Behavior Uncovered

| By | Advanced Malware

When news of the Flame/SkyWiper malware hit the headlines last month, the world went into a frenzy. Flame was immediately hailed as the world’s most sophisticated malware. While security researchers will surely be talking about Flame for years to come, FireEye has since made another discovery regarding Flame’s command and control (CNC) behavior: it appears that the Flamer/sKyWIper malware’s callback has recently changed.

Continue reading »