The Feed 2025-04-28

AI Generated Podcast

Summarized Stories

Here are one-sentence summaries for each source, formatted as requested:

Active Exploitation of SAP Zero-Day Vulnerability: This article details the active exploitation of a critical zero-day vulnerability (CVE-2025-31324) in SAP Visual Composer, allowing unauthenticated file uploads and full system compromise, along with mitigation guidance and resources provided by SAP and Onapsis.
Recent phishing campaigns aim to bypass MFA: Documenting three recent phishing campaigns that aim to bypass MFA for MS365 - Cookie-Bite: How Your Digital Crumbs Let Threat Actors Bypass MFA and Maintain Access to Cloud Environments, Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows, SessionShark Kit Steals Tokens to Bypass Office 365 MFA.
Earth Kurma APT Campaign Targets Southeast Asian Government, Telecom Sectors: This report describes the Earth Kurma APT campaign targeting government and telecommunications sectors in Southeast Asia using custom malware, rootkits (like KRNRAT and MORIYA), credential theft tools (like KMLOG), and public cloud services (like Dropbox and OneDrive) for cyber espionage and data exfiltration.
Waiting Thread Hijacking: A Stealthier Version of Thread Execution Hijacking: This research presents Waiting Thread Hijacking (WTH), a stealthier process injection technique developed by Check Point Research that intercepts the flow of a waiting thread to execute an implant, avoiding commonly monitored APIs like SuspendThread/ResumeThread and SetThreadContext.

Okay team, let’s break down the intelligence regarding this critical SAP NetWeaver vulnerability and its active exploitation. This is a high-priority item requiring immediate attention from SOC, IR, and Hunting teams.

Active Exploitation of SAP Zero-Day Vulnerability (CVE-2025-31324)

Summary

Intelligence indicates active, unauthenticated exploitation of a critical zero-day vulnerability, CVE-2025-31324, within the SAP Visual Composer component of SAP NetWeaver. Graded with a CVSS score of 10.0, this vulnerability allows attackers to upload arbitrary files, commonly webshells, leading to immediate full system compromise of the targeted SAP system. While SAP Visual Composer is not installed by default, it is widely enabled in SAP NetWeaver Application Server Java systems, potentially affecting a significant portion of the SAP landscape. Evidence of exploitation has been observed by multiple security firms and customers, leading to SAP releasing an emergency patch and mitigation guidance. The potential impact is severe, including unauthorized business activity, data theft (financial, PII), data corruption, ransomware deployment, and impacts on regulatory compliance.

Technical Details

The vulnerability, identified as CVE-2025-31324, resides in the SAP Visual Composer component for SAP NetWeaver 7.xx, specifically within the “developmentserver” application part. The root cause is a missing authentication or authorization check (CWE-862 / CWE-306) when accessing certain privileged functionality within the Metadata Uploader. This allows unauthenticated threat actors to interact with the vulnerable component.

Exploitation is performed via unauthenticated HTTP/HTTPS POST requests directed at the /developmentserver/metadatauploader URL. Attackers send carefully crafted requests to this endpoint, leveraging the lack of authentication/authorization to upload arbitrary files. The primary observed payload is the upload of malicious JSP webshells. Examples of webshell filenames observed include “helper.jsp” and “cache.jsp”.

These webshells are typically written to publicly accessible directories within the SAP NetWeaver Java file system. Observed paths for these webshells include C:\usr\sap\<SID>\J<Instance_ID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\root, C:\usr\sap\<SID>\J<Instance_ID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\work, and C:\usr\sap\<SID>\J<Instance_ID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\work\sync (or their Unix equivalents).

Once the webshell is successfully uploaded, attackers can execute arbitrary commands remotely by sending simple GET requests to the location of the uploaded webshell. These webshells are designed to import Java packages for command execution and system interaction, create HTML forms for command input, extract commands from HTTP requests, execute them, and capture/display the output. This provides attackers with tools for remote command execution, additional file uploads, and gaining deeper control.

Successful exploitation grants attackers access to the underlying SAP Operating System with the privileges of the adm OS user. This user context provides full access to SAP resources, including the SAP system database without restrictions. This level of access enables critical actions such as shutting down the SAP application, deploying ransomware, modifying financial records, viewing PII, corrupting business data, and deleting logs. The compromised system can also serve as a pivot point for accessing other internal network systems.

Observed Tactics, Techniques, and Procedures (TTPs) mapped to MITRE ATT&CK include:

T1190: Exploit Public-Facing Application (Leveraging the unauthenticated access vulnerability in the Visual Composer component).
T1505.003: Server Software Component: Web Shell (Uploading and using JSP webshells for remote command execution).

Post-exploitation activities observed by ReliaQuest include the use of sophisticated tools and techniques:

Brute Ratel: A sophisticated for-purchase C2 framework. Attackers used the webshell to upload C# code (e.g., to output.txt in a publicly accessible directory), move it to the ProgramData directory, and compile it using the .NET Framework’s MSBuild utility. This compiled code was then used to retrieve Brute Ratel from an external server. Brute Ratel was subsequently used to inject code into the dllhost.exe Windows process, enabling the loading and decryption of malicious payloads in memory. Brute Ratel offers encrypted C2 communications, customizable payloads to evade AV/EDR, and post-exploitation capabilities like privilege escalation, credential harvesting, lateral movement, and persistence.
Heaven’s Gate: A memory manipulation technique observed during post-exploitation, specifically flagging syscalls indicative of this technique. This technique involves transitioning between 32-bit and 64-bit execution modes, often using the NtSetContextThread API call, to potentially bypass endpoint protections.

The delay observed between initial access and subsequent actions in some cases suggests the involvement of Initial Access Brokers (IABs), who may gain access via this vulnerability and then sell it to other threat actors. While specific forum posts selling access gained via this particular vulnerability were not found at the time of the ReliaQuest report, discussions regarding gaining access to SAP NetWeaver via other exploits (e.g., CVE-2020-6287, CVE-2020-6207) were noted on cybercriminal forums, indicating ongoing interest in compromising these systems.

Initial assessments by ReliaQuest suspected a Remote File Inclusion (RFI) issue or re-exploitation of an old vulnerability like CVE-2017-9844, but SAP’s confirmation identified it as an unrestricted file upload vulnerability within the Visual Composer development server component. Exploitation has been observed even on systems with recent patches, initially suggesting an unreported RFI or vulnerability, which turned out to be this new zero-day.

Countries

Specific targeted countries were not mentioned in the provided sources concerning this vulnerability. The exploitation targets Internet-facing and public SAP NetWeaver systems, which can be located globally. SAP solutions are noted as being used by government agencies and enterprises, implying potential targets across various regions.

Industries

The sources explicitly mention that SAP solutions targeted by this vulnerability are often used by government agencies and enterprises. The potential impact section also highlights risks to organizations subject to significant regulatory requirements (e.g., SEC Rules, NIS2) and industry compliance frameworks (e.g., Sarbanes-Oxley, NERC), implicitly including sectors like finance and critical infrastructure.

Recommendations

