The Feed 2025-03-28

AI Generated Podcast

https://open.spotify.com/episode/7nvN0oGewBngi1OstKuaQM?si=Z2m1oI45TpuaUGI3zDChnQ

Summarized Stories

Cloud Threats on the Rise: Alert Trends Show Intensified Attacker Focus on IAM, Exfiltration: This article analyzes the significant increase in cloud security alerts during 2024, revealing a heightened focus by attackers on identity and access management (IAM) and data exfiltration, and advocates for the use of Cloud Detection and Response (CDR) tools to mitigate these threats.
The “EventLogCrasher” 0day For Remotely Disabling Windows Event Log, And a Free Micropatch For It: This article describes the “EventLogCrasher” zero-day vulnerability discovered in January 2024 that allows authenticated users to remotely crash the Windows Event Log service, thereby hindering security and forensic capabilities, and announces the availability of a free micropatch to address the unpatched flaw.
The Shelby Strategy: This article provides an analysis of the SHELBY malware family, which abuses GitHub for command-and-control, employing sandbox detection techniques and featuring a critical vulnerability due to its embedded GitHub Personal Access Token.
VanHelsing, new RaaS in Town: This article introduces VanHelsingRaaS, a new ransomware-as-a-service program launched in March 2025, detailing its affiliate model, the cross-platform capabilities of its VanHelsing ransomware, and a technical analysis of its Windows variant, highlighting its rapid emergence and impact.
You will always remember this as the day you finally caught FamousSparrow: This article reports on the continued activity of the China-aligned APT group FamousSparrow, which was observed using two previously undocumented versions of its SparrowDoor backdoor and the ShadowPad backdoor in attacks targeting a US financial trade group and a Mexican research institute in July 2024.

Cloud Threats on the Rise: Alert Trends Show Intensified Attacker Focus on IAM, Exfiltration

Summary

Analysis of 2024 cloud security alert trends reveals a significant increase in attacks targeting cloud infrastructure, with a nearly fivefold rise in daily alerts by the year’s end. High severity alerts, indicating successful targeting of critical cloud resources, saw the greatest increase, highlighting attackers’ intensified focus on breaching cloud environments. Identity and access management (IAM) is identified as a primary target due to its role as the cloud infrastructure’s defense perimeter, with attackers frequently targeting IAM tokens and credentials to gain access, move laterally, escalate privileges, and perform malicious operations. The report also notes upward trends in alerts related to suspicious cloud storage activity and remote command-line usage of serverless IAM tokens. The findings underscore the necessity of deploying Cloud Detection and Response (CDR) tools in conjunction with Cloud Security Posture Management (CSPM) to detect and prevent malicious runtime operations and build a robust cloud security defense. The observed trends align with an increase in vulnerability exposures due to accelerated deployments and a rise in advanced persistent threat (APT) attacks targeting cloud environments.

Technical Details

The technical details of the analyzed cloud attack trends indicate a strong focus on compromising identity and access management (IAM) to gain a foothold within cloud environments. Attackers are actively targeting IAM tokens and credentials, recognizing their significance as the “keys to the cloud kingdom”. This is evidenced by a threefold increase in remote command-line access events utilizing IAM tokens and credentials of serverless functions. This particular activity is critical as it can provide attackers with broader access to an organization’s cloud environment. The average cloud environment saw a dramatic increase in alerts for the remote command-line usage of a serverless function IAM token, rising from two alerts in January 2024 to over 200 by December 2024.

Further technical observations include:

A 116% increase in IAM-based “impossible travel event” alerts, suggesting attackers are leveraging compromised credentials from geographically disparate locations within short timeframes.
A 60% increase in IAM application programming interface (API) requests from outside regions for compute resources (cloud virtual machines), indicating potential unauthorized access and control of compute instances.
A peak 45% increase in the number of cloud snapshot exports during November 2024. This is significant because snapshots can contain sensitive data, including IAM credentials, enabling privilege escalation and lateral movement.
A 305% increase in the number of suspicious downloads of multiple cloud storage objects, often triggered when a single IAM-based identity downloads a large number of storage objects rapidly, which can be indicative of ransomware or extortion attempts.

The report highlights the criticality of various cloud resources targeted by attackers:

Identity and access management (IAM): Leaked credentials can provide initial access.
Storage: Contains sensitive organizational or customer data, making it a target for exfiltration, ransomware, and extortion.
Virtual machines: Often connected to internal services, offering opportunities for lateral movement.
Containers: Exploitation of container hosts allows attackers to run malicious containers.
Serverless: Designed for specific automated tasks, unauthorized remote command-line executions are a strong indicator of compromise.

The increase in high severity alerts (235% increase in 2024) underscores that these attacks are not just probing but are successfully impacting critical cloud resources. The top high severity alerts frequently involve runtime-focused events, requiring near real-time or real-time analysis for detection. Examples include remote command-line usage of serverless tokens, suspicious downloads of multiple cloud storage objects, and multiple cloud snapshot exports.

Medium severity alerts also saw a significant mid-year spike, with most of the top 10 alerts detectable only through runtime protection analytics. These include IAM identities attempting multiple denied actions, compute-attached identities making API calls outside their region, suspicious downloads from multiple storage buckets, and impossible travel by cloud compute identities. These alerts often point to compromised cloud resources like Kubernetes service accounts being used maliciously from outside the cluster or the known cloud environment.

The report emphasizes the complementary roles of Cloud Security Posture Management (CSPM) and Cloud Detection and Response (CDR) tools. CSPM tools focus on maintaining secure configurations and identifying vulnerabilities through scheduled scanning. In contrast, CDR tools provide continuous runtime monitoring by collecting and analyzing logs from various cloud resources to detect and prevent malicious operations as they occur. The increasing sophistication of cloud attacks necessitates the deployment of CDR tools to identify threats that bypass posture management controls.

A real-world example from a Unit 42 post highlights a ransomware and extortion campaign that harvested over 90,000 credentials, including nearly 1,200 cloud IAM credentials, from exposed environment variable files, leading to successful extortion attacks. This reinforces the critical need for robust security mechanisms, including both posture management and runtime monitoring.

