Executive Summary

• SentinelLABS has analyzed a Rust macOS implant that embeds a 3.5 KB prompt-injection payload of 38 fabricated “system” messages, built to steer an LLM-assisted triage pipeline into aborting or refusing its analysis.
• Command-and-control runs over a Telegram Bot API polling loop, with AES-GCM payloads over certificate-pinned TLS.
• The implant self-redacts its Telegram bot token in its own runtime output, denying it to anyone who captures logs or crash artifacts.
• We assess with high confidence that the implant, which we track as macOS.Gaslight, belongs to a cluster of DPRK-aligned macOS activity.

Introduction

In early June, an Apple XProtect update surfaced a Mach-O sample that had been uploaded to VirusTotal on May 22. The XProtect rule targets the file purely on its hash rather than on any internal strings or bytecode, yet the sample remains undetected by static engines on VirusTotal at the time of writing. The binary is ad hoc signed and carries the identifier endpoint-macos-aarch64-5555494492fc075f441637fb9d894913dde3a2ea.

The sample is a macOS implant and infostealer written in Rust. Its most notable feature is an embedded cascade of fabricated system-failure messages, designed to make an LLM-assisted triage agent doubt its own session. It attacks the agent’s perception, rather than the sandbox it runs in. Accordingly, we dub this family macOS.Gaslight.

We assess with high confidence that this implant sits within a cluster of DPRK-aligned macOS activity. Apple’s XProtect detects the sample under the rule MACOS_BONZAI_COBUCH, and SentinelLABS associates the BONZAI signature family with North Korean threat activity. A sibling BONZAI sample is additionally caught by Apple’s AIRPIPE rule, a family SentinelLABS likewise ties to North Korean activity.

Command & Control | Telegram Bot API

The implant’s command-and-control channel is a Telegram Bot API getUpdates polling loop. The polling branch executes only when no webhook is registered, and the dispatch handler keys on three Telegram error codes: BotBlocked, InvalidToken, and Conflict.

Telegram issues a Conflict response when two instances of the same bot token poll simultaneously, so the implant treats that response as an implicit single-instance lock. A second copy detects the conflict and terminates.

Once the bot token validates and the polling loop is active, the operator can task the implant, including through the interactive shell described below, and collected data is returned over the same channel using Telegram’s multipart attach:// file-upload mechanism.

The bot token, the chat ID (tg_room_id), and the rest of the operator configuration are supplied at runtime and are absent from this sample. Accordingly, the analysis below is based on static examination of the binary and its embedded payloads.

Transport Hardening | AES-GCM Over Pinned TLS

All C2 payloads are encrypted with AES-GCM, implemented using the pure-Rust aes-gcm 0.10.3 crate, with a fresh nonce generated per message via CCRandomGenerateBytes. The AES key is supplied at runtime through the aes_key field in the operator config rather than being embedded in the sample.

On top of the payload encryption, the implant configures a custom certificate trust anchor and calls SecTrustSetAnchorCertificatesOnly, restricting TLS trust evaluation to that anchor alone. This certificate pinning rejects connections intercepted by a standard proxy CA, frustrating network-level inspection of the operator’s traffic.

The implant also honors the host’s proxy settings, reading the active system proxy configuration via SCDynamicStoreCopyProxies and routing the traffic from its Rust reqwest/hyper networking stack accordingly. As a result, the C2 can still reach the operator on networks that force outbound connections through a proxy.

Taken together, those choices make the channel harder to inspect in transit while still allowing it to operate in tightly managed enterprise networks.

Operator Access | An Interactive Shell

After validation and activation, the operator gains an interactive shell. Two co-located command menus define six verbs.

There is some evidence of a seventh command, focus, but we were unable to recover further details from our analysis.

The implant creates an IOPMAssertionCreateWithName power-management assertion to prevent system sleep. Blocking sleep sustains long-running C2 polling and collection across periods of user inactivity, making the implant resilient to a host that would otherwise idle.

All told, the functionality provides the operator with a persistent, interactive foothold on the host.

The 15-Field Cross-Platform Operator Config

The implant reads its operator configuration using serde, a widely used Rust serialization and deserialization framework.

