Malvertising campaign leads to info stealers hosted on GitHub

In early December 2024, Microsoft Threat Intelligence detected a large-scale malvertising campaign that impacted nearly one million devices globally in an opportunistic attack to steal information. The attack originated from illegal streaming websites embedded with malvertising redirectors, leading to an intermediary website where the user was then redirected to GitHub and two other platforms. The campaign impacted a wide range of organizations and industries, including both consumer and enterprise devices, highlighting the indiscriminate nature of the attack.

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:

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

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

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

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.

READ MORE HERE