Recommendations

The report provides several recommendations for organizations to enhance their cloud security posture:

Implement effective CDR runtime monitoring across all cloud environments. This includes:
- Deploying CDR tools.
- Ensuring runtime enabled agents are active on all mission-critical cloud endpoints to monitor compute and container runtime operations.
- Ensuring runtime cloud audit log monitoring is enabled by CSP providers.
- Integrating cloud SaaS applications to collect logs from Identity Providers (IdP), CI/CD integrations, source code repositories, and ticketing platforms.
Place limits on CSP regions where compute and serverless functions are permitted to operate, as attackers commonly create resources in foreign regions for obfuscation.
Identify and prevent IAM service accounts from performing operations outside their intended functions. Implementing the principle of least privilege for IAM credentials is crucial to limit lateral movement and privilege escalation if a credential is compromised.
Ensure that cloud storage versioning and encryption are enabled for all cloud storage containers. These free configurations from major cloud providers significantly impede attackers attempting to steal sensitive information.
Recognize that CDR runtime monitoring defenses are essential to effectively combat the majority of threats targeting cloud environments.

Hunting methods

The article does not provide specific hunting queries (Yara, Sigma, KQL, SPL or other languages). However, the detailed technical information can inform the development of hunting strategies. For instance:

The significant increase in remote command-line usage of serverless IAM tokens (alerts “Remote command line usage of serverless token” and “Remote command line usage of serverless role”) suggests focusing hunting efforts on unusual command executions originating from serverless functions. Look for command history or execution logs (if available) from serverless environments that deviate from expected automated tasks.
The rise in suspicious downloads of multiple cloud storage objects (alert “An identity performed a suspicious download of multiple cloud storage objects”) indicates a need to monitor access logs for unusually high download volumes from single identities within short periods. Correlate this with the type of data being accessed and the user’s typical activity.
The increase in cloud snapshot exports (alert “Multiple cloud snapshots export”) warrants monitoring cloud audit logs for infrequent or unauthorized snapshot creation and export events, especially to external accounts or regions.
Impossible travel alerts highlight the importance of analyzing login activity for users and service accounts, identifying logins from geographically improbable locations within short timeframes. This can be enhanced by correlating login events with resource access and API calls.
Monitoring IAM API requests originating from outside expected regions for compute resources can help identify potentially compromised compute instances being controlled externally. Analyze API call logs for unusual source IP addresses or regions making resource modification requests.

While specific queries are not provided, the observed alert trends and their descriptions in Tables 2 and 3 offer valuable insights for security teams to develop targeted hunting rules and alerts within their SIEM or cloud security platforms. The logic would involve looking for deviations from baseline behavior for the identified high and medium severity alert categories, focusing on the runtime operations associated with IAM usage, storage access, and compute resource manipulation.

Original link: https://unit42.paloaltonetworks.com/2025-cloud-security-alert-trends/

The “EventLogCrasher” 0day For Remotely Disabling Windows Event Log, And a Free Micropatch For It

Summary

A zero-day vulnerability, dubbed “EventLogCrasher,” allows any authenticated user on a Windows network, including low-privileged domain users, to remotely crash the Windows Event Log service on any other Windows computer, including domain controllers. The vulnerability, disclosed by security researcher Florian, stems from a flaw in how the Event Log service handles malformed UNICODE_STRING objects during a call to RegisterEventSourceW. Microsoft reportedly stated that the bug did not meet their bar for servicing and considered it a duplicate of an older, unserviced bug. The vulnerability remained unpatched by official Windows Updates for a significant period, from at least January 2024 until October 2024 for most Windows versions, with Windows 11 24H2 being the only exception reported as patched. Crashing the Event Log service can lead to a denial of service for logging capabilities, hindering intrusion detection, forensics, and compliance monitoring. While Security and System events are queued and may be logged upon service restart, Application logs and events from other sources are irrecoverably lost during the downtime. An attacker could repeatedly exploit this vulnerability to keep the logging service offline, effectively creating a period of “darkness” for security monitoring. A micropatch to address this vulnerability has been developed and made freely available by 0patch.

Technical Details

The “EventLogCrasher” vulnerability is triggered by sending a malformed UNICODE_STRING object to the ElfrRegisterEventSourceW method exposed by the RPC-based EventLog Remoting Protocol. The proof-of-concept (POC) crafted by Florian involves a single call to the RegisterEventSourceW function, which is intended to retrieve a handle to an event log on a specified computer. An application on one machine can use this function to interact with the event log service on another machine over the network.

Before the request is sent to the target system, the POC manipulates an in-memory structure related to the UNICODE_STRING object. Specifically, the Buffer element of this structure, which should point to the actual string buffer, is set to NULL (0).

The vulnerability lies in the wevtsvc!VerifyUnicodeString function within the Windows Event Log service (wevtsvc.dll). This function receives a pointer to the malformed UNICODE_STRING structure as an argument. Due to the null Buffer pointer, the function attempts to dereference a null pointer, leading to an unhandled access violation and a crash of the wevtsvc.exe process, which hosts the Windows Event Log service.

While the Windows Event Log service is configured to automatically restart upon unexpected termination, it will only do so twice before entering a persistently stopped state. An attacker can exploit this by crashing the service three times in quick succession, ensuring that logging remains disabled.

During the service downtime, the affected system will not write new events to the logs, forward events to centralized logging solutions (like Splunk or Sumo Logic), or allow applications like Event Viewer to read existing or new events. This can severely impair security monitoring and incident response capabilities. Notably, Application logs, including events related to the crashing of the Event Log service itself, are irrecoverably lost.

Interestingly, Security and System events are handled differently. The system employs an in-memory queue to store these important events when the Event Log service is unavailable. Upon restarting the service, these queued events are typically written to the respective logs with their original timestamps. However, this queue has a finite capacity, and if it becomes full (indicated by Event 4612(S)), subsequent events may be discarded. Furthermore, events in the queue will be lost if the system undergoes a non-graceful shutdown (e.g., blue screen, power loss).