Based on the sources, the following technical recommendations are critical:

Patching: Apply the emergency patch provided by SAP in SAP Security Note #3594142 as the highest priority.
Mitigation (if patching is not immediately possible): Implement workaround steps described in SAP Note #3593336.
- Disable the SAP Visual Composer component entirely, as it is deprecated since 2015 and no longer supported. This can be done using filters within SAP NetWeaver.
- Disable the application alias “developmentserver” and configure firewall rules to restrict external or unauthorized access to the development server application URL. This endpoint is targeted in the initial exploitation POST request.
Compromise Assessment: If your systems were exposed (e.g., Internet-facing with the vulnerable component enabled and unpatched/unmitigated), perform a compromise assessment. SAP Note #3596125 provides guidance on identifying potential compromise indicators.
Incident Response: If compromise is detected, follow your organization’s appropriate incident response plan.
Logging and Monitoring: Ensure SAP NetWeaver logs are forwarded to a centralized monitoring platform (e.g., SIEM) for comprehensive visibility and faster investigation of suspicious activity.
File System Review: Manually review specific SAP NetWeaver Java directories for the presence of unauthorized files, particularly those with .jsp, .java, or .class extensions. These directories include:
- C:\usr\sap\<SID>\J<Instance_ID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\root
- C:\usr\sap\<SID>\J<Instance_ID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\work
- C:\usr\sap\<SID>\J<Instance_ID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\work\sync
- Remove any such suspicious files found before applying mitigations, as they may remain active.

Hunting methods

Hunting activities should focus on identifying the vulnerable component, detecting exploitation attempts, and finding indicators of compromise (webshells, post-exploitation tools).

Identify Vulnerable Systems:
- Check the installed components on each SAP NetWeaver Application Server Java system.
- Navigate to System Information → Components Info (tab) on the SAP NetWeaver AS Java homepage.
- Filter or look for components named “VISUAL COMPOSER FRAMEWORK” or “VCFRAMEWORK”. The presence of either indicates the targeted component is installed.
- Review if SAP Security Note #3594142 has been applied or if mitigations from SAP KB #3593336 are implemented.
Detect Exploitation Attempts:
- Monitor network traffic and SAP system logs for HTTP/HTTPS POST requests directed at the /developmentserver/metadatauploader URL. While logs may not always capture payload details, observing interactions with this unpatched component is crucial.
Identify Webshell Presence:
- Search the SAP NetWeaver Java file system for suspicious files, specifically looking for files with .jsp, .java, or .class extensions in the following directories:
  - /usr/sap/<SID>/J<Instance_ID>/j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/root
  - /usr/sap/<SID>/J<Instance_ID>/j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/work
  - /usr/sap/<SID>/J<Instance_ID>/j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/work/sync
- Example shell command for Linux systems (adjust paths as necessary):
```
find /usr/sap/<SID>/J<Instance_ID>/j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/root -type f -name "*.jsp" -ls
find /usr/sap/<SID>/J<Instance_ID>/j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/root -type f -name "*.java" -ls
find /usr/sap/<SID>/J<Instance_ID>/j2ee/cluster\apps\sap.com\irj\servlet_jsp\irj\root -type f -name "*.class" -ls
# Repeat for the other directories: /irj/work and /irj/work/sync
```
- Search for known webshell file hashes.
Post-Exploitation Activity Hunting:
- Look for execution of commands via the webshells (this requires monitoring activity originating from the webshell files/paths).
- Hunt for indicators related to Brute Ratel deployment and execution, including suspicious file writes (e.g., output.txt in public directories), file movements to standard OS directories (ProgramData), compilation attempts using MSBuild, and code injection into processes like dllhost.exe.
- Hunt for the use of techniques like Heaven’s Gate, potentially by monitoring for the NtSetContextThread API call or unusual 32-bit to 64-bit transitions.

IOC

Hashes

1f72bd2643995fab4ecf7150b6367fa1b3fab17afd2abed30a98f075e4913087
794cb0a92f51e1387a6b316b8b5ff83d33a51ecf9bf7cc8e88a619ecb64f1dcf

(Hashes correspond to the Helper.jsp and Cache.jsp webshells observed in exploitation)

Original link: https://onapsis.com/blog/active-exploitation-of-sap-vulnerability-cve-2025-31324/
https://reliaquest.com/blog/threat-spotlight-reliaquest-uncovers-vulnerability-behind-sap-netweaver-compromise/

Okay, Analyst. Based on the provided sources, here is a threat intelligence summary focusing on recent MFA bypass techniques and related activities, tailored for SOC, TI, IR, and Threat Hunting teams.

Recent phishing campaigns aim to bypass MFA

Summary

This research highlights evolving techniques used by threat actors to bypass multi-factor authentication (MFA) and maintain persistent access to cloud environments, primarily focusing on Microsoft 365 and Azure. Attackers leverage stolen browser cookies and authentication tokens, which can be obtained through various means such as infostealer malware or acquired from dark web marketplaces. By hijacking active user sessions via these stolen tokens, attackers can impersonate legitimate users, completely bypassing MFA and gaining unauthorized access to cloud services and applications. The attacks often rely on stealthy initial access and maintaining persistence through the compromised session. The research specifically details the compromise of Azure authentication cookies and demonstrates how attackers can use these to gain ongoing access and perform post-exploitation activities within a cloud tenant.

Technical Details

The core technique discussed involves session hijacking using stolen authentication cookies. Threat actors employ several methods to acquire these cookies:

Infostealer Malware: Malicious programs designed to infiltrate systems and exfiltrate sensitive data, including login credentials, session cookies, and authentication tokens, sending them to remote servers controlled by cybercriminals. Infostealers often operate within a Malware-as-a-Service (MaaS) model, involving specialized roles like operators, tracers, darknet marketplaces, and buyers.
Adversary-in-the-Middle (AITM) Phishing: This advanced phishing technique intercepts authentication tokens and session cookies in real-time. Attackers use reverse proxy tools (e.g., Evilginx, Modlishka, Muraena) to position themselves between the victim and the legitimate authentication service (like Microsoft 365 or Google), capturing credentials, MFA tokens, and session cookies during the login process.
Browser Process Memory Dumping: Attackers exploit the fact that browsers decrypt cookies in memory during active sessions. Malware can inject code into running browser processes (e.g., chrome.exe, msedge.exe) to read this memory space and extract cookies in plaintext, bypassing the need for disk decryption.
Malicious Browser Extensions: These extensions operate within the browser’s security context, providing direct access to authentication cookies and session tokens. Often disguised as legitimate tools, they request excessive permissions, allowing them to interact with web sessions, modify content, and extract stored authentication data via the browser’s storage API, network request interception, or JavaScript injection. This method is harder to detect at the endpoint level as it doesn’t require process injection or disk decryption. Custom, unsigned extensions can be loaded if Developer Mode is enabled.
Decrypting Locally Stored Cookies: Browsers store cookies in encrypted SQLite databases. Attackers can extract and decrypt these cookies by obtaining the database and the encryption key. On Windows, Chromium browsers encrypt cookies using DPAPI, binding encryption to the user profile and machine. Infostealers bypass this by decrypting the AES key locally using CryptUnprotectData() within the infected session or by stealing the DPAPI Master Key to attempt offline decryption.

