Unit 8: APIs and how modern apps talk · Lesson 5 of 5 · 18 min
Case file: keys that outlive the patch
After a server compromise, patching closes the hole but stolen keys keep working. Decide which secrets to replace.
case file
SharePoint ToolShell exploitation
On-premises Microsoft SharePoint customers · 2025
In July 2025 attackers exploited a chain of on-premises SharePoint Server flaws known as ToolShell against internet-facing servers. They stole the servers' ASP.NET machine keys, so patching alone did not remove their access.
What went wrong
Internet-facing on-premises servers with exploitable flaws, where stolen cryptographic keys allowed continued access after patching.
What would have stopped it
- Apply the updates, then rotate the machine keys and restart the service.
- Keep on-premises collaboration servers behind an authenticated gateway or VPN.
- Disconnect end-of-life versions from the internet.
What defenders could have seen
- New .aspx files or unexpected modules in the server's web folders.
- The web server process starting command shells.
sourcesmicrosoft.comcisa.gov
mission
- You are
- The engineer finishing the clean-up after an incident.
- Situation
- The shop's collaboration server collab01 was compromised on 18 July and patched on 21 July. The attacker could read its files, including configuration.
- Goal
- List every secret stored on collab01 and decide which still need replacing.
- Hand in
- A rotation list with owners and a check you can repeat after the next incident.
Patch versus rotate
Each step wraps the data in one more header, the way a sender builds a packet.
What was on the server?
cat cases/rotation/incident-note.txt Incident 2026-07: collab01 (on-premises collaboration server) Compromised: 2026-07-18 Patched: 2026-07-21 Attacker could read files on collab01, including its configuration. Patching closes the hole. Anything secret that was on collab01 must still be replaced. grep ',collab01,' cases/rotation/secrets.csv collab-machine-key,machine key,collab01,2024-02-01 collab-db-password,database password,collab01,2026-07-24 mail-relay-password,smtp password,collab01,2025-11-30 collab-sso-cert,sso signing certificate,collab01,2026-07-22 ldap-bind-password,directory password,collab01,2023-06-15
you should see Five secrets lived on collab01, including its machine key and a directory password.
Which were replaced after the patch?
awk -F, '$3=="collab01" && $4 >= "2026-07-21" {print $1, $4}' cases/rotation/secrets.csv
collab-db-password 2026-07-24
collab-sso-cert 2026-07-22
you should see The database password and the SSO certificate were rotated after the patch.
Which still need replacing?
awk -F, '$3=="collab01" && $4 < "2026-07-21" {print $1}' cases/rotation/secrets.csv
collab-machine-key
mail-relay-password
ldap-bind-password
you should see The machine key, the mail relay password and the directory password are unchanged. Anyone who copied them still holds working secrets.
defender tip Rotating a secret before the patch is wasted effort: the attacker can read the new one. Patch, clean up, then rotate.
Is the shop's own key any safer?
grep -n 'SIGNING_KEY = ' /opt/shop/app.py 54:SIGNING_KEY = b"lab-signing-key-2026" ls -l /opt/shop/app.py -rw-r--r-- 1 shop shop 21259 Oct 14 09:00 /opt/shop/app.py
you should see The shop's token signing key is written into its source, readable by any account on the machine. It belongs in a secret store, where rotating it does not need a code change.
What a defender takes away
- 1Patching removes the way in, not what was taken.
- 2Every secret stored on a compromised server must be replaced after the fix.
- 3Keys hard-coded in source cannot be rotated quickly; keep them in a secret store.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.