The attack leverages the SMB protocol over a named pipe (\pipe\eventlog). It does not require any special firewall rules to be enabled; it works with the default Windows Firewall configuration, even with the “Remote Event Log Management” rules disabled. Similarly, it does not necessitate adding the attacker’s user to the Event Log Readers group. The attacker merely needs to be an authenticated user on the network to send SMB requests to the target machine. This broadens the potential attack surface to include almost any user within a Windows domain.

A crucial aspect of this vulnerability is its potential for remote exploitation. An attacker can crash the Event Log service on any Windows computer they can authenticate to on the network, including domain controllers.

Recommendations

The primary technical recommendation provided in the article is to deploy the free micropatch offered by 0patch. This patch involves adding a check for the null pointer in the wevtsvc!VerifyUnicodeString function, preventing the subsequent null-pointer dereference and service crash. The micropatch can be applied without a system reboot using the 0patch Agent.

Other recommendations include:

Monitor the status of the Windows Event Log service on critical systems, especially domain controllers. Investigate any unexpected service stoppages.
If a crash is suspected, immediately disconnect the affected machine from the network to prevent further attacks.
Manually restart the Windows Event Log service to attempt to salvage any queued Security and System events. Observe incoming events using Event Viewer.
If the service continues to crash upon restart, the system may be under active attack and should remain disconnected from the network. Inspect network traffic for incoming SMB connections to \pipe\eventlog to identify potential sources of the attack.
Consider restricting SMB connectivity to critical systems if feasible, although this may impact other essential network services like file and printer sharing.

Hunting methods

The article provides guidance for investigating potential exploitation:

Monitor for Event Log service crashes. While normal system issues can cause crashes, a sudden and repeated crashing of the service, especially across multiple systems, could indicate exploitation of this vulnerability. Note that the event of the Event Log service crashing might itself be lost in Application logs if the service doesn’t restart quickly.
Examine Security and System logs after a suspected outage. Look for gaps in logging that might correlate with periods when the service was down.
If the Event Log service is running again after a suspected outage, check for a large influx of older Security and System events, which could indicate the processing of a backlog from the queue.
As mentioned in the recommendations, if the service is repeatedly crashing, inspect network traffic (incoming SMB connections to \pipe\eventlog) on a potentially targeted machine to identify the source of the malicious requests. Network monitoring tools could be used to filter for this specific activity.

The article does not provide specific hunting queries in languages like Yara, Sigma, KQL, or SPL. However, the technical details of the vulnerability (manipulated UNICODE_STRING in the context of RegisterEventSourceW calls over SMB) could potentially inform the development of more advanced network-based detection rules if more information about the specific malformed structure becomes publicly available.

Original link: https://blog.0patch.com/2024/01/the-eventlogcrasher-0day-for-remotely.html

The Shelby Strategy

Summary

The “The Shelby Strategy” report details a newly discovered malware family named SHELBY, which leverages GitHub for command-and-control (C2) and data exfiltration. The malware was identified during the analysis of a targeted phishing campaign, REF8685, against an Iraqi telecommunications company. The attack involved a phishing email containing a malicious ZIP archive that, upon execution, installs the SHELBY loader and backdoor. A significant security vulnerability exists in the malware’s C2 design, as the Personal Access Token (PAT) for the GitHub repository is embedded in the malware, allowing anyone with access to it to potentially control infected machines. The malware employs various anti-sandbox techniques and obfuscation to evade detection. Two main components, SHELBYLOADER and SHELBYC2, were analyzed, revealing sophisticated methods for establishing persistence, gathering system information, and executing commands. The malware demonstrates ongoing development due to the presence of unused code and dynamic payload loading capabilities. The use of legitimate platforms like GitHub for C2 highlights a trend in malware development to blend in with normal network activity, making detection more challenging.

Technical Details

The infection chain begins with a phishing email containing a ZIP archive (details.zip). Upon extraction and execution, a seemingly benign executable (JPerf-3.0.0.exe) utilizing the Inno Setup system drops several files into %AppData%\Local\Microsoft\HTTPApi\. These files include the malicious loader (HTTPService.dll), the encrypted backdoor (HTTPApi.dll), and a legitimate .NET executable (Microsoft.Http.Api.exe and its configuration file).

The Microsoft.Http.Api.exe is used for DLL side-loading of the malicious HTTPService.dll. Once loaded, SHELBYLOADER (HTTPService.dll) initiates communication with a private GitHub repository for its C2. The loader retrieves a specific value from the C2, which is then used to decrypt the backdoor payload (HTTPApi.dll) loaded into memory using reflection, thus avoiding writing to disk. Both the loader and the backdoor exhibit a low detection rate on VirusTotal at the time of analysis.

Both the loader and backdoor are obfuscated using Obfuscar, which employs string encryption. Analysts can use tools like de4dot with custom parameters (–strtyp delegate and –strtok ) to deobfuscate the code by replacing calls to the string decryptor function with their plaintext values.

SHELBYLOADER implements several sandbox detection techniques:

WMI Query for System Information: Queries Win32_ComputerSystem and checks Manufacturer and Model for strings like “VMware” or “VirtualBox”.
Process Enumeration: Scans running processes for names associated with virtualization software (e.g., vmsrvc, vmtools, xenservice, vboxservice, vboxtray).
File System Checks: Looks for the presence of specific driver files related to virtualization (e.g., C:\Windows\System32\drivers\VBoxMouse.sys).
Disk Size Analysis: Checks the size of the C: volume; if it’s less than 50 GB, it’s flagged as a potential sandbox.
Parent Process Verification: Verifies if the parent process is explorer.exe, indicating a typical user-driven execution.
Sleep Time Deviation Detection: Measures the execution time of Thread.Sleep(500) to detect if the sleep duration is being accelerated.
WMI Query for Video Controller: Queries Win32_VideoController and checks the Name for indicators of virtual hardware (e.g., “virtual”, “vmware”, “vbox”).