The research focuses on two specific Azure Entra ID cookies: ESTSAUTH (transient, valid for browser session or up to 24 hours) and ESTSAUTHPERSISTENT (persistent, remains after browser closure, valid up to 90 days or policy-defined duration, set when “stay signed in” or KMSI is used). These cookies serve as proof that the user has recently authenticated and satisfied MFA requirements. Stealing these tokens grants immediate, authenticated access, bypassing the entire login process, including MFA prompts.

A Proof-of-Concept (PoC) was built to demonstrate a persistent cookie stealer using a custom Chrome extension and PowerShell automation.

Step 1: Chrome Extension Creation: A Chrome extension is built to listen for authentication events on login.microsoftonline.com. It extracts cookies, including ESTSAUTH and ESTSAUTHPERSISTENT, when a login occurs. Exfiltration in the PoC was done silently via Google Forms.
Step 2: PowerShell Automation: A PowerShell script is used to automate loading the Chrome extension into the user’s default profile. To achieve persistence beyond the browser session lifetime, the script can be scheduled to run periodically, or more complex methods involving registry policies or bypassing Chrome’s Secure Preferences MAC can be used. Alternatives to PowerShell include Python, VBScript, or Macros.
Step 3: Cookie Injection: The stolen cookie data (e.g., in JSON format from the Google Form) is injected into the attacker’s browser, for example, using a tool like the “Cookie-Editor” Chrome extension. Refreshing the page grants access to the victim’s cloud portal. This method provides a valid session regardless of session timeout or revocation because the extension ensures valid cookies are extracted on each login.

Post-exploitation with stolen sessions involves accessing Azure Enterprise Applications available to the compromised user, leveraging their permissions. This can allow attackers to gather sensitive information, launch phishing campaigns, register new applications, or create new users. Initial steps often involve accessing Graph Explorer to enumerate Azure resources like users, devices, groups, and roles. Tools like ROADtools, AADInternals, and TokenSmith facilitate interaction with Azure Entra ID tokens and privilege escalation. TokenSmith can be used to initiate an OAuth authorization code flow against login.microsoftonline.com using the authenticated cookie session to obtain an authorization code, which is then exchanged for Access and Refresh Tokens, granting persistent access and enabling privilege escalation using other tools.

Conditional Access Policies (CAPs) can be bypassed by collecting detailed information about the victim’s host (Domain, Hostname, OS, Public IP, browser version, User Agent, history) to simulate a typical user request and impersonate them.

Countries

The source discusses attacks against enterprise cloud environments globally, but does not specify particular targeted countries. A Conditional Access Policy example uses Germany.

Industries

The source primarily focuses on attacks against users of Microsoft 365, Azure Portal, and other enterprise cloud applications. Targeted environments include enterprise networks and cloud services.

Recommendations

Continuously monitor and detect users’ abnormal behavior within cloud environments.
Utilize Microsoft Risk detection features during sign-in events to identify unusual activity, such as sign-ins from anonymized IP addresses (like VPNs).
Configure Conditional Access Policies to enforce login from compliant devices and consider implementing Token Protection.
Implement Chrome ADMX policies or similar controls for other browsers to enforce an allowlist of approved browser extensions, restricting the installation of malicious ones.

Hunting methods

Hunting Query:

let EPwithNewExt =
DeviceFileEvents
| where ActionType == "FileCreated"
| where FileName endswith ".crx"
| distinct DeviceName;
DeviceProcessEvents
| where FileName =~ "powershell.exe" or InitiatingProcessFileName =~"powershell.exe"
| where ProcessCommandLine has_any ("load-extension")
| where DeviceName has_any(EPwithNewExt)

Logic: This KQL query identifies PowerShell processes attempting to load extensions using the load-extension command, but only on devices where a new Chrome extension file (.crx) was previously created.

Analyze Azure sign-in logs for suspicious patterns, such as multiple successful authentications within a short timeframe using the same Session ID but originating from different geographical locations or browser versions.
Monitor Microsoft Risk detections triggered during sign-in attempts, particularly those flagged for reasons like “anonymizedIPAddress”.
Investigate endpoint logs for signs of malicious browser extension installation or execution, especially unsigned extensions loaded via Developer Mode.
Analyze endpoint logs for execution of PowerShell scripts or alternative automation tools (Python, VBScript, Macros) attempting to interact with browser processes or files.
Monitor for access or modification attempts on browser cookie databases (%LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies on Windows) or DPAPI Master Keys (C:\Users\...\AppData\Roaming\Microsoft\Protect).
Monitor network traffic for unusual exfiltration patterns, such as cookie data being sent to external collection points (e.g., Google Forms in the PoC).
Monitor for the use of tools like ROADtools, AADInternals, or TokenSmith within the environment, particularly when associated with compromised accounts or sessions.
Analyze Azure activity logs for suspicious post-exploitation actions performed using compromised session tokens, such as enumeration of users/groups via Graph API, attempts to register new applications, or create new users.

IOC

Domains

login.microsoftonline.com

Chrome Extension ID

hlkenndednhfkekhgcdicdfddnkalmdm

Microsoft Teams Client ID

1fec8e78-bce4-4aaf-ab1b-5451cc387264

Original link: https://www.varonis.com/blog/cookie-bite

Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows

Summary

Since early March 2025, suspected Russian threat actors, tracked by Volexity as UTA0352 and UTA0355, have been conducting highly targeted social engineering campaigns against individuals and organizations linked to Ukraine and human rights. These actors employ a novel technique that abuses legitimate Microsoft OAuth 2.0 authentication workflows to gain access to Microsoft 365 accounts. The attacks typically involve attackers impersonating European political officials and using secure messaging platforms like Signal and WhatsApp to engage targets. Victims are social engineered into clicking links hosted on Microsoft 365 infrastructure and are then asked to provide Microsoft-generated authorization codes, which the attackers use to obtain access tokens and gain account access. This method relies heavily on one-on-one interaction and exploits the user’s trust in legitimate Microsoft infrastructure. A variation used by UTA0355 also involves registering a new device in the victim’s Entra ID and requiring a social-engineered 2FA approval to access email data.

Technical Details

The attacks initiated by contacting victims via secure messaging apps (Signal, WhatsApp). Attackers impersonated European political officials. The social engineering theme involved invitations to video calls related to Ukraine. Targets who responded received instructions, often a PDF document, followed by a malicious URL. The URLs pointed to the official Microsoft 365 login portal, login.microsoftonline.com, but leveraged legitimate Microsoft OAuth 2.0 authentication workflows for first-party applications.

