Intelligence Cards

Top Attackers: Shai-Hulud

IOCs:

46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09 (bundle.js)

https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7 (Exfiltration endpoint)

.github/workflows/shai-hulud-workflow.yml (File System)

Description:

JLR Shai-hulud refers to a large-scale cyberattack that severely disrupted Jaguar Land Rover's IT systems and forced the suspension of production at its factories in September 2025. The malware used in the attack was named "Shai-Hulud," a reference to the giant sandworms in Frank Herbert's Dune novels. The Shai-Hulud cyberattack :- 1- What it was: A self-replicating software supply chain attack using a "worm" named Shai-Hulud. It initially targeted the npm (Node Package Manager) ecosystem, which is used by developers to share JavaScript code. 2 - How it spread: After breaching the npm ecosystem, the malware targeted GitHub and cloud service credentials, using them to spread and poison other software packages. 3 - Impact on JLR: The attack caused a "catastrophic" shutdown of JLR's IT systems, forcing the company to pause production at its UK assembly plants and severely disrupting its supply chain. This prevented the automaker from ordering parts, booking shipments, and registering new vehicles for sale. 4 - Investigation: In the aftermath, India's CERT-In issued a warning about the malware, and cybersecurity firms investigated how the worm compromised hundreds of open-source packages.

Remediation:

Rotate All Credentials Immediately The malware harvests credentials from multiple sources. Rotate ALL of the following: NPM tokens (automation and publish tokens) GitHub personal access tokens GitHub Actions secrets in all repositories SSH keys used for Git operations AWS IAM credentials, access keys, and session tokens Google Cloud service account keys and OAuth tokens Azure service principals and access tokens Any credentials stored in AWS Secrets Manager or GCP Secret Manager API keys found in environment variables Database connection strings Third-party service tokens CI/CD pipeline secrets Audit Cloud Infrastructure for Compromise Since the malware specifically targets AWS Secrets Manager and GCP Secret Manager, you need to audit your cloud infrastructure for unauthorized access. The malware uses API calls to enumerate and exfiltrate secrets, so reviewing audit logs is critical to understanding the scope of compromise. AWS Security Audit Start by examining your CloudTrail logs for any suspicious secret access patterns. Look specifically for BatchGetSecretValue, ListSecrets, and GetSecretValue API calls that occurred during the time window when the compromised package may have been installed. Also generate and review IAM credential reports to identify any unusual authentication patterns or newly created access keys. # Check CloudTrail for suspicious secret access aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=BatchGetSecretValue aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ListSecrets aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue # Review IAM credential reports for unusual activity aws iam get-credential-report --query 'Content' GCP Security Audit For Google Cloud Platform, review your audit logs for any access to the Secret Manager service. The malware uses the @google-cloud/secret-manager library to enumerate secrets, so look for unusual patterns of secret access. Additionally, check for any unauthorized service account key creation, as these could be used for persistent access. # Review secret manager access logs gcloud logging read "resource.type=secretmanager.googleapis.com" --limit=50 --format=json # Check for unauthorized service account key creation gcloud logging read "protoPayload.methodName=google.iam.admin.v1.CreateServiceAccountKey" Monitor for Active Exploitation Network Monitoring Block outbound connections to webhook.site domains immediately Monitor firewall logs for connections to https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7 Implement Security Controls GitHub Security Hardening Review and remove unnecessary GitHub Apps and OAuth applications Audit all repository webhooks for unauthorized additions Check deploy keys and repository secrets for all projects Enable branch protection rules to prevent force-pushes Turn on GitHub Secret Scanning alerts Enable Dependabot security updates Ongoing Monitoring Set up alerts for any new npm publishes from your organization Monitor CloudTrail/GCP audit logs for secret access patterns Implement regular credential rotation policies Use separate, limited-scope tokens for CI/CD pipelines ‍

Top Attackers: Scattered Lapsus$ Hunters and Shiny Hunters Group

IOCs:

Common Indicators of Compromise (IOCs)

1 - Compromised OAuth Tokens: Attackers steal tokens from third-party integrations (e.g., Salesloft-Drift) to access Salesforce data.
 
2 - Suspicious IP Addresses: Logins from IP addresses associated with known threat actor infrastructure. 

3 - Malicious Connected Apps: Unauthorized or suspicious apps connected to a Salesforce organization. 