The loader initializes variables including a GitHub account name (“johnshelllby”), a private repository name (“myToken”), and a Personal Access Token (PAT). It sets up two timers. The first timer, triggered after 125 seconds, establishes persistence by adding an entry to the SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key, setting the value “MicrosoftWebAppi” to point to the malware’s executable. The success or failure of this operation is reported back to the C2.

The second timer, triggered after 65 seconds, is responsible for loading the backdoor. It generates a unique identifier for the infected machine by creating an MD5 hash of the following system information concatenated with slashes: number of processors, machine name, user domain name, username, and the number of logical drives. A subset of this hash is used as the unique identifier.

The loader then pushes a new commit to the “myToken” repository, creating a directory named after the unique identifier containing an Info.txt file. This file includes the domain name, username, sandbox detection results, persistence flag, and a timestamp. The malware first attempts to push the commit without a proxy and then falls back to using the system-configured proxy if the initial attempt fails.

After the initial beaconing, the loader attempts to download a file named License.txt from the same GitHub repository directory. If present, this 48-byte value is used to generate an AES decryption key and Initialization Vector (IV). The 48-byte value is hashed using SHA256, with the resulting hash used as the key and the first 16 bytes as the IV. This key and IV are used to decrypt the HTTPApi.dll (SHELBYC2). The decrypted backdoor is then loaded into memory using Assembly.Load.

Another variant of SHELBYLOADER uses a DNS-based keying mechanism. It performs the same anti-sandboxing checks and registers with the C2 by building a subdomain under arthurshelby.click containing a static string, the Base32 encoded unique identifier, and Base32 encoded system information and anti-sandbox results. Subsequently, it performs multiple DNS queries to subdomains of arthurshelby.click (e.g., l1.<unique_id>.arthurshelby.click), and the concatenated IP addresses from these queries form the byte sequence used to generate the AES key and IV.

The SHELBYC2 backdoor regenerates the unique identifier and creates a Mutex named Global\GHS<unique_identifier> to ensure single instance execution. After 65 seconds, it collects system information (user identity, OS version, process ID, machine name, current working directory), although this information is currently not used or exfiltrated. It then uploads the current timestamp to a file named Vivante.txt in the GitHub repository as a heartbeat.

The backdoor checks for commands in Command.txt within its unique directory and then in Broadcast.txt outside its directory for global commands. Handled commands include:

/download: Downloads a file from the GitHub repository to the infected machine, requiring the file name and the local save path as parameters.
/upload: Uploads a file from the infected machine to the GitHub repository, taking the local file path as a parameter. The uploaded file is named using the original file name without extension, the current date and time, and the original extension.
/dlextract: Downloads a ZIP file from the GitHub repository and extracts its contents to a specified directory.
/evoke: Reflectively loads a downloaded AES-encrypted .NET binary, requiring the local path to the binary and a value to derive the AES key and IV.

Any command not starting with these handled commands is treated as a PowerShell command and executed using PowerShellProcessInstance.

Communication with GitHub is done via crafted HTTPS requests to the GitHub API, not using the Git tool. Commits are sent as JSON objects with “message”, base64 encoded “content”, and “sha”. Specific HTTP headers are used, including Authorization: token <PAT_token>, which is embedded in the binary. The API endpoint used is https://api.github.com/repos/<owner>/<repo>/contents/<unique identifier>/<file>. This reliance on a hardcoded PAT is a critical flaw, allowing unauthorized control of infected machines.

Countries

Iraq, United Arab Emirates (specifically Sharjah).

Industries

Telecommunications, Aviation (Air Freight).

Recommendations

The report does not explicitly provide technical recommendations for defense. However, based on the analysis, the following can be inferred:

Monitor network traffic for connections to GitHub that are not associated with legitimate Git usage, especially involving non-standard user agents and API endpoints related to content creation or modification.
Inspect running processes for instances of Microsoft.Http.Api.exe that have loaded unusual DLLs (specifically HTTPService.dll).
Monitor for the creation of files in %AppData%\Local\Microsoft\HTTPApi\ with the names HTTPApi.dll, HTTPService.dll, and Microsoft.Http.Api.exe.
Detect registry modifications under SOFTWARE\Microsoft\Windows\CurrentVersion\Run adding an entry for MicrosoftWebAppi pointing to a location within the user’s AppData directory.
Implement robust email security measures to prevent phishing emails, especially those with ZIP attachments containing executables, from reaching end-users.
Educate employees about the risks of opening unsolicited attachments, even if they appear to be from internal sources.
Consider blocking or monitoring connections to known malicious domains associated with this campaign.
Organizations using GitHub for legitimate purposes should ensure their PATs are securely managed and not exposed within applications deployed to untrusted environments.

Hunting methods

YARA Rules:

rule Windows_Trojan_ShelbyLoader {
  meta:
    author = "Elastic Security"
    creation_date = "2025-03-11"
    last_modified = "2025-03-25"
    os = "Windows"
    arch = "x86"
    category_type = "Trojan"
    family = "ShelbyLoader"
    threat_name = "Windows.Trojan.ShelbyLoader"
    license = "Elastic License v2"
  strings:
    $a0 = "[WARN] Unusual parent process detected: "
    $a1 = "[ERROR] Exception in CheckParentProcess:" fullword
    $a2 = "[INFO] Sandbox Not Detected by CheckParentProcess" fullword
    $b0 = { 22 63 6F 6E 74 65 6E 74 22 3A 20 22 2E 2B 3F 22 } // "content": ".+?"
    $b1 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 } // "sha": ".+?"
    $b2 = "Persist ID: " fullword
    $b3 = "https://api.github.com/repos/" fullword
  condition:
    all of ($a*) or all of ($b*)
}