UTA0352’s campaigns primarily used URLs redirecting victims to an in-browser version of Visual Studio Code (insiders.vscode.dev) after successful authentication. The URL format was https://login.microsoftonline[.]com/organizations/oauth2/v2.0/authorize?state=[arbitrary_value]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&redirect_uri=https://insiders.vscode.dev/redirect&login_hint=[email]. The state parameter was often abused to make the link appear related to a legitimate service. After redirection, a dialog in VS Code displayed the OAuth 2.0 authorization code, which the attacker requested the victim share. This code, valid for up to 60 days, allows the attacker to generate an access token with the user’s default access rights, including access to the Microsoft Graph API. An earlier variation used the Azure AD v1.0 format and redirected via vscode-redirect.azurewebsites.net to 127.0.0.1, where the code was only present in the URL.

UTA0355’s campaign started with an email from a compromised Ukrainian Government account, followed by messaging on Signal/WhatsApp. The M365 login URL used redirected to the Device Registration Service (login.microsoftonline.com/WebApp/CloudDomainJoin/8) after login. The URL format was https://login.microsoftonline.com/common/oauth2/authorize?url=https://teams.microsoft.com/[redacted]&client_id=29d9ed98-a469-4536-ade2-f981bc1d605e&resource=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9&response_type=code&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2FWebApp%2FCloudDomainJoin%2F8&amr_values=ngcmfa&login_hint=<[email protected]>>. The victim was asked to share the redirected URL containing the authorization code. UTA0355 used this code to register a new device (named DESKTOP-[redacted]) to the victim’s Entra ID. Using tools like ROADTools, the attacker exploited a flaw in the Entra ID API to gain a broader access token (full Microsoft Graph API access) than initially granted by the Device Registration Service scope. After device registration, UTA0355 required the victim to approve a 2FA request, falsely claiming it was for accessing a “SharePoint instance,” to bypass organizational security and gain access to the victim’s email. Post-compromise activity included downloading the target’s email. Attacker activity (login, email access, device registration) was initially observed from a proxy IP geolocated near the victim, but subsequent Graph API access logs showed a Microsoft IP address. Tracking attacker activity required correlating by the unique deviceId associated with the registered device. The ClientAppID for ongoing access differed from typical email clients.

These attacks are characterized by all user interactions occurring on legitimate Microsoft infrastructure, making them harder to detect and block than attacks using attacker-hosted pages. They utilize first-party Microsoft applications with pre-existing consent, bypassing the need for explicit user approval of a malicious OAuth app.

Countries

Targeted individuals and organizations have ties to Ukraine. Attackers impersonated officials from Ukraine, Bulgaria, Romania, and likely Poland. A compromised Ukrainian Government account was used. Attacker activity was observed from a proxy IP geolocated near the victim.

Industries

NGOs, organizations supporting human rights and providing aid and humanitarian assistance, and Think Tanks.

Recommendations

Educate users extensively about the risks associated with unsolicited contact, especially via secure messaging apps like Signal and WhatsApp. Emphasize the importance of verifying the identity of contacts out-of-band.
Specifically train users that attackers using this technique will request they share a URL or code from a link they clicked on, even if the link appears legitimate or is hosted on a trusted domain like Microsoft.
Configure Conditional Access Policies (CAPs) that restrict access to organizational resources to only approved or managed devices. While blocking specific first-party Microsoft apps via CAPs is not known to be possible, restricting access based on device compliance can prevent unauthorized device registration and access.
Continuously monitor for newly registered devices in Microsoft Entra ID (Azure AD).
Correlate new device registration events with the ClientIPAddress field in logs, looking for IP addresses associated with low-reputation sources or proxy networks.
Be aware that post-compromise access via the Microsoft Graph API may show a Microsoft IP address in the ClientIPAddress field instead of the attacker’s IP. Track activity based on the unique deviceId of registered devices.
Monitor the ClientAppID field for ongoing access sessions, looking for AppIDs that differ from those used by typical, approved email clients.

Hunting methods

Create alerts for Microsoft 365 login activity where the client_id is aebc6443-996d-45c2-90f0-388ff96faa56 (Visual Studio Code) AND the resourceDisplayName contains “Microsoft Graph”. Evaluate feasibility based on legitimate VS Code usage in the environment.
Implement detection or alerting for email or proxy logs containing URLs matching the patterns used by UTA0352:
- https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?state=*&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&login_hint=*&redirect_uri=https://insiders.vscode.dev/redirect
- https://login.microsoftonline[.]com/common/oauth2/authorize?redirect=*&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&resource=https://graph.microsoft.com&response_type=code&redirect_uri=https://vscode-redirect.azurewebsites.net&login_hint=*
- Note that URL parameters can appear in any order.
Evaluate the possibility of blocking access to the hostnames insiders.vscode.dev and vscode-redirect.azurewebsites.net if their legitimate use does not impact business operations significantly.
Monitor Entra ID (Azure AD) logs for device registration events, specifically looking for registrations of suspicious or unexpected device names (e.g., generic DESKTOP- names) or devices associated with unusual ClientIPAddress values.
Analyze Entra ID logs for 2FA approval events that immediately precede access to sensitive resources like email, particularly if initiated from a newly registered device or an unusual IP.

IOC

Domains

login.microsoftonline.com
insiders.vscode.dev
vscode-redirect.azurewebsites.net

Client IDs

aebc6443-996d-45c2-90f0-388ff96faa56
29d9ed98-a469-4536-ade2-f981bc1d605e

Microsoft Resource ID

01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9

Original link: https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/

SessionShark Kit Steals Tokens to Bypass Office 365 MFA

Summary

SessionShark is an Adversary-in-the-Middle (AiTM) phishing-as-a-service toolkit available on cybercrime networks, specifically designed to bypass Microsoft Office 365 multi-factor authentication (MFA) protections. It is marketed with features aimed at defeating 2FA/MFA by stealing valid user session tokens, enabling attackers to hijack authenticated sessions without needing the one-time passcode. The kit includes advanced anti-detection and stealth capabilities, such as antibot technology, Cloudflare compatibility, and enhanced stealth features to evade security scanners and threat intelligence feeds. SessionShark also mimics the Office 365 login interface with high fidelity and offers comprehensive logging with instant session capturing and Telegram bot integration for real-time exfiltration of stolen credentials and session cookies. Despite being advertised under a guise of “educational purposes,” its features clearly indicate its intended use for malicious activities. The availability of such tools on a subscription basis highlights the commercialization and increasing sophistication of phishing in the cybercrime ecosystem.

Technical Details

SessionShark functions as an Adversary-in-the-Middle (AiTM) phishing kit. Its primary capability is to intercept sensitive data, including login credentials and session cookies. By capturing a victim’s session cookie, which serves as proof of successful authentication (including MFA), attackers can bypass subsequent MFA challenges and gain access to the Office 365 account. This method renders MFA ineffective if the initial credential phishing is successful.

Key technical features advertised by SessionShark include:

Advanced Antibot Technology: Implements techniques like human verification (e.g., CAPTCHA) to prevent automated security scanners and bots from accessing the phishing content, thereby avoiding detection and flagging by security systems.
Cloudflare Compatibility: Designed to integrate with Cloudflare services, allowing attackers to deploy the kit behind Cloudflare’s network. This provides protection for the kit’s Virtual Private Server (VPS) IP address, masking the actual hosting server and making takedowns or IP-based blocking more difficult.
Enhanced Stealth Capabilities: Includes custom scripts and HTTP headers specifically designed to minimize visibility to security scanners, evade detection by major threat intelligence feeds, and bypass anti-phishing systems. This suggests the kit may use evasive coding techniques (HTML/JS) or dynamically change content to avoid signature-based detection.
Sophisticated Office 365 Page: Mimics the legitimate Office 365 login interface with high fidelity and dynamically adapts to various conditions to enhance believability. This makes the phishing page convincing and contextually appropriate for the victim.
Comprehensive Logging: Offers a logging panel for the attacker operator and integrates with Telegram bots. This allows for instant session capturing and real-time exfiltration of captured data (victim email, password, and session cookie) to the attacker’s Telegram bot, enabling rapid account takeover.

The kit is sold on a subscription basis and even offers a Telegram support channel, mirroring legitimate software-as-a-service models in the criminal underground. This indicates a trend towards commercialization and user-friendliness in cybercrime tools.

Countries

The source does not specify particular targeted countries.

Industries

Organizations using Microsoft Office 365 are potential targets.

Recommendations

Implement AI-driven phishing defense solutions capable of detecting and blocking credential phishing kits and associated infrastructure, including those designed to bypass MFA through token theft.
Employ security solutions that leverage broad threat telemetry and advanced detection algorithms to identify sophisticated and evasive phishing tools like SessionShark.
Ensure security awareness training for users includes specific information about AiTM phishing techniques and the risks of entering credentials or sensitive information on login pages, even if they appear legitimate.

Hunting methods

Implement detection mechanisms that go beyond static signatures and analyze the behavior and rendering of login pages for signs of malicious activity, such as attempts to evade bots or use of obfuscated code.
Monitor network traffic for connections to known or suspected phishing infrastructure, although AiTM kits like SessionShark may hide behind services like Cloudflare.
Leverage threat intelligence feeds that track emerging phishing kits and their associated infrastructure and techniques.
Investigate login attempts flagged by security systems that exhibit unusual characteristics or patterns that might indicate interaction with an AiTM proxy.

IOC

Based on the provided excerpts, specific tactical IOCs (IPs, domains, hashes) associated with SessionShark infrastructure are not listed.

Original link: https://slashnext.com/blog/sessionshark-steals-session-tokens-to-slip-past-office-365-mfa/

Okay, here is the threat intelligence summary for the Earth Kurma APT campaign based on the provided source, presented from the perspective of a seasoned threat intelligence analyst.

Earth Kurma APT Campaign Targets Southeast Asian Government, Telecom Sectors

Summary

Trend Research has identified a sophisticated Advanced Persistent Threat (APT) campaign attributed to a newly named group, Earth Kurma, which has been actively targeting government and telecommunications sectors in Southeast Asia since at least November 2020, with a significant wave observed since June 2024. The primary objective of this campaign is cyber espionage, specifically data exfiltration. Earth Kurma employs a range of advanced custom malware, kernel-level rootkits, and strategically abuses trusted cloud services like Dropbox and OneDrive for data exfiltration. The group demonstrates adaptive malware toolsets, strategic infrastructure abuse (including Active Directory and Distributed File System Replication (DFSR)), and complex evasion techniques, posing a high business risk to targeted organizations due to potential compromise of sensitive data and persistent, undetected network access. While overlaps in tools have been noted with Operation TunnelSnake (MORIYA rootkit codebase) and ToddyCat (SIMPOBOXSPY, exfiltration scripts, targeted region, timeline), differences in attack patterns prevent conclusive attribution to these known groups, leading to the designation of “Earth Kurma” as a separate APT. The campaign remains highly active, adapting to victim environments and reusing codebases from previous campaigns.

Technical Details

The Earth Kurma campaign involves a multi-stage infection chain encompassing lateral movement, persistence, and collection/exfiltration. While the initial arrival vectors remain unknown due to the analysis starting years after initial compromise, the lateral movement stage utilizes multiple tools for infrastructure scanning and malware deployment. Tools observed include NBTSCAN, LADON, FRPC, WMIHACKER, and ICMPinger. ICMPinger, a simple network scanning tool based on the ICMP protocol to check host liveness, is used and subsequently deleted after operations conclude. Ladon, an open-source tool for infrastructure inspection, is wrapped in a reflective loader compiled by PyInstaller, with XOR keys differing per sample to bypass detection. WMIHACKER, another open-source tool, facilitates command execution over port 135 without requiring SMB. In some instances, attackers use SMB protocols (e.g., net use) for infrastructure inspection and malware deployment, demonstrated by commands showing network drive mapping, file copying, and remote service creation/start/deletion. Credential theft is attempted during lateral movement using a custom keylogger called KMLOG, which saves keystrokes to “%Appdata%\Roaming\Microsoft\Windows\Libraries\infokey.zip”. To conceal the log file, it’s prepended with a fake ZIP header, with the actual content XOR-encoded.

For persistence, the threat actors deploy various loaders like DUNLOADER, TESDAT, and DMLOADER, primarily observed between 2022 and 2024, with most final payloads being Cobalt Strike beacons. DUNLOADER, a DLL, loads payloads via XOR operations from either a file (“pdata.txt”) or an embedded resource (“BIN”) and checks if its parent process name contains “und”, requiring execution via “rundll32.exe” and typically having a “Start” export function. TESDAT, a newer loader (EXE or DLL with “Init” export), loads “.dat” payload files (e.g., “mns.dat”) and uses “SwitchToFiber” instead of common APIs like CreateThread to execute decoded shellcode, likely for evasion. DMLOADER, a more recent loader, loads and decodes an embedded payload as an in-memory PE buffer, often having “DoMain” or “StartProtect” export functions, with the decoded PE having a “MThread” export. The loaders are often placed in common user folders (e.g., Downloads, Documents) with random names to blend in.

In some cases, kernel-level rootkits, namely KRNRAT and MORIYA, are installed by the loaders to evade detection. Rootkit installation abuses “syssetup.dll” and drops an INF file for installation. For example: C:\Windows\SysWOW64\rundll32.exe syssetup,SetupInfObjectInstallAction DefaultInstall 128 c:\users\{user}\downloads\SmartFilter.inf. MORIYA functions as a TCP traffic interceptor, monitoring for specific six magic bytes from the C&C server (registered via IOCTL code 0x222004) to inject malicious payloads into response packets. The observed MORIYA variant also injects an AES-decrypted payload file from “\SystemRoot\system32\drivers\{driver_name}.dat” into svchost.exe using NtCreateThreadEx, calling the syscall directly by enumerating NTDLL exports to find syscall numbers. KRNRAT is a full-featured backdoor based on open-source projects, offering process manipulation, file/network hiding, shellcode execution, and C&C communication via numerous IOCTL codes (e.g., IOCTL_TERMINATE_PROCESS, IOCTL_ADD_HIDDEN_FILE, IOCTL_INJECT_SHELLCODE). Similar to MORIYA, KRNRAT injects its user-mode agent (a stager backdoor) into svchost.exe using direct syscalls to NtCreateThreadEx. This user-mode agent connects to the C&C for next-stage payloads (like SManager, which has a “GetPluginInformation” export function) and uses KRNRAT IOCTLs to hide its process and connections.

