Category Archives: Blog

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.

Cyber Security: Three Parts Art, One Part Science

As I reflect upon my almost 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.”

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 has 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

Protection:

People
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.

Process
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.

Technology
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.

Detection:

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.

People
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.

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

Technology
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?

Reaction:

People
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?

Process
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?

Technology
What cyber security consoles have been deployed that allow quick access to patch a system, change a firewall rule, switch ACL, 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.

The art in cyber security is in the interpretation of the rules, standards, and requirements that are primarily based on a foundation in science in some form. The more experience one has in the cyber security industry, the more effective the art becomes. As a last thought, keep in mind that Connection’s Technology Solutions Group Security Practice has over 150 years of cyber security expertise on tap to apply to that art.

The post Cyber Security: Three Parts Art, One Part Science 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.

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

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

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

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

Vulnerability Used to Target Russian Speakers

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

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

CVE-2017-8759 WSDL Parser Code Injection

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


Figure 1: Vulnerable WSDL Parser

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


Figure 2: SOAP definition VS Generated code

The In-the-Wild Attacks

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


Figure 3: SOAP Moniker

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


Figure 4: DLL loaded

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


Figure 5: Live requests

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


Figure 6: Process Created Chain

The Malware

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

Conclusion

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

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

Acknowledgement

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

Why Is North Korea So Interested in Bitcoin?,Why Is North Korea So Interested in Bitcoin?

In 2016 we began observing actors we believe to be North Korean utilizing their intrusion capabilities to conduct cyber crime, targeting banks and the global financial system. This marked a departure from previously observed activity of North Korean actors employing cyber espionage for traditional nation state activities. Yet, given North Korea's position as a pariah nation cut off from much of the global economy – as well as a nation that employs a government bureau to conduct illicit economic activity – this is not all that surprising. With North Korea's tight control of its military and intelligence capabilities, it is likely that this activity was carried out to fund the state or personal coffers of Pyongyang's elite, as international sanctions have constricted the Hermit Kingdom.

Now, we may be witnessing a second wave of this campaign: state-sponsored actors seeking to steal bitcoin and other virtual currencies as a means of evading sanctions and obtaining hard currencies to fund the regime. Since May 2017, Mandiant experts observed North Korean actors target at least three South Korean cryptocurrency exchanges with the suspected intent of stealing funds. The spearphishing we have observed in these cases often targets personal email accounts of employees at digital currency exchanges, frequently using tax-themed lures and deploying malware (PEACHPIT and similar variants) linked to North Korean actors suspected to be responsible for intrusions into global banks in 2016.

Add to that the ties between North Korean operators and a watering hole compromise of a bitcoin news site in 2016, as well as at least one instance of usage of a surreptitious cryptocurrency miner, and we begin to see a picture of North Korean interest in cryptocurrencies, an asset class in which bitcoin alone has increased over 400% since the beginning of this year.

2017 North Korean Activity Against South Korean Cryptocurrency Targets

  • April 22 – Four wallets on Yapizon, a South Korean cryptocurrency exchange, are compromised. (It is worth noting that at least some of the tactics, techniques, and procedures were reportedly employed during this compromise were different than those we have observed in following intrusion attempts and as of yet there are no clear indications of North Korean involvement).
  • April 26 – The United States announces a strategy of increased economic sanctions against North Korea. Sanctions from the international community could be driving North Korean interest in cryptocurrency, as discussed earlier.
  • Early May – Spearphishing against South Korean Exchange #1 begins.
  • Late May – South Korean Exchange #2 compromised via spearphish.
  • Early June – More suspected North Korean activity targeting unknown victims, believed to be cryptocurrency service providers in South Korea.
  • Early July – South Korean Exchange #3 targeted via spear phishing to personal account.

Benefits to Targeting Cryptocurrencies

While bitcoin and cryptocurrency exchanges may seem like odd targets for nation state actors interested in funding state coffers, some of the other illicit endeavors North Korea pursues further demonstrate interest in conducting financial crime on the regime’s behalf. North Korea's Office 39 is involved in activities such as gold smuggling, counterfeiting foreign currency, and even operating restaurants. Besides a focus on the global banking system and cryptocurrency exchanges, a recent report by a South Korean institute noted involvement by North Korean actors in targeting ATMs with malware, likely actors at the very least supporting similar ends.

If actors compromise an exchange itself (as opposed to an individual account or wallet) they potentially can move cryptocurrencies out of online wallets, swapping them for other, more anonymous cryptocurrencies or send them directly to other wallets on different exchanges to withdraw them in fiat currencies such as South Korean won, US dollars, or Chinese renminbi. As the regulatory environment around cryptocurrencies is still emerging, some exchanges in different jurisdictions may have lax anti-money laundering controls easing this process and make the exchanges an attractive tactic for anyone seeking hard currency.

Conclusion

As bitcoin and other cryptocurrencies have increased in value in the last year, nation states are beginning to take notice. Recently, an advisor to President Putin in Russia announced plans to raise funds to increase Russia's share of bitcoin mining, and senators in Australia's parliament have proposed developing their own national cryptocurrency.

Consequently, it should be no surprise that cryptocurrencies, as an emerging asset class, are becoming a target of interest by a regime that operates in many ways like a criminal enterprise. While at present North Korea is somewhat distinctive in both their willingness to engage in financial crime and their possession of cyber espionage capabilities, the uniqueness of this combination will likely not last long-term as rising cyber powers may see similar potential. Cyber criminals may no longer be the only nefarious actors in this space.

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

Introduction

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)

MD5

C04A7CB926CCBF829D0A36A91EBF91BD

.NET Obfuscator

Reactor

File Size

198 kB

File Type

Win32 EXE

Time Stamp

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

Code Size

199168

File Version

0.0.0.1

Internal Name

Diebold.exe

Legal Copyright

Copyright ©  2015

Original Filename

Diebold.exe

Product Name

Diebold

Product Version

0.0.0.1

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

Persistence

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)

MD5

5AF1F92832378772A7E3B07A0CAD4FC5

.NET Obfuscator

Reactor

File Size

274 kB

File Type

Win32 EXE

