Category Archives: Blog

Cyber Security: Three Parts Art, One Part Science

understanding—require a lot of additional explanation. For example, what is a vulnerability assessment? If five cyber professionals are sitting around a table discussing this question, you will end up with seven or eight answers. One will say that a vulnerability assessment is vulnerability scanning only. Another will say an assessment is much bigger than scanning and addresses ethical hacking and internal security testing. Another will say that it is a passive review of policies and controls. All are correct in some form, but the answer really depends on the requirements or criteria you are trying to achieve. And it also depends on the skills and experience of the risk owner, auditor, or assessor. Is your head spinning yet? I know mine is! Hence the “three parts art.”

There is quite a bit of subjectivity in the cyber security business. One auditor will look at evidence and agree you are in compliance; another will say you are not. If you are going to protect sensitive information, do you encrypt it, obfuscate it, or segment it off and place it behind very tight identification and access controls before allowing users to access the data? Yes. As we advise our client base, it is essential that we have all the context necessary to make good risk-based decisions and recommendations.

Let’s talk about Connection’s artistic methodology. We start with a canvas that addresses the core components of cyber security: protection, detection, and reaction. By addressing each of these three pillars in a comprehensive way, we ensure that the full conversation around how people, process, and technology all work together to provide a comprehensive risk strategy is achieved.

Related: Cyber Security is Everyone’s Business


Users understand threat and risk and know what role they play in the protection strategy. For example, if you see something, say something. Don’t let someone surf in behind you through a badge check entry. And don’t think about trying to shut off your end-point anti-virus or firewall.  In today’s remote workforce environment, good employee security awareness, especially related to phishing is essential.

Policy are established, documented, and socialized. For example, personal laptops should never be connected to the corporate network. Also, don’t send sensitive information to your personal email account so you can work from home.

Some examples of the barriers used to deter attackers and breaches are edge security with firewalls, intrusion detection and prevention, sandboxing, and advanced threat detection. Security leaders need to become a student of threat, and deploy the correct technology to protect, detect, and react to threat.


The average mean time to identify an active incident in a network is 197 days. The mean time to contain an incident is 69 days.

Incident response teams need to be identified and trained, and all employees need to be trained on the concept of “if you see something, say something.” Detection is a proactive process.

What happens when an alert occurs? Who sees it? What is the documented process for taking action?

What is in place to ensure you are detecting malicious activity? Is it configured to ignore noise and only alert you of a real event? Will it help you bring that 197-day mean time to detection way down?


What happens when an event occurs? Who responds? How do you recover? Does everyone understand their role? Do you War Game to ensure you are prepared WHEN an incident occurs?

What is the documented process to reduce the Kill Chain—the mean time to detect and contain—from 69 days to 69 minutes? Do you have a Business Continuity and Disaster Recovery Plan to ensure the ability to react to a natural disaster, significant cyber breach such as ransomware, DDoS, or—dare I say it—a pandemic?

What cyber security consoles have been deployed that allow quick access to patch a system, changing firewall rules, adjusting ACLs, or policy setting at an end point, or track a security incident through the triage process?

All of these things are important to create a comprehensive InfoSec Program. The science is the technology that will help you build a layered, in-depth defense approach. The art is how to assess the threat, define and document the risk, and create a strategy that allows you to manage your cyber risk as it applies to your environment, users, systems, applications, data, customers, supply chain, third party support partners, and business process.

More Art – Are You a Risk Avoider or Risk Transference Expert?

A better way to state that is, “Do you avoid all risk responsibility, or do you give your risk responsibility to someone else?” Hint: I don’t believe in risk avoidance or risk transference.

Yes, there is an art to risk management. There is also science if you use, for example, The Carnegie Mellon risk tools. But a good risk owner and manager documents risk, prioritizes it by risk criticality, turns it into a risk register or roadmap plan, remediates what is necessary, and accepts what is reasonable from a business and cyber security perspective. Oh, by the way, those same five cyber security professional we talked about earlier, they have 17 definitions of risk.

As we wrap up this conversation, let’s talk about the importance of selecting a risk framework. It’s kind of like going to a baseball game and recognizing the program helps you know the players and the stats. What framework will you pick? Do you paint in watercolors or oils? Are you a National Institute of Standards (NIST) artist, an Internal Standards Organization artist, or have you developed your own framework like the Nardone puzzle chart? I developed this several years ago when I was the CTO/CSO of the Commonwealth of Massachusetts. It has been artistically enhanced over the years to incorporate more security components, but it is loosely coupled on the NIST 800-53 and ISO 27001 standards.

When it comes to selecting a security framework as a CISO, I lean towards the NIST Cyber Security Framework (CSF) pictured below. This framework is comprehensive and provides a scoring model that allows risk owners to measure and target what risk level they believe they need to achieve based on their business model, threat profile, and risk tolerance. It has five functional focus areas. The ISO 27001 framework is also a very solid and frequently used model. Both of these frameworks can result in a Certificate of Attestation demonstrating adherence to the standard. Many commercial corporations do an annual ISO 27001 assessment for that very reason. More and more are leaning towards the NIST CSF, especially commercial corporations doing work with the government. Keep in mind that frameworks mature, and compliance requirements change.  For example, if you are a commercial corporation doing business with the federal government, you will need to comply with the new Cyber Security Model Certification (CMMC) soon to continue doing business with the government.

As I reflect upon my 40 years as a cyber security professional, I think of the many instances where the basic tenets of cyber security—those we think have common understanding—require a lot of additional explanation. For example, what is a vulnerability assessment? If five cyber professionals are sitting around a table discussing this question, you will end up with seven or eight answers. One will say that a vulnerability assessment is vulnerability scanning only. Another will say an assessment is much bigger than scanning and addresses ethical hacking and internal security testing. Another will say that it is a passive review of policies and controls. All are correct in some form, but the answer really depends on the requirements or criteria you are trying to achieve. And it also depends on the skills and experience of the risk owner, auditor, or assessor. Is your head spinning yet? I know mine is! Hence the “three parts art.”

The post Cyber Security: Three Parts Art, One Part Science appeared first on Connected.

Best Practices for Keeping Tabs on Your Apps

Let’s start this conversation out with the definition of device. The list of what constitutes one is growing. For now, let’s say that you have a home computer (desktop, laptop, or both), work computer (desktop, laptop, or both), home tablet, work tablet, personal smartphone, and work smartphone. This is a pretty extensive list of devices that an adversary could use to attack you professionally and personally. But what about your Amazon Alexa or gadgets, smart toys, and smart clocks? What about Google Assistant or Microsoft Cortana? Do you also have a SmartTV? What about NEST, Wink, WeMo, SensorPush, Neurio, ecobee4, Philips Hue, Smart Lock, GarageMate? Hoo boy! The list of connected devices goes on and on.

Are all of these devices safe to use? Well, the simple answer is no—unless you specifically paid attention to its security. Also, for your smart devices that work via voice control, do you know who might be listening on the other end? To make things worse, many of these devices are also used in the corporate world, because they are easy to deploy, and are very affordable.

What about applications? Did the developer that created the application you are using ensure they used good secure coding techniques? Or is there a likelihood they introduced a flaw in their code? Are the servers for the application you are running in the cloud secure? Is the data you are storing on these cloud systems protected from unauthorized access?

All really good questions we rarely ask ourselves—at least before we use the latest and coolest applications available. We all make risk-based decisions every day, but do we ever ensure we have all the data before we make that risk-based decision?

What Can You Do?

Start by doing whatever homework and research you can. Make sure you understand the social engineering methods that the malicious actors are currently using. Unsolicited phone calls from a government agency (like the IRS), a public utility, or even Microsoft or Apple are not legitimate. No you don’t owe back taxes, no your computer has not been hacked, no you don’t need to give out sensitive personal information to your power company over the phone.

How Can You Choose Safe Applications?

Simply Google “Is this <name of application> secure?” Never install an application that you don’t feel you can trust. Using an application is all about risk management. Make sure you understand the potential risk to device and data compromise, prior to choosing to use it.

How Can You Better Secure Your Home Network?

  1. Upon installation of any device, immediately change the login and password. These are often stored in the configuration files that come with the product, therefore are easy to look up.
  2. Change the login and password on your home Wi-Fi router frequently.
  3. Ensure the software for anything that connects is up to date.
  4. Make sure you have a clear sense of where your sensitive data is stored—and how it is protected. Is it adequately protected—or, better yet, encrypted?
  5. When in doubt, don’t connect an IoT device to the Internet.

Lastly, look at some solutions that can be added to your home Wi-Fi network, that provide additional layers of protection and detection against IoT and other advanced attacks. F-Secure Sense Gadget is one such solution, as is Luma smart Wi-Fi router, Dojo, and CUJO. Dojo, for example, monitors all incoming and outgoing traffic and performs analysis looking for malicious traffic. With known weaknesses in IoT and home networks in general, solutions like the above are a good investment.

Don’t Give Hackers Easy Access

Not long ago, a casino in the Northeast had a fish tank in their lobby. To make management of the fish tank easier, they installed an IoT-enabled thermostatic control to set and monitor water temperature in the tank. The thermostatic control was connected to their internal network, as well as IoT-enabled to allow easy access from anywhere on the Internet. The device was breached from the Internet by malicious actors, and the internal network was penetrated, allowing the hackers to steal information from a high-roller database before devices monitoring the network were able to identify the unauthorized data leaving the network and shut it down. A classic case of what can happen without the right due diligence.

Try and follow this motto. Just because you can, does not mean you should. The latest shiny IT gadget that will make you seem cool, or potentially make some portion of your life easier to manage, should be evaluated thoroughly for security weaknesses, before you turn it on and open it up to the world. Make that good risk-based decision. Not many of us would consider doing this: “Hey Alexa, open up my desktop computer so that all my sensitive data is opened for all the world to see.” Or would we?

The post Best Practices for Keeping Tabs on Your Apps appeared first on Connected.

Businesses Beware: Top 5 Cyber Security Risks