4 - Unusual Activity Logs: Check Salesforce logs for anomalies, such as:
  Object Enumeration: Repeated attempts to query or list Salesforce objects, especially cases. 
  Broad Queries: Unexpectedly large or wide-ranging queries. 

5 - Social Engineering: Employees being tricked into granting access or sharing credentials via voice phishing campaigns.

Description:

Threat actors known as "Scattered Lapsus$ Hunters" have launched a data leak site to extort 39 companies whose data was stolen from Salesforce. The site, which mimics the notorious hacking forum "BreachForums," is located at breachforums[.]hn. The group is attempting to extort major companies and brands, including FedEx, Disney/Hulu, Home Depot, Marriott, Google, Cisco, Toyota, Gap, Kering, McDonald's, Walgreens, Instacart, Cartier, Adidas, Sake Fifth Avenue, Air France & KLM, Transunion, HBO MAX, UPS, Chanel, and IKEA. In total, the threat actors claimed to have stolen nearly 1 billion data records, which would be publicly released if an extortion demand was paid by individual companies or as a single payment from Salesforce that would cover all the impacted customers listed on the site. In two separate campaigns during 2025, attackers stole data from Salesforce. The first campaign began in late 2024. The attackers used social engineering—pretending to be IT support—to trick employees into connecting a malicious application to their company's Salesforce accounts. Once they gained access, they stole databases and then used the stolen data to extort the companies via email. This attack impacted several well-known companies, including Google, Cisco, Qantas, Adidas, Allianz Life, Farmers Insurance, Workday, Kering, and LVMH subsidiaries like Dior, Louis Vuitton, and Tiffany & Co. A second campaign started in early August 2025. In this case, the attackers used stolen SalesLoft Drift OAuth tokens to access and steal data from customer CRM environments. The campaign, attributed to a financially motivated group tracked by Google as UNC6040 and often linked to the ShinyHunters name, relied entirely on social engineering rather than exploiting any flaw in Salesforce’s infrastructure. While no vulnerabilities within Salesforce itself have been exploited, the incidents demonstrate how social engineering can bypass technical controls when users are misled into granting permissions. In multiple cases, stolen data has later been linked to extortion attempts, sometimes occurring months after the initial breach. The threat actors have, at times, claimed affiliation with the well-known group ShinyHunters during these extortion efforts, likely to increase pressure on victims.

Remediation:

Mitigation and Readiness Strategies :- To defend against threats like the Salesforce breach, organizations should take a multi-layered approach: 1 - Restrict API access: Ensure connected applications like Data Loader only have the minimum access needed for essential functions. 2 - Control third-party apps: Authorize only trusted and vetted applications to prevent malicious integrations. 3 - Limit access by location: Use strict IP restrictions to block unauthorized logins and API calls. 4 - Strengthen authentication: Deploy strong multi-factor authentication (MFA) and educate employees on how to avoid phishing and MFA fatigue attacks. 5 - Detect data exfiltration: Set up monitoring to automatically detect suspicious data access, such as large-scale downloads or unusual API activity.

Top Attackers: ToolShell

IOCs:

Submitted Files (6)
3461da3a2ddcced4a00f87dcd7650af48f97998a3ac9ca649d7ef3b7332bd997 (osvmhdfl.dll)

60a37499f9b02c203af24c2dfd7fdb3834cea707c4c56b410a7e68376938c4b7 (stage3.txt)

92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514 (spinstall0.aspx)

9340bf7378234db5bca0dc5378bf764b6a24bb87a42b05fa21a996340608fbd7 (info3.aspx)

d0c4d6a4be0a65f8ca89e828a3bc810572fff3b3978ff0552a8868c69f83d170 (spinstallp.aspx)

d9c4dd5a8317d1d83b5cc3482e95602f721d58e3ba624d131a9472f927d33b00 (spinstallb.aspx)

Additional Files (2)
675a10e87c248d0f629da864ba8b7fd92b62323c406a69dec35a0e6e1552ecbc (info3.aspx)

bee94b93c1796981a55d7bd27a32345a61304a88ed6cd70a5f7a402f1332df72 (bjcloiyq.dll)

Description:

On July 19th, Microsoft confirmed that a 0-day vulnerability impacting on-premises Microsoft SharePoint Servers, dubbed “ToolShell” (by researcher Khoa Dinh @_l0gg), was being actively exploited in the wild. This flaw has since been assigned the identifier CVE‑2025‑53770, along with an accompanying bypass tracked as CVE‑2025‑53771. These two new CVEs are being used alongside the previously patched CVEs (49704/49706) which were patched on July 8th, with PoC code surfacing by July 14th. The advisory also confirmed emergency patches for on-prem SharePoint Subscription Edition and SharePoint Server  2019, with updates scheduled for version 2016 as well. We strongly recommend immediate patching, and following Microsoft’s recommendations of enabling AMSI detection, rotating ASP.NET machine keys, and isolating public-facing SharePoint servers until defenses are in place. Technical Overview Both previously patched CVEs (49704/49706) were first disclosed at Pwn2Own Berlin. It was later discovered that these two flaws could be paired together to produce the full RCE ‘ToolShell’ attack chain. The name ‘ToolShell’ refers to the initial abuse of SharePoint’s /ToolPane.aspx (CVE-2025-49704), a system page used for website configuration and management. This vulnerability chain enables unauthenticated remote code execution by sending a crafted POST request to the URI /layouts/15/ToolPane.aspx?DisplayMode=Edit, exploiting a logic flaw in the Referer header validation. This bypass allows attackers to access SharePoint’s ToolPane functionality without authentication, ultimately leading to code execution via uploaded or in-memory web components. xxx.aspx On July 18th, 2025 at 09:58 GMT, SentinelOne observed a single exploitation attempt where the attacker dropped a custom password-protected ASPX webshell named xxx.aspx. This activity appears to be hands-on and exploratory in nature, likely performed by a human operator rather than an automated script. The webshell was written to the following path: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\xxx.aspx This webshell provides a basic HTML interface allowing three primary functions: Authentication via an embedded form that sets a cookie. Command Execution by submitting commands through the GTaRkhJ9wz parameter, which are run via cmd.exe and returned to the client. File Upload via a multipart form using fields 0z3H8H8atO (file) and 7KAjlfecWF (destination path). The shell leverages basic obfuscation and validation mechanisms, including cookie-based authentication and a hardcoded SHA512 hash to restrict access. The password check logic suggests the actor anticipated repeated or remote usage of the shell. After the webshell was dropped, the attacker issued the following commands: cmd.exe /c whoami > c:\progra~1\common~1\micros~1\webser~1\16\template\layouts\info.js The first attempt to redirect the whoami output failed due to a typo (\templa), indicating the activity was likely manual and exploratory. The corrected second command successfully writes the output of whoami into a web-accessible .js file, a common tactic for validating command execution and potentially retrieving output through a browser. While this activity was limited to a single observed instance, the customized tooling and interactive behavior suggest a deliberate post-exploitation attempt by a threat actor testing or preparing for broader operations. spinstall0.aspx SentinelOne observed two distinct waves of activity involving a consistent final payload, spinstall0.aspx, dropped across SharePoint environments from different attacker infrastructure on July 18 and 19, 2025. While the initial dropper scripts varied slightly between waves, both resulted in deployment of the same webshell, designed to extract and expose sensitive cryptographic material from the host. First Wave – July 18, 2025 (14:54–18:44 GMT) Source IP: 107.191.58[.]76 This initial wave involved PowerShell-based payload delivery. A base64-encoded blob was decoded and written to the SharePoint LAYOUTS directory: $base64String = [REDACTED] $destinationFile = "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx" $decodedBytes = [System.Convert]::FromBase64String($base64String) $decodedContent = [System.Text.Encoding]::UTF8.GetString($decodedBytes) $decodedContent | Set-Content -Path $destinationFile -ErrorAction Stop The resulting file, spinstall0.aspx, is not a traditional command webshell but rather a reconnaissance and persistence utility: <%@ Import Namespace="System.Diagnostics" %> <%@ Import Namespace="System.IO" %> This code extracts and prints the host’s MachineKey values, including the ValidationKey, DecryptionKey, and cryptographic mode settings—information critical for attackers seeking to maintain persistent access across load-balanced SharePoint environments or to forge authentication tokens. Second Wave – July 19, 2025 (03:06–07:59 GMT) Source IP: 104.238.159[.]149 Roughly 12 hours later, a second wave used nearly identical logic to deliver the same spinstall0.aspx payload. The key difference was in the PowerShell staging script: $b = [REDACTED] $c = "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\15\TEMPLATE\LAYOUTS\spinstall0.aspx" $d = [System.Convert]::FromBase64String($b) $e = [System.Text.Encoding]::UTF8.GetString($d) $e | Set-Content -Path $c -ErrorAction Stop Start-Sleep -s 3 While the encoded payload was marginally different in form, it decoded to the same spinstall0.aspx shell. The change in target directory, from 16\TEMPLATE to 15\TEMPLATE, may reflect testing across different SharePoint versions or environments. Unlike more interactive webshells observed in this campaign, spinstall0.aspx does not support command execution or file upload. Instead, its singular purpose appears to be information gathering, specifically targeting cryptographic secrets that could be reused to forge authentication or session tokens across SharePoint instances. Given the uniqueness and strategic value of the MachineKey data harvested by this shell, we assess this cluster to be part of a broader effort to establish durable access into high-value SharePoint deployments. “no shell” This activity cluster, tracked as “no shell”, represents a more advanced and stealthy approach compared to others in this campaign. SentinelOne observed this cluster operating between July 17, 2025 10:35:04 GMT and July 18, 2025 03:51:29 GMT, making it our earliest known exploitation of CVE-2025-53770 in the wild.