For collection and exfiltration, the attackers first use commands, often executed via Powershell called by TESDAT, to collect specific document files (.pdf, .doc, .docx, .xls, .xlsx, .ppt, .pptx) from user directories, filtering by last write time within the last 30 days. These documents are copied to a temporary folder named “tmp” and then archived into a password-protected RAR file named after the hostname, typically with a maximum size of 200MB per volume. Example commands include: C:\Windows\system32\cmd.exe /C mkdir tmp C:\Windows\system32\cmd.exe /C powershell.exe "dir c:\users -File -Recurse -Include '*.pdf', '*.doc', '*.docx', '*.xls', '*.xlsx', '*.ppt' , '*.pptx'| where LastWriteTime -gt (Get-date).AddDays(-30) | foreach {cmd /c copy $_ /y c:\users\{username}\documents\tmp};echo Finish!" C:\Windows\system32\cmd.exe /C c:\"program files"\winrar\rar.exe a -p{password} -v200m c:\users\{username}\documents\{hostname} c:\users\{username}\documents\tmp -ep The temporary “tmp” folder is then deleted: C:\Windows\system32\cmd.exe /C rmdir /s /q tmp.

Two customized tools are used for exfiltration: SIMPOBOXSPY and ODRIZ. SIMPOBOXSPY, also seen in ToddyCat operations, uploads archive files (e.g., with extensions .z, .001-.128, .7z) to Dropbox using a specified access token. A new folder named with the current date and time is created on Dropbox for the uploaded files. ODRIZ, an older tool from 2023, uploads collected files with the pattern “.z.” to OneDrive using a provided refresh token.

A notable technique involves copying the collected RAR archives to the Active Directory sysvol folder (\\DC_server\sysvol\{domain}\Policies\{ID}\user\) via SMB. The attackers leverage the native Windows Distributed File System Replication (DFSR) feature, which synchronizes the sysvol folder across Domain Controllers, to automatically replicate the stolen archives to all DCs, facilitating exfiltration from any one of them. An example command for transferring the file via SMB is shown in the source.

Countries

Primarily Southeast Asia, specifically including:

Philippines
Vietnam
Thailand
Malaysia

Industries

Government
Government-related telecommunications sectors
Telecommunications

Recommendations

Based on the identified tactics and techniques, the following technical recommendations are suggested:

Enforce strict driver installation policies: Only allow digitally signed and explicitly approved drivers through Group Policies or application control solutions to prevent the installation of malicious rootkits.
Strengthen Active Directory (AD) and DFSR controls: Secure the AD sysvol directory and closely audit DFSR replication events to prevent its misuse for stealthy data exfiltration.
Limit SMB communications: Restrict the use of the SMB protocol across the network to prevent lateral movement and unauthorized file transfers.

Hunting methods

Trend Vision One™ customers can use the Search App to hunt for the malicious indicators. The following query can be used to scan for detections related to the Earth Kurma malware components:

malName: (*DUNLOADER* OR *TESDAT* OR *DMLOADER* OR *MORIYA* OR *KRNRAT* OR *SIMPOBOXSPY* OR *ODRIZ* OR *KMLOG*) AND eventName: MALWARE_DETECTION

Logic of the query: This query targets the malName field, which likely contains the detected name of the malware. It uses wildcard searches (*) to match any event where the malware name includes one of the known Earth Kurma tools: DUNLOADER, TESDAT, DMLOADER, MORIYA, KRNRAT, SIMPOBOXSPY, ODRIZ, or KMLOG. The OR operator combines these searches. Additionally, it filters these results by the eventName being MALWARE_DETECTION, focusing specifically on events where Trend Vision One™ detected these malicious components.

IOC

The source mentions that indicators of compromise for this entry can be found here.