Hackers are working hard to find new ways to get your data. It’s not surprising that cyber security risk is top of mind for every risk owner, in every industry. As the frequency and complexity of malicious attacks persistently grows, every company should recognize that they are susceptible to an attack at any time—whether it comes as an external focused attack, or a social engineering attack. Let’s take a look at the top 5 risks that every risk owner should be preparing for:

  1. Your Own Users. It is commonly known, in the security industry, that people are the weakest link in the security chain. Despite whatever protections you put in place from a technology or process/policy point of view, human error can cause an incident or a breach. Strong security awareness training is imperative, as well as very effective documented policies and procedures. Users should also be “audited” to ensure they understand and acknowledge their role in policy adherence. One area that is often overlooked is the creation of a safe environment, where a user can connect with a security expert on any issue they believe could be a problem, at any time. Your security team should encourage users to reach out. This creates an environment where users are encouraged to be part of your company’s detection and response. To quote the Homeland Security announcements you frequently hear in airports, “If you see something, say something!” The biggest threat to a user is social engineering—the act of coercing a user to do something that would expose sensitive information or a sensitive system.
  2. Phishing. Phishing ranks number three in both the 2018 Verizon Data Breach Investigation Report Top 20 action varieties in incidents and Top 20 action varieties in breaches. These statistics can be somewhat misleading. For example, the first item on the Top 20 action varieties in breaches list is the use of stolen credentials; number four is privilege abuse. What better way to execute both of those attacks than with a phishing scam. Phishing coerces a user through email to either click on a link, disguised as a legitimate business URL, or open an attachment that is disguised as a legitimate business document. When the user executes or opens either, bad things happen. Malware is downloaded on the system, or connectivity to a Command and Control server on the Internet is established. All of this is done using standard network communication and protocols, so the eco-system is none the wiser—unless sophisticated behavioral or AI capabilities are in place. What is the best form of defense here? 1.) Do not run your user systems with administrative rights. This allows any malicious code to execute at root level privilege, and 2.) Train, train, and re-train your users to recognize a phishing email, or more importantly, recognize an email that could be a phishing scam. Then ask the right security resources for help. The best mechanism for training is to run safe targeted phishing campaigns to verify user awareness either internally or with a third-party partner like Connection.
  3. Ignoring Security Patches. One of the most important functions any IT or IT Security Organization can perform is to establish a consistent and complete vulnerability management program. This includes the following key functions:
    • Select and manage a vulnerability scanning system to proactively test for flaws in IT systems and applications.
    • Create and manage a patch management program to guard against vulnerabilities.
    • Create a process to ensure patching is completed.
  4. Partners. Companies spend a lot of time and energy on Information Security Programs to address external and internal infrastructures, exposed Web services, applications and services, policies, controls, user awareness, and behavior. But they ignore a significant attack vector, which is through a partner channel—whether it be a data center support provider or a supply chain partner. We know that high-profile breaches have been executed through third partner channels, Target being the most prominent.The Target breach was a classic supply chain attack, where they were compromised through one of their HVAC vendors. Company policies and controls must extend to all third-party partners that have electronic or physical access to the environment. Ensure your Information Security Program includes all third partner partners or supply chain sources that connect or visit your enterprise. The NIST Cyber Security Framework has a great assessment strategy, where you can evaluate your susceptibility to this often-overlooked risk.
  5. Data Security. In this day and age, data is the new currency. Malicious actors are scouring the Internet and Internet-exposed corporations to look for data that will make them money. The table below from the 2018 Ponemon Institute 2018 Cost of a Data Breach Report shows the cost of a company for a single record data breach.
Cost for a Single Record Data Breach

The Bottom Line

You can see that healthcare continues to be the most lucrative target for data theft, with $408 per record lost. Finance is nearly half this cost. Of course, we know the reason why this is so. A healthcare record has a tremendous amount of personal information, enabling the sale of more sensitive data elements, and in many cases, can be used to build bullet-proof identities for identity theft. The cost of a breach in the US, regardless of industry, averages $7.9 million per event. The cost of a single lost record in the US is $258.

I Can’t Stress It Enough

Data security should be the #1 priority for businesses of all sizes. To build a data protection strategy, your business needs to:

  • Define and document data security requirements
  • Classify and document sensitive data
  • Analyze security of data at rest, in process, and in motion
  • Pay attention to sensitive data like PII, ePHI, EMR, financial accounts, proprietary assets, and more
  • Identify and document data security risks and gaps
  • Execute a remediation strategy

Because it’s a difficult issue, many corporations do not address data security. Unless your business designed classification and data controls from day one, you are already well behind the power curve. Users create and have access to huge amounts of data, and data can exist anywhere—on premises, user laptops, mobile devices, and in the cloud. Data is the common denominator for security. It is the key thing that malicious actors want access to. It’s essential to heed this warning: Do Not Ignore Data Security! You must absolutely create a data security protection program, and implement the proper policies and controls to protect your most important crown jewels.

Cyber criminals are endlessly creative in finding new ways to access sensitive data. It is critical for companies to approach security seriously, with a dynamic program that takes multiple access points into account. While it may seem to be an added expense, the cost of doing nothing could be exponentially higher. So whether it’s working with your internal IT team, utilizing external consultants, or a mix of both, take steps now to assess your current situation and protect your business against a cyber attack. Stay on top of quickly evolving cyber threats. Reach out to one of our security experts today to close your businesses cyber security exposure gap!

The post Businesses Beware: Top 5 Cyber Security Risks appeared first on Connected.

Be a Conscientious Risk Manager

Whether you are a CIO or CISO in the Federal, State or Local, Education, or Commercial Business areas, you are all faced the with same challenge, whether you accept it or not. In the security risk management world, if the malicious actor wants into your network, they will figure out a way to get in. You of course still need to build a comprehensive risk governance and management plan, but that plan must be built on the premise of how you will respond, when the breach occurs.

Having spent 38 years in Information Security, the one constant that I see, is that the individuals who make it their business to steal or disrupt your data, are better funded, better trained, and have unlimited hours to execute their trade. What we hope to achieve is being a half-step behind them at worst case. There is no way to stay in step, and a step ahead is out of the question.

So what does this really mean to the conscientious risk manager. Create a strategy whereby you frequently identify the threat, and measure the risk against that threat in your as-built infrastructure. Test frequently, outside and inside, using he same tools and techniques the malicious actors use. Test user security awareness, as we know it only takes one click of a phishing email malicious link, to potentially bring down and entire enterprise. Measure, document, prioritize, and build a risk roadmap strategy to keep risk mitigation focus on those most critical exploitable areas.

Three Top Security Imperatives
Keep in mind that your top three security imperatives are: Reducing your threat exposure, enhancing your response and recovery times, and increasing security visibility. What does security visibility mean, implementing the people, process, and technology in key security areas, to give you a fighting chance to detect, and react to malicious and advanced persistent threats.

Let’s talk people, process, and technology. We all know users are the weakest link in any security chain. Not because they have sinister intent, although sometimes they do, but primarily because in today’s high-powered technical, mobile, and social world, it is commonplace for a lapse in judgment to occur. We live in a rapid–fire, high-availability, high-output world, and mistakes can and will be made. So make is less commonplace, train and educate often, and monitor closely for when that lapse in judgment occurs.

Process: Again our high-powered technical, mobile, and social world often demands we run at warp speed.  Who has time to document? Well — make the time.  Good documentation to include process, policies and standards, as well as a documented and managed configuration control process, will help keep you more secure. Every process, policy and standard document has to have an assigned owner, has to have a designated review date, and has to have an oversight or governance process. All roles and responsibilities need to be included in the documentation, and the expected outcome needs to be defined. Make the time to prepare and socialize your critical information security program documentation.

Technology: Many risk owners fall prey to purchasing every piece of security technology available, at what I like to call the security “choke points”, end-point, network, edge, gateway, etc. This is just what everyone does. However, why not use the process we discussed above — measure, document, prioritize, and build a risk roadmap strategy — as your guideline for what you purchase and deploy for technology. Ask yourself — what is so wrong with selecting and implementing a product, only after you validate how it will help you manage your documented security risk? Of course the answer to that is — nothing.

Focus on Seamless Collaboration
You have documented your risk, you have prioritized your risk roadmap, and as a result you know the very specific technology, or set of technologies, you need to implement first. Most importantly, your technology selections should focus on products that collaborate in a seamless way. In other words, your end-point, edge, network, gateway, sandbox, etc., security technologies all talk to each other. We call this approach to complete security visibility across the whole landscape, Unified Security Stack. And, don’t forget that all technology must have a people and process component as well.

Good information security risk management and risk governance does not come by accident.  It takes planning and execution. In the end, although you may not keep the bad guy out, you will be better prepared for when.

The post Be a Conscientious Risk Manager appeared first on Connected.

Protecting Critical Infrastructure from Cyber Threats

The basic infrastructure that supports our daily lives is deeply dependent on the Internet, and, therefore, continually exposed to the risk of new threats and cyber attacks. As security breaches grow in frequency and sophistication every day, it’s crucial to build resiliency and then take steps to protect critical infrastructure to remain safe and secure online.

It’s important to identify current and future strategies to protect your infrastructure and manage your risk. Cyber security is one of the biggest challenges organizations face today. Regardless of size or industry, every organization must ask themselves, is my security strategy up to date? If your organization is looking to stay on the front line of cyber security, it’s imperative to know how an end-to-end risk management strategy can help you properly secure your infrastructure.

Our security experts have an abundance of experience, and several areas of expertise we can put to work for you. We are committed to keeping your organization safe and secure, and can help design, deploy, and support solutions to address your critical risks and defend your critical infrastructure. For more information, contact one of our security experts today!

The post Protecting Critical Infrastructure from Cyber Threats appeared first on Connected.

Protecting Critical Infrastructure

In this blog, the focus is on protecting critical infrastructure—the essential systems that support our daily lives such as the electric grid, financial institutions, and transportation. Unfortunately, attacks on critical infrastructure have become a concern worldwide. A devastating attack isn’t just a theoretical possibility anymore. As we’ve recently seen with Equifax, and other security breaches in healthcare and other industries, the growing threat of serious attacks on critical infrastructure is real. These days, hackers have become much more formidable, and we will undoubtedly see more of these attacks in the future. It’s no longer a matter of if there will be another attack, but when.

Protecting your infrastructure requires constant vigilance and attention to evolving cyber attacks. Risk is inherent in everything we do, so trying to stay ahead of the cyber security curve is key. Our team of security experts can help you build a security strategy to detect, protect, and react to the complete threat lifecycle. The threats we all need to manage today evolve quickly, and we can help you minimize your risk and maximize your defenses to improve your cyber resiliency.

The post Protecting Critical Infrastructure appeared first on Connected.

The Internet Wants YOU: Consider a Career in Cyber Security.

With the continuous state of change in the global threat landscape, organizations face cyber attacks and security breaches that are growing in frequency and sophistication every day. But now, consider this: according to a study by the Center for Cyber Safety and Education, there will be a shortage of 1.8 million information security workers by 2022. This gap should be of great concern to organizations.

Skilled people make the difference in protecting sensitive data, so it’s more critical than ever that organizations begin to attract and retain the cybersecurity talent needed to defend against the evolving threat landscape. At Connection, we help inspire individuals coming out of universities to engage in co-op or intern-related opportunities, and I strongly encourage other organizations to see what they can do to help young people today who are really interested in building their skills in this area.

The figures don’t lie. The demand for cyber security will only continue to grow. Through local collaborative efforts between employers, training providers, and community leaders, we can ensure individuals have the opportunity to build on their tech knowledge and participate in a secure, thriving economy.

The post The Internet Wants YOU: Consider a Career in Cyber Security. appeared first on Connected.

Cyber Security Careers Are in High Demand

It’s impossible to overstate the importance of security in today’s digital world. Cyber attacks are growing in frequency and sophistication every day, and a key risk to our economy and security is the lack of professionals to protect our growing networks. According to a study by the Center for Cyber Safety and Education, by 2022, there will be a shortage of 1.8 million information security workers. So, it’s critical that that we begin now to prepare our students—and any others who are interested in making a career move—to fill these gaps. Many colleges and universities have developed information assurance programs that help technical, security-minded students achieve a great foundation in this industry. We also challenge corporations to offer intern and co-op opportunities for students in these degree programs, so they can see what security looks like in practical, business-world applications.

Connection is committed to promoting cyber security and online safety.  Cyber security is a viable and rewarding profession and we encourage people from all backgrounds to see information security as an essential career path.

Read this next:

The post Cyber Security Careers Are in High Demand appeared first on Connected.

WPA2 Hacks and You

The world has been rocked once again with a serious flaw in a basic security mechanism that we all take for granted to keep us safe and secure. According to Dark Reading, researchers at Belgium’s University of Leuven have uncovered as many as 10 critical vulnerabilities in the Wi-Fi Protected Access II (WPA2) protocol used to secure Wi-Fi networks. This is a protocol that—as we have all learned over the last several years—must be configured to keep us safe.

