Monthly Archives: February 2014

Labs Webinar: Find out why governments are spying on you

ThreatReportCoverH22013It’s that time again. Our Threat Report H2 2013 is being released next week, and we’re holding another F-Secure Labs webinar with our own Mikko Hypponen and Sean Sullivan. Catch the details of the Threat Report before it’s even published.

Get the latest from Sean and Mikko on governmental surveillance, malware threats to PC, Mac and Android, exploit kits, schemes like sharking, the fast-approching end of Windows XP support and what that means, and more.

It’s Tuesday, March 4, at 5pm Helsinki time (find out what time that is in your city by using this handy time zone converter)

Sign up for the Google Hangout here. Tweet your questions using the hashtag #SAFE

See you then!

Episode #175: More Time! We Need More Time!

Tim leaps in

Every four years (or so) we get an extra day in February, leap year. When I was a kid this term confused me. Frogs leap, they leap over things. A leap year should be shorter! Obviously, I was wrong.

This extra day can give us extra time to complete tasks (e.g. write blog post), so we are going to use our shells to check if the current year is a leap year.

PS C:\> [DateTime]::IsLeapYear(2014)

Sadly, this year we do not have extra time. Let's confirm that this command does indeed work by checking a few other years.

PS C:\> [DateTime]::IsLeapYear(2012)
PS C:\> [DateTime]::IsLeapYear(2000)
PS C:\> [DateTime]::IsLeapYear(1900)

Wait a second! Something is wrong. The year 1900 is a multiple of 4, why is it not a leap year?

The sun does not take exactly 365.25 days to get around the sun, it is actually 365.242199 days. This means that if we always leaped every four years we would slowly get off course. So every 100 years we skip the leap year.

Now you are probably wondering why 2000 had a leap year. That is because it is actually the exception to the exception. Every 400 years we skip skipping the leap year. What a cool bit of trivia, huh?

Hal, how jump is your shell?

Hal jumps back

I should have insisted Tim do this one in CMD.EXE. Isn't is nice that PowerShell has a IsLeapYear() built-in? Back in my day, we didn't even have zeroes! We had to bend two ones together to make zeroes! Up hill! Both ways! In the snow!

Enough reminiscing. Let's make our own IsLeapYear function in the shell:

function IsLeapYear {
year=${1:-$(date +%Y)};
[[ $(($year % 400)) -eq 0 || ( $(($year % 4)) -eq 0 && $(($year % 100)) -ne 0 ) ]]

There's some fun stuff in this function. First we check to see if the function is called with an argument ("${1-..."). If so, then that's the year we'll check. Otherwise we check the current year, which is the value returned by "$(date +%Y)".

The other line of the function is the standard algorithm for figuring leap years. It's a leap year if the year is evenly divisible by 400, or divisible by 4 and not divisible by 100. Since shell functions return the value of the last command or expression executed, our function returns whether or not it's a leap year. Nice and easy, huh?

Now we can run some tests using our IsLeapYear function, just like Tim did:

$ IsLeapYear && echo Leaping lizards! || echo Arf, no
Arf, no
$ IsLeapYear 2012 && echo Leaping lizards! || echo Arf, no
Leaping lizards!
$ IsLeapYear 2000 && echo Leaping lizards! || echo Arf, no
Leaping lizards!
$ IsLeapYear 1900 && echo Leaping lizards! || echo Arf, no
Arf, no

Assuming the current year is not a Leap Year, we could even wrap a loop around IsLeapYear to figure out the next leap year:

$ y=$(date +%Y); while :; do IsLeapYear $((++y)) && break; done; echo $y

We begin by initializing $y to the current year. Then we go into an infinte loop ("while :; do..."). Inside the loop we add one to $y and call IsLeapYear. If IsLeapYear returns true, then we "break" out of the loop. When the loop is all done, simply echo the last value of $y.

Stick that in your PowerShell pipe and smoke it, Tim!

The 2013 FireEye Advanced Threat Report!

FireEye has just released its 2013 Advanced Threat Report (ATR), which provides a high-level overview of the computer network attacks that FireEye discovered last year.

In this ATR, we focused almost exclusively on a small, but very important subset of our overall data analysis – the advanced persistent threat (APT).

APTs, due to their organizational structure, mission focus, and likely some level of nation-state support, often pose a more serious danger to enterprises than a lone hacker or hacker group ever could.

Over the long term, APTs are capable of cyber attacks that can rise to a strategic level, including widespread intellectual property theft, espionage, and attacks on national critical infrastructures.

The data contained in this report is gleaned from the FireEye Dynamic Threat Intelligence (DTI) cloud, and is based on attack metrics shared by FireEye customers around the world.

Its insight is derived from:

  • 39,504 cyber security incidents
  • 17,995 malware infections
  • 4,192 APT incidents
  • 22 million command and control (CnC) communications
  • 159 APT-associated malware families
  • CnC infrastructure in 206 countries and territories

FireEye 2013 Threat Report Final

Based on our data, the U.S., South Korea, and Canada were the top APT targets in 2013; the U.S., Canada, and Germany were targeted by the highest number of unique malware families.

The ATR describes attacks on 20+ industry verticals. Education, Finance, and High-Tech were the top overall targets, while Government, Services/Consulting, and High-Tech were targeted by the highest number of unique malware families.

In 2013, FireEye discovered eleven zero-day attacks. In the first half of the year, Java was the most common target for zero-days; in the second half, FireEye observed a surge in Internet Explorer (IE) zero-days that were used in watering hole attacks, including against U.S. government websites.

Last year, FireEye analyzed five times more Web-based security alerts than email-based alerts – possibly stemming from an increased awareness of spear phishing as well as a more widespread use of social media.

In sum, the 2013 ATR offers strong evidence that malware infections occur within enterprises at an alarming rate, that attacker infrastructure is global in scope, and that advanced attackers continue to penetrate legacy defenses, such as firewalls and anti-virus (AV), with ease.

Amazon’s Mobile Shopping Clients and CAPTCHA

Amazon is a popular online retailer serving millions of users. Unfortunately, FireEye mobile security researchers have found security issues within Amazon’s mobile apps on both Android and iOS platforms through which attackers can crack the passwords of target Amazon accounts. Amazon confirmed our findings and hot fixed the issue.

Recently, we found two security issues within Amazon’s mobile apps on both Android and iOS platforms:

  • No limitation or CAPTCHA for password attempts
  • Weak password policy

Attackers can exploit these two security issues remotely against target Amazon accounts.

fig1 Figure 1. Verification Code for Wrong Password Attempts

A CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a challenge-response test designed to determine whether the user is a human. CAPTCHAs are well adopted for preventing programmed bots from accessing online services for bad purposes, such as conducting denial-of-service attacks, harvesting information and cracking passwords.

The web version of Amazon requires the user to complete a CAPTCHA after ten incorrect password attempts (Figure 1), to prevent password cracking. However, Amazon’s mobile apps haven’t adopted such protection using CAPTCHA (Figure 2 and Figure 3). This design flaw provides attackers the chance to crack any Amazon account’s password using brute force.

 fig2 Figure 2. Amazon Android App

fig3 Figure 3. Amazon iOS App

Furthermore, Amazon doesn’t have a strong password strength requirement. It accepts commonly used weak passwords such as "123456" and "111111". We know that the weaker the password, the easier for hackers to break into an account. Therefore, allowing weak passwords puts account safety to potential security risks. Given that there are many well-known previous password leakages, attackers can use these password leakages as knowledge bases to conduct password cracking.

As a proof of concept, we figured out the password of one Amazon account we setup within 1000 attempts, using the latest version (2.8.0) of Amazon’s Android shopping client.

After receiving our vulnerability report, Amazon hot fixed the first issue by patching their server. Now if the user tries multiple incorrect passwords, the server will block the user from login (Figure 4). In the future, we suggest adding CAPTCHA support for Amazon mobile (Android and iOS) apps, and enforcing requirements for stronger passwords.

fig4 Figure 4. Wrong Password Block

Background Monitoring on Non-Jailbroken iOS 7 Devices — and a Mitigation

Background monitoring mobile applications has become a hot topic on mobile devices. Existing reports show that such monitoring can be conducted on jailbroken iOS devices. FireEye mobile security researchers have discovered such vulnerability, and found approaches to bypass Apple's app review process effectively and exploit non-jailbroken iOS 7 successfully. We have been collaborating with Apple on this issue.


Fig.1 Background Monitoring

We have created a proof-of-concept "monitoring" app on non-jailbroken iOS 7.0.x devices. This “monitoring” app can record all the user touch/press events in the background, including, touches on the screen, home button press, volume button press, and TouchID press, and then this app can send all user events to any remote server, as shown in Fig.1. Potential attackers can use such information to reconstruct every character the victim inputs.

Note that the demo exploits the latest 7.0.4 version of iOS system on a non-jailbroken iPhone 5s device successfully. We have verified that the same vulnerability also exists in iOS versions 7.0.5, 7.0.6, and 6.1.x. Based on the findings, potential attackers can either use phishing to mislead the victim to install a malicious/vulnerable app or exploit another remote vulnerability of some app, and then conduct background monitoring.


Fig.2 Background App Refresh Settings


Fig.3 Killing An App on iOS7

iOS7 provides settings for "background app refresh". Disabling unnecessary app's background refreshing contributes to preventing the potential background monitoring. However, it can be bypassed. For example, an app can play music in the background without turning on its "background app refresh" switch. Thus a malicious app can disguise itself as a music app to conduct background monitoring.

Before Apple fixes this issue, the only way for iOS users to avoid this security risk is to use the iOS task manager to stop the apps from running in the background to prevent potential background monitoring. iOS7 users can press the Home button twice to enter the task manager and see preview screens of apps opened, and then swipe an app up and out of preview to disable unnecessary or suspicious applications running on the background, as shown in Fig.3.

We conducted this research independently before we were aware of this recent report. We hope this blog could help users understand and mitigate this threat further.

Acknowledgement: Special thanks to Jari Salomaa for his valuable comments and feedback. We also thank Raymond Wei, Dawn Song, and Zheng Bu for their valuable help on writing this blog.

Deep Data Governance

One of the first things to catch my eye this week at RSA was a press release by STEALTHbits on their latest Data Governance release. They're a long time player in DG and as a former employee, I know them fairly well. And where they're taking DG is pretty interesting.

The company has recently merged its enterprise Data (files/folders) Access Governance technology with its DLP-like ability to locate sensitive information. The combined solution enables you to locate servers, identify file shares, assess share and folder permissions, lock down access, review file content to identify sensitive information, monitor activity to look for suspicious activity, and provide an audit trail of access to high-risk content.

The STEALTHbits solution is pragmatic because you can tune where it looks, how deep it crawls, where you want content scanning, where you want monitoring, etc. I believe the solution is unique in the market and a number of IAM vendors agree having chosen STEALTHbits as a partner of choice for gathering Data Governance information into their Enterprise Access Governance solutions.

Learn more at the STEALTHbits website.

RSA Conference 2014

I'm at the RSA Conference this week. I considered the point of view that perhaps there's something to be said for abstaining this year but ultimately my decision to maintain course was based on two premises: (1) RSA didn't know the NSA had a backdoor when they made the arrangement and (2) The conference division doesn't have much to do with RSA's software group.

Anyway, my plan is to take notes and blog or tweet about what I see. Of course, I'll primarily be looking at Identity and Access technologies, which is only a subset of Information Security. And I'll be looking for two things: Innovation and Uniqueness. If your company has a claim on either of those in IAM solutions, please try to catch my attention.

Write Once, Exploit Everywhere: FireEye Report Analyzes Four Widely Exploited Java Vulnerabilities

Over the last couple of decades, Java has become the lingua franca of software development, a near-universal platform that works across different operating systems and devices. With its “write once, run anywhere” mantra, Java has drawn a horde of developers looking to serve a large user base as efficiently as possible.

Cyber attackers like Java for many of the same reasons. With a wide pool of potential targets, the platform has become the vehicle of choice for quickly dispersing lucrative crimeware packages.

In our continuing mission to equip security professionals against today’s advanced cyber threats, FireEye has published a free report, “Brewing Up Trouble: Analyzing Four Widely Exploited Java Vulnerabilities.” The report outlines four commonly exploited Java vulnerabilities and maps out the step-by-step infection flow of exploits kits that leverage them.

Download the paper to learn more about these vulnerabilities:

  • CVE-2013-2471, which allows attackers to override Java’s getNumDataElements() method, leading to memory corruption.
  • CVE-2013-2465,  which involves insufficient bounds checks in the storeImageArray() function. This vulnerability is used by White Lotus and other exploit kits.
  • CVE-2012-4681,  which allows attackers to bypass security checks using the findMethod () function.
  • CVE-2013-2423, which  arises due to insufficient validation in the findStaticSetter () method, leading to Java type confusion. This vulnerability employed by RedKit and other exploits kits.

As explained in the paper, Java’s popularity among the developers and widespread use in Web browsers all but  guarantees continuing interest from threat actors.

Motivated by the profits, cyber attackers are bound to adopt more intelligent exploit kits. And these attacks will continue to mushroom as more threat actors scramble for a piece of the crimeware pie.

Operation GreedyWonk: Multiple Economic and Foreign Policy Sites Compromised, Serving Up Flash Zero-Day Exploit

Less than a week after uncovering Operation SnowMan, the FireEye Dynamic Threat Intelligence cloud has identified another targeted attack campaign — this one exploiting a zero-day vulnerability in Flash. We are collaborating with Adobe security on this issue. Adobe has assigned the CVE identifier CVE-2014-0502 to this vulnerability and released a security bulletin.

As of this blog post, visitors to at least three nonprofit institutions — two of which focus on matters of national security and public policy — were redirected to an exploit server hosting the zero-day exploit. We’re dubbing this attack “Operation GreedyWonk.”

We believe GreedyWonk may be related to a May 2012 campaign outlined by ShadowServer, based on consistencies in tradecraft (particularly with the websites chosen for this strategic Web compromise), attack infrastructure, and malware configuration properties.

The group behind this campaign appears to have sufficient resources (such as access to zero-day exploits) and a determination to infect visitors to foreign and public policy websites. The threat actors likely sought to infect users to these sites for follow-on data theft, including information related to defense and public policy matters.


On Feb. 13, FireEye identified a zero-day Adobe Flash exploit that affects the latest version of the Flash Player ( and 11.7.700.261). Visitors to the Peter G. Peterson Institute for International Economics (www.piie[.]com) were redirected to an exploit server hosting this Flash zero-day through a hidden iframe.

We subsequently found that the American Research Center in Egypt (www.arce[.]org) and the Smith Richardson Foundation (www.srf[.]org) also redirected visitors the exploit server. All three organizations are nonprofit institutions; the Peterson Institute and Smith Richardson Foundation engage in national security and public policy issues.


To bypass Windows’ Address Space Layout Randomization (ASLR) protections, this exploit targets computers with any of the following configurations:

  • Windows XP
  • Windows 7 and Java 1.6
  • Windows 7 and an out-of-date version of Microsoft Office 2007 or 2010

Users can mitigate the threat by upgrading from Windows XP and updating Java and Office. If you have Java 1.6, update Java to the latest 1.7 version. If you are using an out-of-date Microsoft Office 2007 or 2010, update Microsoft Office to the latest version.

These mitigations do not patch the underlying vulnerability. But by breaking the exploit’s ASLR-bypass measures, they do prevent the current in-the-wild exploit from functioning.

Vulnerability analysis

GreedyWonk targets a previously unknown vulnerability in Adobe Flash. The vulnerability permits an attacker to overwrite the vftable pointer of a Flash object to redirect code execution.

ASLR bypass

The attack uses only known ASLR bypasses. Details of these techniques are available from our previous blog post on the subject (in the “Non-ASLR modules” section).

For Windows XP, the attackers build a return-oriented programming (ROP) chain of MSVCRT (Visual C runtime) gadgets with hard-coded base addresses for English (“en”) and Chinese (“zh-cn” and “zh-tw”).

On Windows 7, the attackers use a hard-coded ROP chain for MSVCR71.dll (Visual C++ runtime) if the user has Java 1.6, and a hard-coded ROP chain for HXDS.dll (Help Data Services Module) if the user has Microsoft Office 2007 or 2010.

Java 1.6 is no longer supported and does not receive security updates. In addition to the MSVCR71.dll ASLR bypass, a variety of widely exploited code-execution vulnerabilities exist in Java 1.6. That’s why FireEye strongly recommends upgrading to Java 1.7.

The Microsoft Office HXDS.dll ASLR bypass was patched at the end of 2013. More details about this bypass are addressed by Microsoft’s Security Bulletin MS13-106 and an accompanying blog entry. FireEye strongly recommends updating Microsoft Office 2007 and 2010 with the latest patches.

Shellcode analysis

The shellcode is downloaded in ActionScript as a GIF image. Once ROP marks the shellcode as executable using Windows’ VirtualProtect function, it downloads an executable via the InternetOpenURLA and InternetReadFile functions. Then it writes the file to disk with CreateFileA and WriteFile functions. Finally, it runs the file using the WinExec function.

PlugX/Kaba payload analysis

Once the exploit succeeds, a PlugX/Kaba remote access tool (RAT) payload with the MD5 hash 507aed81e3106da8c50efb3a045c5e2b is installed on the compromised endpoint. This PlugX sample was compiled on Feb. 12, one day before we first observed it, indicating that it was deployed specifically for this campaign.

This PlugX payload was configured with the following command-and-control (CnC) domains:

  • java.ns1[.]name
  • wmi.ns01[.]us

Sample callback traffic was as follows:

POST /D28419029043311C6F8BF9F5 HTTP/1.1

Accept: */*

HHV1: 0

HHV2: 0

HHV3: 61456

HHV4: 1

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; SV1)


Content-Length: 0

Connection: Keep-Alive

Cache-Control: no-cache

Campaign analysis

Both java.ns1[.]name and[.]org resolved to on Feb. 18, 2014. Passive DNS analysis reveals that the domain previously resolved to between July 4, 2013 and July 15, 2013 and on Feb. 17, 2014.  java.ns1[.]name also resolved to on February 18.

Domain First Seen Last Seen IP Address[.]org[.]org 2014-02-18 2014-02-18 2014-02-19 2014-02-19
java.ns1[.]name java.ns1[.]name 2014-02-18 2014-02-18 2014-02-19 2014-02-19
java.ns1[.]name java.ns1[.]name 2014-02-18 2014-02-18 2014-02-18 2014-02-18
wmi.ns01[.]us wmi.ns01[.]us 2014-02-17 2014-02-17 2014-02-17 2014-02-17
proxy.ddns[.]info proxy.ddns[.]info 2013-05-02 2013-05-02 2014-02-18 2014-02-18
updatedns.ns02[.]us updatedns.ns02[.]us 2013-09-06 2013-09-06 2013-09-06 2013-09-06
updatedns.ns01[.]us updatedns.ns01[.]us 2013-09-06 2013-09-06 2013-09-06 2013-09-06
wmi.ns01[.]us wmi.ns01[.]us 2013-07-04 2013-07-04 2013-07-15 2013-07-15


MD5 Family Compile Time Alternate C2s
7995a9a6a889b914e208eb924e459ebc 7995a9a6a889b914e208eb924e459ebc PlugX PlugX 2012-06-09 2012-06-09 fuckchina.govnb[.]com fuckchina.govnb[.]com
bf60b8d26bc0c94dda2e3471de6ec977 bf60b8d26bc0c94dda2e3471de6ec977 PlugX PlugX 2010-03-15 2010-03-15[.]org[.]org
fd69793bd63c44bbb22f9c4d46873252 fd69793bd63c44bbb22f9c4d46873252 Poison Ivy Poison Ivy 2013-03-07 2013-03-07 N/A N/A
88b375e3b5c50a3e6c881bc96c926928 88b375e3b5c50a3e6c881bc96c926928 Poison Ivy Poison Ivy 2012-06-11 2012-06-11 N/A N/A
cd07a9e49b1f909e1bd9e39a7a6e56b4 cd07a9e49b1f909e1bd9e39a7a6e56b4 Poison Ivy Poison Ivy 2012-06-11 2012-06-11 N/A N/A

The Poison Ivy variants that connected to the domain wmi.ns01[.]us had the following unique configuration properties:

Domain First Seen Last Seen IP Address
fuckchina.govnb[.]com fuckchina.govnb[.]com 2013-12-11 2013-12-11 2013-12-11 2013-12-11[.]org[.]org 2014-02-12 2014-02-12 2014-02-12 2014-02-12[.]org[.]org 2013-12-04 2013-12-04 2013-12-04 2013-12-04

We found a related Poison Ivy sample (MD5 8936c87a08ffa56d19fdb87588e35952) with the same “java7” password, which was dropped by an Adobe Flash exploit (CVE-2012-0779). In this previous incident, visitors to the Center for Defense Information website (www.cdi[.]org — also an organization involved in defense matters — were redirected to an exploit server at

This exploit server hosted a Flash exploit file named BrightBalls.swf (MD5 1ec5141051776ec9092db92050192758). This exploit, in turn, dropped the Poison Ivy variant. In addition to using the same password “java7,” this variant was configured with the mutex with the similar pattern of “YFds*&^ff” and connected to a CnC server at windows.ddns[.]us.

Using passive DNS analysis, we see the domains windows.ddns[.]us and wmi.ns01[.]us both resolved to in mid-2012.

Domain First Seen Last Seen IP Address 2012-07-07 2012-07-07 2012-09-19 2012-09-19 2012-05-23 2012-05-23 2012-06-10 2012-06-10

During another earlier compromise of the same website, visitors were redirected to a Java exploit test.jar (MD5 7d810e3564c4eb95bcb3d11ce191208e). This jar file exploited CVE-2012-0507 and dropped a Poison Ivy payload with the hash (MD5 52aa791a524b61b129344f10b4712f52). This Poison Ivy variant connected to a CnC server at ids.ns01[.]us. The domain ids.ns01[.]us also overlaps with the domain wmi.ns01[.]us on the IP

Domain First Seen Last Seen IP Address
wmi.ns01[.]us wmi.ns01[.]us 2012-07-03 2012-07-03 2012-07-04 2012-07-04
ids.ns01[.]us ids.ns01[.]us 2012-04-23 2012-04-23 2012-05-18 2012-05-18

The Poison Ivy sample referenced above (MD5 fd69793bd63c44bbb22f9c4d46873252) was delivered via an exploit chain that began with a redirect from the Center for European Policy Studies (www.ceps[.]be). In this case, visitors were redirected from www.ceps[.]be to a Java exploit hosted on shop.fujifilm[.]be.

In what is certainly not a coincidence, we also observed www.arce[.]org (one of the sites redirecting to the current Flash exploit) also redirect visitors to the Java exploit on shop.fujifilm[.]be in 2013.



This threat actor clearly seeks out and compromises websites of organizations related to international security policy, defense topics, and other non-profit sociocultural issues. The actor either maintains persistence on these sites for extended periods of time or is able to re-compromise them periodically.

This actor also has early access to a number of zero-day exploits, including Flash and Java, and deploys a variety of malware families on compromised systems. Based on these and other observations, we conclude that this actor has the tradecraft abilities and resources to remain a credible threat in at least the mid-term.

XtremeRAT: Nuisance or Threat?

Rather than building custom malware, many threat actors behind targeted attacks use publicly or commercially available remote access Trojans (RATs). This pre-built malware has all the functionality needed to conduct cyber espionage and is controlled directly by humans, who have the ability to adapt to network defenses. As a result, the threat posed by these RATs should not be underestimated.

However, it is difficult to distinguish and correlate the activity of targeted threat actors based solely on their preference to use particular malware — especially, freely available malware. From an analyst’s perspective, it is unclear whether these actors choose to use this type of malware simply out of convenience or in a deliberate effort to blend in with traditional cybercrime groups, who also use these same tools.

There are numerous RATs available for free and for purchase in online forums, chat rooms and market places on the Internet. Most RATs are easy to use and thus attract novices. They are used for a variety of criminal activity, including “sextortion”. [1] The ubiquity of these RATs makes it difficult to determine if a particular security incident is related to a targeted threat, cybercrime or just a novice “script kiddie” causing a nuisance.

Although publicly available RATs are used by a variety of operators with different intents, the activity of particular threat actors can still be tracked by clustering command and control server information as well as the information that is set by the operators in the builder. These technical indicators, combined with context of an incident (such as the timing, specificity and human activity) allow analysts to assess the targeted or non-targeted nature of the threat.

In this post, we examine a publicly available RAT known as XtremeRAT. This malware has been used in targeted attacks as well as traditional cybercrime. During our investigation we found that the majority of XtremeRAT activity is associated with spam campaigns that typically distribute Zeus variants and other banking-focused malware. Why have these traditional cybercrime operators begun to distribute RATs? This seems odd, considering RATs require manual labor as opposed to automated banking Trojans.

Based on our observations we propose one or more of the following possible explanations:

  1. Smokescreen
    The operations may be part of a targeted attack that seeks to disguise itself and its possible targets, by using spam services to launch the attacks.
  2. Less traditional tools available
    With more crimeware author arrests and/or disappearance of a number of banking Trojan developers, cybercriminals are resorting to using RATs to manually steal data, such as banking and credit card details. [2]
  3. Complicated defenses require more versatile tools
    As many traditional banking and financial institutions have improved their security practices, perhaps attackers have had a much more difficult time developing automation in their Trojans to cover all variations of these defenses; as such, RATs provide more versatility and effectiveness, at the expense of scalability.
  4. Casting a wider net
    After compromising indiscriminate targets, attackers may dig deeper into specific targets of interest and/or sell off the access rights of the victims’ systems and their data to others.

These possible explanations are not mutually exclusive. One or all of them may be factors in explaining this observed activity.


The XtremeRAT was developed by “xtremecoder” and has been available since at least 2010.  Written in Delphi, the code of XtremeRAT is shared amongst several other Delphi RAT projects including SpyNet, CyberGate, and Cerberus. The RAT is available for free; however, the developer charges 350 Euros for the source code.  Unfortunately for xtremecoder, the source code has been leaked online.  The current version is Xtreme 3.6, however, there are a variety of “private” version of this RAT available as well. As such, the official version of this RAT and its many variants are used by a wide variety of actors.

XtremeRAT allows an attacker to:

  • Interact with the victim via a remote shell
  • Upload/download files
  • Interact with the registry
  • Manipulate running processes and services
  • Capture images of the desktop
  • Record from connected devices, such as a webcam or microphone

Moreover, during the build process, the attacker can specify whether to include keylogging and USB infection functions.

Extracting Intelligence

XtremeRAT contains two components: a “client” and a “server”; however, from the attacker’s perspective, these terms have reversed meanings. Specifically, according to the author, the “server” component is the malware that resides on victim endpoints that connect to the “client”, which is operated by the attacker from one or more remote command-and-control (CnC) systems. Due to this confusing and overloaded terminology, we refer to the “server” as a “backdoor” on the victim and the “client” as a remote “controller” operated by the attacker.

XtremeRAT backdoors maintain and reference configuration data that was chosen by the attacker at the time they were built. This data can contain very useful hints to help group attacks and attribute them to actors, similar to what we have previously described in our Poison Ivy whitepaper. [3]

Several versions of XtremeRAT write this configuration data to disk under %APPDATA%\Microsoft\Windows, either directly, or to a directory named after mutex configured by the attacker. When written to disk, the data is RC4 encrypted with a key of either "CYBERGATEPASS" or "CONFIG" for the versions we have analyzed. In both cases, the key is Unicode. The config file has either a “.nfo” or ".cfg" extension depending on the version. XtremeRAT's key scheduling algorithm (KSA) implementation contains a bug wherein it only considers the length of the key string, not including the null bytes between each character, as is found in these Unicode strings. As a result, it only effectively uses the first half of the key. For example, the key “C\x00O\x00N\x00F\x00I\x00G\x00” is 12 bytes long, but the length is calculated as only being 6 bytes long. Because of this, the key that is ultimately used is “C\x00O\x00N\x00”.

The configuration data includes:

  • Name of the installed backdoor file
  • Directory under which the backdoor file is installed
  • Which process it will inject into (if specified)
  • CnC information
  • FTP information for sending stolen keystroke data to
  • Mutex name of the master process,
  • ID and group name which are used by the actors for organizational purposes

Because the decrypted configuration data can be reliably located in memory (with only slight variations in its structure from version to version) and because not all versions of XtremeRAT will write their configuration data to disk, parsing memory dumps of infected systems is often the ideal method for extracting intelligence.

We are releasing python scripts we have developed to gather the configuration details for various versions of XtremeRAT from both process memory dumps and the encrypted configuration file on disk. The scripts are available at

Also included in this toolset is a script that decrypts and prints the contents of the log file created by XtremeRAT containing victim keystroke data. This log file is written to the same directory as the config file and has a “.dat” extension. Curiously, this log file is encrypted with a simple two-byte XOR instead of RC4. Later in this blog, we will share some of the configuration details we have extracted during our subsequent analysis.

XtremeRAT Activity

Using telemetry from the FireEye Dynamic Threat Intelligence (DTI) cloud, we examined 165 XtremeRAT samples from attacks that primarily hit the following sectors:

  • Energy, utilities, and petroleum refining
  • Financial Services
  • High-tech

These incidents include a spectrum of attacks including targeted attacks as well as indiscriminate attacks. Among these XtremeRAT-based attacks, we found that 4 of the 165 samples were used in targeted attacks against the High-Tech sector by threat actors we have called “MoleRats”. [4]

Operation Molerats

In 2012, XtremeRAT was used against a variety of governments as well as Israeli and Palestinian targets in what was known as Operation Molerats (the same attackers have also used variants of the Poison Ivy RAT). [5] Upon executing one particular sample (45142b17abd8a17a5e38305b718f3415), the malware beacons to “” and “”. In this particular case, the attacker used XtremeRAT 2.9 within a self-extracting archive that also presents a decoy document to the victim, where the decoy content appears to have been copied from a website.

[caption id="attachment_4467" align="alignnone" width="849"] Figure 1. Contents of SFX archive containing XtremeRAT
Figure 1. Contents of SFX archive containing XtremeRAT[/caption]

[caption id="attachment_4470" align="alignnone" width="623"]Figure 2. SFX settings inside malicious archive Figure 2. SFX settings inside malicious archive[/caption]

[caption id="attachment_4472" align="alignnone" width="675"]Figure 3. Decoy content presented in malicious archive Figure 3. Decoy content presented in malicious archive[/caption]

Figure 4 shows the controller the attacker uses to interact with systems compromised with XtremeRAT. In this case, it appears the actor used the ID field to record the type of attack delivered (docx) and the Group field was used to record a “campaign code” (IDF), which helps the actor keep track of the set of victims that were attacked during this campaign.

[caption id="attachment_4474" align="alignnone" width="900"]Figure 4. XtremeRAT controller GUI Figure 4. XtremeRAT controller GUI[/caption]

The attacker modified the highlighted information at build time. By default, the XtremeRAT controller sets the ID field as “Server” and Group field as “Servers”, with the default password used to authenticate, connect, and control a compromised endpoint as “1234567890”.

[caption id="attachment_4475" align="alignnone" width="900"]Figure 5. XtremeRAT controller connection settings Figure 5. XtremeRAT controller connection settings[/caption]

In the Figure 5, the attacker specified custom CnC servers and ports and changed the default password to “1411”. The attacker also changed the default process mutex name.

[caption id="attachment_4476" align="alignnone" width="900"]Figure 6. XtremeRat install settings Figure 6. XtremeRat install settings[/caption]

By default, the controller assigns a process mutex name of is “--((Mutex))--” and the attackers changed it to “fdgdfdg”. These indicators along with command and control domain names and the IP addresses that they resolve to can be used to cluster and track this activity over time.

[caption id="attachment_4477" align="alignnone" width="900"]Figure 7. Molerats cluster analysis Figure 7. Molerats cluster analysis[/caption]

This is a cluster of Molerats activity. In addition to using the password “1411”, the attackers are also using the password “12345000”. This is a simple way to track the activity of these actors by using both passive DNS data and configuration information extracted from XtremeRAT.

Spam Activity

The vast majority of XtremeRAT activity clustered around the default password “1234567890” (116 samples). There was overlap between this large cluster and the second largest one which used the password “123456” (12 samples). The activity in these two clusters aligns with indicators observed in Spanish language spam runs. The “123456” cluster also contains spam in the English language, leveraging the recent tragedy in Kenya as a lure. [7]

The Uranio Cluster

In our sample set, we have 28 malware samples that connect to a set of sequentially numbered command and control servers:


The malware is being spammed out and has file names such as:

  • Certificaciones De Pagos Nominas Parafiscales jpg 125420215 58644745574455 .exe
  • Soportes de pagos  certificaciones y documentos mes mayo 30 2013 567888885432235678888888123456.exe
  • Certificaciones De Pago Y Para Fiscales.exe

We extracted the configurations for a sampling of the XtremeRAT samples we came across in this spam run and found the following results:

MD5 ID Group Version Mutex
a6135a6a6346a460792ce2da285778b1 a6135a6a6346a460792ce2da285778b1 ABRIL ABRIL CmetaS3 CmetaS3 3.6 Private 3.6 Private C5AapWKh C5AapWKh
988babfeec5111d45d7d7eddea6daf28 988babfeec5111d45d7d7eddea6daf28 ABRIL ABRIL CmetaS3 CmetaS3 3.6 Private 3.6 Private C5AapWKh C5AapWKh
715f54a077802a0d67e6e7136bcbe340 715f54a077802a0d67e6e7136bcbe340 ABRIL ABRIL CmetaS3 CmetaS3 3.6 Private 3.6 Private C5AapWKh C5AapWKh
167496763aa8d369ff482c4e2ca3da7d 167496763aa8d369ff482c4e2ca3da7d ABRIL ABRIL CmetaS3 CmetaS3 3.6 Private 3.6 Private C5AapWKh C5AapWKh
3f288dfa95d90a3cb4503dc5f3d49c16 3f288dfa95d90a3cb4503dc5f3d49c16 Server Server Cometa4 Cometa4 3.6 Private 3.6 Private 4QtgfoP 4QtgfoP
6a8057322e62c569924ea034508068c9 6a8057322e62c569924ea034508068c9 Server Server Platino4 Platino4 3.6 Private 3.6 Private mbojnXS mbojnXS
37b90673aa83d177767d6289c4b90468 37b90673aa83d177767d6289c4b90468 Server Server Platino4 Platino4 3.6 Private 3.6 Private mbojnXS mbojnXS
98fb1014f6e90290da946fdbca583334 98fb1014f6e90290da946fdbca583334 Server Server Platino8 Platino8 3.6 Private 3.6 Private G7fjZQYAH G7fjZQYAH
5a9547b727f0b4baf9b379328c797005 5a9547b727f0b4baf9b379328c797005 Server Server Platino8 Platino8 3.6 Private 3.6 Private G7fjZQYAH G7fjZQYAH
fb98c8406e316efb0f46024f7c6a6739 fb98c8406e316efb0f46024f7c6a6739 Server Server Platino9 Platino9 3.6 Private 3.6 Private kUHwdc8Y kUHwdc8Y
64f6f819a029956b8aeafb729512b460 64f6f819a029956b8aeafb729512b460 Server Server Uranio Uranio 3.6 Private 3.6 Private eYwJ6QX0i eYwJ6QX0i
a4c47256a7159f9556375c603647f4c2 a4c47256a7159f9556375c603647f4c2 Mayo Mayo Uranio2011 Uranio2011 3.6 Private 3.6 Private 0pg6ooH 0pg6ooH
62d6e190dcc23e838e11f449c8f9b723 62d6e190dcc23e838e11f449c8f9b723 Mayo Mayo Uranio2011 Uranio2011 3.6 Private 3.6 Private 0pg6ooH 0pg6ooH
d5d99497ebb72f574c9429ecd388a019 d5d99497ebb72f574c9429ecd388a019 Mayo Mayo Uranio2011 Uranio2011 3.6 Private 3.6 Private 0pg6ooH 0pg6ooH
3a9237deaf25851f2511e355f8c506d7 3a9237deaf25851f2511e355f8c506d7 Server Server Uranio3 Uranio3 QwcgY0a QwcgY0a
c5e95336d52f94772cbdb2a37cef1d33 c5e95336d52f94772cbdb2a37cef1d33 Server Server Uranio3 Uranio3 QwcgY0a QwcgY0a
0ea60a5d4c8c629c98726cd3985b63c8 0ea60a5d4c8c629c98726cd3985b63c8 Server Server Uranio4 Uranio4 xjUfrQHP6Xy xjUfrQHP6Xy
41889ca19c18ac59d227590eeb1da214 41889ca19c18ac59d227590eeb1da214 Server Server Uranio4 Uranio4 xjUfrQHP6Xy xjUfrQHP6Xy
90e11bdbc380c88244bb0152f1142aff 90e11bdbc380c88244bb0152f1142aff Server Server Uranio4 Uranio4 xjUfrQHP6Xy xjUfrQHP6Xy
c1ad4445f1064195de1d6756950e2ae9 c1ad4445f1064195de1d6756950e2ae9 Server Server Uranio5 Uranio5 3.6 Private 3.6 Private R9lmAhUK R9lmAhUK
e5b781ec77472d8d4b3b4a4d2faf5761 e5b781ec77472d8d4b3b4a4d2faf5761 Server Server Uranio6 Uranio6 3.6 Private 3.6 Private KdXTsbjJ6 KdXTsbjJ6
a921aa35deedf09fabee767824fd8f7e a921aa35deedf09fabee767824fd8f7e Server Server Uranio6 Uranio6 3.6 Private 3.6 Private KdXTsbjJ6 KdXTsbjJ6
9a2e510de8a515c9b73efdf3b141f6c2 9a2e510de8a515c9b73efdf3b141f6c2 CC CC Uranio7 Uranio7 3.6 Private 3.6 Private UBt3eQq0 UBt3eQq0
a6b862f636f625af2abcf5d2edb8aca2 a6b862f636f625af2abcf5d2edb8aca2 CC CC Uranio7 Uranio7 3.6 Private 3.6 Private iodjmGyP3 iodjmGyP3
0327859be30fe6a559f28af0f4f603fe 0327859be30fe6a559f28af0f4f603fe CC CC Uranio7 Uranio7 3.6 Private 3.6 Private UBt3eQq0 UBt3eQq0

“Server”, “Servers”, and “--((Mutex))--” are the defaults in the XtremeRAT controller for ID, Group, and Mutex respectively. The random mutex names in the table above can be generated by double-clicking in the Mutex field within the controller. In most cases, the number at the end of the group label is the same number used at the end of the subdomain for the CnC. In the case of “Uranio2011”, the subdomain is simply “uranio” and 2011 represents the port number used to communicate with the CnC infrastructure.

[caption id="attachment_4478" align="alignnone" width="900"]Figure 8. Portugese version of XtremeRAT controller Figure 8. Portugese version of XtremeRAT controller[/caption]

Uranio Sinkhole Analysis

We sinkholed between November 22, 2013 and January 6, 2014. During that time, 12000 unique IPs connected to the Recall, that this number reflects only one of many command and control servers. [8]

However, estimating the number of victims this way is difficult due to DHCP lease times, which inflate the numbers, and NAT connections, which deflate the numbers. [9] As such, we counted the unique IP addresses that connected to the sinkhole on each day. The highest number of connections to this sinkhole was on Dec. 3, 2013 with 2003 connections and the lowest was Jan. 6, 2014 with 109 connections. The average number of unique IP addresses that connected to the sinkhole per day was 657.

While these IP addresses were in ranges assigned to 40 distinct countries, the vast majority of the connections to the sinkhole (92.7 percent) were from Colombia. Argentina was a distant second with 1.22 percent, followed by Venezuela with 1.02 percent, Egypt with 0.95 percent and the U.S. with 0.9 percent.


Determining the activity of targeted threat actors is difficult. Most of the activity associated with publicly available RATs is traditional cybercrime associated with spam runs, banking Trojans and malware distribution. However, useful indicators can be extracted from these ubiquitous RATs to track the activities of targeted threat actors (as well as cybercrime).




2. The group behind the Carberp banking Trojan were arrested, the author of Zeus retired,, the author of SpyEye went into hiding and was recently arrested, FBI and Microsoft have gone after Citadel which is not off the market and an overview of the “Big 4” banking Trojans

3. /content/dam/legacy/resources/pdfs/fireeye-poison-ivy-report.pdf





8. We filtered out all non-XtremeRAT traffic and ensured that each of the 12000 IPs attempted to make an XtremeRAT connection.


Forbes Data Breach Impacts Over 1 Millions Accounts

Today The Syrian Electronic army via their Twitter account @Official_SEA16 announced that they have leaked the Forbes WordPress user database not long after it was announced that they had managed to hack their website.

Eduard Kovacs from Softpedia has stated that the leak has a been uploaded to an IP address ( which was also used last year in a defacement on as well.

This breach is quite substantial and includes 1,056,986 unique emails addresses and accounts with 844 of them being government (.GOV) and 14,572 educational accounts (.EDU). In addition, the dump contains credentials from a Forbes wp_users database and contains 564 based emails including administrators accounts.

Forbes has posted a statement to their Facebook page regarding the breach urging all users to reset their password on the Forbes network and on any other sites they may have used the same credentials.

Security message: was targeted in a digital attack and our publishing platform was compromised. Users’ email addresses may have been exposed. The passwords were encrypted, but as a precaution, we strongly encourage Forbes readers and contributors to change their passwords on our system, and encourage them to change them on other websites if they use the same password elsewhere. We have notified law enforcement. We take this matter very seriously and apologize to the members of our community for this breach.

As Eduard points out that although the passwords are encrypted, the email addresses are still very useful. In addition, it is not clear the type of the encryption used and there is still a potential that they can easily be decrypted. It is clear that this breach has the potential to pose a significant risk for many of their users.

Breakout of just a few type of email domains:
844 .GOV
14,572 .EDU
185, 271

Plasma HTTP



Online bot:

offline bots:




Yeah take this lame article to second degree, i just talk about Plasma because i've promised to write something today on irc.

I'm not dead but there nothing interesting to review for the moment, only crappy bots
That also one of the reason i haven't talked of JackPos and all the rest.
I have some interesting things but it's too sensitive for the moment and when it's not the reason, it's due to people who request me to don't talk of a subject because they want to cover it 'first' for their company but who finaly write nothing, so i still wait (you know who you are)
e.g: ZeusVM, i wanted to talk about the weird version who appeared since some months now
a version who download from sites (on ssl and fastflux) a picture with a config embedded inside.. but well, fuck it now.
As i already told on a previous article, i may appear inactive but i'm not so inactive.
I've recently do this, i still continue to posts malwares, break things but without necessarily talking about it or just briefly like for jackTrash, and today: PlasmaTrash, and iTrashing.
I still continue to do trashy video, show trashy things on my hackerspace and talk about trashs on irc. (yeah that a lot of trash)
So for the moment, i just wait and see...

Operation SnowMan: DeputyDog Actor Compromises US Veterans of Foreign Wars Website

On February 11, FireEye identified a zero-day exploit (CVE-2014-0322)  being served up from the U.S. Veterans of Foreign Wars’ website (vfw[.]org). We believe the attack is a strategic Web compromise targeting American military personnel amid a paralyzing snowstorm at the U.S. Capitol in the days leading up to the Presidents Day holiday weekend. Based on infrastructure overlaps and tradecraft similarities, we believe the actors behind this campaign are associated with two previously identified campaigns (Operation DeputyDog and Operation Ephemeral Hydra).

This blog post examines the vulnerability and associated attacks, which we have dubbed “Operation SnowMan."

Exploit/Delivery analysis

After compromising the VFW website, the attackers added an iframe into the beginning of the website’s HTML code that loads the attacker’s page in the background. The attacker’s HTML/JavaScript page runs a Flash object, which orchestrates the remainder of the exploit. The exploit includes calling back to the IE 10 vulnerability trigger, which is embedded in the JavaScript.  Specifically, visitors to the VFW website were silently redirected through an iframe to the exploit at www.[REDACTED].com/Data/img/img.html.


The exploit targets IE 10 with Adobe Flash. It aborts exploitation if the user is browsing with a different version of IE or has installed Microsoft’s Experience Mitigation Toolkit (EMET). So installing EMET or updating to IE 11 prevents this exploit from functioning.

Vulnerability analysis

The vulnerability is a previously unknown use-after-free bug in Microsoft Internet Explorer 10. The vulnerability allows the attacker to modify one byte of memory at an arbitrary address. The attacker uses the vulnerability to do the following:

  • Gain access to memory from Flash ActionScript, bypassing address space layout randomization (ASLR)
  • Pivot to a return-oriented programing (ROP) exploit technique to bypass data execution prevention (DEP)

EMET detection

The attacker uses the Microsoft.XMLDOM ActiveX control to load a one-line XML string containing a file path to the EMET DLL. Then the exploit code parses the error resulting from the XML load order to determine whether the load failed because the EMET DLL is not present.  The exploit proceeds only if this check determines that the EMET DLL is not present.

ASLR bypass

Because the vulnerability allows attackers to modify memory to an arbitrary address, the attacker can use it to bypass ASLR. For example, the attacker corrupts a Flash Vector object and then accesses the corrupted object from within Flash to access memory. We have discussed this technique and other ASLR bypass approaches in our blog. One minor difference between the previous approaches and this attack is the heap spray address, which was changed to 0x1a1b2000 in this exploit.

Code execution

Once the attacker’s code has full memory access through the corrupted Flash Vector object, the code searches through loaded libraries gadgets by machine code. The attacker then overwrites the vftable pointer of a flash.Media.Sound() object in memory to point to the pivot and begin ROP. After successful exploitation, the code repairs the corrupted Flash Vector and flash.Media.Sound to continue execution.

Shellcode analysis

Subsequently, the malicious Flash code downloads a file containing the dropped malware payload. The beginning of the file is a JPG image; the end of the file (offset 36321) is the payload, encoded with an XOR key of 0x95. The attacker appends the payload to the shellcode before pivoting to code control. Then, when the shellcode is executed, the malware creates files “sqlrenew.txt” and “stream.exe”. The tail of the image file is decoded, and written to these files. “sqlrenew.txt” is then executed with the LoadLibraryA Windows API call.

ZxShell payload analysis

As documented above, this exploit dropped an XOR (0x95) payload that executed a ZxShell backdoor (MD5: 8455bbb9a210ce603a1b646b0d951bce). The compile date of the payload was 2014-02-11, and the last modified date of the exploit code was also 2014-02-11. This suggests that this instantiation of the exploit was very recent and was deployed for this specific strategic Web compromise of the Veterans of Foreign Wars website. A possible objective in the SnowMan attack is targeting military service members to steal military intelligence. In addition to retirees, active military personnel use the VFW website. It is probably no coincidence that Monday, Feb. 17, is a U.S. holiday, and much of the U.S. Capitol shut down Thursday amid a severe winter storm.

The ZxShell backdoor is a widely used and publicly available tool used by multiple threat actors linked to cyber espionage operations. This particular variant called back to a command and control server located at newss[.]effers[.]com. This domain currently resolves to The domain info[.]flnet[.]org also resolved to this IP address on 2014-02-12.

Infrastructure analysis

The info[.]flnet[.]org domain overlaps with icybin[.]flnet[.]org and book[.]flnet[.]org via the previous resolutions to the following IP addresses:

First Seen Last Seen CnC Domain IP
2013-08-31 2013-08-31 2013-08-31 2013-08-31 icybin.flnet[.]org icybin.flnet[.]org
2013-05-02 2013-05-02 2013-08-02 2013-08-02 info.flnet[.]org info.flnet[.]org
2013-08-02 2013-08-02 2013-08-02 2013-08-02 book.flnet[.]org book.flnet[.]org
2013-08-10 2013-08-10 2013-08-10 2013-08-10 info.flnet[.]org info.flnet[.]org
2013-07-15 2013-07-15 2013-07-15 2013-07-15 icybin.flnet[.]org icybin.flnet[.]org
2014-01-02 2014-01-02 2014-01-02 2014-01-02 book.flnet[.]org book.flnet[.]org
2013-12-03 2013-12-03 2014-01-02 2014-01-02 info.flnet[.]org info.flnet[.]org

We previously observed Gh0stRat samples with the custom packet flag “HTTPS” calling back to book[.]flnet[.]org and icybin[.]flnet[.]org. The threat actor responsible for Operation DeputyDog also used the “HTTPS” version of the Gh0st. We also observed another “HTTPS” Gh0st variant connecting to a related command and control server at me[.]scieron[.]com.

MD5 Hash CnC Domain
758886e58f9ea2ff22b57cbbb015166e 758886e58f9ea2ff22b57cbbb015166e book.flnet[.]org book.flnet[.]org
0294f9280491f85d898ebe471f0fb58e 0294f9280491f85d898ebe471f0fb58e icybin.flnet[.]org icybin.flnet[.]org
9d20566a327076b7152bbf9ed20292c4 9d20566a327076b7152bbf9ed20292c4 me.scieron[.]com me.scieron[.]com

The me[.]scieron[.]com domain previously resolved to The book[.]flnet[.]org domain also resolved to another IP in the same subnet Specifically, book[.]flnet[.]org previously resolved to

Others domain seen resolving to this same /24 subnet were dll[.]freshdns[.]org, ali[.]blankchair[.]com, and cht[.]blankchair[.]com. The domain dll[.]freshdns[.]org resolved to Both ali[.]blankchair[.]com and cht[.]blankchair[.]com resolved to

First Seen Last Seen CnC Domain IP
2012-11-12 2012-11-12 2012-11-28 2012-11-28 me.scieron[.]com me.scieron[.]com
2012-04-09 2012-04-09 2012-10-24 2012-10-24 cht.blankchair[.]com cht.blankchair[.]com
2012-04-09 2012-04-09 2012-09-18 2012-09-18 ali.blankchair[.]com ali.blankchair[.]com
2012-11-08 2012-11-08 2012-11-25 2012-11-25 dll.freshdns[.]org dll.freshdns[.]org
2012-11-23 2012-11-23 2012-11-27 2012-11-27 rt.blankchair[.]com rt.blankchair[.]com
2012-05-29 2012-05-29 2012-6-28 2012-6-28 book.flnet[.]org book.flnet[.]org

A number of other related domains resolve to these IPs and other IPs also in this /24 subnet. For the purposes of this blog, we’ve chosen to focus on those domains and IP that relate to the previously discussed DeputyDog and Ephemeral Hydra campaigns.

You may recall that dll[.]freshdns[.]org, ali[.]blankchair[.]com and cht[.]blankchair[.]com were all linked to both Operation DeputyDog and Operation Ephemeral Hydra. Figure 1 illustrates the infrastructure overlaps and connections we observed between the strategic Web compromise campaign leveraging the VFW’s website, the DeputyDog, and the Ephemeral Hydra operations.

Figure 1: Ties between Operation SnowMan, DeputyDog, and Ephemeral Hydra

Links to DeputyDog and Ephemeral Hydra

Other tradecraft similarities between the actor(s) responsible for this campaign and the actor(s) responsible for the DeputyDog/Ephemeral Hydra campaigns include:

  • The use of zero-day exploits to deliver a remote access Trojan (RAT)
  • The use of strategic web compromise as a vector to distribute remote access Trojans
  • The use of a simple single-byte XOR encoded (0x95) payload obfuscated with a .jpg extension
  • The use of Gh0stRat with the “HTTPS” packet flag
  • The use of related command-and-control (CnC) infrastructure during the similar time frames

We observed many similarities from the exploitation side as well. At a high level, this attack and the CVE-2013-3163 attack both leveraged a Flash file that orchestrated the exploit, and would call back into IE JavaScript to trigger an IE flaw. The code within the Flash files from each attack are extremely similar. They build ROP chains and shellcode the same way, both choose to corrupt a Flash Vector object, have some identical functions with common typos, and even share the same name.


These actors have previously targeted a number of different industries, including:

  • U.S. government entities
  • Japanese firms
  • Defense industrial base (DIB) companies
  • Law firms
  • Information technology (IT) companies
  • Mining companies
  • Non-governmental organizations (NGOs)

The proven ability to successfully deploy a number of different private and public RATs using zero-day exploits against high-profile targets likely indicates that this actor(s) will continue to operate in the mid to long-term.

Safer Internet Day: 4 Things You Might Not Realise Your Webfilter Can Do

Since it's Safer Internet Day today, I thought i'd use it as an excuse to write a blog post. Regular readers will know I don't usually need an excuse, but I always feel better if I do.

Yesterday, I was talking to our Content Filter team about a post on the popular Edugeek forum, where someone asked "is it possible to block adult content in BBC iPlayer?". Well, with the right web filter, the answer is "yes", but how many people think to even ask the question? Certainly we hadn't thought much about formalising the answer. So I'm going to put together a list of things your web filter should be capable of, but you might not have realised...

1. Blocking adult content on "TV catch up" services like iPlayer. With use of the service soaring, it's important that any use in education is complemented with the right safeguards. We don't need students in class seeing things their parents wouldn't want them watching at home. There's a new section of the Smoothwall blocklist now which will deal with anything on iPlayer that the BBC deem unsuitable for minors.

2. Making Facebook and Twitter "Read Only". These social networks are great fun, and it can be useful to relax the rules a bit to prevent students swarming for 4G. A read-only approach can help reduce the incidence of cyber-bullying and keep users more focused.

3. Stripping the comments out of YouTube. YouTube is a wonderful resource, and the majority of video is pretty safe (use Youtube for Schools if you want to tie that down further — your filter can help you there too). The comments on videos, however, are often at best puerile and at worst downright offensive. Strip out the junk, and leave the learning tool - win win!

4. Busting Google searches back down to HTTP and forcing SafeSearch. Everybody appreciates a secure service, but when Google moved their search engine to HTTPS secure traffic by default, they alienated the education community. With SSL traffic it is much harder to vet search terms, log accesses in detain, and importantly force SafeSearch. Google give you DNS trickery to force the site back into plain HTTP - but that's a pain to implement, especially on a Windows DNS server. Use your web filter to rewrite the requests, and have the best of both.

Working With the Darkleech Bitly Data

Data Driven Security took the time to analyze the raw data that I published in my recent post on Sucuri blog about how I used Bitly data to understand the scale of the Darkleech infection.

In their article, they have a few questions about data formats, meaning of certain fields and some inconsistencies, so I’ll try to answer their questions here and explain how I worked with the data.

So I needed to get information about all the links of the “grantdad” bitly account.

I checked the API and somehow missed the “link_history” API request (it was the first time I worked with the bitly API), so I decided to screenscrape the web pages where bitly listed the links creaded by grantdad. 1,000 pages with 10 links on each. Since pages didn’t contain all the information I needed I only collected the short links so that I could use them later in API calls to get more detailed information about each of them.

As you can see I was limited with the 10,000 links that bitly made available via their web interface. Not sure if I could get more links via that link_history API. Right now it returns “ACCOUNT_SUSPENDED” and when it was not suspended, API calls for known links beyond those 10,000 produced various errors.

When I compiled my list of 10,000 links I used the following API calls to get information about each of the links:

Referring domains

API:link/referring_domains — for each link, it returned a list of domains referring traffic to this link (in our case sites, containing the iframes) along with the number of clicks from each domain. This helped me compile this list of iframe loads per domain: Then I tried to resolve each of the domain names and created this list of infected domains per IP address:
I also used this API call to get number of iframe loads for each bitly link.


API:link/info – this gave me timestamps of the links and their long URLs (the rest information was not interesting for my research). Unfortunately, this particular API call is poorly documented so I can only guess what this timestamp mean. It is actually called “indexed“. But I guess it’s the time when the link was created. It is definiteley not the time of the first click because there were no registered clicks for many of the links. As a result, I compiled these datasets: ,
which contain tab separated values of “bitly link id”, “timestamp”, “# of clicks/iframe loads”, and “long URL”.

At that point, I already had the number of iframe loads from the previous step (“link/referring_domains“). Then, for readability, I converted the numeric timestamp using this Python function datetime.datetime.fromtimestamp(). However, you can notice that the second dataset (for January 28th) has a different date format. Instead of “2014-01-25 19:10:07” it uses “Jan 28 23:10:19“. Why? Because of Because it doesn’t allow unregistered users to post more than 500Kb of data (I deliberately post such data as a guest). Removing the year from the date allowed me to save 4 bytes on each row and fit the dataset in 500Kb.

Actually this 500Kb limit is the reason why I have separate pastebins for each date and only specify bitly ids instead of the full bitly links.


And finally, API:link/countries – for each link, it returned a list of countries referring traffic to this link along with the number of clicks from those countries. This helped me compile this list of iframe loads per country

The last dataset Feb 4-5

When I wrote my blogpost on February 5th, I noticed that there were new links available on the grantdad acount page. I began to browse pages of his links and figured that most of the links were the same (Jan 25 and 28) but around 1,700 of them were new (late February 4th and the beginning of February 5th). I immediately repeated the same procedure that included screenscraping, and 3 API calls for each new bitly link. After that I created this new dataset and updated the rest datasets (domains, countries, etc).

Some more details

If you check the total numbers in these two datasets (domains) and (countries) you’ll see the different in total number of iframe loads: 87152 and 87269. I don’t know why. I used the same links just different API calls (referring_domains and countries) and the totals are supposed to be the same. I didn’t save the “per link” data so can’t tell exactly whether it was my error or the bitly API produces slightly inconsistent results. Anyway, the difference is neglectable for my calculations and doesn’t affect the estimations (given that I tried to underestimate when in doubt ).

I didn’t check for duplicates that guys from Data Driven security found in my datasets. They must have to do with my screenscraper and the way that displays links in user accounts. The total number of scraped links matched the number of links that Bitly reported for the user. The extra 121 clicks that these duplicates are responsible for are so close to the 117 difference that I mentioned above so I wonder if these numbers somehow connected? Anyway, this shouldn’t affect the accuracy of the estimates either.

Building the geo distribution map

For the map, I used the Geochart from Google visualization. Since the difference in numbers of clicks for the top 3 countries and the lower half of the list was 3 orders of magnitude, I had to re-scale the data so that we could still see the difference between countries with 50 iframe loads and 2 iframe loads.. I used a square of a natural logarithm for that

Math.pow( Math.round( Math.log(i)), 2)

This gave me a nice distribution from 0 to 100 and the below map.

Darkleech iFrame load geo distribution

IFrame Load Geo Distribution

Speculation on the link generation

After checking the link creation per minute-of-an-hour distribution, Bob Rudis wondered:

This is either the world’s most inconsistent (or crafty) cron-job or grantdad like to press ↑ + ENTER alot.

I guess, it was neither cron-job nor manual link creation. I think the [bitly] links were created on-demand. So if someone loads a page and Darkleech needs to inject an iframe then it (or rather the server it works with) generates a new bitly link. Given that this malware may lurk on a server, there may be time periods when no malicious code is being injection into any web pages across all the infected servers. At the same time, the bitly links with zero clicks may refer to page loads by various bots (including our own) when the malicious code is injected but the iframe is never loaded. On the other hand, the volume of bitly links with 0 clicks (~35%) suggests that there might really more complex link generation mechanism than a simple “on-demand” approach.

Anyway, that’s great when people double check our data and try to find new interesting patterns there. Make sure to let me know (here or on the Sucuri blog) if you find more patterns and inconsistencies, or have any comments on how the Darkleech works.

Related posts:

IAM for the Third Platform

As more people are using the phrase "third platform", I'll assume it needs no introduction or explanation. The mobile workforce has been mobile for a few years now. And most organizations have moved critical services to cloud-based offerings. It's not a prediction, it's here.

The two big components of the third platform are mobile and cloud. I'll talk about both.


A few months back, I posed the question "Is MAM Identity and Access Management's next big thing?" and since I did, it's become clear to me that the answer is a resounding YES!

Today, I came across a blog entry explaining why Android devices are a security nightmare for companies. The pain is easy to see. OS Updates and Security Patches are slow to arrive and user behavior is, well... questionable. So organizations should be concerned about how their data and applications are being accessed across this sea of devices and applications. As we know, locking down the data is not an option. In the extended enterprise, people need access to data from wherever they are on whatever device they're using. So, the challenge is to control the flow of information and restrict it to proper use.

So, here's a question: is MDM the right approach to controlling access for mobile users? Do you really want to stand up a new technology silo that manages end-user devices? Is that even practical? I think certain technologies live a short life because they quickly get passed over by something new and better (think electric typewriters). MDM is one of those. Although it's still fairly new and good at what it does, I would make the claim that MDM is antiquated technology. In a BYOD world, people don't want to turn control of their devices over to their employers. The age of enterprises controlling devices went out the window with Blackberry's market share.

Containerization is where it's at. With App Containerization, organizations create a secure virtual workspace on mobile devices that enables corporate-approved apps to access, use, edit, and share corporate data while protecting that data from escape to unapproved apps, personal email, OS malware, and other on-device leakage points. For enterprise use-case scenarios, this just makes more sense than MDM. And many of the top MDM vendors have validated the approach by announcing MAM offerings. Still, these solutions maintain a technology silo specific to remote access which doesn't make much sense to me.

As an alternate approach, let's build MAM capabilities directly into the existing Access Management platform. Access Management for the third platform must accommodate for mobile device use-cases. There's no reason to have to manage mobile device access differently than desktop access. It's the same applications, the same data, and the same business policies. User provisioning workflows should accommodate for provisioning mobile apps and data rights just like they've been extended to provision Privileged Account rights. You don't want or need separate silos.


The same can be said, for cloud-hosted apps. Cloud apps are simply part of the extended enterprise and should also be managed via the enterprise Access Management platform.

There's been a lot of buzz in the IAM industry about managing access (and providing SSO) to cloud services. There have even been a number of niche vendors pop-up that provide that as their primary value proposition. But, the core technologies for these stand-alone solutions is nothing new. In most cases, it's basic federation. In some cases, it's ESSO-style form-fill. But there's no magic to delivering SSO to SaaS apps. In fact, it's typically easier than SSO to enterprise apps because SaaS infrastructures are newer and support newer standards and protocols (SAML, REST, etc.)

My Point

I guess if I had to boil this down, I'm really just trying to dispel the myths about mobile and cloud solutions. When you get past the marketing jargon, we're still talking about Access Management and Identity Governance. Some of the new technologies are pretty cool (containerization solves some interesting, complex problems related to BYOD). But in the end, I'd want to manage enterprise access in one place with one platform. One Identity, One Platform. I wouldn't stand up a IDaaS solution just to have SSO to cloud apps. And I wouldn't want to introduce an MDM vendor to control access from mobile devices.

The third platform simply extends the enterprise beyond the firewall. The concept isn't new and the technologies are mostly the same. As more and newer services adopt common protocols, it gets even easier to support increasingly complex use-cases. An API Gateway, for example, allows a mobile app to access legacy mainframe data over REST protocols. And modern Web Access Management (WAM) solutions perform device fingerprinting to increase assurance and reduce risk while delivering an SSO experience. Mobile Security SDKs enable organizations to build their own apps with native security that's integrated with the enterprise WAM solution (this is especially valuable for consumer-facing apps).

And all of this should be delivered on a single platform for Enterprise Access Management. That's third-platform IAM.