The operator provides the implant with a config blob at runtime and serde fills in a predefined set of fields. By default, serde matches incoming config keys to fields by their literal names, so the entire configuration schema of 15 field names is baked into the binary as plaintext.

tg_room_id           	
github_token         	
github_repo          	
github_polling_interval 
main_upload_url      	
main_base_url        	
aes_key              	
payload_path_linux   	
payload_path_macos   	
persist_name_linux   	
persist_name_macos   	
persist_type_linux   	
persist_type_macos   	
init_python_enable   	
persist_enable       	

The Linux- and GitHub-related fields are not exercised in the sample, suggesting the schema is an operator-facing interface to a broader toolset.

Collection | A Gated Python Stealer With Its Own Runtime Supply Chain

The implant carries a 6.6 KB base64-encoded Python script which serves as a data collection module. Once decoded, it harvests:

• Chrome, Brave, Firefox, and Safari browser data
• Terminal command histories
• Installed application listings
• A running-process snapshot via ps aux
• System hardware and software profile via system_profiler
• A raw copy of login.keychain-db

Collected artifacts are archived to temp/collected_data.zip and uploaded to the operator via Telegram.

SentinelLABS has previously documented Atomic macOS Stealer (AMOS) harvesting the same login keychain copy and browser data and an early Rust macOS stealer targeting login.keychain-db in 2023.

A separate 2 KB base64-encoded bash installer fetches and stages a self-contained cpython-3.10.18 interpreter from the astral-sh/python-build-standalone project. The installer, a prerequisite for deploying the Python stealer, carries the literal constants PY_VERSION=3.10.18 and BUILD_DATE=20250708 and targets both arm64 and x86_64 macOS. The widespread use of emojis and strict adherence to comment headers are consistent with LLM-generated output.

Microsoft has previously described macOS stealers bundling Python via PyInstaller and Nuitka. However, fetching a standalone CPython build from astral-sh/python-build-standalone at runtime has not been previously documented as far as we are aware. The separation keeps the main implant in Rust while letting the operator stage a fuller Python-based collection environment only when needed.

We identified init_python_enable in the serde schema as the configuration field associated with both the stealer and installer. Consistent with our earlier observations, we found no exact runtime branch logic, so we describe both only as configurable capabilities present in the binary.

Persistence | An Apple System-Service Masquerade

Persistence is achieved through a LaunchAgent. This implant’s plist carries the Label value com.apple.system.services.activity. Masquerading within Apple’s com.apple.* namespace is a tactic widely used in many macOS malware families, including those previously tied to DPRK-linked activities.

In order to write a valid absolute path to itself into the plist’s ProgramArguments array, the implant resolves its own executable location at runtime via __NSGetExecutablePath.

The implant’s persistence behavior is controlled through the persist_enable serde config field, and again we did not recover a separate static branch that would confirm exactly how installation is triggered in this sample.

OPSEC | Bot-Token Self-Redaction

Telegram bot tokens are a known weak point in bot-based C2. If the token can be recovered, defenders can use it as a detection artifact and even query the Telegram Bot API directly, exposing the bot’s chat history, operator commands, and registered webhooks. macOS.Gaslight addresses this with a self-redaction routine built into its Telegram URL constructor.

When the URL path segment is the 4-byte literal “file” (0x656c6966 little-endian), the constructor substitutes the token that follows with the hardcoded placeholder file/token:redacted, preventing the live bot credential from appearing in any diagnostic output or error string the implant produces at runtime.

The logic prevents anyone who captures the process’s logs, errors, or crash artifacts from determining the bot token, which otherwise is only available in the config itself and cannot be recovered from the sample.

NVISO Labs has previously noted that most documented Telegram bot abuse embeds recoverable tokens; macOS.Gaslight’s runtime self-redaction appears novel relative to that reporting.

A Prompt Injection That Targets the Analyst

The implant does little conventional anti-analysis. It resolves its API calls at runtime through dlsym so as to avoid embedding them in the static symbol table, and it locates its own executable dynamically rather than from a hardcoded path.