Time Stamp

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

Code Size

29696

OS Version

4.0

Image Version

0.0

Subsystem Version

4.0

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:

\HKLM\SOFTWARE\XFS\PHYSICAL_SERVICES\DBD_AdvFuncDisp\Denomination Table

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.

Conclusion

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.

IOCs

FileSystem:

[D-Z]:\Data\P.bin
C:\Diebold\EDC\edclocal.dat

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

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

Mutex names:

Ploutos
DIEBOLDPL
KaligniteAPP

Services:

Service Name: DIEBOLDP

Registry:

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

DHS and FBI Joint Analysis Report Confirms FireEye’s Assessment that Russian Government Likely Sponsors APT28 and APT29

On Dec. 29, 2016, the Department of Homeland Security (DHS) and Federal Bureau of Investigation (FBI) released a Joint Analysis Report confirming FireEye’s long held public assessment that the Russian government likely sponsors the groups that we track as Advanced Persistent Threat (APT) 28 and APT29. We have tracked and profiled these groups through multiple investigations, endpoint and network detections, and continuous monitoring, allowing us to understand the groups’ malware, operational changes and motivations. This intelligence has been critical to protecting and informing our clients and exposing this threat.

FireEye first publicly announced that the Russian government likely sponsors APT28 in a report released in October 2014. APT28 has pursued military and political targets in the U.S. and globally, including U.S. political organizations, anti-doping agencies, NGOs, foreign and defense ministries, defense attaches, media outlets, and high profile government and private sector entities. Since at least 2007, APT28 has conducted operations using a sophisticated set of malware that employs a flexible, modular framework allowing APT28 to consistently evolve its toolset for future operations. APT28’s operations closely align with Russian military interests and the 2016 breaches, and pursuant public data leaks demonstrate the Russian government's wide-ranging approach to advancing its strategic political interests.

In July 2015, we released a report focusing on a tool used by APT29, malware that we call HAMMERTOSS. In detailing the sophistication and attention to obfuscation evident in HAMMERTOSS, we sought to explain how APT29’s tool development effort defined a clandestine, well-resourced and state-sponsored effort. Additionally, we have observed APT29 target and breach entities including government agencies, universities, law firms and private sector targets. APT29 remains one of the most capable groups that we track, and the group’s past and recent activity is consistent with state espionage.

The Joint Analysis Report also includes indicators for another group we (then iSIGHT Partners) profiled publicly in 2014: Sandworm Team. Since 2009, this group has targeted entities in the energy, transportation and financial services industries. They have deployed destructive malware that impacted the power grid in Ukraine in late 2015 and used related malware to affect a Ukrainian ministry and other financial entities in December 2016. Chiefly characterized by their use of the well-known Black Energy trojan, Sandworm Team has often retrofitted publicly available malware to further their offensive operations. Sandworm Team has exhibited considerable skill and used extensive resources to conduct offensive operations. 

A Growing Number of Android Malware Families Believed to Have a Common Origin: A Study Based on Binary Code

Introduction

On Feb. 19, IBM XForce researchers released an intelligence report [1] stating that the source code for GM Bot was leaked to a crimeware forum in December 2015. GM Bot is a sophisticated Android malware family that emerged in the Russian-speaking cybercrime underground in late 2014. IBM also claimed that several Android malware families recently described in the security community were actually variants of GM Bot, including Bankosy[2], MazarBot[3], and the SlemBunk malware recently described by FireEye[4, 5].

Security vendors may differ in their definition of a malware “variant.” The term may refer to anything from almost identical code with slight modifications, to code that has superficial similarities (such as similar network traffic) yet is otherwise very different.

Using IBM’s reporting, we compared their GM Bot samples to SlemBunk. Based on the disassembled code of these two families, we agree that there are enough code similarities to indicate that GM Bot shares a common origin with SlemBunk. Interestingly, our research led us to identify an earlier malware family named SimpleLocker – the first known file-encryption ransomware on Android [6] – that also shares a common origin with these banking trojan families.

GM Bot and SlemBunk

Our analysis showed that the four GM Bot samples referenced by IBM researchers all share the same major components as SlemBunk. Figure 1 of our earlier report [4] is reproduced here, which shows the major components of SlemBunk and its corresponding class names:

  • ServiceStarter: An Android receiver that will be invoked once an app is launched or the device boots up. Its functionality is to start the monitoring service, MainService, in the background.
  • MainService: An Android service that runs in the background and monitors all running processes on the device. It prompts the user with an overlay view that resembles the legitimate app when that app is launched. This monitoring service also communicates with a remote host by sending the initial device data and notifying of device status and app preferences.
  • MessageReceiver: An Android receiver that handles incoming text messages. In addition to the functionality of intercepting the authentication code from the bank, this component also acts as the bot client for remote command and control (C2).
  • MyDeviceAdminReceiver: A receiver that requests administrator access to the Android device the first time the app is launched. This makes the app more difficult to remove.
  • Customized UI views: Activity classes that present fake login pages that mimic those of the real banking apps or social apps to phish for banking or social account credentials.

Figure 1. Major components of SlemBunk malware family

The first three GM Bot samples have the same package name as our SlemBunk sample. In addition, the GM Bot samples have five of the same major components, including the same component names, as the SlemBunk sample in Figure 1.

The fourth GM Bot sample has a different initial package name, but unpacks the real payload at runtime. The unpacked payload has the same major components as the SlemBunk sample, with a few minor changes on the class names: MessageReceiver replaced with buziabuzia, and MyDeviceAdminReceiver replaced with MDRA.

Figure 2. Code Structure Comparison between GM Bot and SlemBunk

Figure 2 shows the code structure similarity between one GM Bot sample and one SlemBunk sample (SHA256 9425fca578661392f3b12e1f1d83b8307bfb94340ae797c2f121d365852a775e and SHA256 e072a7a8d8e5a562342121408493937ecdedf6f357b1687e6da257f40d0c6b27 for GM Bot and SlemBunk, respectively). From this figure, we can see that the five major components we discussed in our previous post [4] are also present in GM Bot sample. Other common classes include:

  • Main, the launching activity of both samples.
  • MyApplication, the application class that starts before any other activities of both samples.
  • SDCardServiceStarter, another receiver that monitors the status of MainService and restarts it when it dies.