rule Windows_Trojan_ShelbyC2 {
  meta:
    author = "Elastic Security"
    creation_date = "2025-03-11"
    last_modified = "2025-03-25"
    os = "Windows"
    arch = "x86"
    category_type = "Trojan"
    family = "ShelbyC2"
    threat_name = "Windows.Trojan.ShelbyC2"
    license = "Elastic License v2"
  strings:
    $a0 = "File Uploaded Successfully" fullword
    $a1 = "/dlextract" fullword
    $a2 = "/evoke" fullword
    $a4 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 } // "sha": ".+?"
    $a5 = { 22 2C 22 73 68 61 22 3A 22 } // ", "sha": "
  condition:
    all of them
}

Logic of the YARA rules:

Windows_Trojan_ShelbyLoader: This rule looks for specific strings found within the SHELBYLOADER malware. The $a* strings target log messages related to sandbox detection and parent process checks. The $b* strings target patterns indicative of the malware’s communication with the GitHub API for content upload and retrieval (JSON structure with “content” and “sha” fields) and the persistence mechanism (“Persist ID:”) and the GitHub API base URL. The condition all of ($a*) or all of ($b*) means the rule will trigger if all of the $a strings are found, or if all of the $b strings are found.
Windows_Trojan_ShelbyC2: This rule targets the SHELBYC2 backdoor. The $a* strings look for specific command handling strings (“File Uploaded Successfully”, “/dlextract”, “/evoke”). The $a4 and $a5 strings look for patterns within JSON structures used for communication with the GitHub API, specifically the “sha” field. The condition all of them means all defined strings within the rule must be present for a match.

IOC

Hashes

0e25efeb4e3304815f9e51c1d9bd3a2e2a23ece3a32f0b47f829536f71ead17a
feb5d225fa38efe2a627ddfbe9654bf59c171ac0742cd565b7a5f22b45a4cc3a
0354862d83a61c8e69adc3e65f6e5c921523eff829ef1b169e4f0f143b04091f
fb8d4c24bcfd853edb15c5c4096723b239f03255f17cec42f2d881f5f31b6025
472e685e7994f51bbb259be9c61f01b8b8f35d20030f03215ce205993dbad7f5
5c384109d3e578a0107e8518bcb91cd63f6926f0c0d0e01525d34a734445685c
e51c6f0fbc5a7e0b03a0d6e1e1d26ab566d606b551c785bf882e9a02f04c862b

Domains

github[.]com/johnshelllby
github[.]com/arturshellby
arthurshelby[.]click
speed-test[.]click
[REDACTED]telecom[.]digital
[REDACTED]airport[.]cloud
[REDACTED]airport[.]pro
portal.[REDACTED]airport[.]cloud
[REDACTED]-connect[.]online
mail.[REDACTED]tell[.]com
[REDACTED]-meeting[.]online

IP Addresses

56.126[.]151
56.126[.]157
56.126[.]188
86.68[.]55
16.74[.]138

Original link: https://www.elastic.co/security-labs/the-shelby-strategy

VanHelsing, new RaaS in Town

Summary

VanHelsingRaaS is a newly emerged and rapidly expanding ransomware-as-a-service (RaaS) affiliate program that was launched on March 7, 2025. This program operates on a revenue-sharing model where affiliates, after paying a $5,000 deposit for new members (reputable affiliates can join for free), retain 80% of the ransom payments, while the core operators receive the remaining 20%. A critical operational rule is the strict prohibition of targeting systems located within the Commonwealth of Independent States (CIS). The RaaS offers a cross-platform ransomware locker, named VanHelsing, capable of targeting a wide array of operating systems beyond Windows, including Linux, BSD, ARM, and ESXi systems. Affiliates are provided with an intuitive control panel to streamline the management and execution of ransomware attacks. Within the initial two weeks of its appearance in the cybercrime community, VanHelsingRaaS has already been linked to three successful infections, demanding substantial ransom payments, exemplified by a $500,000 demand in one instance, payable in Bitcoin. The rapid development and deployment of this RaaS indicate a significant and evolving threat in the ransomware landscape.

Technical Details

VanHelsing Ransomware, the locker associated with the RaaS, was first observed on March 16, 2025. It is developed in C++. The ransomware is designed to operate across multiple platforms, as advertised by the RaaS, targeting Windows, Linux, BSD, ARM, and ESXi systems. Two Windows-targeting variants were identified by Check Point Research, compiled just five days apart (March 11th and March 16th, 2025), with the newer version showing significant updates and the introduction of new command-line arguments and features, indicating active development.

The ransomware supports a variety of command-line arguments that allow attackers to customize the encryption process. These arguments control aspects such as targeting specific drives, directories, or files (--Driver, --Directory, --File), execution parameters (--Force to allow multiple instances, --no-priority to avoid increasing process priority, --Silent for silent mode), stealth features (--no-wallpaper, --no-logs), scope of encryption (--no-local, --no-mounted, --no-network), privilege requirements (--no-admin), and potential spreading mechanisms (--spread-smb, --spread-vcenter - not yet implemented). There are also unimplemented arguments like --no-autostart and --system.

To hinder data recovery, the ransomware attempts to delete shadow copies using the Volume Shadow Copy Service (VSS). This process involves initializing the Component Object Model (COM) using CoInitializeEx and CoInitializeSecurity, determining the system architecture, and creating a COM object instance via CoCreateInstance. It then connects to the ROOT\CIMV2 namespace and executes a WMI query to retrieve and subsequently delete all shadow copies using the Win32_ShadowCopy class.

For local drive enumeration, the ransomware uses the GetLogicalDriveStringsW function to identify valid drives on the system and then selects only fixed local drives and optionally mounted drives for encryption, depending on the presence of the --no-mounted argument.

The ransomware employs a blacklist to exclude certain files, folders, and file extensions from encryption to avoid rendering the system inoperable. Excluded folders include common system and application directories like “tmp”, “winnt”, “temp”, “Windows”, “Program Files”, etc.. Excluded file extensions and files include critical system files and executables such as “.exe”, “.dll”, “.sys”, as well as the ransom note itself (“README.txt”) and others. Notably, there is a flaw in the blacklist where “.vanlocker” is mistakenly excluded instead of the actual encrypted file extension “.vanhelsing”.