What makes the sample notable is its attempt to mislead the analyst reading the output. It carries a 3.5 KB Markdown-fenced blob of hostile data containing 38 fabricated “system” messages delimited with {{DATA}} tokens.

The {{DATA}} tokens and the surrounding Markdown fence mimic an LLM triage harness’s own prompt scaffold, blurring the boundary between untrusted sample data and trusted instructions.

The scaffold contains fake system messages about token expiry, out-of-memory kills, disk exhaustion, and repeated operation failures. It also plants bogus warnings about injection vulnerabilities and static-analysis flags. The aim is to push an LLM agent into aborting, truncating, or refusing analysis.

Check Point first documented this kind of analyst-targeting prompt injection publicly in 2025, describing a Windows proof-of-concept that used a single direct-instruction prompt injection to evade AI-based detection.

Socket has since documented a Hades supply-chain payload whose stealer opens with a fake prompt-injection header to pollute AI-assisted analysis, while the leaked Shai-Hulud code carried an “Anthropic Magic String” intended to stop Claude Code from analyzing it. Each relied on a single injected block or header rather than the 38-message harness-spoofing cascade seen here.

Previous SentinelLABS research, by contrast, examined malware that uses LLMs to generate or support capability at runtime rather than interfere with analyst tooling.

Conclusion

macOS.Gaslight packs considerable capability into a single, persistent Rust binary, bundling a credential and session-data stealer, an interactive shell, and a self-staged Python collection chain behind a hardened Telegram C2. Aside from the runtime-fetched standalone CPython interpreter, these are all established macOS tradecraft.

However, macOS.Gaslight is noteworthy for its analyst-targeting prompt injection, an attempt to weaponize the LLM-assisted triage pipelines that increasingly sit in the reverse-engineering loop.

Anyone building such tooling should treat the contents of the samples they triage as adversarial input, never as instructions, and be prepared to keep hostile content out of the model entirely. As LLM-assisted analysis becomes routine, defenders should expect more samples built to exploit it.

Indicators of Compromise

Executive Summary

• DPRK threat actors are utilizing Nim-compiled binaries and multiple attack chains in a campaign targeting Web3 and Crypto-related businesses.
• Unusually for macOS malware, the threat actors employ a process injection technique and remote communications via wss, the TLS-encrypted version of the WebSocket protocol.
•  A novel persistence mechanism takes advantage of SIGINT/SIGTERM signal handlers to install persistence when the malware is terminated or the system rebooted.
• The threat actors deploy AppleScripts widely, both to gain initial access and also later in the attack chain to function as lightweight beacons and backdoors.
• Bash scripts are used to exfiltrate Keychain credentials, browser data and Telegram user data.
• SentinelLABS’ analysis highlights novel TTPs and malware artifacts that tie together previously reported components, extending our understanding of the threat actors’ evolving playbook.

In April 2025, Huntabil.IT observed a targeted attack on a Web3 startup, attributing the incident to a DPRK threat actor group. Several reports on social media at the time described similar incidents at other Web3 and Crypto organizations. Analysis revealed an attack chain consisting of an eclectic mix of scripts and binaries written in AppleScript, C++ and Nim. Although the early stages of the attack follow a familiar DPRK pattern using social engineering, lure scripts and fake updates, the use of Nim-compiled binaries on macOS is a more unusual choice. A report by Huntress in mid-June described a similar initial attack chain as observed by Huntabil.IT, albeit using different later stage payloads.

SentinelLABS’ analysis of the payloads used in the April incidents shows the Nim stages contain some unique features including encrypted configuration handling, asynchronous execution built around Nim’s native runtime, and a signal-based persistence mechanism previously unseen in macOS malware.

In this post, we provide an overview of the attack chain and a technical analysis of the C++ and Nim-based components. We refer to this family of malware collectively as NimDoor, based on its functionality and development traits. Indicators of compromise and insights into the malware’s architecture are provided to aid defenders and threat hunters in identifying related activity.

Initial Access and Payload Delivery

The attack chain begins with a now-familiar social engineering vector: impersonation of a trusted contact over Telegram and inviting the target to schedule a meeting via Calendly. The target is subsequently sent an email containing a Zoom meeting link and instructions to run a so-called “Zoom SDK update script”.