Type 	Indicator 								Description 
sha256 	004adec667373bdf6146e05b9a1c6e0c63941afd38e30c2461eaecb707352466 	TESDAT 
sha256 	0a50587785bf821d224885cbfc65c5fd251b3e43cda90c3f49435bb3323d2a8b 	TESDAT 
sha256 	10898b74b612b1e95826521c5ccf36f7a238f5d181993c3c78c2098fcfdc1f3f 	TESDAT 
sha256 	131bacdddd51f0d5d869b63912606719cd8f7a8f5b5f4237cbdb5c2e22e2cba2 	WMIHACKER 
sha256 	1ab42121bb45028a17a3438b65a3634adb7d673a4e1291efeabf227a4e016cfb 	SIMPOBOXSPY 
sha256 	1c350d09c1cd545d54c38cd03aba3fd4eb0e8d97a3ba6c3744cc33ed92cb9a48 	DUNLOADER 
sha256 	1e48967e24d4ae2ac2697ef09c0f2702285825831bd516cb3be8859496fd296f 	DUNLOADER 
sha256 	1f3f384e29eab247ec99d97dfe6a4b67110888e4ad313b75fa9d0beceef87e93 	KRNRAT 
sha256 	1f5f6cc1cbf578412ea5279dbdb432eda251309695513a74de66063ab02789f1 	TESDAT 
sha256 	2c9b8e4852181d51ff72dc6dec78bef014db8af83d30c05c3e9c5eb060278730 	KRNRAT 
sha256 	2e87615142170a7510e26f94790bfb81df4d499a9f530d0bd8fe0fb1575b17f8 	TESDAT 
sha256 	34366323262346e10d8780bad9d30c6d4d747e4ec543243be76f33b7c028ea36 	TESDAT 
sha256 	37a397a2482b37d19d58588c0a897a08111b74d122c21542f1bf852ae83e1db0 	DMLOADER 
sha256 	383aa73fe72caf268ce0874ebbcd13fc4c9e1e5c6200cdd66862de7257942cea 	TESDAT 
sha256 	398234b692a80a424939e98a2d96a705ce3fd9d61950420b5f2af45890abc48e 	TESDAT 
sha256 	4198b4ec5bb0c72112e9cf835686c33b9a97037acfb7727e494046a73106e938 	MORIYA 
sha256 	45e1138f2b8e822cbd4573cb53104b402ae26dcddb42c70534cf024a8bc6db66 	DUNLOADER 
sha256 	49ab6e2b5e378c74d196aecac4e84c969c800051167c1e33d204531fabd17990 	KMLOG 
sha256 	4ae186ee19d0d3e246dc37ac722a27d5297d2577de59b8583c97897480290bc1 	TESDAT 
sha256 	54e14b7742801970c578fad2ec2a193334ca8a17b60ee18dd6ec0fbfc8ce900b 	SIMPOBOXSPY 
sha256 	612a5fcb7620deef45a021140b6c06ab9c0473dce5b7e4a54960e330a00c90f3 	DUNLOADER 
sha256 	6190b13df521306bfa7ee973b864ba304ee0971865a66afbe0b4661c986099f4 	KMLOG 
sha256 	66edb72f6f7c8cad23c6659a81fa023f57c1a86c7d7b7022f1453b177f2b3670 	NBTSCAN 
sha256 	6bbbb227d679ea00f0663c2e261d5649417d08285f9acc1fd80e806ddea08403 	TESDAT 
sha256 	6ef3a27fdca386fe093c12146cd854d9ae6b42ca637950ca46bfd364ceab5b53 	DUNLOADER 
sha256 	73afc6af6fdfcaf9832aa2975489271bad7c8ea58679f1a2ddd8f60b44cc4a13 	TESDAT 
sha256 	75cc8474abb1d9a06cd8086fede98958653d013fb7ff89bbc32458b022a8fc94 	DUNLOADER 
sha256 	823a0862d10f41524362ba8e8976ddfd4524c74075bd7f3beffa794afb54f196 	MORIYA 
sha256 	8414136128f73fa7e29032df7b8115bc89832c57e2602d81de1e520cc2d7958d 	ICMPINGER 
sha256 	85e78a1b0a78e5d921c89241aaadd505d66dc4df29ca7d8a81098f42487ba350 	TESDAT 
sha256 	876c822f333e812041af24ae80935a830ca5016f9aaf2e8319ebb6cab1f9d7d0 	SIMPOBOXSPY 
sha256 	8c703148567cb66fe27bc07d18de58aa36aa84a49f1ce7545e9ec56378857d3d 	TESDAT 
sha256 	8ca1ffbd3cd22b9bead766ebd2a0f7b2d195b03d533bacf0cb8e1b1887af5636 	KMLOG 
sha256 	8e6583cca6dd4a78bdc0387c7f30334ab038e5c77848f708fe578e60dd8d9e00 	DUNLOADER 
sha256 	96b407856889c920a49f921d925118a130b904e99f9fe43a87342c680ffb9f27 	ODRIZ 
sha256 	a359a06fbc6b5cf5adf7f53c35145b28f3c8a70f6998631090021825aea08e22 	TESDAT 
sha256 	aa925a5a8a7d5b36a66431f4968bd1003d1bbb6cb3ff6d03d9e3e0143c48382b 	DUNLOADER 
sha256 	aef3407310de48e13575c3d98b660ab7ddafb7efe3f4909682907ac286062392 	TESDAT 
sha256 	b26e8e0be066ee0b86f8fb2b0a703717ebbf34c8a33ef9a6f8f164ad012f1746 	LADON 
sha256 	c0326a0cd6137514ee14b6ac3be7461e8cf6c6adec74d087fd30cb06b91ecda2 	TESDAT 
sha256 	c6f73268eba553c7991f876a166440f5b4d519dea6b13bc90583fde1e89e81ed 	FRPC 
sha256 	d3d2355b1ffb3f6f4ba493000e135dfd1b28156672e17f0b34dfc90cc3add352 	TESDAT 
sha256 	e143c15eaa0b3faccc93ce3693960323dbaa683ac9ce30382e876690278dfefa 	DUNLOADER 
sha256 	ec9220cf8208a3105022b47861d4e200672846ef484c1ea481c5cfd617cb18dc 	MORIYA 
sha256 	f3916c414db0f660d488c9d3aaa8355f3eb036ca27a9c606fe7e5e1a9bd42b38 	LADON 
sha256 	f52d9355b9efb6a1fcb32b890c5c373274df21ce38050d49416f469be95dc783 	DUNLOADER 
sha256 	f9892636093266a01ed6f0486c00189d2eeb532a3086660490f4efeb6d026487 	FRPC 
domain 	www[.]dfsg3gfsga[.]space 						C&C 
domain 	www[.]igtsadlb2ra[.]pw 							C&C 
domain 	www[.]ihyvcs5t[.]pw 							C&C 
domain 	www[.]vidsec[.]cc 							    C&C 
ipv4 	103[.]238[.]214[.]88 							C&C 
ipv4 	149[.]28[.]147[.]63 							C&C 
ipv4 	166[.]88[.]194[.]53 							C&C 
ipv4 	185[.]239[.]225[.]106 							C&C 
ipv4 	38[.]147[.]191[.]103 							C&C 
ipv4 	38[.]60[.]199[.]225 							C&C 
ipv4 	45[.]77[.]250[.]21 							    C&C 

Original link: https://www.trendmicro.com/en_us/research/25/d/earth-kurma-apt-campaign.html

Okay, Analyst. Here is the summary and operational cyber intelligence for the research article on Waiting Thread Hijacking, presented in the requested format.

Waiting Thread Hijacking: A Stealthier Version of Thread Execution Hijacking

Summary

Check Point Research has developed and documented a novel process injection technique dubbed “Waiting Thread Hijacking” (WTH). This research aims to achieve stealthy code injection into a running process by approaching the problem differently than typical methods. Unlike classic Thread Execution Hijacking, which often involves suspending and resuming threads or directly setting thread context (actions frequently monitored by security products), WTH intercepts the flow of a thread that is already in a waiting state. By manipulating the return address on the thread’s stack when it’s waiting on a syscall, WTH can redirect execution to implanted code without using potentially noisy APIs like SuspendThread, ResumeThread, or SetThreadContext. The technique leverages common building blocks (remote memory allocation/writing, context reading, system information querying) in an atypical sequence, offering a stealthier execution method. WTH can be seen as an evolution of classic Thread Hijacking and builds upon observations from research into Windows Thread Pools.

Technical Details

Waiting Thread Hijacking (WTH) is a sophisticated process injection technique designed to avoid common detection vectors associated with traditional thread manipulation. The core idea is to target an existing thread within the victim process that is currently in a waiting state and redirect its execution flow without directly modifying its context or suspending/resuming it.

The process involves several key steps and API calls:

Process and Thread Enumeration: The injector process first needs to identify suitable target processes and threads within them. This is done by calling NtQuerySystemInformation with the SystemProcessInformation parameter. This allows enumerating all running processes and their threads, retrieving structures like SYSTEM_THREAD_INFORMATION.
Identifying Suitable Waiting Threads: For each enumerated thread, the SYSTEM_THREAD_INFORMATION structure provides the ThreadState and WaitReason fields. WTH specifically targets threads that are in a Waiting state (ThreadState) with a WaitReason of WrQueue. This wait reason indicates the thread is waiting on a KQUEUE object, often associated with Thread Pool worker threads waiting on tasks. These threads are typically found within functions like NtRemoveIoCompletion (called by GetQueuedCompletionStatus) or NtWaitForWorkViaWorkerFactory (called by TppWorkerThread). These syscall wrappers have a simple structure where the return address is located at the top of the stack.
Obtaining Handles and Context: Once a suitable waiting thread is identified, the injector needs handles to the target process and thread with specific access rights. A handle to the process requires PROCESS_VM_OPERATION, PROCESS_VM_READ, and PROCESS_VM_WRITE. A handle to the target thread requires THREAD_GET_CONTEXT. The GetThreadContext API is then used to retrieve the context of the waiting thread.
Locating and Reading the Return Address: Using the retrieved thread context, specifically the stack pointer (ctx.Rsp on x64), the injector can read the contents of the stack using ReadProcessMemory. Since the target threads are waiting within specific syscall wrappers, the return address back to the calling function is predictably located at the memory address pointed to by the stack pointer. This original return address is read and saved.
Allocating and Writing Shellcode: Memory is allocated within the target process for the shellcode and a necessary stub. This is typically done using VirtualAllocEx with MEM_COMMIT | MEM_RESERVE and initially PAGE_READWRITE permissions. The malicious shellcode, along with a custom stub (explained below), is then written to this allocated memory using WriteProcessMemory.
Setting Memory Protection: After the shellcode and stub are written, the memory permissions are changed to allow execution using VirtualProtectEx, setting the protection to PAGE_EXECUTE_READ. This step might be delayed as an obfuscation technique.
Hijacking the Return Address: The critical step is overwriting the original return address saved from the target thread’s stack. Using WriteProcessMemory, the address on the target thread’s stack (originally pointing back to the legitimate code after the syscall) is replaced with the address of the injected stub within the target process’s memory. Specifically, the address pointing to the shellcode after the location reserved for saving the original return pointer is used.
Execution Trigger: Since the targeted thread is already in a waiting state, it will automatically resume execution when the awaited event occurs (e.g., the syscall completes or a work item is available in the queue). When the thread resumes, it will read the now-overwritten return address from its stack and jump to the injected stub.
The Stub and Seamless Return: The injected stub is crucial for ensuring the target process’s stability. It includes code to save the original thread’s flags and registers (pushf, push rax, etc.). It then calls the main shellcode function (call shellcode_main). After the shellcode finishes, the stub restores the saved flags and registers (popf, pop rax, etc.). Finally, it performs a jmp to the original return address that was saved before overwriting the stack. This allows the thread to return to its legitimate execution flow as if it had just completed the syscall normally, minimizing disruption. A space at the beginning of the stub is reserved to store the original return pointer.

WTH avoids the use of SuspendThread/ResumeThread and SetThreadContext, which are commonly monitored APIs that trigger EDR alerts. It also avoids creating a new thread, which triggers kernel callbacks. While it uses common memory allocation/write APIs, the combination and the method of triggering execution via stack manipulation in a waiting thread are less typical.

An additional obfuscation technique described involves splitting the injection steps (allocation, writing, protecting, overwriting return address) into separate child processes. This aims to break process-centric behavioral signatures that monitor sequences of API calls from a single process.

The necessary access rights for WTH are PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE for the target process and THREAD_GET_CONTEXT for the target thread.

Recommendations

Based on the research, technical recommendations for defense focus on detecting the underlying operations used by WTH:

Monitor Remote Memory Operations: Implement robust monitoring and detection for remote processes allocating executable memory (VirtualAllocEx with PAGE_EXECUTE_READ or subsequent VirtualProtectEx changing to executable) and writing to that memory (WriteProcessMemory).
Monitor Remote Writes to Thread Stacks: Specifically detect and alert on remote writes (WriteProcessMemory) targeting memory regions identified as thread stacks, particularly those of waiting threads. Examine the source process performing the write and the target address.
Monitor NtQuerySystemInformation and GetThreadContext Usage: While these APIs are common, monitor their use by unexpected processes, especially when followed by remote memory operations. The combination of querying thread information and reading contexts, particularly targeting waiting threads, could be a behavioral indicator.
Behavioral Detection: Focus on behavioral signatures that combine the observed API calls (querying threads, reading contexts, allocating/writing/protecting memory remotely, writing to stack pointers) even if split across processes.
Prevent Remote Writes: Some EDRs may prevent remote writes entirely, which would thwart WTH if traditional write APIs are used.

Check Point indicates that their Harmony Endpoint product includes protections against the threats described in this research, specifically mentioning “Behavioral Guard protections” and a protection rule named “WaitingThreadHijackBlock”.

Hunting methods

Explicit Yara, Sigma, KQL, or SPL rules are not provided in the source. However, based on the technical details, hunting methods should focus on detecting the sequence of operations and specific API calls used by WTH.

Potential Hunting Logic (General): Hunting for Waiting Thread Hijacking should focus on the combination of process interaction and memory/thread state manipulation. Since the technique relies on querying system/thread information, reading thread contexts, allocating/writing/protecting memory in a remote process, and specifically modifying a return address on a waiting thread’s stack, a hunting query would look for events correlating these actions.

Example Logic for a Query (Conceptual): Look for events where:

A process (Injector) calls NtQuerySystemInformation potentially followed by process/thread opening APIs targeting another process (Target).
The Injector process opens a handle to the Target process with PROCESS_VM_OPERATION, PROCESS_VM_READ, or PROCESS_VM_WRITE access rights.
The Injector process opens a handle to a thread within the Target process with THREAD_GET_CONTEXT access right.
The Injector process calls GetThreadContext on a thread within the Target process.
The Injector process calls VirtualAllocEx within the Target process, especially allocating executable memory or memory that is later changed to executable.
The Injector process calls WriteProcessMemory to the allocated memory region in the Target process, writing the shellcode and stub.
Crucially, the Injector process calls WriteProcessMemory targeting an address within the Target process’s thread stack, identified potentially by being close to a value obtained via GetThreadContext (ctx.Rsp). The value being written should point back to the memory allocated in step 5.
Investigate processes performing remote writes to memory regions corresponding to stack pages, particularly for threads found to be in a waiting state (this requires correlating with thread state information, which might be harder to get directly from EDR logs but is the core of the technique).

Given the obfuscation technique, hunting should also consider sequences of these events originating from a parent process that then spawns child processes, each performing one step of the injection.

Without specific log schema or query languages, providing exact queries is not possible, but the logic described above covers the key TTPs of WTH for detection and hunting.

Original link: https://research.checkpoint.com/2025/waiting-thread-hijacking/

The Feed 2025-04-28

AI Generated Podcast

Summarized Stories

Active Exploitation of SAP Zero-Day Vulnerability (CVE-2025-31324)

Summary

Technical Details

Countries

Industries

Recommendations

Hunting methods

IOC

Recent phishing campaigns aim to bypass MFA

Cookie-Bite: How Your Digital Crumbs Let Threat Actors Bypass MFA and Maintain Access to Cloud Environments

Summary

Technical Details

Countries

Industries

Recommendations

Hunting methods

IOC

Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows

Summary

Technical Details

Countries

Industries

Recommendations

Hunting methods

IOC

SessionShark Kit Steals Tokens to Bypass Office 365 MFA

Summary

Technical Details

Countries

Industries

Recommendations

Hunting methods

IOC

Earth Kurma APT Campaign Targets Southeast Asian Government, Telecom Sectors

Summary

Technical Details

Countries

Industries

Recommendations

Hunting methods

IOC

Waiting Thread Hijacking: A Stealthier Version of Thread Execution Hijacking

Summary

Technical Details

Recommendations

Hunting methods