Among all the above components and classes, MainService is the most critical one. It is started by class Main at the launching time, keeps working in the background to monitor the top running process, and overlays a phishing view when a victim app (e.g., some mobile banking app) is recognized. To keep MainService running continuously, malware authors added two receivers – ServiceStarter and SDCardServiceStarter – to check its status when particular system events are received. Both GM Bot and SlemBunk samples share the same architecture. Figure 3 shows the major code of class SDCardServiceStarter to demonstrate how GM Bot and SlemBunk use the same mechanism to keep MainService running.

Figure 3. Method onReceive of SDCardServiceStarter for GM Bot and SlemBunk

From this figure, we can see that GM Bot and SlemBunk use almost identical code to keep MainService running. Note that both samples check the country in system locale and avoid starting MainService when they find the country is Russia. The only difference is that GM Bot applies renaming obfuscation to some classes, methods and fields. For example, static variable “MainService;->a” in GM Bot has the same role as static variable “MainService;->isRunning” in SlemBunk. Malware authors commonly use this trick to make their code harder to understand. However this won’t change the fact that the underlying codes share the same origin.

Figure 4 shows the core code of class MainService to demonstrate that GM Bot and SlemBunk actually have the same logic for main service. In Android, when a service is started its onCreate method will be called. In method onCreate of both samples, a static variable is first set to true. In GM Bot, this variable is named “a”, while in SlemBunk it is named “isRunning”. Then both will move forward to read an app particular preference. Note that the preferences in both samples have the same name: “AppPrefs”. The last tasks of these two main services are also the same. Specifically, in order to check whether any victim apps are running, a runnable thread is scheduled. If a victim app is running, a phishing view is overlaid on top of that of the victim app. The only difference here is also on the naming of the runnable thread. Class “d” in GM Bot and class “MainService$2” in SlemBunk are employed respectively to conduct the same credential phishing task.

Figure 4. Class MainService for GM Bot and SlemBunk

In summary, our investigation into the binary code similarities supports IBM’s assertion that GM Bot and SlemBunk share the same origin.

SimpleLocker and SlemBunk

IBM noted that GM Bot emerged in late 2014 in the Russian-speaking cybercrime underground. In our research, we noticed that an earlier piece of Android malware named SimpleLocker also has a code structure similar to SlemBunk and GM Bot. However, SimpleLocker has a different financial incentive: to demand a ransom from the victim. After landing on an Android device, SimpleLocker scans the device for certain file types, encrypts them, and then demands a ransom from the user in order to decrypt the files. Before SimpleLocker’s emergence, there were other types of Android ransomware that would lock the screen; however, SimpleLocker is believed to be the first file-encryption ransomware on Android.

The earliest report on SimpleLocker we identified was published by ESET in June 2014 [6]. However, we found an earlier sample in our malware database from May 2014 (SHA256 edff7bb1d351eafbe2b4af1242d11faf7262b87dfc619e977d2af482453b16cb). The compile date of this app was May 20, 2014. We compared this SimpleLocker sample to one of our SlemBunk samples (SHA256 f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96) using the same methods used to compare GM Bot and SlemBunk.

Figure 5 shows the code structure comparison between these two samples. Note that this SimpleLocker variant also has the major components ServiceStarter and MainService, both used by SlemBunk. However, the purpose of the main service here is not to monitor running apps and provide phishing UIs to steal banking credentials. Instead, SimpleLocker’s main service component scans the device for victim files and calls the file encryption class to encrypt files and demand a ransom. The major differences in the SimpleLocker code are shown in the red boxes: AesCrypt and FileEncryptor. Other common classes include:

  • Main, the launching activity of both samples.
  • SDCardServiceStarter, another receiver that monitors the status of MainService and restarts it when it dies.
  • Tor and OnionKit, third-party libraries for private communication.
  • TorSender, HttpSender and Utils, supporting classes to provide code for CnC communication and for collecting device information.

Figure 5. Code structure comparison between SimpleLocker and SlemBunk samples

Finally, we located another SimpleLocker sample (SHA256 304efc1f0b5b8c6c711c03a13d5d8b90755cec00cac1218a7a4a22b091ffb30b) from July 2014, about two months after the first SimpleLocker sample. This new sample did not use Tor for private communications, but shared four of the five major components as the SlemBunk sample (SHA256: f3341fc8d7248b3d4e58a3ee87e4e675b5f6fc37f28644a2c6ca9c4d11c92b96). Figure 6 shows the code structure comparison between these two samples.

Figure 6. Code structure comparison between SimpleLocker and SlemBunk variants

As we can see in Figure 6, the new SimpleLocker sample used a packaging mechanism similar to SlemBunk, putting HttpSender and Utils into a sub-package named “utils”. It also added two other major components that were originally only seen in SlemBunk: MessageReceiver and MyDeviceAdminReceiver. In total, this SimpleLocker variant shares four out of five major components with SlemBunk.

Figure 7 shows the major code of MessageReceiver in the previous samples to demonstrate that SimpleLocker and SlemBunk use basically the same process and logic to communicate with the CnC server. First, class MessageReceiver registers itself to handle incoming short messages, whose arrival will trigger its method onReceive. As seen from the figure, the main logics here are basically the same for SimpleLocker and SlemBunk. They first read the value of a particular key from app preferences. Note that the names for the key and shared preference are the same for these two different malware families: key is named “CHECKING_NUMBER_DONE” and preference named “AppPrefs”.  The following steps call method retrieveMessage to retrieve the short messages, and then forward the control flow to class SmsProcessor. The only difference here is that SimpleLocker adds one extra method named processControlCommand to forward control flow.

Class SmsProcessor defines the CnC commands supported by the malware families. Looking into class SmsProcessor, we identified more evidence that SimpleLocker and SlemBunk are of the same origin. First, the CnC commands supported by SimpleLocker are actually a subset of those supported by SlemBunk. In SimpleLocker, CnC commands include "intercept_sms_start", "intercept_sms_stop", "control_number" and "send_sms", all of which are also present in SlemBunk sample. What is more, in both SimpleLocker and SlemBunk there is a common prefix “#” before the actual CnC command. This kind of peculiarity is a good indicator that SimpleLocker and SlemBunk share a common origin.

