Google issues emergency update for 2B Chrome users after confirming active zero-day exploitation.
The post Google Issues Emergency Update for 2B Chrome Users appeared first on TechRepublic.
Google issues emergency update for 2B Chrome users after confirming active zero-day exploitation.
The post Google Issues Emergency Update for 2B Chrome Users appeared first on TechRepublic.
A new, critical zero-day vulnerability dubbed “ToolShell” (CVE-2025-53770) poses a significant threat to on-premises SharePoint Server deployments. This vulnerability enables unauthenticated remote code execution (RCE), posing a significant risk to organizations worldwide. SentinelOne has detected exploitation in the wild, elevating the active threat posed by this new attack and the importance of organizations taking mitigative action as soon as possible.
In this blog, we outline ways to defend against ToolShell and how SentinelOne keeps you ahead of the curve for this critical vulnerability. For a comprehensive technical breakdown of this threat, we published a detailed analysis on the SentinelOne blog.
ToolShell is a critical zero-day remote code execution vulnerability impacting on-premises SharePoint Servers. Its severity stems from several key characteristics:
At SentinelOne, our commitment to proactive security means we are constantly working to identify and neutralize emerging threats, such as ToolShell, often before they become widespread news. SentinelOne was aware and working to defend our customers from ToolShell two days prior to the public announcement of the vulnerability. This integrated approach ensures that SentinelOne customers are protected from the outset:
Given the critical nature of ToolShell, we strongly recommend that organizations implement a multi-layered defense strategy. Proactive measures are crucial to mitigate the risk of compromise:
Immediate Mitigation & Patching:
Enhanced Detection and Monitoring:
ToolShell represents a significant vulnerability that leaves many organizations running on-premises SharePoint Server at considerable risk. The potential for unauthenticated remote code execution, coupled with observed in-the-wild exploitation, underscores the urgent need for organizations to take decisive action to maintain their security posture. This includes diligently applying patches, implementing robust monitoring, and leveraging advanced threat detection capabilities to mitigate the risk.
For SentinelOne customers, you can rest assured that you are protected. Our dedicated threat research and MDR teams work tirelessly to stay one step ahead of adversaries, ensuring that our platform provides immediate and effective defense against emerging threats, such as ToolShell. Our proactive identification, rapid deployment of detection logic, and continuous sharing of intelligence empower our customers to maintain a resilient security posture.
Contact SentinelOne today to learn how our AI-powered security platform can provide the comprehensive protection and peace of mind your organization deserves. Don’t wait for the next zero-day; secure your future today.
SHA-1
f5b60a8ead96703080e73a1f79c3e70ff44df271 – spinstall0.aspx webshell
fe3a3042890c1f11361368aeb2cc12647a6fdae1 – xxx.aspx webshell
76746b48a78a3828b64924f4aedca2e4c49b6735 – App_Web_spinstall0.aspx.9c9699a8.avz5nq6f.dll, a compiled version of spinstall0.aspx
IP Addresses
96.9.125[.]147 – attacker IP from “no shell” cluster
107.191.58[.]76 – attacker IP used in 1st wave of spinstall0.aspx cluster
104.238.159[.]149 – attacker IP used in 2nd wave of spinstall0.aspx cluster
//Suspicious SharePoint Activity dataSource.name = 'SentinelOne' and endpoint.os = "windows" and event.type = "Process Creation" and src.process.parent.name contains "svchost.exe" and src.process.name contains "w3wp.exe" and tgt.process.name contains "cmd.exe" and src.process.cmdline contains "SharePoint" //spinstall0.aspx execution traces dataSource.name = 'SentinelOne' and endpoint.os = "windows" and event.type = "Process Creation" and src.process.name contains "csc.exe" and tgt.file.path contains "App_Web_spinstall0.aspx"
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
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.
SentinelOne first observed ToolShell exploitation on July 17th, ahead of official Microsoft advisories. Since then, we’ve identified three distinct attack clusters, each with unique tradecraft and objectives. In this blog, we unpack the timeline, explore these clusters, and equip defenders with best-practice mitigation strategies. At this time, we provide no attribution beyond this early clustering as research is ongoing.
We have observed initial ToolShell exploitation against high value organizations, with victims primarily in technology consulting, manufacturing, critical infrastructure, and professional services tied to sensitive architecture and engineering organizations. The early targets suggest that the activity was initially carefully selective, aimed at organizations with strategic value or elevated access.
The attacks that we describe in this report were targeted in nature and occurred before public disclosure of the vulnerability spurred mass exploitation efforts from a wider set of actors. We expect broader exploitation attempts to accelerate, driven by both state-linked and financially motivated actors seeking to capitalize on unpatched systems.
SentinelOne has observed multiple state-aligned threat actors, unrelated to the first wave of exploitation, beginning to engage in reconnaissance and early-stage exploitation activities. Additionally, we’ve also identified actors possibly standing up decoy honeypot environments to collect and test exploit implementations , as well as sharing tooling and tradecraft across known sharing platforms. As awareness spreads within these communities, we expect further weaponization and sustained targeting of vulnerable SharePoint infrastructure.
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.
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:
Login
GTaRkhJ9wz parameter, which are run via cmd.exe and returned to the client.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.
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.
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.
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.
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.
Unlike the other clusters, no persistent webshells were written to disk. Instead, telemetry and behavioral indicators suggest the attackers relied on in-memory .NET module execution, avoiding traditional file-based artifacts entirely. This approach significantly complicates detection and forensic recovery, underscoring the threat posed by fileless post-exploitation techniques.
All observed activity in this cluster originated from a single IP address: 96.9.125[.]147. Despite the lack of file system artifacts, compromised hosts exhibited patterns consistent with SharePoint exploitation, followed by encoded payload delivery and dynamic assembly loading via PowerShell or native .NET reflection.
Given the timing, just days after public proof-of-concept chatter began, and the sophistication of the fileless execution chain, we assess this cluster to be either a skilled red team emulation exercise or the work of a capable threat actor with a focus on evasive access and credential harvesting.
Defenders should be especially vigilant for memory-resident activity following SharePoint exploitation attempts and should employ EDR solutions capable of detecting anomalous .NET execution patterns and assembly loading.
Modern threat actors are maximizing gains from patch diffing, n-day adoption, and iterative development of exploits through fast adoption. SharePoint servers are attractive to threat actors for the high likelihood that they store sensitive organizational data. Beyond their value as a knowledge store, vulnerable SharePoint servers can be used to stage and deliver additional attack components to the victim organization for internal watering hole attacks. The ease of exploitation and potential value of the data hosted on these servers make ‘ToolShell’ a potent and dangerous attack chain.
As of this writing, SharePoint Online for Microsoft 0365 is not impacted. Our research teams have provided out-of-the-box Platform Detection rules and Hunting Queries to assist in discovering and isolating related behavior. We recommend that vulnerable organizations apply the available security updates released by Microsoft (released July 21, 2025) to mitigate the related vulnerabilities as soon as possible. SentinelOne is actively monitoring its customer base for impact and is notifying those affected as they are identified.
SHA-1
f5b60a8ead96703080e73a1f79c3e70ff44df271 - spinstall0.aspx webshell
fe3a3042890c1f11361368aeb2cc12647a6fdae1 - xxx.aspx webshell
76746b48a78a3828b64924f4aedca2e4c49b6735 - App_Web_spinstall0.aspx.9c9699a8.avz5nq6f.dll, a compiled version of spinstall0.aspx
IP Addresses
96.9.125[.]147 - attacker IP from “no shell” cluster
107.191.58[.]76 - attacker IP used in 1st wave of spinstall0.aspx cluster
104.238.159[.]149 - attacker IP used in 2nd wave of spinstall0.aspx cluster
//Suspicious SharePoint Activity dataSource.name = 'SentinelOne' and endpoint.os = "windows" and event.type = "Process Creation" and src.process.parent.name contains "svchost.exe" and src.process.name contains "w3wp.exe" and tgt.process.name contains "cmd.exe" and src.process.cmdline contains "SharePoint" //spinstall0.aspx execution traces dataSource.name = 'SentinelOne' and endpoint.os = "windows" and event.type = "Process Creation" and src.process.name contains "csc.exe" and tgt.file.path contains "App_Web_spinstall0.aspx"
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
In late 2021, the Apache Software Foundation disclosed a vulnerability that set off a panic across the global tech industry. The bug, known as Log4Shell, was found in the ubiquitous open-source logging library Log4j, and it exposed a huge swath of applications and services.
Nearly anything from popular consumer and enterprise platforms to critical infrastructure and IoT devices was exposed. Over 35,000 Java packages were impacted by Log4j vulnerabilities. That’s over 8% of the Maven Central repository, the world’s largest Java package repository.
When Log4j was discovered, CISA Director Jen Easterly said, “This vulnerability is one of the most serious that I’ve seen in my entire career, if not the most serious.”
Since Log4j surfaced, how has the security community responded? What lessons have we learned (or not learned)?
Log4Shell is no longer a massive, widespread danger. Still, researchers warn that the vulnerability is still present in far too many systems. And actors will continue to exploit it for years to come.
Log4Shell was unusual because it was so easy to exploit wherever it was present. Developers use logging utilities to record operations in applications. To exploit Log4Shell, all an attacker has to do is get the system to log a special string of code. From there, they can take control of their victim to install malware or launch other attacks.
“Logging is fundamental to essentially any computer software or hardware operation. Whether it’s a phlebotomy machine or an application server, logging is going to be present,” said David Nalley, president of the nonprofit Apache Software Foundation, in an interview with Wired. “We knew Log4j was widely deployed, we saw the download numbers, but it’s hard to fully grasp since in open source you’re not selling a product and tracking contracts. I don’t think you fully appreciate it until you have a full accounting of where software is, everything it’s doing and who’s using it. And I think the fact that it was so incredibly ubiquitous was a factor in everyone reacting so immediately. It’s a little humbling, frankly.”
According to Nalley, they had software fixes out within two weeks. Alarmingly, Apache still sees up to 25% of downloads involving non-patched versions of Log4j.
Threat actors continue to exploit the Log4j vulnerability to this day. CISA has released alerts regarding Iranian and Chinese actors using the exploit. From Iran, cyber threat actors took advantage of the Log4Shell vulnerability in an unpatched VMware Horizon server, installed crypto mining software, moved laterally to the domain controller, compromised credentials and implanted reverse proxies on several hosts to maintain persistence. Meanwhile, the top Common Vulnerabilities and Exposures (CVEs) most used by Chinese state-sponsored cyber actors since 2020 is Log4j.
Given the danger and ongoing threat, why do so many vulnerable versions of Log4j still persist? Could it be that some IT pros don’t really know what’s in their software?
The problem isn’t software vulnerability alone. It’s also not knowing if you have vulnerable code hiding your applications. Surprisingly, many security and IT professionals have no idea whether Log4j is part of their software supply chain. Or even worse, they choose to ignore the danger.
Part of the challenge is due to the rise of open-source software (OSS). Coders leverage OSS to accelerate development, cut costs and reduce time to market. Easy access to open-source frameworks and libraries takes the place of writing custom code or buying proprietary software. And while many applications get built quickly, the exact contents might not be known.
In a Linux Foundation SBOM and Cybersecurity Readiness report, 98% of organizations surveyed use open-source software. Due to the explosion of OSS use, it’s clear that supply chain cybersecurity may be impossible to gauge for any given application. If you don’t know what’s in your supply chain, how can you possibly know it’s secure?
The threat of vulnerabilities (both known and zero-day) combined with the unknown contents of software packages has led security regulators and decision-makers to push for the development of software bills of materials.
According to CISA:
A “software bill of materials” (SBOM) has emerged as a key building block in software security and software supply chain risk management. An SBOM is a nested inventory, a list of ingredients that make up software components.
If you have a detailed list of individual software components, you can assess risk exposure more accurately. Also, with a well-developed SBOM, you can match your list against CISA’s Known Exploited Vulnerabilities Catalog. Or, if you hear about an emerging mass exploit like Log4j, you can quickly confirm if your stack is at risk. If you don’t have an SBOM, you’re in the dark until you are notified by your vendor or until you get hacked.
If you were to scan your systems for software vulnerabilities, you might discover hundreds of thousands of weaknesses. Also, if you merged with another company recently, you inherit their risk burden as well. For larger enterprises, detected vulnerabilities can number in the millions.
Trying to patch everything at once would be impossible. Instead, proper triage is essential. For example, vulnerabilities nearest to mission-critical systems should be prioritized. Also, an organization should audit, monitor and test its software vulnerability profile often. And since IT teams might add applications at any moment, an up-to-date network inventory and scheduled vulnerability scanning are critical. Automated software vulnerability management programs can be a great help here.
Many companies don’t have the time or qualified resources to identify, prioritize and remediate vulnerabilities. The process can be overwhelming. Given the high risk involved, some organizations opt to hire expert vulnerability mitigation services.
While Log4j sent some into a frenzy, others didn’t even seem to notice. This gives rise to the debate about cyber responsibility. If my partner hasn’t patched a vulnerability, and it affects my operations, should my partner be held responsible?
In one survey, 87% of respondents said that given the level of cyber risk posed by Log4j, government regulatory agencies (such as the U.S. Federal Trade Commission) should take legal action against organizations that fail to patch the flaw.
Only time will tell how far the security community will take responsibility for vulnerabilities — whether by being proactive or by force.
The post Log4j Forever Changed What (Some) Cyber Pros Think About OSS appeared first on Security Intelligence.