Remediation:

<b>Customers using SharePoint Server should follow the guidance below.</b> Use or upgrade to supported versions of on-premises Microsoft SharePoint Server. Supported versions: SharePoint Server 2016, 2019, and SharePoint Subscription Edition Apply the latest security updates. Ensure the Antimalware Scan Interface is turned on and configured correctly and deploy Defender Antivirus on all SharePoint servers Configure Antimalware Scan Interface (AMSI) integration in SharePoint, enable Full Mode for optimal protection, and deploy Defender Antivirus on all SharePoint servers which will stop unauthenticated attackers from exploiting this vulnerability. Note: AMSI integration was enabled by default in the September 2023 security update for SharePoint Server 2016/2019 and the Version 23H2 feature update for SharePoint Server Subscription Edition. If you cannot enable AMSI, we recommend you consider disconnecting your server from the internet until you have applied the most current security update linked above. If the server cannot be disconnected from the internet, consider using a VPN or proxy requiring authentication or an authentication gateway to limit unauthenticated traffic. Deploy Microsoft Defender for Endpoint, or equivalent solutions We recommend organizations to deploy Defender for Endpoint to detect and block post-exploit activity. Rotate SharePoint Server ASP.NET machine keys After applying the latest security updates above or enabling AMSI, it is critical that customers rotate SharePoint server ASP.NET machine keys and restart Internet Information Services (IIS) on all SharePoint servers. Manually using PowerShell To update the machine keys using PowerShell, use the Set-SPMachineKey cmdlet. Manually using Central Admin: Trigger the Machine Key Rotation timer job by performing the following steps: Navigate to the Central Administration site. Go to Monitoring -> Review job definition. Search for Machine Key Rotation Job and select Run Now. Restart IIS on all SharePoint servers using iisreset.exe. NOTE: If you cannot enable AMSI, you will need to rotate your keys and restart IIS after you install the new security update. Implement your incident response plan. To protect against post-exploitation activity, including ransomware deployment, Microsoft recommends the following mitigations: Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants. Read our human-operated ransomware blog for advice on developing a holistic security posture to prevent ransomware, including credential hygiene and hardening recommendations. Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint – or equivalent EDR solution – can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach. Configure automatic attack disruption in Microsoft Defender XDR. Automatic attack disruption is designed to contain attacks in progress, limit the impact on an organization’s assets, and provide more time for security teams to remediate the attack fully. Enable LSA protection. Enable and configure Credential Guard. Ensure that tamper protection is enabled in Microsoft Defender for Endpoint. Enable controlled folder access. Microsoft Defender customers can turn on attack surface reduction rules to prevent common attack techniques. Attack surface reduction rules are sweeping settings that stop entire classes of threats. The following bullet points offer more guidance on specific mitigation advice: Use advanced protection against ransomware. Block credential stealing from the Windows local security authority subsystem. Block process creations originating from PSExec and WMI commands.