ToolShell Day 4: We Audited 22 On-Prem SharePoints This Weekend — Here's the Patch + Recovery Flow

Between Saturday morning and Sunday night (July 19-20, 2025) our security bench audited 22 on-premises SharePoint farms across Indian SMBs running CRMs, vendor portals, and internal intranets. Of the 22, 14 were unpatched when we arrived, 3 had a confirmed spinstall0.aspx web shell on disk, and 1 had MachineKey theft confirmed by Mandiant IOC matches in the IIS logs. By Monday morning all 22 were patched, rotated, hunted, and verified. This post is the 90-minute recovery flow we standardised across that weekend so your team can run it without us.

The 60-Second Answer

Patch + rotate + hunt is a 90-minute job per farm if you have farm-admin access and a runbook. Patch with the July 19 emergency KB, rotate the MachineKey via Set-SPMachineKey, restart IIS, then run a Get-ChildItem sweep of the LAYOUTS directories for spinstall*.aspx. Cross-check IIS logs from July 7 onward for the known POST + Referer pattern. If you find a web shell, that farm is in IR territory, not patch territory — see Section 7 below.

Why Day 4 Matters More Than Day 0

Day 0 (July 19) was the "is my farm patched" question. Day 4 (July 22) is the "did the patch work, and what did the attacker leave behind" question. Singapore's CSA published a remediation guide on July 21 that explicitly notes patching does not evict an attacker who already stole MachineKey material. Krebs on Security and Mandiant have both confirmed that some farms patched on July 19 are still being re-entered on July 21-22 using forged ViewState payloads signed with stolen keys. The window between "patched" and "actually clean" is where most teams lose.

For the 8 of our 22 farms that were already patched on arrival (good), only 3 had also rotated MachineKeys (bad). The other 5 were one ViewState forgery away from re-compromise.

The 90-Minute Recovery Sprint (The Exact Flow)

Step 1 — Verify version (5 minutes)

Open SharePoint Management Shell as farm admin:

Get-SPProduct | Select-Object PatchVersion, ProductName
  Get-SPFarm | Select-Object BuildVersion

Compare against Microsoft's CVE-2025-53770 advisory. If your build is older than the patched build for your edition, proceed to Step 2.

Step 2 — Patch (20-30 minutes including reboot)

Download the appropriate KB and run as administrator. The install script triggers SharePoint Configuration Wizard (PSConfig) automatically; if it does not, run it manually:

PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

Reboot the WFE servers in sequence (not parallel — you want the second WFE patched and warm before the first goes offline for reboot). Verify build with Get-SPProduct after both reboots.

Step 3 — Rotate the MachineKey (10 minutes)

This is the step most teams skip. Without it, a stolen ValidationKey still forges valid ViewState payloads. From SharePoint Management Shell on a WFE:

Set-SPMachineKey -WebApplication "https://intranet.example.com"
  iisreset /restart

Microsoft published Set-SPMachineKey as part of the July 20 follow-up after community pressure on Day 1 — earlier, you had to edit each web.config by hand. The cmdlet now handles every web app and SCA in the farm. Run it for every web application, not just the public one.

Step 4 — Hunt the web shell (10 minutes)

The known IOC name is spinstall0.aspx (variants: spinstall.aspx, spinstall1.aspx, spinstall2.aspx, randomly named ASPX files modified after July 7). On every WFE:

# SharePoint Server 2019 / Subscription Edition use 16
SharePoint Server 2016 uses 16, older 2013 uses 15
  $paths = @(
    "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS",
    "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS"
  )
  foreach ($p in $paths) {
    if (Test-Path $p) {
      Get-ChildItem -Path $p -Recurse -Filter "*.aspx" |
        Where-Object { $_.LastWriteTime -gt (Get-Date "2025-07-07") } |
        Select-Object FullName, LastWriteTime, Length
    }
  }

Any hit on a file modified after July 7 is suspicious. Any hit named spinstall*.aspx is presumed bad. Do not delete on sight — copy the file to a forensic share first, hash it (Get-FileHash -Algorithm SHA256), and compare against the public IOC lists from SentinelOne and Palo Alto Unit 42.

Step 5 — Review IIS logs from July 7 (15-30 minutes)

The exploit signature in IIS logs is a POST to /_layouts/15/ToolPane.aspx?DisplayMode=Edit where the Referer is /_layouts/SignOut.aspx. From PowerShell on the WFE:

$logPath = "C:\inetpub\logs\LogFiles\W3SVC1"
  Get-ChildItem -Path $logPath -Filter "*.log" |
    Where-Object { $_.LastWriteTime -gt (Get-Date "2025-07-07") } |
    ForEach-Object {
      Select-String -Path $_.FullName -Pattern "POST.ToolPane\.aspx.DisplayMode=Edit"
    }

Then cross-reference each source IP against threat intel feeds. Known early IPs documented by Mandiant include 134.199.202.205, but that list grows daily.