An attacker-controlled domain hosts an AppleScript file named zoom_sdk_support.scpt. Variants of this script can be found in public malware repositories through the seemingly unintentional typo in a code comment: - - Zook SDK Update instead of - - Zoom SDK Update. The file is heavily padded, containing 10,000 lines of whitespace to obfuscate its true function.

The script ends with three lines of malicious code that retrieve and execute a second-stage script from a command-and-control server hosted at support.us05web-zoom[.]forum. This domain name format has been chosen for similarity to the legitimate Zoom meeting domain us05web.zoom[.]us.

Our analysis found a number of parallel domains in use by the same actor.

support.us05web-zoom[.]pro
support.us05web-zoom[.]forum
support.us05web-zoom[.]cloud
support.us06web-zoom[.]online

The follow-on script downloads an HTML file named check, which includes a legitimate Zoom redirect link.

<a ref="https://us05web.zoom[.]us/j/4724012536?pwd=ADlAXdxkUclRhvYoJbpKQmizkQ1RV4.1">Temporary Redirect</a>

This HTML file is passed to curl and executed via run script, ultimately launching the attack’s core logic.

Researchers at Validin have also recently published extended indicators around this and associated infrastructure. The posts by Huntabil.IT and Huntress mentioned earlier describe much the same initial attack chain. However, the second part of the attack chain is where things begin to get both different and increasingly complex.

Execution Chain and File Deployment

The multi-staged infection process Huntabil.IT observed resulted in the download of two Mach-O binaries—a and installer—into /private/var/tmp. These two binaries set off two independent execution chains.

In the first, the a binary is a C++-compiled universal architecture Mach-O executable. It writes an encrypted embedded payload called netchk to disk. The execution from here involves a complex chain of obfuscation and distraction which we describe in the following section. Ultimately, the aim is to fetch two Bash scripts used for data exfiltration. These include mechanisms for scraping general system data as well as application-specific data like browser data and Telegram chat histories. All operations are staged from a folder created at ~/Library/DnsService.

The second execution chain starts with the installer binary, which is also a universal Mach-O executable compiled from Nim source code, and is responsible for persistence setup. It drops two additional Nim-compiled binaries: GoogIe LLC (where “GoogIe” is spelled using a deceptive capital “i” rather than a lowercase ‘L’) and CoreKitAgent. These payloads orchestrate long-term access and recovery mechanisms for the threat actor.

Technical Analysis of a, netchk and trojan1_arm64

Both Huntabil.IT and Huntress describe use of a C++-compiled binary with the name a being deposited as a result of initial infection through the fake Zoom update scripts described earlier.

The a binary is ad hoc signed and carries the identifier InjectWithDyldArm64. As reported by previous researchers, it can take a command line argument --d, which results in the deletion of a‘s current working directory, or a file name and password. In the Huntabil.IT post, this was reported as:

./a ./netchk gift123$%^

The InjectWithDyldArm64 (aka a) binary uses Password-Based Key Derivation Function 2 (PBKDF2) with HMAC-SHA-256 to derive a 32-byte key from the password gift123$%^, using 10000 iterations and a salt consisting of the first sixteen characters of the embedded base64 string.

The derived key and the base64 decoded encrypted data are passed to the AesEncrypt function, which iterates through 16 byte blocks of the encrypted data. On each iteration it:

• calls AesTrans, a wrapper for CCCrypt, to perform an AES encryption in CBC mode with the derived key and a zero-filled initialization vector. In the first iteration the data to be encrypted is the key itself, but in subsequent iterations the input data is taken from the previous AesTrans call.
• XORs the current encrypted data block with the current AesTrans result.

SentinelLABS’ analysis shows that this process is used to decrypt two embedded binaries. The first carries an ad hoc signature and the identifier Target. The second has an ad hoc signature with the identifier trojan1_arm64. The Target binary is benign and appears to do nothing other than generate random numbers.

However, Target is spawned by InjectWithDyldArm64 in a suspended state via