The key reinstallation attack—or KRACKs—impacts all modern wireless networks using the WPA2 protocol. The flaw gives attackers the ability to decrypt data packets that make all private (encrypted) communication no longer private. Although the flaw requires the attacker to have close proximity to the network to execute, this is especially bad news for those with far-reaching wireless signals—such as hotel and hospital lobbies—where an attacker can just sit down and work their trade.

The Vulnerability Notes Database provides a summary and detailed description of the vulnerabilities. It includes a list of vendors who may be affected by the vulnerability, and a status field indicating whether the vendor has any products that are affected.

What can you do?

Vendors are currently identifying their affected products and working on patches to address this attack. In the meantime, here are a few things you can do to keep your information safe:

  1. Apply patches as they are released
  2. Pay careful attention to your wireless environment
  3. Watch for people and technology that look out of place
  4. Utilize a trusted VPN solution
  5. When possible, transfer data over an encrypted channel—such as HTTPS
  6. Restrict sensitive information that would normally pass over a wireless network
  7. And, as always, it’s a good practice to monitor access logs and wireless traffic to look for anomalies in standard business communication

How has this WiFi vulnerability affected your organization? Leave a comment bellow to share your experience and any additional advice you have for staying protected.

Read this next:


The post WPA2 Hacks and You appeared first on Connected.

What About the Plant Floor? Six Subversive Concerns for ICS Environments

Industrial enterprises such as electric utilities, petroleum companies, and manufacturing organizations invest heavily in industrial control systems (ICS) to efficiently, reliably, and safely operate industrial processes. Without this technology operating the plant floor, these businesses cannot exist.

Board members, executives, and security officers are often unaware that the technology operating the economic engine of their enterprise invites undetected subversion.  

In this paper, FireEye iSIGHT Intelligence prepares risk executives and security practitioners to knowledgeably discuss six core weaknesses an adversary can use to undermine a plant's operation:

  • Unauthenticated protocols
  • Outdated hardware
  • Weak user authentication
  • Weak file integrity checks
  • Vulnerable Windows operating systems
  • Undocumented third-party relationships

Download the report to learn more. To discuss these six subversive vulnerabilities threatening today’s industrial environments, register for our live webinar scheduled for Tuesday, April 25 at 11:00am ET/8:00am PT. Explore the implications and how to address them firsthand with our ICS intelligence experts.

New Variant of Ploutus ATM Malware Observed in the Wild in Latin America


Ploutus is one of the most advanced ATM malware families we’ve seen in the last few years. Discovered for the first time in Mexico back in 2013, Ploutus enabled criminals to empty ATMs using either an external keyboard attached to the machine or via SMS message, a technique that had never been seen before.

FireEye Labs recently identified a previously unobserved version of Ploutus, dubbed Ploutus-D, that interacts with KAL’s Kalignite multivendor ATM platform. The samples we identified target the ATM vendor Diebold. However, minimal code change to Ploutus-D would greatly expand its ATM vendor targets since Kalignite Platform runs on 40 different ATM vendors in 80 countries.

Once deployed to an ATM, Ploutus-D makes it possible for a money mule to obtain thousands of dollars in minutes. A money mule must have a master key to open the top portion of the ATM (or be able to pick it), a physical keyboard to connect to the machine, and an activation code (provided by the boss in charge of the operation) in order to dispense money from the ATM. While there are some risks of the money mule being caught by cameras, the speed in which the operation is carried out minimizes the mule’s risk.

This blog covers the changes, improvements, and Indicators of Compromise (IOC) of Ploutus-D in order to help financial organizations identify and defend against this threat.

Previously unobserved features of Ploutus-D

  • It uses the Kalignite multivendor ATM Platform.
  • It could run on ATMs running the Windows 10, Windows 8, Windows 7 and XP operating systems.
  • It is configured to control Diebold ATMs.
  • It has a different GUI interface.
  • It comes with a Launcher that attempts to identify and kill security monitoring processes to avoid detection.
  • It uses a stronger .NET obfuscator called Reactor.

Commonality between Ploutus and Ploutus-D

  • The main purpose is to empty the ATM without requiring an ATM card.
  • The attacker must interact with the malware using an external keyboard attached to the ATM.
  • An activation code is generated by the attacker, which expires after 24 hours.
  • Both were created in .NET.
  • Can run as Windows Service or standalone application.

Dissecting Ploutus-D

Ploutus-D (observed in the wild with the filename of “AgilisConfigurationUtility.exe”) can run as a standalone application or as a Windows service started by a Launcher (observed in the wild as “Diebold.exe”). Although multiple functionality is shared between the two components, the main difference is that Ploutus-D is the component with the capability to dispense money.

Launcher – Diebold.exe (.NET)



.NET Obfuscator


File Size

198 kB

File Type

Win32 EXE

Time Stamp

2016:11:16 04:55:56-08:00

Code Size


File Version

Internal Name


Legal Copyright

Copyright ©  2015

Original Filename


Product Name


Product Version

Table 1: Launcher Properties

This time, the attackers put more effort into trying to obfuscate and protect their code from reverse engineering by switching from .NET Confuser to Reactor. A quick look at how the protected code appears is shown in Figure 1.

Figure 1: Code protected by Reactor

Inspecting the Launcher

Once the code is deobfuscated, it is easy to understand the internal workings. Before the Launcher execution starts, it will perform an integrity check on itself to make sure it has not been altered.

The Launcher can receive different arguments in the command line to either install as a service, run Ploutus-D, or uninstall from the machine. The service properties can be seen in Figure 2.

Figure 2: Service Description of the Launcher


Using a very common persistence technique, the malware will add itself to the “Userinit” registry key to allow execution after every reboot. The key is located at:

\HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

Interacting with the Launcher

The attacker must interact with the Launcher by attaching a keyboard to the ATM USB or PS/2 port. Figure 3 below shows an example of this setup.

Figure 3: Keyboard attached to the ATM port

Once the Launcher has been installed in the ATM, it will perform keyboard hooking in order to read the instructions from the attackers via the external keyboard. A combination of “F” keys will be used to request the action to execute (see Figure 4).

Figure 4: Interacting with the Launcher via keyboard

The main tasks supported are:

  • Start programs on demand, some of which are decrypted from the resource section of the Launcher:
    • C:\Program Files\Diebold\Agilis Startup\AgilisShellStart.exe
    • Main.exe
    • XFSConsole.exe
  • Kill Processes:
    • NHOSTSVC.exe
    • AgilisConfigurationUtility.exe
    • XFSConsole.exe
  • Delete Files:
    • NetOp.LOG – Secure Remote Management solution
  • Reboot Machine:
    • “wmic os where Primary='TRUE' reboot”

As seen in Figure 5, a request has been sent to run Ploutus-D (AgilisConfigurationUtility.exe) from command line.

Figure 5: Starting Ploutus-D by the Launcher

Legitimate KAL ATM software is dropped into the system along with Ploutus-D, as shown in the Figure 6. The reason for this is to make sure that all the software and versions needed to properly run the malware are present in the same folder to avoid any dependency issues. The same technique was also used by the first version of Ploutus.

Figure 6: Dropped files by the Launcher

The K3A.Platform.dll DLL will load the Kalignite Platform to allow Ploutus-D to control the ATM.

This shows that the attackers likely have access to the targeted ATM software. They can either buy physical ATMs from authorized resellers, which come preloaded with vendor software, or they could just steal the ATMs directly from the bank’s facility. An example of a real incident reported in Mexico is shown in Figure 7.

Figure 7: Attackers physically stealing ATMs

Ploutus-D – AgilisConfigurationUtility.exe (.NET)



.NET Obfuscator


File Size

274 kB

File Type

Win32 EXE

Time Stamp

1992:06:19 15:22:17-07:00

Code Size


OS Version


Image Version


Subsystem Version


Table 2: Ploutus-D Properties

Similar to the Launcher, this binary also came protected with Reactor obfuscator (see Figure 8).

Figure 8. Protected with Reactor

Looking at the unprotected code (see Figure 9), the connection with Ploutus became evident since the names of most of the functions are the same as in the first version.

Figure 9: Unprotected code

Ploutus-D will make sure a mutex with the name “KaligniteAPP” does not exist in the system in order to start running. Similar to the Launcher, Ploutus-D will hook the keyboard in order for the attackers to interact with it; however, apart from receiving commands from “F” keys, it will also read from the numeric pad (numbers).

Similar to the previous version, the GUI will be enabled by entering a combination of “F” keys. Then, a valid 8-digit code must be entered in the GUI in order to be able to dispense money. Ploutus-D also allows the attackers to enter the amount to withdraw (billUnits – 4 digits) and the number of cycles (billCount – 2 digits) to repeat the dispensing operation (see Figure 10).

Figure 10: Parsing amount and cycles

The Ploutus-D GUI is displayed in Figure 11. It is configured to list properties of 18 cassettes (C1-C18). Letter “D” shows the status of the cassette and “CV” is a value taken from the registry. The message “Estado:Activado”, which means “State: Activated”, is displayed if a valid code has been entered. The ATM ID and HW_ID are unique to the ATM. The amount to be retrieved is displayed as: “Cantidad: 500” (default value if no amount entered in the GUI). The total amount depends on the currency, which is also calculated by the malware.

Figure 11: Ploutus-D GUI enabled

All the actions are logged into a file with the name “Log.txt”. An extract can be seen in Figure 12.

Figure 12: Log File recording actions

Dispensing the Money

In order for the mule to be able to start dispensing money, a valid 8-digit code must be entered. This code is provided by the boss in charge of the operation and is calculated based on a unique ID generated per ATM, and the current month and day of the attack.

Once a valid activation code has been entered (which expires in 24 hours), the dispensing process will start by pressing “F3” from the external keyboard.

The malware will first identify the cassette’s denomination by querying the registry denomination table from Diebold Dispenser Logical Name “DBD_AdvFuncDisp” at:


A similar strategy will be used to get the cassette’s status and type, to make sure they are working properly, and, more important, to identify that it has at least one bill to withdraw.

Ploutus-D will load “KXCashDispenserLib” library implemented by Kalignite Platform (K3A.Platform.dll) to interact with the XFS Manager and control the Dispenser (see Figure 13).

Figure 13: Loading Dispenser Class

Figure 14 shows a graphical representation of the XFS Manager and its interaction with Kalignite Platform via KXCashDispenserLib.

Figure 14: XFS Manager

The knowledge shown in the code to properly implement all the different classes and methods to control the Dispenser suggests that the developers of the malware have either access to real ATMs during the development or they hired individuals with experience coding on these machines.

Expanding Ploutus to other ATM vendors

Kalignite Platform is said to support 40 ATM vendors. Looking at the code to dispense money, the only pieces adjusted to target Diebold are the different registry keys to read the cassette (DBD_AdvFuncDisp) parameters (see Figure 15).

Figure 15: Getting Diebold Cassette parameters

Since Ploutus-D interacts with the Kalignite Platform, only minor modifications to the Ploutus-D code may be required to target different ATM vendors worldwide.


As anticipated in our 2017 predictions report, the use of ATM malware will continue to increase, especially in underdeveloped countries with weaker physical security controls. By leveraging the Kalignite Platform, Ploutus can be easily modified to attack various ATM vendors and operating systems.

Frequently Asked Questions

  1. When was Ploutus-D first discovered?
    • Ploutus-D was uploaded to VirusTotal in November 2016.
  2. Does Ploutus-D target cardholder information?
    • No. It is designed to dispense cash from within the ATM.
  3. Is Ploutus-D already affecting ATMs in the wild?
    • Yes. It has been observed in Latin America.
  4. What type of ATMs are affected?
    • Ploutus-D affects Diebold ATMs.
    • Minor modifications could be made to Ploutus-D to affect other vendors using the Kalignite Platform.
  5. How is Ploutus-D installed on the ATM?
    • Through physical access to the ATM.
  6. How do attackers interact with Ploutus-D?
    • Via an external keyboard that needs to be connected to the ATM.