Step 6 — Sign-off (5 minutes)

Document in a single page:

• Farm name, edition, build (before and after)
• Date + time of patch
• Date + time of MachineKey rotation
• IOC hunt result (clean / found, with hashes)
• IIS log review window and result
• Names of admins who ran each step

Save it. Send it to your CISO and your cyber-insurance broker. The broker will want this document at renewal.

The 3 Worst Findings From Our Weekend (Anonymised)

What "Found a Web Shell" Means In Practice

If your hunt returned a hit, the farm is no longer in patch mode. It is in incident response. Steps you do next, in order, in the next 24 hours:

The Patch-Verification Test (Three Numbers To Reach)

Common Mistakes We Saw Across The 22 Farms

Real Example: 90-Minute Sprint At A 110-Staff Logistics SMB

Saturday 10:00 IST, the CTO of a Pune logistics SMB (the "Farm C" above) ping. We dialed in via Tailscale to their on-prem AD admin jumpbox. Build was 16.0.10396.20034 (unpatched 2019). 10:05-10:35 patched (KB5002754, 28 minutes including reboot). 10:35-10:45 ran Set-SPMachineKey and iisreset. 10:45-10:55 ran the LAYOUTS sweep — found spinstall0.aspx modified July 14. 10:55-11:25 reviewed IIS logs back to July 7 — three POSTs to ToolPane.aspx from a Romanian IP, but no follow-on traffic that would suggest exfil. Snapshotted the VM, hashed the web shell, opened ticket with CERT-In at 11:30. Total: 90 minutes.

When Patching Is Not Enough — The Rebuild Decision

Skip the patch path and rebuild from scratch if (a) the web shell has been on disk for 7+ days with active exfil traffic in IIS logs, (b) you find evidence of lateral movement (new local accounts, new scheduled tasks, abnormal SAM/SYSTEM hive accesses), or (c) you cannot account for what the attacker did between July 7 and your hunt date. A 3-day rebuild is cheaper than a 90-day breach response.

A Common Question We Get About 2013 And Earlier

"We are still on SharePoint 2013. Are we exposed?"

SharePoint 2013 reached end-of-life on April 11, 2023 — Microsoft is not issuing a patch. If your 2013 farm is reachable via the same ToolPane endpoint, you are exposed and unfixable in place. The honest answer: migrate to Subscription Edition, M365 SharePoint Online, or replace SharePoint entirely. In the meantime, get the farm off the public internet today (firewall rule), run the IOC hunt, and treat any hit as confirmed compromise. We have helped two clients replace 2013 farms with Microsoft 365 SharePoint Online in 4-6 weeks; ping us if that is your situation.

FAQ

How do we know the patch worked?

Three checks. (1) Get-SPProduct shows the post-patch build. (2) The Microsoft Defender query for spinstall*.aspx creation events returns zero new hits in the 7 days after patch. (3) The IIS log review for POSTs to ToolPane.aspx with the SignOut.aspx Referer returns zero requests after patch date. If all three are clean, the patch worked.

Do we need to rotate every key, or just SharePoint?

Start with SharePoint MachineKey. If exfil is suspected, rotate any credential that touched the farm: service account passwords, OAuth grants from M365 to the on-prem farm, certificate-based auth between farms, and any API key used by line-of-business apps that posted to SharePoint. The MachineKey alone evicts the ViewState forgery path; the broader rotation evicts everything else.

What about Defender for Endpoint coverage?

Microsoft strongly recommends enabling the AMSI integration in Full Mode for SharePoint. With AMSI Full Mode, Defender catches the deserialization payload as it executes and blocks the web shell from being written. We recommend this as a baseline for every on-prem SharePoint farm regardless of CVE status.

How long does the recovery sprint take if everything works?

90 minutes per farm, assuming you have farm-admin access, the right KB downloaded, and a runbook. Add 30 minutes per farm if you are debugging a multi-WFE farm or fighting a slow PSConfig run. Add 4-12 hours per farm if you find a web shell and have to engage IR.

Is CERT-In notification mandatory for SMBs?

Yes if you are a body corporate handling personal data. The April 2022 CERT-In Directions require notification within 6 hours of awareness for a defined list of incidents that includes "compromise of critical systems" and "data breach." Even if your lawyer argues your specific farm does not meet the threshold, notify in good faith — the regulator gives you significant goodwill credit for proactive reporting.

Where can I find the full IOC list?

Palo Alto Unit 42 and SentinelOne LABScon have the most actively maintained lists. r/blueteamsec threads also aggregate community-shared IOCs faster than vendor blogs. Our founder Vivek Kumar has been curating a daily digest of new IOCs and tactics on his blog as the campaign evolves.

What if our SharePoint is too old for the patch?

If you are on SharePoint 2013 (out of support since April 2023), there is no patch. Take it off the internet today, run the IOC hunt, and start a migration plan. SharePoint 2010 and earlier — same answer, more urgent.