Network drive enumeration is performed by default in a separate thread, unless the --no-network argument is used. The ransomware retrieves the local hostname and IP address and then scans a range of IP addresses on the local network (1-255) for open SMB port 445. For each identified SMB server, it uses NetShareEnum to access shared resources and proceeds with folder and file enumeration and encryption. In “Silent” mode, files on network shares are encrypted without the “.vanhelsing” extension being added.

The ransomware possesses SMB spreading capabilities activated by the --spread-smb argument. It drops an embedded psexec.exe binary into the Temp folder. It then scans for writable SMB shares, excluding those containing “NETLOGON” or “sysvol” to avoid disrupting user authentication. The ransomware copies itself as $SHARE\\vanlocker.exe to the network share and uses psexec.exe to execute it remotely with the arguments --no-mounted and --no-network, ensuring the copied instance encrypts the share without further lateral movement.

Silent encryption mode, triggered by the --Silent command-line argument, is a two-stage process designed for evasion. In the first stage (“Normal”), the ransomware encrypts files but skips renaming them. In the second stage (“Silent”), it re-enumerates the files and folders solely to rename the encrypted files by adding the “.vanhelsing” extension.

File encryption involves the use of the Curve25519 public key, which is embedded in the ransomware. For each file, it generates a 32-byte key and a 12-byte nonce, which are then used with the ChaCha20 algorithm for encryption. These ephemeral key and nonce are subsequently encrypted using the embedded Curve25519 public key and stored in hexadecimal format at the beginning of the encrypted file. The structure of an encrypted file is: ---key---$KEY_HEX---endkey------nonce---$NONCE_HEX---endnonce--$ENCRYPTED_CHUNKS. For files larger than approximately 1GB, only the first 30% of the content is encrypted in roughly 1MB chunks. The “.vanhelsing” extension is added immediately unless the --Silent flag is set, in which case it’s added in the second “Silent” stage.

The ransomware executable contains a PDB file path: C:\Users\ADMINI~1\AppData\Local\Temp\2\cd9563b4cbc415b3920633b93c0d351b\1-locker\Release\1-locker.pdb, which provides information about the development environment and could potentially link to other projects by the same author. A second, ineffective loader variant was also discovered based on its PDB path, compiled on March 11, 2025. The ransomware drops a ransom note named README.txt in each enumerated folder. This note informs victims about the breach and encryption of their data, demands Bitcoin for file restoration, warns against using third-party decryptors, and provides Tor links for contacting the attackers along with a unique ticket ID. The ransomware also drops two embedded images in the C:\Windows\Web folder: vhlocker.png to set as the desktop background (displaying the RaaS logo) and vhlocker.ico, intended to be associated with the encrypted “.vanlocker” files (note the extension mismatch). The ransomware attempts to create a mutex named “Global\VanHelsing” to prevent multiple instances from running simultaneously, unless the --Force flag is used.

Countries

Targeted Countries: All countries except those in the Commonwealth of Independent States (CIS).

Industries

Targeted Industries: No specific industries are mentioned in the sources.

Recommendations

Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems and protect against the attacks and threats described in this report. Specific protections mentioned include:

Ransomware.Win.FilesMovedOrOverwrites.A
Ransomware.Win.TouchTrapFiles.A
TS_Ransomware.Win.FilesMovedOrOverwrites.A
Trojan.Win.Krap.gl.D
Trojan.Wins.Imphash.taim.XT
Trojan.Wins.PDB.tapd.ON

Hunting methods

Mutex Detection: Monitor for the creation of the mutex “Global\VanHelsing”. The presence of this mutex might indicate an active or failed attempt to execute the VanHelsing ransomware (unless the --Force argument is used).
File System Monitoring: Look for the creation of files named README.txt in multiple directories shortly after potential intrusion activity. This is the standard ransom note dropped by VanHelsing.
Desktop Background Changes: Detect changes in the desktop background to an image named vhlocker.png in the C:\Windows\Web folder.
Encrypted File Extension: Monitor for the creation of files with the .vanhelsing extension across the file system.
Icon File Association: Although flawed, detection of the file vhlocker.ico being dropped in C:\Windows\Web could be an indicator. However, note the mismatch with the actual encrypted file extension.
PDB Path in Memory or on Disk: While more challenging to detect in real-time, if the ransomware executable is captured, the presence of the PDB file path C:\Users\ADMINI~1\AppData\Local\Temp\2\cd9563b4cbc415b3920633b93c0d351b\1-locker\Release\1-locker.pdb within the binary can be a strong indicator.
SMB Activity: Monitor for unusual SMB traffic patterns, particularly attempts to connect to port 445 from multiple internal hosts, which could indicate the network scanning phase. Also, look for the dropping and execution of vanlocker.exe or psexec.exe on network shares.
Shadow Copy Deletion: Investigate suspicious processes invoking WMI commands to delete shadow copies (wmic.exe shadowcopy delete).

IOC

Hashes

79106dd259ba5343202c2f669a0a61b10adfadff
e683bfaeb1a695ff9ef1759cf1944fa3bb3b6948
4211cec2f905b9c94674a326581e4a5ae0599df9

Negotiation Onion Pages

vanhelcbxqt4tqie6fuevfng2bsdtxgc7xslo2yo7nitaacdfrlpxnqd.onion
vanhelqmjstkvlhrjwzgjzpq422iku6wlggiz5y5r3rmfdeiaj3ljaid.onion
vanhelsokskrlaacilyfmtuqqa5haikubsjaokw47f3pt3uoivh6cgad.onion
vanheltarnbfjhuvggbncniap56dscnzz5yf6yjmxqivqmb5r2gmllad.onion

RaaS Onion Pages

vanhelvuuo4k3xsiq626zkqvp6kobc2abry5wowxqysibmqs5yjh4uqd.onion
vanhelwmbf2bwzw7gmseg36qqm4ekc5uuhqbsew4eihzcahyq7sukzad.onion
vanhelxjo52qr2ixcmtjayqqrcodkuh36n7uq7q7xj23ggotyr3y72yd.onion

Bitcoin Wallet