The following files should be found at the same place where the service Diebold.exe is located:

P.bin – Mac address of the system, plus string: “PLOUTUS-MADE-IN-LATIN-AMERICA-XD”
PDLL.bin – Encoded version of P.bin

Mutex names:



Service Name: DIEBOLDP


\\HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit=”Diebold.exe,%system32%/userinit.exe”

Credit Card Data and Other Information Targeted in Netflix Phishing Campaign


Through FireEye’s Email Threat Prevention (ETP) solution, FireEye Labs discovered a phishing campaign in the wild targeting the credit card data and other personal information of Netflix users primarily based in the United States.

This campaign is interesting because of the evasion techniques that were used by the attackers:

  • The phishing pages were hosted on legitimate, but compromised web servers.
  • Client-side HTML code was obfuscated with AES encryption to evade text-based detection.
  • Phishing pages were not displayed to users from certain IP addresses if its DNS resolved to companies such as Google or PhishTank.

At the time of posting, the phishing websites we observed were no longer active.

Attack Flow

The attack seems to start with an email notification – sent by the attackers – that asks the user to update their Netflix membership details. The phishing link inside the email body directs recipients to a page that attempts to mimic a Netflix login page, as seen in Figure 1.

Figure 1: Fake login page mimicking the Netflix website

Upon submitting their credentials, victims are then directed to webpages requesting additional membership details (Figure 2) and payment information (Figure 3). These websites also attempt to mimic authentic Netflix webpages and appear legitimate. Once the user has entered their information, they are taken to the legitimate Netflix homepage.

Figure 2: Fake webpage asking users to update their personal details

Figure 3: Netflix phishing webpage used to steal credit card information

Technical Details

The phishing kit uses techniques to evade phishing filters. One technique is the use of AES encryption to encode the content presented at the client’s side, as seen in Figure 4. The purpose of using this technique is code obfuscation, which helps to evade text-based detection. By obfuscating the webpage, attackers try to deceive text-based classifiers and prevent them from inspecting webpage content. This technique employs two files, a PHP and a JavaScript file that have functions to encrypt and decrypt input strings. The PHP file is used to encrypt the webpages at the server side, as seen in Figure 5. At the client side, the encrypted content is decoded using a defined function in the JavaScript file, as seen in Figure 6. Finally, the webpage is rendered using the ‘document.write’ function.

Figure 4: Client-side code obfuscation using AES encryption

Figure 5: PHP code used at server side for encryption

Figure 6: JavaScript code used at client-side for decryption

Another technique is the host-based evasion, as seen in Figure 7. The host name of organizations such as ‘phishtank’ and ‘google’ are blacklisted. The host name of the client is compared against a list of blacklisted host names. If there is a match against the blacklist, a “404 Not Found” error page is presented.

Figure 7: Server side code for blacklisting known hosts. Click image to enlarge.

As with the majority of phishing attacks, this campaign uses PHP mail utility to send the attacker the stolen credentials. The advantage of using this technique is that the attacker can host their phishing kits on a number of websites and still get the stolen credentials and other information from a single email account. This enables attackers to extend their reach.

Figure 8: Stolen information is sent to an email address using mail() function

Tips to Secure your Netflix Account

To learn more about securing your Netflix account, Netflix provides additional information on how to keep your account safe from phishing scams and other fraudulent activity at

‘One-Stop Shop’ – Phishing Domain Targets Information from Customers of Several Indian Banks

FireEye Labs recently discovered a malicious phishing domain designed to steal a variety of information – including credentials and mobile numbers – from customers of several banks in India. Currently, we have not observed this domain being used in any campaigns. The phishing websites appear to be in the earlier stages of development and through this post we hope users will be able to identify these types of emerging threats in the future.

FireEye phishing detection technology identified a newly registered domain, “csecurepay[.]com”, that was registered on Oct. 23, 2016. The website purports to offer online payment gateway services, but is actually a phishing website that leads to the capturing of victim logon credentials – and other information – for multiple banks operating in India.

Prior to publication, FireEye notified the Indian Computer Emergency Response Team.

Phishing Template Presentation and Techniques

Step 1

URL: hxxp://csecurepay[.]com/load-cash-step2.aspx

When navigating to the URL, the domain appears to be a payment gateway and requests that the user enter their bank account number and the amount to be transferred, as seen in Figure 1. The victim is allowed to choose their bank from a list that is provided.

Figure 1: Bank information being requested

By looking at the list, it is clear that only Indian banks are being targeted at this time. A total of 26 banks are available and these are named in the Appendix.

Step 2

URL:  hxxp://csecurepay[.]com/PaymentConfirmation.aspx

The next website requests the victim to enter their valid 10-digit mobile number and email ID (Figure 2), which makes the website appear more legitimate.

Figure 2: Personal information being requested

Step 3

The victim will then be redirected to the spoofed online banking page of the bank they selected, which requests that they log in using their user name and password. Figure 3 shows a fake login page for State Bank of India. See the Appendix for more banks that have spoofed login pages.

Figure 3: Fake login page for State Bank of India

After entering their login credentials, the victim will be asked to key in their One Time Password (OTP), as seen in Figure 4.

Figure 4: OTP being requested

Step 4

URL: hxxp://csecurepay[.]com/Final.aspx

Once all of the sensitive data is gathered, a fake failed login message will be displayed to the victim, as seen in Figure 5.

Figure 5: Fake error message being displayed

Credit and Debit Card Phishing Website

Using the registrant information from the csecurepay domain, we found another domain registered by the phisher as “nsecurepay[.]com”. The domain, registered in latest August 2016, aims to steal credit and debit card information.

The following are among the list of cards that are targeted:

1.     ICICI Credit Card

2.     ICICI Debit Card

3.     Visa/Master Credit Card

4.     Visa/Master Debit Card

5.     SBI Debit Card Only

At the time of this writing, the nsecurepay website was producing errors when redirecting to spoofed credit and debit card pages. Figure 6 shows the front end.

Figure 6: Nsecurepay front end


Phishing has its own development lifecycle. It usually starts off with building the tools and developing the “hooks” for luring victims into providing their financial information. Once the phishing website (or websites) is fully operational, we typically begin to see a wave of phishing emails pointing to it.

In this case, we see that phishing websites have been crafted to spoof multiple banks in India. These attackers can potentially grab sensitive online banking information and other personal data, and even provided support for multifactor authentication and OTP. Moreover, disguising the initial presentation to appear as an online payment gateway service makes the phishing attack seem more legitimate.

FireEye Labs detects this phishing attack and customers will be protected against the usage of these sites in possible future campaigns.


Fake login pages were served for 26 banks. The following is a list of some of the banks:

-Bank of Baroda - Corporate

-Bank of Baroda - Retail

-Bank of Maharashtra

-HDFC Bank

Figure 7: HDFC Bank fake login page


-IDBI Bank

-Indian Bank

-IndusInd Bank

-Jammu and Kashmir Bank

-Kotak Bank

-Lakshmi Vilas Bank - Corporate

-Lakshmi Vilas Bank - Retail

-State Bank of Hyderabad

-State Bank of India

-State Bank of Jaipur

-State Bank of Mysore

-State Bank of Patiala

-State Bank of Bikaner

-State Bank of Travancore

-Tamilnad Mercantile Bank

-United Bank of India

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.

Connected Cars: The Open Road for Hackers

As vehicles become both increasingly complex and better connected to the Internet, their newfound versatility may be manipulated for malicious purposes. Three of the most concerning potential threats looking ahead to the next few years are those posed by manipulating vehicle operation, ransomware and using vehicular systems as command and control (C2) infrastructure for illicit cyber activity.

Car Hacking?

Vehicles have come a long way in terms of the high-tech features and connectivity that come standard in most new models. Modern cars are controlled almost entirely by software, and many drivers don’t realize the most complex digital device they own may be in their driveway. Of the growing number of devices in the “Internet of Things” (IoT), vehicles are among the most significant additions to the global Internet. An ever-growing list of features—including web browsing, Wi-Fi access points, and remote-start mobile phone apps—enhance user enjoyment, but also greatly expand vehicles’ attack surface, rendering them potentially vulnerable to advanced attacks. During the past year especially, numerous proof-of-concept demonstrations have revealed connected-car vulnerabilities that malicious actors can exploit, ranging from unauthorized entry to commandeering the vehicle’s operation. Unfortunately, as consumer demand drives ever more features, the opportunities for compromise will increase as well.


The scourge of ransomware has so far affected thousands of systems belonging to ordinary individuals, hospitals, and police stations. A vehicle’s increased connectivity, ever-expanding attack surface, and high upfront cost make them attractive ransomware targets. In contrast to ransomware that infects ordinary computer systems, vehicles are more likely susceptible to ransomware attacks when their disablement causes knock-on effects.

For example, where a single driver might be able to reinstall his car’s software with the help of a mechanic to remedy a ransomware infection, a group of vehicles disabled on a busy highway could cause far more serious disruption. Victims or municipal authorities may have little choice but to pay the ransom to reopen a busy commuting route. Alternatively, a logistics company might suddenly find a large portion of its truck fleet rendered useless by ransomware. The potential for lost revenue due to downtime might pressure the company to pay the ransom rather than risk more significant financial losses.

Malicious C2 and Final Hop Points

One effective law enforcement tactic in countering cyber espionage and criminal campaigns is identifying, locating and seizing the systems threat actors use to route malicious traffic through the Internet. Since many modern vehicles can be better described as a computer attached to four wheels and an engine, their mobility and power present challenges to this means of countering threat activity. We have already witnessed malware designed to hijack IoT devices for malicious purposes; vehicular systems’ greater computing power, compared to connected home thermostats, can significantly enhance their value as a C2 node.

Locating vehicles used to route malicious traffic would present a major challenge to law enforcement investigation, largely due to their mobility. We have not yet observed threat actors using connected vehicle systems to route malicious traffic, but it is most likely that a vehicle would be used as a final hop point to the intended target network. The perpetrators may use the vehicle only once, choosing to hijack the connectivity of a different vehicle on their next operation, and so on. This ever-changing roster of potential last-hop nodes situated on highly mobile platforms may allow threat actors to elude law enforcement for extended periods of time.

Understanding the Risk Landscape

The impact of cyber threats is most often considered in financial terms—the cost of a breach, whether direct financial losses or indirect costs of investigation, remediation, and improved security. As computers increasingly control vehicles, among other critical devices and systems, the potential for malfunction or manipulation that causes human harm rises dramatically. Automobile manufacturers may face greater liability, not only for the car’s physical components, but its software as well. How long before vehicles need a “cyber security rating,” similar to that awarded for crash testing and fuel economy?

These new risks point to the need for automotive manufacturers and suppliers to not only ensure the traditional operational safety of their vehicles, but to also secure both the vehicle's operations and occupant privacy. This requires an ongoing understanding about the nature of threats and vulnerabilities in a rapidly evolving landscape, and building in strong proactive security measures to protect against these risks. FireEye explores these risks to automotive safety in our latest FireEye iSIGHT Intelligence and Mandiant Consulting report: Connected Cars: The Open Road for Hackers. The report is available for download here.

FireEye Capabilities

FireEye combines our industry leading threat intelligence, incident response and red team capabilities with our ICS domain expertise to help the automotive industry improve their prevention, detection and response capabilities. FireEye’s Red Team Operations and Penetration Tests can provide firms in the automotive industry experience responding to real-world attacks without the risk of negative headlines. A one-time risk assessment is not enough, because threat attackers are consistently evolving.