Figure 7. Class MessageReceiver for SimpleLocker and SlemBunk variants

The task of class MyDeviceAdminReceiver is to request device administrator privilege, which makes these malware families harder to remove. SimpleLocker and SlemBunk are also highly similar in this respect, supporting the same set of device admin relevant functionalities.

At this point, we can see that these variants of SimpleLocker and SlemBunk share four out of five major components and share the same supporting utilities. The only difference is in the final payload, with SlemBunk phishing for banking credentials while SimpleLocker encrypts certain files and demands ransom. This leads us to believe that SimpleLocker came from the same original code base as SlemBunk.

Conclusion

Our analysis confirms that several Android malware families share a common origin, and that the first known file-encrypting ransomware for Android – SimpleLocker – is based on the same code as several banking trojans. Additional research may identify other related malware families.

Individual developers in the cybercrime underground have been proficient in writing and customizing malware. As we have shown, malware with specific and varied purposes can be built on a large base of shared code used for common functions such as gaining administrative privileges, starting and restarting services, and CnC communications. This is apparent simply from looking at known samples related to GM Bot – from SimpleLocker that is used for encryption and ransomware, to SlemBunk that is used as a banking Trojan and for credential theft, to the full-featured MazarBot backdoor.

With the leak of the GM Bot source code, the number of customized Android malware families based on this code will certainly increase. Binary code-based study, one of FireEye Labs’ major research tools, can help us better characterize and track malware families and their relationships, even without direct access to the source code. Fortunately, the similarities across these malware families make them easier to identify, ensuring that FireEye customers are well protected.

References:

[1]. Android Malware About to Get Worse: GM Bot Source Code Leaked
[2]. Android.Bankosy: All ears on voice call-based 2FA
[3]. MazarBOT: Top class Android datastealer
[4]. SLEMBUNK: AN EVOLVING ANDROID TROJAN FAMILY TARGETING USERS OF WORLDWIDE BANKING APPS
[5]. SLEMBUNK PART II: PROLONGED ATTACK CHAIN AND BETTER-ORGANIZED CAMPAIGN
[6]. ESET Analyzes Simplocker – First Android File-Encrypting, TOR-enabled Ransomware

 

iBackDoor: High-risk Code Sneaks into the App Store

The library embeds backdoors in unsuspecting apps that make use of it to display ads, exposing sensitive data and functionality. The backdoors can be controlled remotely by loading JavaScript code from remote servers to perform the following actions:

  • 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 contains identifying data suggesting that it is a version of the mobiSage SDK [1]. We found 17 distinct versions of the backdoored ad library, with version codes between 5.3.3 and 6.4.4. However, in the latest mobiSage SDK publicly released by adSage [2], identified as version 7.0.5, the backdoors are not present. We cannot determine with certainty whether the backdoored versions of the library were actually released by adSage, or whether they were created and/or compromised by a third party.

As of publication of this blog, we have identified 2846 apps published in the App Store containing backdoored versions of mobiSage SDK. Among these 2846 apps, we have observed over 900 attempt to contact their command and control (C2) server. We have notified Apple and provided the details to them.

These backdoors can be controlled not only by the original creators of the ad library, but potentially also by outside threat actors. While we have not observed commands from the C2 server intended to trigger the most sensitive capabilities such recording audio or stealing sensitive data, there are several ways that the backdoors could be abused by third-party targeted attackers to further compromise the security and privacy of the device and user:

  • An attacker could reverse-engineer the insecure HTTP-based control protocol between the ad library and its server, and then hijack the connection to insert commands to trigger the backdoors and steal sensitive information.
  • A malicious app developer can similarly inject commands, utilizing the library’s backdoors to build their own surveillance app. Since the ad library has passed the App Store review process in numerous apps, this is an attractive way to create an app with these hidden behaviors that will pass under Apple’s radar.

App Store Protections Ineffective

Despite Apple’s reputation for keeping malware out of the App Store with its strict review process, this case demonstrates that it is still possible for dangerous code that exposes users to critical security and privacy risks to sneak into the App Store by piggybacking on unsuspecting apps. Backdoors that enable silently recording audio and uploading sensitive data when triggered by downloaded code clearly violate the requirements of the iOS Developer Program [3]. The requirements state that apps are not permitted to download code or scripts, with the exception of scripts that “do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.” And, for apps that can record audio, “a reasonably conspicuous audio, visual or other indicator must be displayed to the user as part of the Application to indicate that a Recording is taking place.”  The backdoored versions of mobiSage clearly violate these requirements, yet thousands of affected apps made it past the App Store review process.

Technical Details

As shown in Figure 1, the backdoored mobiSage library includes 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 backdoors and exposes 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 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.

High-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

Interfaces

MSageCoreUIManagerPlugin

- captureAudio:

- captureImage:

- openMail:

- openSMS:

- openApp:

- openInAppStore:

- openCamera:

- openImagePicker:

- ...

MSageCoreLocation

- start:

- stop:

- setTimer:

- returnLocationInfo:webViewId:

- ...

MSageCorePluginFileModule

 

- createDir

- deleteDir:

- deleteFile:

- createFile:

- getFileContent:

- ...

MSageCoreKeyChain

- writeKeyValue:

- readValueByKey:

- resetValueByKey:

MSageCorePluginNetWork

- sendHttpGet:

- sendHttpPost:

- sendHttpUpload:

- ...

MSageCoreEncryptPlugin

- 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 backdoors in the library. They expose the 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 exposes users to additional risks by including explicit logic to promote and install “enpublic” apps shown in Figure 4. As we have highlighted in previous blogs [4, 5, 6, 7, 8], enpublic apps can introduce additional security risks by using private APIs, which would normally cause an app to be blocked by the App Store review process. In previous blogs we have described a number of “Masque” attacks utilizing enpublic apps [5, 6, 7], which affect pre-iOS 9 devices. The attacks include background monitoring of SMS or phone calls, breaking the app sandbox, stealing email messages, and demolishing arbitrary app installations.

 

 

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

 