bc1q0cuvj9eglxk43v9mqmyjzzh6m8qsvsanedwrru

TOX

FEE914521FB507AB978107ACE3B69B4CA41DA89859408BAE23E1512E8C2E614A26C5FFD482A3

Original link: https://research.checkpoint.com/2025/vanhelsing-new-raas-in-town/

You will always remember this as the day you finally caught FamousSparrow

Summmary

ESET Research has uncovered a resurgence of activity from the China-aligned Advanced Persistent Threat (APT) group FamousSparrow in July 2024. Previously thought to be inactive since 2022, the group targeted a trade group in the financial sector in the United States and a research institute in Mexico. This campaign revealed significant advancements in FamousSparrow’s toolset, most notably two previously undocumented versions of their flagship SparrowDoor backdoor. One new version of SparrowDoor showed similarities to the CrowDoor backdoor attributed to Earth Estries, while the other is a modular variant with a significantly different architecture. This campaign also marks the first documented use of the ShadowPad backdoor by FamousSparrow. Further investigation revealed additional targeting of a governmental institution in Honduras between 2022 and 2024. The analysis indicates that FamousSparrow has been actively developing its tools during its presumed inactivity. The report also discusses the ongoing debate and differing opinions among security researchers regarding the potential links between FamousSparrow and other threat actors like Salt Typhoon and GhostEmperor.

Technical Details

The observed attack chain began with initial access likely gained through the exploitation of a vulnerability in outdated versions of Windows Server and Microsoft Exchange. The attackers deployed webshells on an IIS server. A batch script was used to download and deploy a DotNetNuke webshell. This webshell communicated using AES encryption with a hardcoded key e2c99096bcecd1b5. The webshell was used to spawn an interactive remote PowerShell session.

Following initial access, the threat actor performed reconnaissance using legitimate Windows tools and the PowerHub post-exploitation framework. They employed the BadPotato privilege-escalation technique (specifically the open-source Invoke-BadPotato module added to PowerHub) to achieve SYSTEM privileges.

The attackers then deployed SparrowDoor using a trident loader scheme similar to one documented by the UK NCSC in 2022. This involved three files: a legitimate version of K7AntiVirus Messenger Scanner (K7AVMScn.exe) for DLL side-loading, a malicious DLL named K7AVWScn.dll, and an encrypted payload file K7AVWScn.doc. The payload was encrypted using RC4, with the key hardcoded in both the loader and the payload. The decrypted payload contained a custom configuration and reflective loader shellcode. The C&C server configuration was located in the last 202 bytes of the payload, encrypted with the same RC4 key. This configuration consisted of three C&C server addresses and ports, followed by a retry interval.

The first new version of SparrowDoor exhibited improved code quality and architecture, including parallelization of time-consuming commands like file I/O and the interactive shell. It uses an integer value from the registry (HKLM\Software\CLASSES\CLSID\ID or HKCU\Software\CLASSES\CLSID\ID) as a victim identifier. Network communication used a base packet format with a command ID and data length.

Key command-line arguments for this SparrowDoor version included executing without arguments to establish persistence (via a service named K7Soft or a registry Run key), 11 for process hollowing of colorcpl.exe and loader injection, and 22 for main backdoor operation. The backdoor attempts to terminate other running instances by checking for the existence of a mutex named Global\ID() using process IDs.

Notable commands supported by this SparrowDoor version include:

0x32341122: Initial connection.
0x32341123: Send host information (IP, ID, OS details, computer name, username).
0x32341124: Start interactive shell session (parallel) using named pipes \\.\pipe\id2 (commands to shell) and \\.\pipe\id1 (shell output). Commands and output use ID 0x32341126.
0x32341127: Sleep and move to the next C&C server.
0x32341128: Uninstall backdoor and cleanup.
0x32341129: Get current network configuration.
0x3234112A: Set network configuration (received data is RC4 encrypted and overwrites the last 202 bytes of the payload file).
0x3234112B: Execute loader with argument 11 and terminate.
0x3234112D: File I/O (parallel) with subcommands for read (0x3234112E), write (0x3234112F), and data transfer (0x32341130). File reads are done in 4kB chunks. File writes only occur if the received size is greater than the existing file size.
0x32341131: Get connected drive information.
0x32341132: List files (sends an acknowledgement 0x32341133 followed by file information with ID 0x32341132 and a completion message 0x32341134).
0x32341135: Create directory.
0x32341136: Move or rename file.
0x32341137: Delete file.
0x32341138: Start proxy (parallel, sends acknowledgement with same ID, server initiates proxy with 0x32341139).

The second new version is a modular SparrowDoor, significantly different in architecture. The command header is sent separately and the body is RC4 encrypted with the key iotrh^%4CFGTj. It implements fewer built-in commands, focusing on C&C configuration management and backdoor uninstallation. Host information, including a list of installed security products, is sent automatically after the initial connection. The remaining functionality is implemented through plugins. Plugins are PE files sent by the C&C server and loaded in memory. They are referenced via a C++ list with a bitmask and handler function. A default plugin with bitmask 0x10000 handles the installation of new plugins. Similarities were found with HemiGate, which also uses plugins implemented as C++ classes.

The campaign also involved the use of ShadowPad, marking the first observation of this backdoor being deployed by FamousSparrow. A ShadowPad loader (DLL imjpp14.dll) was side-loaded by a renamed, outdated Microsoft Office IME executable (imjp14k.exe). The loader validates the process and decrypts imjp14k.dll.dat before injecting the payload into wmplayer.exe. An in-memory detection of ShadowPad connected to IP 216.238.106[.]150 was observed.

Other tools used during the compromise include:

A basic batch script to dump registry hives (HKLM\SYSTEM, HKLM\SAM, hklm\security).
Impacket or NetExec (detected by firewall).
A modified version of the open-source Spark RAT with a Go shellcode loader.
A tool to dump LSASS memory using the MiniDumpW API, split into two DLLs (%HOME%\dph.dll and %WINDIR%\SysWOW64\msvc.dll) and loaded via a renamed legitimate VLC Cache Generator (dph.exe).