For more information, contact FireEye.

FireEye iSIGHT Intelligence’s Horizons Team conducts strategic forecasting to anticipate risks posed by emerging technologies and geopolitical developments, helping clients and the public better assess their exposure to a dynamic cyber threat landscape.

IRONGATE ICS Malware: Nothing to See Here…Masking Malicious Activity on SCADA Systems

In the latter half of 2015, the FireEye Labs Advanced Reverse Engineering (FLARE) team identified several versions of an ICS-focused malware crafted to manipulate a specific industrial process running within a simulated Siemens control system environment. We named this family of malware IRONGATE.

FLARE found the samples on VirusTotal while researching droppers compiled with PyInstaller — an approach used by numerous malicious actors. The IRONGATE samples stood out based on their references to SCADA and associated functionality. Two samples of the malware payload were uploaded by different sources in 2014, but none of the antivirus vendors featured on VirusTotal flagged them as malicious.

Siemens Product Computer Emergency Readiness Team (ProductCERT) confirmed that IRONGATE is not viable against operational Siemens control systems and determined that IRONGATE does not exploit any vulnerabilities in Siemens products. We are unable to associate IRONGATE with any campaigns or threat actors. We acknowledge that IRONGATE could be a test case, proof of concept, or research activity for ICS attack techniques.

Our analysis finds that IRONGATE invokes ICS attack concepts first seen in Stuxnet, but in a simulation environment. Because the body of industrial control systems (ICS) and supervisory control and data acquisition (SCADA) malware is limited, we are sharing details with the broader community.

Malicious Concepts

Deceptive Man-in-the-Middle

IRONGATE's key feature is a man-in-the-middle (MitM) attack against process input-output (IO) and process operator software within industrial process simulation. The malware replaces a Dynamic Link Library (DLL) with a malicious DLL, which then acts as a broker between a PLC and the legitimate monitoring software. This malicious DLL records five seconds of 'normal' traffic from a PLC to the user interface and replays it, while sending different data back to the PLC. This could allow an attacker to alter a controlled process unbeknownst to process operators.

Sandbox Evasion

IRONGATE's second notable feature involves sandbox evasion. Some droppers for the IRONGATE malware would not run if VMware or Cuckoo Sandbox environments were employed. The malware uses these techniques to avoid detection and resist analysis, and developing these anti-sandbox techniques indicates that the author wanted the code to resist casual analysis attempts. It also implies that IRONGATE’s purpose was malicious, as opposed to a tool written for other legitimate purposes.

Dropper Observables

We first identified IRONGATE when investigating droppers compiled with PyInstaller — an approach used by numerous malicious actors. In addition, strings found in the dropper include the word “payload”, which is commonly associated with malware.

Unique Features for ICS Malware

While IRONGATE malware does not compare to Stuxnet in terms of complexity, ability to propagate, or geopolitical implications, IRONGATE leverages some of the same features and techniques Stuxtnet used to attack centrifuge rotor speeds at the Natanz uranium enrichment facility; it also demonstrates new features for ICS malware.

  • Both pieces of malware look for a single, highly specific process.
  • Both replace DLLs to achieve process manipulation.
  • IRONGATE detects malware detonation/observation environments, whereas Stuxnet looked for the presence of antivirus software.
  • IRONGATE actively records and plays back process data to hide manipulations, whereas Stuxnet did not attempt to hide its process manipulation, but suspended normal operation of the S7-315 so even if rotor speed had been displayed on the HMI, the data would have been static.

A Proof of Concept