We can observe the functionality of the ad library 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 C2 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://entry.adsage.com/d/ to check for updates. The server responds with information about the latest msageJS version, including a download URL, as shown in Figure 9. Note that since the request uses HTTP rather than HTTPS, the response can be hijacked easily by a network attacker, who could replace the download URL with a link to malicious JavaScript code that triggers the backdoors.

 

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

Conclusion

In this blog, we described a high-risk ad library affecting thousands of iOS apps in the Apple App Store. We revealed the internals of backdoors which can be used to silently record audio, 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 backdoors can be controlled remotely by JavaScript code fetched from the Internet in an insecure manner.

 

FireEye Protection

Immediately after we discovered the high-risk ad library and affected apps, FireEye updated detection rules in its NX and Mobile Threat Prevention (MTP) products to detect the affected apps and their network activities. In addition, FireEye customers can access the full list of affected apps upon request.

FireEye NX customers are alerted if an employee uses an infected app while their iOS device is connected to the corporate network. It is important to note that, even if the servers that the backdoored mobiSage SDK communicates with do not deliver JavaScript code that triggers the high-risk backdoors, the affected apps still try to connect to them using HTTP. This HTTP session is vulnerable to hijacking by outside attackers.

FireEye MTP management customers have full visibility into high-risk apps installed on mobile devices in their deployment base. End users receive on-device notifications of the detection and IT administrators receive email alerts.

Click here to learn more about FireEye Mobile Threat Protection product.

 

 

 

[1] http://www.adsage.com/mobisage

[2] http://www.adsage.cn/

[3] https://developer.apple.com/programs/ios/information/iOS_Program_Information_4_3_15.pdf [4] https://www.fireeye.com/blog/threat-research/2015/08/ios_masque_attackwe.html

[5] https://www.fireeye.com/blog/threat-research/2015/02/ios_masque_attackre.html

[6] https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html

[7] https://www.fireeye.com/blog/threat-research/2015/06/three_new_masqueatt.html

[8] https://www.virusbtn.com/virusbulletin/archive/2014/11/vb201411-Apple-without-shell

 

 

 

 

Second Adobe Flash Zero-Day CVE-2015-5122 from HackingTeam Exploited in Strategic Web Compromise Targeting Japanese Victims

On July 14, FireEye researchers discovered attacks exploiting the Adobe Flash vulnerability CVE-2015-5122, just four days after Adobe released a patch. CVE-2015-5122 was the second Adobe Flash zero-day revealed in the leak of HackingTeam’s internal data. The campaign targeted Japanese organizations by using at least two legitimate Japanese websites to host a strategic web compromise (SWC), where victims ultimately downloaded a variant of the SOGU malware.

Strategic Web Compromise