posix_spawnattr_init(&attrp) && !posix_spawnattr_setflags(&attrp, POSIX_SPAWN_START_SUSPENDED)
posix_spawn(&pid, filename, 0, &attrp, argv_1, environ)

and injected with the trojan1_arm64 binary’s code. After injection, the suspended Target process is resumed via

kill(pid, SIGCONT)

and the code from the trojan1_arm64 binary is executed.

This kind of process injection technique is rare in macOS malware and requires specific entitlements to be performed; in this case, the InjectWithDyldArm64 binary has the following entitlements to allow the injection:

com.apple.security.cs.debugger
com.apple.security.get-task-allow

After first negotiating an HTTP handshake, the injected code uses wss to communicate with the C2 – another uncommon technique for macOS malware – at wss://firstfromsep[.]online/client.

The malware uses multiple levels of RC4 encryption in combination with the base64 encoding and three different keys before the communication.

Our analysis found that the communication messages from the C2 use a JSON format of {"name":"","payload":"","target":""}. The name field takes the value auth or message.

When the auth value is used, the payload field has the JSON structure {"uid":"","cipher":""}, where the uid field contains a generated uid value and the cipher field contains the uid value encrypted using the key Ej7bx@YRG2uUhya#50Yt*ao and then encoded in base64. We suspect the target field is used for the victim identifier.

When the message value is used, the payload field value is encrypted using the key 3LZu5H$yF^FSwPu3SqbL*sK. The payload has the JSON structure {"cmd":, "data":""} where the cmd field contains an int value for the command to be executed. Available commands we were able to identify in trojan1_arm64 were as follows:

The result of an executed command is returned to the C2 in the payload field, now having the form {"cmd":,"err":,"data":""}, where cmd contains the int value related to the command that was executed, err contains an int value related to success or failure, and data contains the results of the executed command. For example, when a getSysInfo command is executed, the data field will be populated with values in a JSON structure of the form {"boottime":,"username":"","version":"","comname":"","platform":"","arch":""}.

The whole JSON message is encrypted using the key lZjJ7iuK2qcmMW6hacZOw62.

Data Stealing Bash Scripts

The first part of the attack chain concludes with trojan1_arm64 downloading and executing two scripts, upl and tlgrm.

The upl script is a credential-stealer designed to silently extract browser and system-level information, package it, and exfiltrate it. The script targets data from the following browsers:

• Arc
• Brave
• Firefox
• Google Chrome
• Microsoft Edge

Browser data is copied to

/private/var/tmp/uplex_<username>/<browser>/

The script also targets the following Keychain and shell files and directories:

/Library/Keychains/System.keychain
~/Library/Keychains/login.keychain-db
~/.bash_history
~/.zsh_history
~/.zsh/

The data is then compressed via ditto -ck and posted to the C2 using curl.

The tlgrm script steals Telegram’s encrypted local database (postbox/db) and the decryption key blob, .tempkeyEncrypted, presumably for offline decryption or brute force attempts.

The Telegram data is exfiltrated to the same server used in the upl script. The uploadData() function in both scripts is identical save for one variable name used to specify the server address: hostName in upl and serverUrl in tlgrm.

upl:
hostName="https[:]//dataupload[.]store/uploadfiles"

tlgrm:
serverUrl="https[:]//dataupload[.]store/uploadfiles"

Our investigation found related scripts in public malware repositories that may be tied to similar attacks. We list these in the Indicators of Compromise section at the end of this post.

Technical Analysis of installer, GoogIe LLC, and CoreKitAgent

Installer

The second part of the attack chain begins with the installer binary dropped alongside a by the initial access scripts. Compiled from Nim and weighing in at ~233KB, the installer binary is a universal architecture Mach-O with an ad hoc signature and the identifier user_startup_installer_arm64.

The installer binary checks for the existence of a LaunchAgent at [~]/Library/LaunchAgents/com.google.update.plist and creates folder paths at [~]/Library/CoreKit/ and  [~]/Library/Application Support/GoogIe LLC/ for use by the later stages described in the following sections.

The misspelling of GoogIe LLC (uppercase ‘i’, not lowercase ‘L’) is intended to help the malware blend in and avoid suspicion.