IRONGATE’s characteristics lead us to conclude that it is a test, proof of concept, or research activity.

  • The code is specifically crafted to look for a user-created DLL communicating with the Siemens PLCSIM environment. PLCSIM is used to test PLC program functionality prior to in-field deployment. The DLLs that IRONGATE seeks and replaces are not part of the Siemens standard product set, but communicate with the S7ProSim COM object. Malware authors test concepts using commercial simulation software.
  • Code in the malicious software closely matched usage on a control engineering blog dealing with PLCSIM ( and
  • While we have identified and analyzed several droppers for the IRONGATE malware, we have yet to identify the code’s infection vector.
  • In addition, our analysis did not identify what triggers the MitM payload to install; the scada.exe binary that deploys the IRONGATE DLL payload appears to require manual execution.
  • We have not identified any other instances of the ICS-specific IRONGATE components (scada.exe and Step7ProSim.dll), despite their having been compiled in September of 2014.
  • Siemens ProductCERT has confirmed that the code would not work against a standard Siemens control system environment.

Implications for ICS Asset Owners

Even though process operators face no increased risk from the currently identified members of the IRONGATE malware family, IRONGATE provides valuable insight into adversary mindset.

Network security monitoring, indicator of compromise (IoC) matching, and good practice guidance from vendors and other stakeholders represent important defensive techniques for ICS networks.

To specifically counter IRONGATE’s process attack techniques, ICS asset owners may, over the longer term, implement solutions that:

  • Require integrity checks and code signing for vendor and user generated code. Lacking cryptographic verification facilitates file replacement and MitM attacks against controlled industrial processes.
  • Develop mechanisms for sanity checking IO data, such as independent sensing and backhaul, and comparison with expected process state information. Ignorance of expected process state facilitates an attacker’s ability to achieve physical consequence without alarming operators.

Technical Malware Analysis

IRONGATE Dropper Family

FireEye has identified six IRONGATE droppers: bla.exe, update.exe1, update_no_pipe.exe1, update_no_pipe.exe2, update_no_pipe.exe2, update.exe3. All but one of these Python-based droppers first checks for execution in a VMware or Cuckoo Sandbox environment. If found, the malware exits.

If not found, the IRONGATE dropper extracts a UPX-packed, publicly available utility (NirSoft NetResView version 1.27) to audiodg.exe in the same directory as the dropper. The dropper then executes the utility using the command audiodg.exe /scomma scxrt2.ini. This command populates the file scxrt2.ini with a comma-separated list of network resources identified by the host system.

The dropper iterates through each entry in scxrt2.ini, looking for paths named move-to-operational or move-to-operational.lnk. If a path is found, the dropper first extracts the Base64-encoded .NET executable scada.exe to the current directory and then moves the file to the path containing move-to-operational or move-to-operational.lnk. The path move-to-operational is interesting as well, perhaps implying that IRONGATE was not seeking the actual running process, but rather a staging area for code promotion. The dropper does not execute the scada.exe payload after moving it.

Anti-Analysis Techniques

Each IRONGATE dropper currently identified deploys the same .NET payload, scada.exe. All but one of the droppers incorporated anti-detection/analysis techniques to identify execution in VMware or the Cuckoo Sandbox. If such environments are detected, the dropper will not deploy the .NET executable (scada.exe) to the host.

Four of the droppers (update.exe1, update_no_pipe.exe1, update_no_pipe.exe2, and update.exe3) detect Cuckoo environments by scanning subdirectories of the %SystemDrive%. Directories with names greater than five, but fewer than ten characters are inspected for the subdirectories drop, files, logs, memory, and shots. If a matching directory is found, the dropper does not attempt to deploy the scada.exe payload.

The update.exe1 and update.exe3 droppers contain code for an additional Cuckoo check using the SysInternals pipelist program, install.exe, but the code is disabled in each.

The update.exe2 dropper includes a check for VMware instead of Cuckoo. The VMWare check looks for the registry key HKLM\SOFTWARE\VMware, Inc.\VMware Tools and the files %WINDIR%\system32\drivers\vmmouse.sys and %WINDIR%\system32\drivers\vmhgfs.sys. If any of these are found, the dropper does not attempt to deploy the scada.exe payload.

The dropper bla.exe does not include an environment check for either Cuckoo or VMware.

scada.exe Payload

We surmise that scada.exe is a user-created payload used for testing the malware. First, our analysis did not indicate what triggers scada.exe to run. Second, Siemens ProductCERT informed us that scada.exe is not a default file name associated with Siemens industrial control software.

When scada.exe executes, it scans drives attached to the system for filenames ending in Step7ProSim.dll. According to the Siemens ProductCERT, Step7ProSim.dll is not part of the Siemens PLCSIM software. We were unable to determine whether this DLL was created specifically by the malware author, or if it was from another source, such as example code or a particular custom ICS implementation. We surmise this DLL simulates generation of IO values, which would normally be provided by an S7-based controller, since the functions it includes appear derived from the Siemens PLCSIM environment.

If scada.exe finds a matching DLL file name, it kills all running processes with the name biogas.exe. The malware then moves Step7ProSim.dll to Step7ConMgr.dll and drops a malicious Step7ProSim.dll – the IRONGATE payload – to the same directory.

The malicious Step7ProSim.dll acts as an API proxy between the original user-created Step7ProSim.dll (now named Step7ConMgr.dll) and the application biogas.exe that loads it. Five seconds after loading, the malicious Step7ProSim.dll records five seconds of calls to ReadDataBlockValue. All future calls to ReadDataBlockValue return the recorded data.

Simultaneously, the malicious DLL discards all calls to WriteDataBlockValue and instead calls WriteInputPoint(0x110, 0, 0x7763) and WriteInputPoint(0x114, 0, 0x7763) every millisecond. All of these functions are named similarly to Siemens S7ProSim v5.4 COM interface. It appears that other calls to API functions are passed through the malicious DLL to the legitimate DLL with no other modification.


As mentioned previously, IRONGATE seeks to manipulate code similar to that found on a blog dealing with simulating PLC communications using PLCSIM, including the use of an executable named biogas.exe.

Examination of the executable from that blog’s demo code shows that the WriteInputPoint function calls with byte indices 0x110 and 0x114 set pressure and temperature values, respectively:


         WriteInputPoint(0x110, 0, 0x7763)
WriteInputPoint(0x114, 0, 0x7763)

 Equivalent pseudo code from Biogas.exe: 

        S7ProSim.WriteInputPoint(0x110, 0, (short)this.Pressure.Value)
     S7ProSim.WriteInputPoint(0x114, 0, (short)this.Temperature.Value)

We have been unable to determine the significance of the hardcoded value 0x7763, which is passed in both instances of the write function.

Because of the noted indications that IRONGATE is a proof of concept, we cannot conclude IRONGATE’s author intends to manipulate specific temperature or pressure values associated with the specific biogas.exe process, but find the similarities to this example code striking.

Artifacts and Indicators

PyInstaller Artifacts

The IRONGATE droppers are Python scripts converted to executables using PyInstaller. The compiled droppers contain PyInstaller artifacts from the system the executables were created on. These artifacts may link other samples compiled on the same system. Five of the six file droppers (bla.exe, update.exe1, update_no_pipe.exe1, update_no_pipe.exe2 and update.exe3) all share the same PyInstaller artifacts listed in Table 1.

Table 1: Pyinstaller Artifacts

The remaining dropper, update.exe2, contains the artifacts listed in Table 2.

Table 2: Pyinstaller Artifacts for update.exe2

Unique Strings

Figure 1 and 2 list the unique strings discovered in the scada.exe and Step7ProSim.dll binaries.

Figure 1: Scada.exe Unique Strings

Figure 2: Step7ProSim.dll Unique Strings

File Hashes

Table 3 contains the MD5 hashes, file and architecture type, and compile times for the malware analyzed in this report.

Table 3: File MD5 Hashes and Compile Times

FireEye detects IRONGATE. A list of indicators can be found here.

Special thanks to the Siemens ProductCERT for providing support and context to this investigation.

Citrix XenApp and XenDesktop Hardening Guidance

A Joint Whitepaper from Mandiant and Citrix

Throughout the course of Mandiant’s Red Team and Incident Response engagements, we frequently identify a wide array of misconfigured technology solutions, including Citrix XenApp and XenDesktop.

We often see attackers leveraging stolen credentials from third parties, accessing Citrix solutions, breaking out of published applications, accessing the underlying operating systems, and moving laterally to further compromise the environment. Our experience shows that attackers are increasingly using Citrix solutions to remotely access victim environments post-compromise, instead of using traditional backdoors, remote access tools, or other types of malware. Using a legitimate means of remote access enables attackers to blend in with other users and fly under the radar of security monitoring tools.

Citrix provides extensive security hardening guidance and templates to their customers to mitigate the risk of these types of attacks. The guidance is contained in product-specific eDocs, Knowledge Base articles and detailed Common Criteria configurations. System administrators (a number of them wearing many hats and juggling multiple projects) may not have the time to review all of the hardening documentation available, so Mandiant and Citrix teamed up to provide guidance on the most significant risks posed to Citrix XenApp and XenDesktop implementations in a single white paper.

This white paper covers risks and official Citrix hardening guidance for the following topics:

  • Environment and Application Jailbreaking
  • Network Boundary Jumping
  • Authentication Weaknesses
  • Authorization Weaknesses
  • Inconsistent Defensive Measures
  • Non-configured or Misconfigured Logging and Alerting

The white paper is available here.

Maimed Ramnit Still Lurking in the Shadow

Newspapers have the ability to do more than simply keep us current with worldly affairs; we can use them to squash bugs! Yet, as we move from waiting on the newspaper delivery boy to reading breaking news on ePapers, we lose the subtle art of bug squashing. Instead, we end up exposing ourselves to dangerous digital bugs that can affect our virtual worlds.

This is exactly what happened to visitors of one of the top five news sites of China. Any users running Internet Explorer (IE) who navigated to the website may have been exposed to an old, yet persistent VBScript worm that has the ability to self-replicate recursively from infected machines. Incidentally, the major actors involved with this old campaign have been taken down, yet traces of their injected recursive malware have still managed to sneak on to one of the highest browsed sites in China.

The FireEye Dynamic Threat Intelligence (DTI) first discovered that the site was compromised and used to host VBS/Ramnit on Jan. 28, 2016. We can confirm that the infection is still live as of the time of this writing. IE users who visit the site may be compromised if they browse to a specific page (paperindex[.]htm) and click ‘Yes’ to run ActiveX, which may appear to be safe since the website is familiar and popular. There is no exploit used for infection, simply social engineering and errant clicks.

As shown in Figure 1, a malicious VBScript is appeneded after the HTML body. Upon landing on this page, the victim’s browser will load the news content while it executes a malicious ActiveX component in the background.

Figure 1: Legitimate HTML page appended with malicious VBScript

As shown in Figure 2 and Figure 3, the VBScript drops a binary named “svchost.exe” in the %TEMP% folder and executes it upon successful ActiveX execution. In a case where the system is compromised, it also tries to connect to a CnC server, fget-career[.]com, which has been involved in campaigns for this trojan before.

Figure 2: The VBScript drops the binary in the %TEMP% folder and executes it

Figure 3: The full path to “svchost.exe” (using Internet Explorer 11 on Windows 7)

Successful execution of the VBScript and the delivery of W32.Ramnit onto the victim’s machine depends on the user’s browser, as well as the browser’s setting. Since Chrome and Firefox do not support client-side VBScript, only IE users are susceptible to this attack.

Fortunately, recent versions of IE do not run code automatically by default. Instead, users will see two popup warnings when the browser is rendering potentially dangerous objects such as ActiveX components, as shown in Figure 4 and Figure 5.

Figure 4: First warning for blocked content in IE 11

Figure 5: Second warning for blocked content in IE 11

Only when the victim clicks on “Yes” will the browser execute the blocked content. In this case, the IE executes the VBScript, drops the payload, and executes it in the background while the user simply sees the usual news page.

As long as users click “No” to disallow ActiveX components, they will remain safe from W32.Ramnit. However, this type of social engineering continues to be successful. When a legitimate site is compromised to host exploits or malware, the positive reputation of the site is leveraged to trick users into clicking “Yes” and becoming infected. The potential impact of this particular threat is compounded by the fact that the compromised site is ranked in the Alexa Top 100 for most visited sites internationally, and is in the Top 25 for most popular websites in China [1].

FireEye appliances detect this infection at multiple levels. FireEye’s multiflow detection traces out the complete attack chain, as well as CnC communication. While the CnC host has been suspended for a long time, the worm’s presence alone can be a pain for the victim because it adds itself into all HTML files that it can access. Additionally, it adds itself to the startup registry and impacts the machine’s performance.

So the question that you need to ask yourself is this: If a Top 100 Alexa domain is still infected by this veteran malware, are you?

iBackDoor: High-Risk Code Hits iOS Apps


FireEye mobile researchers recently discovered potentially “backdoored” versions of an ad library embedded in thousands of iOS apps originally published in the Apple App Store. The affected versions of this library embedded functionality in iOS apps that used the library to display ads, allowing for potential malicious access to sensitive user data and device functionality. NOTE: Apple has worked with us on the issue and has since removed the affected apps.

These potential backdoors could have been controlled remotely by loading JavaScript code from a remote server to perform the following actions on an iOS device:

  • Capture audio and screenshots
  • Monitor and upload device location
  • Read/delete/create/modify files in the app’s data container
  • Read/write/reset the app’s keychain (e.g., app password storage)
  • Post encrypted data to remote servers
  • Open URL schemes to identify and launch other apps installed on the device
  • “Side-load” non-App Store apps by prompting the user to click an “Install” button

The offending ad library contained identifying data suggesting that it is a version of the mobiSage SDK [1]. We found 17 distinct versions of the potentially backdoored ad library: version codes 5.3.3 to 6.4.4. However, in the latest mobiSage SDK publicly released by adSage [2] – version 7.0.5 – the potential backdoors are not present. It is unclear whether the potentially backdoored versions of the ad library were released by adSage or if they were created and/or compromised by a malicious third party.

As of November 4, we have identified 2,846 iOS apps containing the potentially backdoored versions of mobiSage SDK. Among these, we observed more than 900 attempts to contact an ad adSage server capable of delivering JavaScript code to control the backdoors. We notified Apple of the complete list of affected apps and technical details on October 21, 2015.

While we have not observed the ad server deliver any malicious commands intended to trigger the most sensitive capabilities such as recording audio or stealing sensitive data, affected apps periodically contact the server to check for new JavaScript code. In the wrong hands, malicious JavaScript code that triggers the potential backdoors could be posted to eventually be downloaded and executed by affected apps.

Technical Details

As shown in Figure 1, the affected mobiSage library included two key components, separately implemented in Objective-C and JavaScript. The Objective-C component, which we refer to as msageCore, implements the underlying functionality of the potential backdoors and exposed interfaces to the JavaScript context through a WebView. The JavaScript component, which we refer to as msageJS, provides high-level execution logic and can trigger the potential backdoors by invoking the interfaces exposed by msageCore. Each component has its own separate version number.

Figure 1: Key components of backdoored mobiSage SDK

In the remainder of this section, we reveal internal details of msageCore, including its communication channel and high-risk interfaces. Then we describe how msageJS is launched and updated, and how it can trigger the backdoors.

Backdoors in msageCore

Communication channel

MsageCore implements a general framework to communicate with msageJS via the ad library’s WebView. Commands and parameters are passed via specially crafted URLs in the format adsagejs://cmd&parameter. As shown in the reconstructed code fragment in Figure 2, msageCore fetches the command and parameters from the JavaScript context and inserts them in its command queue.

Figure 2: Communication via URL loading in WebView

To process a command in its queue, msageCore dispatches the command, along with its parameters, to a corresponding Objective-C class and method. Figure 3 shows portions of the reconstructed command dispatching code.

Figure 3: Command dispatch in msageCore

At-risk interfaces

Each dispatched command ultimately arrives at an Objective-C class in msageCore. Table 1 shows a subset of msageCore classes and the corresponding interfaces that they expose.

msageCore Class Name



- captureAudio:

- captureImage:

- openMail:

- openSMS:

- openApp:

- openInAppStore:

- openCamera:

- openImagePicker:

- ...


- start:

- stop:

- setTimer:

- returnLocationInfo:webViewId:

- ...



- createDir

- deleteDir:

- deleteFile:

- createFile:

- getFileContent:

- ...


- writeKeyValue:

- readValueByKey:

- resetValueByKey:


- sendHttpGet:

- sendHttpPost:

- sendHttpUpload:

- ...


- MD5Encrypt:

- SHA1Encrypt:

- AESEncrypt:

- AESDecrypt:

- DESEncrypt:

- DESDecrypt:

- XOREncrypt:

- XORDecrypt:

- RC4Encrypt:

- RC4Decrypt

- ...

Table 1: Selected interfaces exposed by msageCore

The selected interfaces reveal some of the key capabilities exposed by the potential backdoors in the library. They expose the potential ability to capture audio and screenshots while the affected app is in use, identify and launch other apps installed on the device, periodically monitor location, read and write files in the app’s data container, and read/write/reset “secure” keychain items stored by the app. Additionally, any data collected via these interfaces can be encrypted with various encryption schemes and uploaded to a remote server.

Beyond the selected interfaces, the ad library potentially exposed users to additional risks by including logic to promote and install “enpublic” apps as shown in Figure 4. As we have highlighted in previous blogs [footnotes 3, 4, 5, 6, 7], enpublic apps can introduce additional security risks by using private APIs in certain versions of iOS. These private APIs potentially allow for background monitoring of SMS or phone calls, breaking the app sandbox, stealing email messages, and demolishing arbitrary app installations. Apple has addressed a number of issues related to enpublic apps that we have brought to their attention.

Figure 4: Installing “enpublic” apps to bypass Apple App Store review

We can see how this ad library functions by examining the implementations of some of the selected interfaces. Figure 5 shows reconstructed code snippets for capturing audio. Before storing recorded audio to a file audio_xxx.wav, the code retrieves two parameters from the command for recording duration and threshold.

Figure 5: Capturing audio with duration and threshold

Figure 6 shows a code snippet for initializing the app’s keychain before reading. The accessed keychain is in the kSecClassGenericPassword class, which is widely used by apps for storing secret credentials such as passwords.

Figure 6: Reading the keychain in the kSecClassGenericPassword class

Remote control in msageJS

msageJS contains JavaScript code for communicating with a remote server and submitting commands to msageCore. The file layout of msageJS is shown in Figure 7. Inside sdkjs.js, we find a wrapper object called adsage and the JavaScript interface for command execution.

Figure 7: The file layout of msageJS

The command execution interface is constructed as follows:

          adsage.exec(className, methodName, argsList, onSuccess, onFailure);

The className and methodName parameters correspond to classes and methods in msageCore. The argsList parameter can be either a list or dict, and the exact types and values can be determined by reversing the methods in msageCore. The final two parameters are function callbacks invoked when the method exits. For example, the following invocation starts audio capture:

adsage.exec("MSageCoreUIManager", "captureAudio", ["Hey", 10, 40],  onSuccess, onFailure);

Note that the files comprising msageJS cannot be found by simply listing the files in an affected app’s IPA. The files themselves are zipped and encoded in Base64 in the data section of the ad library binary. After an affected app is launched, msageCore first decodes the string and extracts msageJS to the app’s data container, setting index.html shown in Figure 7 as the landing page in the ad library WebView to launch msageJS.

Figure 8: Base64 encoded JavaScript component in Zip format

When msageJS is launched, it sends a POST request to hxxp:// to check for updates. The server responds with information about the latest msageJS version, including a download URL, as shown in Figure 9.

Figure 9: Server response to msageJS update request via HTTP POST

Enterprise Protection

To ensure the protection of our customers, FireEye has deployed detection rules in its Network Security (NX) and Mobile Threat Prevention (MTP) products to identify the affected apps and their network activities.

For FireEye NX customers, alerts will be generated if an employee uses an infected app while their iOS device is connected to the corporate network. FireEye MTP management customers have full visibility into high-risk apps installed on mobile devices in their deployment base. End users will receive on-device notifications of the risky app and IT administrators receive email alerts.


In this blog, we described an ad library that affected thousands of iOS apps with potential backdoor functionality. We revealed the internals of backdoors which could be used to trigger audio recording, capture screenshots, prompt the user to side-load other high-risk apps, and read sensitive data from the app’s keychain, among other dubious capabilities. We also showed how these potential backdoors in ad libraries could be controlled remotely by JavaScript code should their ad servers fall under malicious actors’ control.


FLARE IDA Pro Script Series: MSDN Annotations Plugin for Malware Analysis

The FireEye Labs Advanced Reverse Engineering (FLARE) Team continues to share knowledge and tools with the community. We started this blog series with a script for Automatic Recovery of Constructed Strings in Malware. As always, you can download these scripts at the following location: We hope you find all these scripts as useful as we do.




During my summer internship with the FLARE team, my goal was to develop IDAPython plug-ins that speed up the reverse engineering workflow in IDA Pro. While analyzing malware samples with the team, I realized that a lot of time is spent looking up information about functions, arguments, and constants at the Microsoft Developer Network (MSDN) website. Frequently switching to the developer documentation can interrupt the reverse engineering process, so we thought about ways to integrate MSDN information into IDA Pro automatically. In this blog post we will release a script that does just that, and we will show you how to use it.




The MSDN Annotations plug-in integrates information about functions, arguments and return values into IDA Pro’s disassembly listing in the form of IDA comments. This allows the information to be integrated as seamlessly as possible. Additionally, the plug-in is able to automatically rename constants, which further speeds up the analyst workflow. The plug-in relies on an offline XML database file, which is generated from Microsoft’s documentation and IDA type library files.




Table 1 shows what benefit the plug-in provides to an analyst. On the left you can see IDA Pro’s standard disassembly: seven arguments get pushed onto the stack and then the CreateFileA function is called. Normally an analyst would have to look up function, argument and possibly constant descriptions in the documentation to understand what this code snippet is trying to accomplish. To obtain readable constant values, an analyst would be required to research the respective argument, import the corresponding standard enumeration into IDA and then manually rename each value. The right side of Table 1 shows the result of executing our plug-in showing the support it offers to an analyst.

The most obvious change is that constants are renamed automatically. In this example, 40000000h was automatically converted to GENERIC_WRITE. Additionally, each function argument is renamed to a unique name, so the corresponding description can be added to the disassembly.


Table 1: Automatic labelling of standard symbolic constants

In Figure 1 you can see how the plug-in enables you to display function, argument, and constant information right within the disassembly. The top image shows how hovering over the CreateFileA function displays a short description and the return value. In the middle image, hovering over the hTemplateFile argument displays the corresponding description. And in the bottom image, you can see how hovering over dwShareMode, the automatically renamed constant displays descriptive information.







Figure 1: Hovering function names, arguments and constants displays the respective descriptions


How it works


Before the plug-in makes any changes to the disassembly, it creates a backup of the current IDA database file (IDB). This file gets stored in the same directory as the current database and can be used to revert to the previous markup in case you do not like the changes or something goes wrong.

The plug-in is designed to run once on a sample before you start your analysis. It relies on an offline database generated from the MSDN documentation and IDA Pro type library (TIL) files. For every function reference in the import table, the plug-in annotates the function’s description and return value, adds argument descriptions, and renames constants. An example of an annotated import table is depicted in Figure 2. It shows how a descriptive comment is added to each API function call. In order to identify addresses of instructions that position arguments prior to a function call, the plug-in relies on IDA Pro’s markup.


Figure 2: Annotated import table

Figure 3 shows the additional .msdn segment the plug-in creates in order to store argument descriptions. This only impacts the IDA database file and does not modify the original binary.


Figure 3: The additional segment added to the IDA database

The .msdn segment stores the argument descriptions as shown in Figure 4. The unique argument names and their descriptive comments are sequentially added to the segment.


Figure 4: Names and comments inserted for argument descriptions

To allow the user to see constant descriptions by hovering over constants in the disassembly, the plug-in imports IDA Pro’s relevant standard enumeration and adds descriptive comments to the enumeration members. Figure 5 shows this for the MACRO_CREATE enumeration, which stores constants passed as dwCreationDisposition to CreateFileA.


Figure 5: Descriptions added to the constant enumeration members


Preparing the MSDN database file


The plug-in’s graphical interface requires you to have the QT framework and Python scripting installed. This is included with the IDA Pro 6.6 release. You can also set it up for IDA 6.5 as described here (

As mentioned earlier, the plug-in requires an XML database file storing the MSDN documentation. We cannot distribute the database file with the plug-in because Microsoft holds the copyright for it. However, we provide a script to generate the database file. It can be cloned from the git repository at together with the annotation plug-in.

You can take the following steps to setup the database file. You only have to do this once.



  1. Download and install an offline version of the MSDN documentationYou can download the Microsoft Windows SDK MSDN documentation. The standalone installer can be downloaded from Although it is not the newest SDK version, it includes all the needed information and data extraction is straight-forward.As shown in Figure 6, you can select to only install the help files. By default they are located in C:\Program Files\Microsoft SDKs\Windows\v7.0\Help\1033.



    Figure 6: Installing a local copy of the MSDN documentation


  2. Extract the files with an archive manager like 7-zip to a directory of your choice.
  3. Download and extract tilib.exe from Hex-Ray’s download page at 


    To allow the plug-in to rename constants, it needs to know which enumerations to import. IDA Pro stores this information in TIL files located in %IDADIR%/til/. Hex-Rays provides a tool (tilib) to show TIL file contents via their download page for registered users. Download the tilib archive and extract the binary into %IDADIR%. If you run tilib without any arguments and it displays its help message, the program is running correctly.

  4. Run MSDN_crawler/ <path to extracted MSDN documentation> <path to tilib.exe> <path to til files>



    With these prerequisites fulfilled, you can run the script, located in the MSDN_crawler directory. It expects the path to the TIL files you want to extract (normally %IDADIR%/til/pc/) and the path to the extracted MSDN documentation. After the script finishes execution the final XML database file should be located in the MSDN_data directory.



You can now run our plug-in to annotate your disassembly in IDA.

Running the MSDN annotations plug-in

In IDA, use File - Script file... (ALT + F7) to open the script named This will display the dialog box shown in Figure 7 that allows you to configure the modifications the plug-in performs. By default, the plug-in annotates functions, arguments and rename constants. If you change the settings and execute the plug-in by clicking OK, your settings get stored in a configuration file in the plug-in’s directory. This allows you to quickly run the plug-in on other samples using your preferred settings. If you do not choose to annotate functions and/or arguments, you will not be able to see the respective descriptions by hovering over the element.


Figure 7: The plug-in’s configuration window showing the default settings

When you choose to use repeatable comments for function name annotations, the description is visible in the disassembly listing, as shown in Figure 8.


Figure 8: The plug-in’s preview of function annotations with repeatable comments


Similar Tools and Known Limitations


Parts of our solution were inspired by existing IDA Pro plug-ins, such as IDAScope and IDAAPIHelp. A special thank you goes out to Zynamics for their MSDN crawler and the IDA importer which greatly supported our development.

Our plug-in has mainly been tested on IDA Pro for Windows, though it should work on all platforms. Due to the structure of the MSDN documentation and limitations of the MSDN crawler, not all constants can be parsed automatically. When you encounter missing information you can extend the annotation database by placing files with supplemental information into the MSDN_data directory. In order to be processed correctly, they have to be valid XML following the schema given in the main database file (msdn_data.xml). However, if you want to extend partly existing function information, you only have to add the additional fields. Name tags are mandatory for this, as they get used to identify the respective element.

For example, if the parser did not recognize a commonly used constant, we could add the information manually. For the CreateFileA function’s dwDesiredAccess argument the additional information could look similar to Listing 1.

















<?xml version="1.0" encoding="ISO-8859-1"?>








<constants enums="MACRO_GENERIC">




<description>All possible access rights</description>





<description>Execute access</description>





<description>Write access</description>





<description>Read access</description>










Listing 1: Additional information enhancing the dwDesiredAccess argument for the CreateFileA function




In this post, we showed how you can generate a MSDN database file used by our plug-in to automatically annotate information about functions, arguments and constants into IDA Pro’s disassembly. Furthermore, we talked about how the plug-in works, and how you can configure and customize it. We hope this speeds up your analysis process!

Stay tuned for the FLARE Team’s next post where we will release solutions for the FLARE On Challenge (


Havex, It’s Down With OPC

FireEye recently analyzed the capabilities of a variant of Havex (referred to by FireEye as “Fertger” or “PEACEPIPE”), the first publicized malware reported to actively scan OPC servers used for controlling SCADA (Supervisory Control and Data Acquisition) devices in critical infrastructure (e.g., water and electric utilities), energy, and manufacturing sectors.

While Havex itself is a somewhat simple PHP Remote Access Trojan (RAT) that has been analyzed by other sources, none of these have covered the scanning functionality that could impact SCADA devices and other industrial control systems (ICS). Specifically, this Havex variant targets servers involved in OPC (Object linking and embedding for Process Control) communication, a client/server technology widely used in process control systems (for example, to control water pumps, turbines, tanks, etc.).

Note: ICS is a general term that encompasses SCADA (Supervisory Control and Data Acquisition) systems, DCS (Distributed Control Systems), and other control system environments. The term SCADA is well-known to wider audiences, and throughout this article, ICS and SCADA will be used interchangeably.

Threat actors have leveraged Havex in attacks across the energy sector for over a year, but the full extent of industries and ICS systems affected by Havex is unknown. We decided to examine the OPC scanning component of Havex more closely, to better understand what happens when it’s executed and the possible implications.

OPC Testing Environment

To conduct a true test of the Havex variant’s functionality, we constructed an OPC server test environment that fully replicates a typical OPC server setup (Figure 1 [3]). As shown, ICS or SCADA systems involve OPC client software that interacts directly with an OPC server, which works in tandem with the PLC (Programmable Logic Controller) to control industrial hardware (such as a water pump, turbine, or tank). FireEye replicated both the hardware and software the OPC server setup (the components that appear within the dashed line on the right side of Figure 1).




Figure 1: Topology of typical OPC server setup

The components of our test environment are robust and comprehensive to the point that our system could be deployed in an environment to control actual SCADA devices. We utilized an Arduino Uno [1] as the primary hardware platform, acting as the OPC server. The Arduino Uno is an ideal platform for developing an ICS test environment because of the low power requirements, a large number of libraries to make programming the microcontroller easier, serial communication over USB, and cheap cost. We leveraged the OPC Server and libraries from St4makers [2] (as shown in Figure 2). This software is available for free to SCADA engineers to allow them to develop software to communicate information to and from SCADA devices.


Figure 2: OPC Server Setup

Using the OPC Server libraries allowed us to make the Arduino Uno act as a true, functioning OPC SCADA device (Figure 3).


Figure 3: Matrikon OPC Explorer showing Arduino OPC Server

We also used Matrikon’s OPC Explorer [1], which enables browsing between the Arduino OPC server and the Matrikon embedded simulation OPC server. In addition, the Explorer can be used to add certain data points to the SCADA device – in this case, the Arduino device.


Figure 4: Tags identified for OPC server

In the OPC testing environment, we created tags in order to simulate a true OPC server functioning. Tags, in relation to ICS devices, are single data points. For example: temperature, vibration, or fill level. Tags represent a single value monitored or controlled by the system at a single point in time.

With our test environment complete, we executed the malicious Havex “.dll" file and analyzed how Havex’s OPC scanning module might affect OPC servers it comes in contact with.


The particular Havex sample we looked at was a file named PE.dll (6bfc42f7cb1364ef0bfd749776ac6d38). When looking into the scanning functionality of the particular Havex sample, it directly scans for OPC servers, both on the server the sample was submitted on, and laterally, across the entire network.

The scanning process starts when the Havex downloader calls the runDll export function.  The OPC scanner module identifies potential OPC servers by using the Windows networking (WNet) functions.  Through recursive calls to WNetOpenEnum and WNetEnumResources, the scanner builds a list of all servers that are globally accessible through Windows networking.  The list of servers is then checked to determine if any of them host an interface to the Component Object Models (COM) listed below:




Screen Shot 2014-07-17 at 12.31.56 PM



Figure 5: Relevant COM objects

Once OPC servers are identified, the following CLSIDs are used to determine the capabilities of the OPC server:

Screen Shot 2014-07-17 at 12.33.22 PM

            Figure 6: CLSIDs used to determine capabilities of the OPC server

When executing PE.dll, all of the OPC server data output is first saved as %TEMP%\[random].tmp.dat. The results of a capability scan of an OPC server is stored in %TEMP%\OPCServer[random].txt. Files are not encrypted or deleted once the scanning process is complete.

Once the scanning completes, the log is deleted and the contents are encrypted and stored into a file named %TEMP%\[random].tmp.yls.  The encryption process uses an RSA public key obtained from the PE resource TYU.  The RSA key is used to protect a randomly generated 168-bit 3DES key that is used to encrypt the contents of the log.

The TYU resource is BZip2 compressed and XORed with the string “1312312”.  A decoded configuration for 6BFC42F7CB1364EF0BFD749776AC6D38 is included in the figure below:

Screen Shot 2014-07-17 at 12.27.24 PM

Figure 7: Sample decoded TYU resource

The 4409de445240923e05c5fa6fb4204 value is believed to be an RSA key identifier. The AASp1… value is the Base64 encoded RSA key.

A sample encrypted log file (%TEMP%\[random].tmp.yls) is below.














00000000  32 39 0a 66 00 66 00 30  00 30 00 66 00 66 00 30 29.f.f.0.0.f.f.000000010  00 30 00 66 00 66 00 30  00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000020  00 30 00 66 00 66 00 30  00 30 00 66 00 66 00 30 .0.f.f.0.0.f.f.000000030  00 30 00 66 00 66 00 30  00 30 00 66 00 37 39 36 .0.f.f.0.0.f.79600000040  0a 31 32 38 0a 96 26 cc  34 93 a5 4a 09 09 17 d3 .128..&.4..J....00000050  e0 bb 15 90 e8 5d cb 01  c0 33 c1 a4 41 72 5f a5 .....]...3..Ar_.00000060  13 43 69 62 cf a3 80 e3  6f ce 2f 95 d1 38 0f f2 .Cib....o./..8..00000070  56 b1 f9 5e 1d e1 43 92  61 f8 60 1d 06 04 ad f9 V..^..C.a.`.....00000080  66 98 1f eb e9 4c d3 cb  ee 4a 39 75 31 54 b8 02 f....L...J9u1T..00000090  b5 b6 4a 3c e3 77 26 6d  93 b9 66 45 4a 44 f7 a2 ..J<.w&m..fEJD..000000A0  08 6a 22 89 b7 d3 72 d4  1f 8d b6 80 2b d2 99 5d .j"...r.....+..]000000B0  61 87 c1 0c 47 27 6a 61  fc c5 ee 41 a5 ae 89 c3 a...G'ja...A....000000C0  9e 00 54 b9 46 b8 88 72  94 a3 95 c8 8e 5d fe 23 ..T.F..r.....].#000000D0  2d fb 48 85 d5 31 c7 65  f1 c4 47 75 6f 77 03 6b -.H..1.e..Guow.k


--Truncated--Probable Key Identifierff00ff00ff00ff00ff00ff00ff00fRSA Encrypted 3DES Key5A EB 13 80 FE A6 B9 A9 8A 0F 41…The 3DES key will be the last 24 bytes of the decrypted result.3DES IV88 72  94 a3 95 c8 8e 5d3DES Encrypted Logfe 23 2d fb 48 85 d5 31 c7 65 f1…

Figure 8: Sample encrypted .yls file


When executing PE.dll against the Arduino OPC server, we observe interesting responses within the plaintext %TEMP%\[random].tmp.dat:



Screen Shot 2014-07-17 at 12.41.27 PM



Figure 9: Sample scan log

The contents of the tmp.dat file are the results of the scan of the network devices, looking for OPC servers. These are not the in-depth results of the OPC servers themselves, and only perform the initial scanning.

The particular Havex sample in question also enumerates OPC tags and fully interrogates the OPC servers identified within %TEMP%\[random].tmp.dat. The particular fields queried are: server state, tag name, type, access, and id. The contents of a sample %TEMP%\OPCServer[random].txt can be found below:



Screen Shot 2014-07-17 at 12.43.48 PM



Figure 10: Contents of OPCServer[Random].txt OPC interrogation

While we don’t have a particular case study to prove the attacker’s next steps, it is likely after these files are created and saved, they will be exfiltrated to a command and control server for further processing.


Part of threat intelligence requires understanding all parts of a particular threat. This is why we took a closer look at the OPC functionality of this particular Havex variant.  We don’t have any case study showcasing why the OPC modules were included, and this is the first “in the wild” sample using OPC scanning. It is possible that these attackers could have used this malware as a testing ground for future utilization, however.

Since ICS networks typically don’t have a high-level of visibility into the environment, there are several ways to help minimize some of the risks associated with a threat like Havex. First, ICS environments need to have the ability to perform full packet capture ability. This gives incident responders and engineers better visibility should an incident occur.

Also, having mature incident processes for your ICS environment is important. Being able to have security engineers that also understand ICS environments during an incident is paramount. Finally, having trained professionals consistently perform security checks on ICS environments is helpful. This ensures standard sets of security protocols and best practices are followed within a highly secure environment.

We hope that this information will further educate industrial control systems owners and the security community about how the OPC functionality of this threat works and serves as the foundation for more investigation. Still, lots of questions remain about this component of Havex. What is the attack path? Who is behind it? What is their intention? We’re continuing to track this specific threat and will provide further updates as this new tactic unfolds.


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

Related MD5s





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

Executive Summary

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

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

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

Campaign Details


Figure 1: Attack Architecture

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

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

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


Figure 2 Email Sample


Figure 3 Email Headers

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

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

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

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


Figure 4 Worldwide Crimeware Activity


Figure 5 Overall Asprox Botnet tracking


Figure 6 Asprox Botnet Activity Unique Samples

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


Figure 7 FireEye Detection vs. Anti-Virus Detection

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


Figure 8 Asprox Campaign Unique Sample Tracking


Figure 9 Geographical Distribution of the Campaign


Figure 10 Distribution of Industries Affected

Brief Technical Analysis


Figure 11 Attack Architecture


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


Figure 12 Malware Payload Icon


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

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


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


Example filename:


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



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

Default Public Key






-----END PUBLIC KEY-----

First Communication Packet

Bot ID RC4 Encrypted URL

POST /5DBA62A2529A51B506D197253469FA745E7634B4FC


Accept: */*

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

User-Agent: <host useragent>

Host: <host ip>:443

Content-Length: 319

Cache-Control: no-cache


C2 Commands

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

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


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


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


if ( wcsicmp(Str1, L"ear")


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


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


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

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

C2 Campaign Characteristics


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

April May-June


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


Nart Villeneuve, Jessa dela Torre, and David Sancho. Asprox Reborn. Trend Micro. 2013.

The 2013 FireEye Advanced Threat Report!

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

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

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

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

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

Its insight is derived from:

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

FireEye 2013 Threat Report Final

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

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

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

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

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

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.

Feodo – A new botnet on the rise

We are seeing a trend where new banking trojans are emerging on the threat landscape very rapidly.  First came Bugat followed by Carberp.  Unfortunately, it is time to meet 'Feodo'. Since august of this year when FireEye's MPS devices detected this malware in the field, we have been monitoring this banking trojan very closely. In many ways, this malware looks similar to other famous banking trojans like Zbot and SpyEye.  Although my analysis says that this malware is not a toolkit and is in the hands of a single criminal group.

At the time of writing this article, AV coverage for this malware looks very disappointing. Out of 42 antivirus software listed on VirusTotal only two were able to detect it as malicious. Screenshot from VT:




Complete report can be found here: MD5: 557597074df3d3ce0e1674285ef19732

Here are some high level features offered by this malware:

1. Bot herders can supply a list of URLs (mostly of banking sites) so that the malware can start intercepting these web pages.  What this means is that whenever a user tries to visit these web sites, the malware will start submitting the web form data back to its CnC.  These web forms and the data inside them will be intercepted well before its gets encapsulated into HTTPS.  All the information including login credentials will be in hands of bot herders in plain text.

2. It's fully capable of Man in the Browser (MITB) attacks. This means that it can intercept original web contents coming from legitimate servers in order to append its own crafted HTML.  This is normally done to ask the user for more information than was originally requested by the actual server, like your PIN numbers, Social Security number etc.

3. It can also steal HTML pages from your browsing sessions.  Sound strange?  Well for any successful MITB attack, the attacker needs to know about the HTML being served by the legitimate server.  Just imagine an attacker wants to modify HTML pages for the Wells Fargo "Add New Payee" web page.  Unless the attacker himself has an account with Wells Fargo, he may not know the contents of this page.  By stealing this private page while a legitimate user is browsing to it, the attacker is in a perfect position to prepare his future MITB attack.

How does this all happen? Let's take a closer look.

At the time of writing this post, I can see that the bot herders are instructing its zombies to target over a dozen banks.  This is a huge list , I rarely see even bot herders behind Zbot targeting so many banks.

Configuration file:


Above is the configuration file for the malware containing all the web urls the bot herders want to intercept for information stealing.  In this list, one can see many famous banks like Wells Fargo, Bank Of America, Citibank etc.  Many other famous web sites like, Myspace, and Google mail are in the target list as well.


Stealing web forms:



Note: The above credentials are fake and were supplied by me to generate this particular scenario.

Stealing HTML pages:


I must say that with respect to the feature set, this malware is almost equivalent to other known banking trojans.  Although this malware may have few advantages over other famous banking trojans like Zbot and SpyEye.  First of all it's private code so unlike other tool kits it wont cost the bot herders thousands of dollars.  Unlike Zbot which has become a victim of its own success, this malware can fly under the radar for a long time. If the attackers want a new feature, they don't need to wait for a new toolkit version, a change can be made right away.

Atif Mushtaq @ FireEye Malware Intelligence Lab

Detailed Question/Comments : research SHIFT-2 fireeye DOT COM