At least two different Japanese websites were compromised to host the exploit framework and malicious downloads:

  • Japan’s International Hospitality and Conference Service Association (IHCSA) website (hxxp://www.ihcsa[.]or[.]jp) in Figure 1

    Figure 1: IHCSA website

  • Japan’s Cosmetech Inc. website (hxxp://cosmetech[.]co[.]jp)

The main landing page for the attacks is a specific URL seeded on the IHCSA website (hxxp://www.ihcsa[.]or[.]jp/zaigaikoukan/zaigaikoukansencho-1/), where users are redirected to the HackingTeam Adobe Flash framework hosted on the second compromised Japanese website. We observed in the past week this same basic framework across several different SWCs exploiting the “older” CVE-2015-5119 Adobe Flash vulnerability in Figure 2.

    Figure 2: First portion of exploit chain

The webpage (hxxp://cosmetech[.]co[.]jp/css/movie.html) is built with the open source framework Adobe Flex and checks if the user has at least Adobe Flash Player version 11.4.0 installed. If the victim has the correct version of Flash, the user is directed to run a different, more in-depth profiling script (hxxp://cosmetech.co.jp/css/swfobject.js), which checks for several more conditions in addition to their version of Flash. If the conditions are not met then the script will not attempt to load the Adobe Flash (SWF) file into the user’s browser. In at least two of the incidents we observed, the victims were running Internet Explorer 11 on Windows 7 machines.

The final component is delivering a malicious SWF file, which we confirmed exploits CVE-2015-5122 on Adobe Version 18.0.0.203 for Windows in Figure 3.

    Figure 3: Malicious SWF download

SOGU Malware, Possible New Variant

After successful exploitation, the SWF file dropped a SOGU variant—a backdoor widely used by Chinese threat groups and also known as “Kaba”—in a temporary directory under “AppData\Local\”. The directory contains the properties and configuration in Figure 4.

    Filename: Rdws.exe

    Size: 413696 bytes

    MD5: 5a22e5aee4da2fe363b77f1351265a00

    Compile Time: 2015-07-13 08:11:01

    SHA256: df5f1b802d553cddd3b99d1901a87d0d1f42431b366cfb0ed25f465285e38d27

    SSDeep:6144:Na/PSOE9OPXCQpA3abFUntBrDP3FVPsCE2NiYfFei78GlGeYO:IPSOE9OPXCQ
    pAK5YBvPPPrZVkiY2Y

    Import Hash: ae984e4ab41d192d631d4f923d9210e4

    PEHash: 57e6b26eac0f34714252957d26287bc93ef07db2

    .text: e683e1f9fb674f97cf4420d15dc09a2b

    .rdata: 3a92b98a74d7ffb095fe70cf8acacc75

    .data: b5d4f68badfd6e3454f8ad29da54481f

    .rsrc: 474f9723420a3f2d0512b99932a50ca7

    C2 Password: gogogod<

    Memo: 201507122359

    Process Inject Targets: %windir%\system32\svchost.exe

    Sogu Config Encoder: sogu_20140307

    Mutex Name: ZucFCoeHa8KvZcj1FO838HN&*wz4xSdmm1

    Figure 4: SOGU Binary ‘Rdws.exe’

The compile timestamp indicates the malware was assembled on July 13, less than a day before we observed the SWC. We believe the time stamp in this case is likely genuine, based on the time line of the incident. The SOGU binary also appears to masquerade as a legitimate Trend Micro file named “VizorHtmlDialog.exe” in Figure 5.

    LegalCopyright: Copyright (C) 2009-2010 Trend Micro Incorporated. All rights reserved.

    InternalName: VizorHtmlDialog

    FileVersion: 3.0.0.1303

    CompanyName: Trend Micro Inc.

    PrivateBuild: Build 1303 - 8/8/2010

    LegalTrademarks: Trend Micro Titanium is a registered trademark of Trend Micro Incorporated.

    Comments:

    ProductName: Trend Micro Titanium

    SpecialBuild: 1303

    ProductVersion: 3.0

    FileDescription: Trend Titanium

    OriginalFilename: VizorHtmlDialog.exe

    Figure 5: Rdws.exe version information

The threat group likely used Trend Micro, a security software company headquartered in Japan, as the basis for the fake file version information deliberately, given the focus of this campaign on Japanese organizations.

SOGU Command and Control

The SOGU variant calls out to a previously unobserved command and control (CnC) domain, “amxil[.]opmuert[.]org” over port 443 in Figure 6. It uses modified DNS TXT record beaconing with an encoding we have not previously observed with SOGU malware, along with a non-standard header, indicating that this is possibly a new variant.

    Figure 6: SOGU C2 beaconing

The WHOIS registrant email address for the domain did not indicate any prior malicious activity, and the current IP resolution (54.169.89.240) is for an Amazon Web Services IP address.

Another Quick Turnaround on Leveraging HackingTeam Zero-Days

Similar to the short turnaround time highlighted in our blog on the recent APT3/APT18 phishing attacks, the threat actor quickly employed the leaked zero-day vulnerability into a SWC campaign. The threat group appears to have used procured and compromised infrastructure to target Japanese organizations. In two days we have observed at least two victims related to this attack.

We cannot confirm how the organizations were targeted, though similar incidents involving SWC and exploitation of the Flash vulnerability CVE-2015-5119 lured victims with phishing emails. Additionally, the limited popularity of the niche site also contributes to our suspicion that phishing emails may have been the lure, and not incidental web browsing.

Malware Overlap with Other Chinese Threat Groups

We believe that this is a concerted campaign against Japanese companies given the nature of the SWC. The use of SOGU malware and dissemination method is consistent with the tactics of Chinese APT groups that we track. Chinese APT groups have previously targeted the affected Japanese organizations, but we have yet to confirm which group is responsible for this campaign.

Why Japan?

In this case, we do not have enough information to discern specifically what the threat actors may have been pursuing. The Japanese economy’s technological innovation and strengths in high-tech and precision goods have attracted the interest of multiple Chinese APT groups, who almost certainly view Japanese companies as a rich source of intellectual property and competitive intelligence. The Japanese government and military organizations are also frequent targets of cyber espionage.[1]  Japan’s economic influence, alliance with the United States, regional disputes, and evolving defense policies make the Japanese government a dedicated target of foreign intelligence.

Recommendations

FireEye maintains endpoint and network detection for CVE-2015-5122 and the backdoor used in this campaign. FireEye products and services identify this activity as SOGU/Kaba within the user interface. Additionally, we highly recommend:

  • Applying Adobe’s newest patch for Flash immediately;
  • Querying for additional activity by the indicators from the compromised Japanese websites and the SOGU malware callbacks;
  • Blocking CnC addresses via outbound communications; and
  • Scope the environment to prepare for incident response.

     

    [1] Humber, Yuriy and Gearoid Reidy. “Yahoo Hacks Highlight Cyber Flaws Japan Rushing to Twart.” BloombergBusiness. 8 July 2014. http://www.bloomberg.com/news/articles/2014-07-08/yahoo-hacks-highlight-cyber-flaws-japan-rushing-to-thwart

    Japanese Ministry of Defense. “Trends Concerning Cyber Space.” Defense of Japan 2014.  http://www.mod.go.jp/e/publ/w_paper/pdf/2014/DOJ2014_1-2-5_web_1031.pdf

    LAC Corporation. “Cyber Grid View, Vol. 1.” http://www.lac.co.jp/security/report/pdf/apt_report_vol1_en.pdf

    Otake, Tomoko. “Japan Pension Service hack used classic attack method.” Japan Times. 2 June 2015. http://www.japantimes.co.jp/news/2015/06/02/national/social-issues/japan-pension-service-hack-used-classic-attack-method/

     

June 2 6/12/2015 Consulting Thought Leadership “Proactively Engaged – Questions Executives Should Ask Their Security Teams ” “-Many breaches occur as a result of executive decisions made w/out full knowledge of the people/processes needed to prevent them; -Offers specific questions that execs should ask to understand and prevent a breach” Jim Aldridge Kyrk Content Finalized Global June 2 6/12/2015 Consulting Thought Leadership “Proactively Engaged – Questions Executives Should Ask Their Security Teams ” “-Many breaches occur as a result of executive decisions made w/out full knowledge of the people/processes needed to prevent them; -Offers specific questions that execs should ask to understand and prevent a breach” Jim Aldridge Kyrk Content Finalized GlobCaching Out: The Value of Shimcache for Investigators

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: https://github.com/fireeye/flare-ida. We hope you find all these scripts as useful as we do.

 

Motivation

 

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.

 

Introduction

 

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.

 

Features

 

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.

flare1

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.

Functions

flare2

Arguments

flare3

Constants

flare4

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.

flare5

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.

flare6

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.

flare7

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.

flare8

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 (http://www.hexblog.com/?p=333).

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 https://github.com/fireeye/flare-ida 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 http://www.microsoft.com/en-us/download/details.aspx?id=18950. 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.

     

    flare9

    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 https://www.hex-rays.com/products/ida/support/download.shtml 

     

    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/msdn_crawler.py <path to extracted MSDN documentation> <path to tilib.exe> <path to til files>

     

     

    With these prerequisites fulfilled, you can run the MSDN_crawler.py 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.

  5.  

 

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 annotate_IDB_MSDN.py. 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.

flare10

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.

flare11

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"?>

<msdn>

<functions>

<function>

<name>CreateFileA</name>

<arguments>

<argument>

<name>dwDesiredAccess</name>

<constants enums="MACRO_GENERIC">

<constant>

<name>GENERIC_ALL</name>

<value>0x10000000</value>

<description>All possible access rights</description>

</constant>

<constant>

<name>GENERIC_EXECUTE</name>

<value>0x20000000</value>

<description>Execute access</description>

</constant>

<constant>

<name>GENERIC_WRITE</name>

<value>0x40000000</value>

<description>Write access</description>

</constant>

<constant>

<name>GENERIC_READ</name>

<value>0x80000000</value>

<description>Read access</description>

</constant>

</constants>

</argument>

</arguments>

</function>

</functions>

</msdn>

 

 

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

 

Conclusion

 

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 (www.flare-on.com).

 

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

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

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

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

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

Discovery

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

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

Mitigation

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

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

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

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

Vulnerability analysis

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

ASLR bypass

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

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

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

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

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

Shellcode analysis

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

PlugX/Kaba payload analysis

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

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

  • java.ns1[.]name
  • adservice.no-ip[.]org
  • wmi.ns01[.]us

Sample callback traffic was as follows:

POST /D28419029043311C6F8BF9F5 HTTP/1.1

Accept: */*

HHV1: 0

HHV2: 0

HHV3: 61456

HHV4: 1

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

Host: java.ns1.name

Content-Length: 0

Connection: Keep-Alive

Cache-Control: no-cache

Campaign analysis

Both java.ns1[.]name and adservice.no-ip[.]org resolved to 74.126.177.68 on Feb. 18, 2014. Passive DNS analysis reveals that the domain wmi.ns01.us previously resolved to 103.246.246.103 between July 4, 2013 and July 15, 2013 and 192.74.246.219 on Feb. 17, 2014.  java.ns1[.]name also resolved to 192.74.246.219 on February 18.

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

 

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

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

Domain First Seen Last Seen IP Address
fuckchina.govnb[.]com fuckchina.govnb[.]com 2013-12-11 2013-12-11 2013-12-11 2013-12-11 204.200.222.136 204.200.222.136
microsafes.no-ip[.]org microsafes.no-ip[.]org 2014-02-12 2014-02-12 2014-02-12 2014-02-12 74.126.177.70 74.126.177.70
microsafes.no-ip[.]org microsafes.no-ip[.]org 2013-12-04 2013-12-04 2013-12-04 2013-12-04 74.126.177.241 74.126.177.241

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

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

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

Domain First Seen Last Seen IP Address
wmi.ns01.us wmi.ns01.us 2012-07-07 2012-07-07 2012-09-19 2012-09-19 76.73.80.188 76.73.80.188
windows.ddns.us windows.ddns.us 2012-05-23 2012-05-23 2012-06-10 2012-06-10 76.73.80.188 76.73.80.188

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

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

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

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

greedywonk-campaign-v2

Conclusion

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

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

New Targeted Attack On Taiwanese Government & Tibetan Activists Open Up a Can Of Worms – GrayPigeon, Hangame & Shiqiang gang

We observed new targeted attacks targeting various personnel with pro-Tibetan views.  The targets? We’ve seen targets at various branches of the Taiwanese government as well as a professor at the Central University Of Tibetan Studies in India.

Taiwan is a logical target since they have a history of accepting Tibetan refugees. Also, the other target is a professor at the Central University Of Tibetan Studies in India—a institution founded by the first Prime Minister of India with the Dalai Lama himself. It was established in 1967 to educate exiled Tibetans and to preserve Tibetan culture and history.

The attackers, called the "Shiqiang gang", show a consistent modus operandi. They use similar remote administration tool (RAT) payloads, stolen certificates, and seem to target anyone pro-Tibetan. The RAT payload in this attack in called "GrayPigeon," also known as "Huigezi" in Chinese[2]. It is very popular in the Chinese webspace which indicates that the attackers speak the language. The RAT payload has multiple layers of encryption making it harder to identify.

Attack Vector:

The threat arrives in the form of a targeted email with an XLS attachment. The content  of the emails are as shown below in Figure 1 and Figure 2. The email attempts to draw on the sentiments of the Taiwanese government and activists towards the exiled members of the Tibetan government.

[caption id="attachment_1707" align="alignnone" width="584"] Figure 1[/caption]

 

[caption id="attachment_1708" align="alignnone" width="590"] Figure 2[/caption]

The content of both the emails are similar and roughly translate to:

 

To friends who care about the Tibetan government-in-exile

Now we publish this for you <<Tibetan government-in-exile offices in the Americas 2013 for the second half the year with detail list requesting for comments>>

Do not distribute this letter and this is only for friends who care about this

Also hope that you can actively participate in our activities in the second half of the year

                   Office of the Tibetan government-in-exile in the Americas

                    Chinese chief liaison officer Gongga Tashi kungatashi

 

Technical Analysis: How the Attack Works

The attached file in both emails is the same (2010790755b4aca0edc3c50ee8480c0b) When opened, the XLS file exploits CVE-2012-0158 and launches a decoy document as shown in Figure 3. The decoy document contains a ruse as usual and this time it states that Tibetan fonts are missing. In the background, it drops a series of files eventually leading to the launch and execution of 2013soft.dll. This in turn injects a RAT payload in to explorer.exe.

[caption id="attachment_1703" align="alignnone" width="629"] Figure 3[/caption]

Analysis of Payload:

The main functionality lies within 2013soft.dll (28426ddc3c49635c11a2ee72118e9814) and the subsequent DLL it decrypts and injects in to explorer.exe (05eda4aaa49b2409f52cf2356f4a91db).

On inspection of 2013soft.dll, it is evident that this payload contains a rather large resource section. The MAIN stub in resource section holds large amount of data however it appears to be encrypted.

[caption id="attachment_1710" align="alignnone" width="648"] Figure 4[/caption]

On dynamic analysis of the payload, it becomes clear that the Main stub eventually decrypts to the final DLL payload. The stub is loaded into memory and decrypted using the loop shown in Figure 5. It operates on 8 bytes of data at a time and uses the 16 bytes key "1234567890ABCDEF". This, in addition to that fact that it uses the constant value 0x9E3779B9, gives away the algorithm as TEA (Tiny encryption algorithm). The TEA algorithm uses this value as the Delta constant.

[caption id="attachment_1711" align="alignnone" width="427"] Figure 5[/caption]

It then jumps to the decrypted stub after setting the memory region it resides in as executable. The start of this decrypted MAIN stub contains an XOR decryption loop shown in Figure 6. This decryption loop decrypts the remainder of the stub. Notice how the XOR key "0x27691C" is only 3 bytes in length but the EAX pointer is incremented by 4. This means the first byte in every 4 bytes (little endian) is not subjected to XOR.

[caption id="attachment_1713" align="alignnone" width="421"] Figure 6[/caption]

You would think we have the payload after two levels of decryption but not in this case. It jumps to another shellcode, which performs a rolling byte XOR decryption using a 4 byte key on the latter part of the stub.

[caption id="attachment_1714" align="alignnone" width="465"] Figure 7[/caption]

Now we are getting somewhere as we can see an MZ file header interspersed with other characters past the "MinxxxA" marker as shown in Figure 8. This data is then subjected to what appears to be a custom decompression algorithm, following which it is injected into a new instance of explorer.exe

[caption id="attachment_1709" align="alignnone" width="567"] Figure 8[/caption]

The injected DLL payload is a variant of the RAT called "GrayPigeon"[2] also known as "Huigezi" which is popular in the Chinese web space. It is written in Delphi and contains comprehensive functionality. The RAT uses various Pascal modules [3] such as "TscreenCaptureUnit.pas" and "UnitServices.pas" also widely seen on Chinese forums and associated with this RAT.

It creates a mutex "\BaseNamedObjects\windows!@#$" and sets up startup persistence by adding a registry key "\Software\ts\Explorer\run\2013Soft\run = rundll32.exe C:\WINDOWS\2013soft.dll,Player". In this case the RAT was observed key logging and storing the data under C:\WINDOWS\2013soft.log along with the corresponding Window names.

It then uses the same TEA (Tiny Encryption algorithm) described earlier to decrypt the address of the command and control server "help.2012hi.hk". It reuses the key "1234567890ABCDEF" for TEA decryption. It makes a DNS query specifically to Google’s DNS server 8.8.8.8 and it attempts to connect to the resolved server on port 91.

[caption id="attachment_1706" align="alignnone" width="720"] Figure 9[/caption]

We observed the following outbound communication on port 91.

[caption id="attachment_1712" align="alignnone" width="576"] Figure 10[/caption]

This GrayPigeon RAT instance we analyzed had extensive functionality and a summary of the features is listed below:

  • Determine Host name and OS version
  • Ability to log keystrokes and mouse events
  • Ability to capture users screen
  • Ability to use Telnet protocol
  • Ability to send and receive files
  • Sniff URL addresses from Internet Explorer and read form values
  • Get list of active services
  • Ability to shutdown/restart etc.

Connection to Shiqiang Gang:

We mined for other samples talking to the same C&C infrastructure and we found two with the md5sums 4e454584403d5521abea98d21ee26f72 and 7de5485b7dd154a9bbd85e7d5fcdbdec which drop Hangame RAT and GrayPigeon RAT respectively. The RAT payloads in these instances also phone home to help.2012hi.hk. This C&C domain was also referenced in a white paper published by Symantec as part of the overall campaign coined the Elderwood project [4]. The campaign in the current instance and related samples are more in line with Tibetan themed attacks on NGOs and Taiwanese officials. The campaign also heavily uses stolen certificates. These have been attributed with the Shiqiang gang as discussed by Snorre Fagerland from Norman[1] and also discussed by Trend [5] and AlienVault [6].

[caption id="attachment_1705" align="alignnone" width="582"] Figure 11[/caption]

The decoy document associated with 7de5485b7dd154a9bbd85e7d5fcdbdec also has a Taiwanese target as evident from the contents of the document.

[caption id="attachment_1704" align="alignnone" width="791"] Figure 12[/caption]

Also, both these two variants interestingly have digital certificates in the payload [1]. The certificate for 4e454584403d5521abea98d21ee26f72 is a stolen certificate that has already been revoked.

 

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            38:93:f1:3d:d3:9f:e0:88:fd:f5:4e:e0:08:ae:38:e1

        Signature Algorithm: sha1WithRSAEncryption

        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA

        Validity

            Not Before: Dec  8 00:00:00 2011 GMT

            Not After : Dec  7 23:59:59 2012 GMT

        Subject: C=CN, ST=Guangdong, L=Shenzhen, O=Shenzhen Xuri Weiye Technology Co., Ltd., OU=Digital ID Class 3 - Microsoft Software Validation v2, CN=Shenzhen Xuri Weiye Technology Co., Ltd.

 

The certificate for 7de5485b7dd154a9bbd85e7d5fcdbdec appears to be modified manually and is invalid.

 

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            02:fe:4b:0a:55:23:56:65

        Signature Algorithm: sha1WithRSAEncryption

        Issuer: C=CN, ST=Beijing, L=Beijing, O=CA365, CN=CA365 Free Root Certificate

        Validity

            Not Before: Oct 23 10:47:29 2010 GMT

            Not After : Oct 23 10:47:29 2011 GMT

        Subject: C=CN, ST=shanghai, L=shanghai, O=International Test User, OU=Market, CN=International Test User

 

 Hashes of Analyzed Samples:

References:

[2] http://baike.baidu.com/view/25407.htm

[3] http://en.verysource.com/classicgraypigeoncon-191546.html

[4] http://www.symantec.com/connect/blogs/elderwood-project

[5] http://blog.trendmicro.com/trendlabs-security-intelligence/cve-2012-0158-now-being-used-in-more-tibetan-themed-targeted-attack-campaigns/

[6] http://labs.alienvault.com/labs/index.php/2012/cve-2012-0158-tibet-targeted-attacks-and-so-on/

I would like to thank Darien Kindlund for his assistance in research.