An interesting feature of this and the other compiled Nim binaries is the existence of code that at first blush could be mistaken for C2 command options.

Huntress researchers also reported observing a subset of these “po” commands in their analysis. Nim documentation reveals that these are part of Nim’s std/osproc module, used for executing OS processes, similar to the way Objective-C uses NSTask, and are not attacker-written code or malware artifacts.

We identified two versions of the installer binary, identical except for the path used to set up the config file used by later stage payloads. One version of installer uses /private/tmp/cfg (06566eabf54caafe36ebe94430d392b9cf3426ba) while the other uses /private/tmp/.config (08af4c21cd0a165695c756b6fda37016197b01e7).

In both cases, installer checks that the file does not exist, then writes a 0 byte file to the path, setting write-only access (O_WRONLY) on the file. The file path contents are populated by the next stage GoogIe LLC and later read by CoreKitAgent.

GoogIe LLC

Compiled from Nim and approximately 195KB, the GoogIe LLC executable is a universal Mach-O bearing an ad hoc code signature with the identifier user_startup_loader_arm64. Interestingly, only the filename for this stage uses the typo spoofing trick; the parent folder /Google LLC/ spells Google correctly with a lowercase “L”.

~/Library/Application Support/Google LLC/GoogIe LLC

The binary’s primary function is to set up a configuration file and launch the next stage, CoreKitAgent. The GoogIe LLC executable contains hardcoded data that is combined with local environmental data, encoded, and then written out to the config file in /private/tmp.

The resulting config file contains a 298 byte string of hexadecimal characters. This is later read by CoreKitAgent, which is responsible for writing the LaunchAgent to disk using com.google.update.plist for the Label key and the GoogIe LLC binary for the program argument. The data written to the config file is used as the value for the LaunchAgent’s CLIENT_AUTH_KEY key.

The first 47 characters of the value of CLIENT_AUTH_KEY are also identical to the first 47 characters (of the total 86) used for the value of SERVER_AUTH_KEY.

When the LaunchAgent is activated by a user login or reboot, GoogIe LLC is launched, which in turn calls CoreKitAgent and the rest of the payload logic.

CoreKitAgent

Of the four Nim binaries observed, CoreKitAgent is the most technically complex. It exists in both an unsigned stripped (~233KB) version and an ad hoc signed, unstripped (~340KB) version. VirusTotal telemetry indicates that the stripped version was uploaded from South Korea in October 2024. The unstripped version was observed in the wild in early April 2025. Although it is a universal binary, the ad hoc signature identifies the binary as user_startup_main_arm64.

The CoreKitAgent program operates as an event-driven application using macOS’s kqueue mechanism. The _main function sets up Nim’s standard signal handlers and then hands control to an asynchronous continuation function _mainX20X28AsyncX29___user95startup95main_u45, which initiates the malware’s core logic.

Control flow within this function is handled by a 10-case switch statement implemented as a table-driven state machine, with an execution state stored in memory and updated via a lookup table with the following values:

00 00 fe ff 03 00 00 00 fe ff fe ff fe ff fe ff

After each case completes, the code consults the lookup table to determine the next state depending on error conditions or specific flags set during execution of the previous case. For example, if certain error bits are set, the next state value might be negated, effectively creating alternate paths through the state sequence depending on runtime conditions.

From an analysis point of view, much of the interesting malicious behaviour occurs in Case 1, which overrides some of the earlier signal handlers for intercepting SIGINT and SIGTERM. SIGINT is sent to a process when a user attempts to kill a process (such as by pressing ctl-c in the Terminal). SIGTERM, in contrast, is a signal sent by the system or another process, such as when the kill command is invoked by a user in the Terminal or by a program or script.

When triggered, CoreKitAgent catches these signals and writes the LaunchAgent for persistence, a copy of GoogIe LLC as the loader, and a copy of itself as the trojan, setting executable permissions on the latter two via the addExecutionPermissions_user95startup95mainZutils_u32 function.

This behavior ensures that any user-initiated termination of the malware results in the deployment of the core components, making the code resilient to basic defensive actions.