The ShadowPad C&C server used a self-signed TLS certificate with SHA-1 fingerprint BAED2895C80EB6E827A6D47C3DD7B8EFB61ED70B that spoofed Dell certificates. One SparrowDoor C&C server (45.131.179[.]24:80) had a TLS certificate on port 443 with the same Common Name as the ShadowPad C&C server. Three unique SparrowDoor C&C servers on port 80 were identified. The modular SparrowDoor sample used amelicen[.]com as a C&C domain, which resolved to 45.131.179[.]24. One SparrowDoor loader download server (43.254.216[.]195:80) was also used as a C&C server in the modular sample.

Countries

United States
Mexico
Honduras

Industries

Financial Sector (trade group)
Research Institute
Governmental Institution

Recommendations

The source article does not explicitly list technical recommendations for defense. However, based on the TTPs observed, typical recommendations for mitigating APT threats would apply:

Keep operating systems and software, especially internet-facing applications like Microsoft Exchange and IIS servers, up to date with the latest security patches.
Implement strong password policies and multi-factor authentication to protect domain accounts.
Monitor network traffic for suspicious connections and command-and-control activity, particularly to the identified IOCs.
Implement endpoint detection and response (EDR) solutions to detect and block malicious activities, including process injection, DLL side-loading, and suspicious PowerShell usage.
Monitor for the creation of unusual services or registry Run keys for persistence.
Be vigilant for the execution of legitimate tools like certutil.exe, reg.exe, wmic.exe, net.exe, tasklist.exe, and PowerShell in unusual contexts.
Inspect the HKLM\Software\CLASSES\CLSID\ and HKCU\Software\CLASSES\CLSID\ registry hives for keys with non-standard names.
Monitor for the use of open-source tools like PowerHub and Spark RAT, especially if they are modified.
Detect and block known ShadowPad infrastructure and loaders.

Hunting methods

The article mentions several indicators and techniques that can be used for threat hunting:

Unusual registry keys: Hunting for non-standard named keys under Software\Classes\CLSID\ in both HKLM and HKCU hives can identify potential SparrowDoor activity.

// Example pseudo-query
Registry Hive: HKLM OR HKCU
Path: Software\Classes\CLSID\
Description: Look for registry keys under CLSID that do not conform to the GUID format (i.e., not enclosed in curly brackets).

Process hollowing of colorcpl.exe: Monitoring for colorcpl.exe being launched with the command-line argument 22 followed by injection of a suspicious module could indicate SparrowDoor execution.
```
// Example pseudo-query
Process Name: colorcpl.exe
Command Line: * 22
Description: Investigate if this process is followed by suspicious DLL injection or network activity.
```
Mutex creation pattern: Detecting the creation of mutexes with the name Global\ID(<PID>) where <PID> is the process ID of running processes, especially if followed by process termination, could indicate SparrowDoor attempting to kill other instances.
```
// Example pseudo-query
Mutex Name: Global\ID(*)
Description: Correlate mutex creation with subsequent process termination events, excluding known legitimate patterns.
```

Network connections on port 80: Monitor connections to the identified SparrowDoor C&C IPs on port 80.

// Example pseudo-query
Network Destination IP: 43.254.216[.]195 OR 45.131.179[.]24 OR 103.85.25[.]166
Network Destination Port: 80
Protocol: TCP
Description: Investigate traffic to these known FamousSparrow C&C servers.

ShadowPad loader side-loading: Look for the execution of imecmnt.exe (renamed to imjp14k.exe) loading imjpp14.dll. Also monitor for wmplayer.exe being spawned by imjp14k.exe and connecting to 216.238.106[.]150.

// Example pseudo-query
Process Name: imjp14k.exe
Loaded DLL: imjpp14.dll
Description: Investigate instances of this DLL being loaded by the renamed IME executable.

Process Name: wmplayer.exe
Parent Process Name: imjp14k.exe
Network Destination IP: 216.238.106[.]150
Protocol: TCP
Description: Look for Windows Media Player processes spawned by the renamed IME executable connecting to the ShadowPad C&C server.

LSASS memory dumping: Monitor for the execution of dph.exe loading msvc.dll from SysWOW64, which could be indicative of the custom LSASS dumping tool.

// Example pseudo-query
Process Name: dph.exe
Loaded DLL: %WINDIR%\SysWOW64\msvc.dll
Description: Investigate instances of dph.exe loading this specific DLL, especially if `dph.exe` is a renamed VLC cache generator.

IOC

Hashes

C26F04790C6FB7950D89AB1B08207ACE01EFB536
F35CE62ABEEDFB8C6A38CEAC50A250F48C41E65E
5265E8EDC9B5F7DD00FC772522511B8F3BE217E3
A91B42E5062FEF608F285002DEBAFF9358162B25
0DC20B2F11118D5C0CC46B082D7F5DC060276157
EF189737FB7D61B110B9293E8838526DCE920127
D03FD329627A58B40E805F4F55B5D821063AC27F
3A395DAAF518BE113FCFF2E5E48ACD9B9C0DE69D
0925F24082971F50EDD987D82F708845A6A9D7C9
5F1553F3AF9425EF5D68341E991B6C5EC96A82EB
CC350BA25947B7F9EC5D11EA8269407C0FD74095
DB1591C6E23160A94F6312CA46DA2D0BB243322C
1B06E877C2C12D74336E7532BC0ECF761E5FA5D4
EBC93A546BCDF6CC1EB61D7174BCB85407BBD892
D6D32A1F17D48FE695C0778018C0D51626DB4A3B
7D66B550EA68A86FCC0958E7C159531D4431B788
5DF3C882DB6BE14887182B7439B72A86BD28B83F
AA823148EEA6F43D8EB9BF20412402A7739D91C2

Domains

amelicen[.]com

IPs

254.216[.]195
131.179[.]24
85.25[.]166
238.106[.]150

Original link: https://www.welivesecurity.com/en/eset-research/you-will-always-remember-this-as-the-day-you-finally-caught-famoussparrow/