The state machine also contains a 10-minute sleep routine, likely as an anti-VM or sandbox countermeasure. The sleep routine is set up and called in Case 6 with a hard-coded value of 0x927c0 (600,000ms), as indicated in the following pseudocode.

void* rax_29 = _sleepAsync__user95startup95main_u73(0x927c0);  // 600,000ms = 10min
if (*r12 != 0)
	_eqdestroy___pureZasyncdispatch_u1229(rax_29);  // Error cleanup
else {
	_eqsink___pureZasyncdispatch_u7188(rsi_1 + 0x40, rax_29);  // Store future
	if (*r12 == 0) {
		*(r15 + 8) = 7;  // Transition to state 7
		rsi_15 = *(r15 + 0x40);
	}
}

The sleep function, _sleepAsync__user95startup95main_u73, uses the operating system’s mach_absolute_time() and mach_timebase_info() to create an asynchronous sleep. Rather than just blocking execution for 10 minutes – a technique many sandboxes would detect and counter – it instead registers a wake-up time with a global dispatcher and continues execution of the main event loop. When the sleep timer expires, CoreKitAgent calls Case 7 and continues execution.

AppleScript Beacon and Backdoor

The malware’s custom encryption and obfuscation routines involve multiple passes through several functions. One of these involves deobfuscating string literals made up of long sequences of hexadecimal numbers that are passed to a decrypt function, _fromHex__pkgZnimcryptoZutils_u257.

In the unstripped version, one of the hexadecimal strings contains the template for the previously discussed LaunchAgent. In both versions, although the content differs, an AppleScript is decoded, written to disk at  ~/.ses, and launched via osascript.

The embedded AppleScript fetches the current Unix timestamp via date to create a unique ID and builds an HTTP header string. Throughout, the authors have broken strings down into character lists to help protect the script from simple scanning rules. The same trick is used to disguise two hardcoded C2 addresses, writeup[.]live and safeup[.]store.

On execution, the script beacons out every 30 seconds to one of the two hardcoded C2s, chosen at random, and attempts to post data obtained from listing all running processes on the victim machine. The script also executes any response received from the C2 via the run script command, meaning this simple AppleScript functions both as a beacon and a backdoor.

The embedded AppleScript in the stripped version of CoreKitAgent takes a different form and uses different embedded C2 server addresses but has similar functionality, including the 30 second delay interval.

Conclusion

SentinelLABS’ analysis of NimDoor shows how threat actors are continuing to explore cross-platform languages that introduce new levels of complexity for analysts.

North Korean-aligned threat actors have previously experimented with Go and Rust, similarly combining scripts and compiled binaries into multi-stage attack chains. However, Nim’s rather unique ability to execute functions during compile time allows attackers to blend complex behaviour into a binary with less obvious control flow, resulting in compiled binaries in which developer code and Nim runtime code are intermingled even at the function level.

At the same time, the attackers take full advantage of macOS’s built-in scripting capabilities. Leveraging AppleScript to perform duties like beaconing is a novel approach that removes the need for a traditional post-exploitation framework and the detection ‘noise’ such implants can create. In addition, the use of wss for communications and signal interrupts to trigger persistence logic provide yet further evidence of active development in new ways to defeat security measures.

Earlier this year, we saw threat actors utilizing Nim as well as Crystal, and we expect the choice of less familiar languages to become an increasing trend among macOS malware authors due both to their technical advantages and their unfamiliarity to analysts. As ever in the cat-and-mouse game of threat and threat detection, when one side innovates, the other must respond, and we encourage other analysts, researchers, and detection engineers to invest effort in understanding these lesser-known languages and how they will eventually be leveraged.

Indicators of Compromise

Domains

FilePaths
~/Library/Application Support/Google LLC/GoogIe LLC
~/Library/LaunchAgents/com.google.update.plist
~/.ses
~/Library/CoreKit/CoreKitAgent
~/Library/DnsService/a
~/Library/DnsService/netchk
/private/tmp/.config
/private/tmp/cfg
/private/var/tmp/uplex_//

Binaries | SHA-1

Scripts
Observed

Related