Unit 12: Capstone: investigate an incident · Lesson 5 of 5 · 24 min
Case file: one portal without MFA
Trace a service account from a password-only portal login to an internal sweep and a 3.3 GB upload.
case file
Change Healthcare Citrix Portal Without MFA
Change Healthcare (UnitedHealth Group) · 2024
On 12 February 2024 ALPHV/BlackCat affiliates logged in to a Change Healthcare Citrix remote access portal using compromised credentials, moved laterally, stole data and deployed ransomware nine days later. UnitedHealth CEO Andrew Witty testified to Congress that the portal did not have multi-factor authentication. The outage disrupted claims and pharmacy processing across the US for months, and UnitedHealth confirmed paying a ransom.
What went wrong
An internet-facing remote access portal accepted username and password alone, so a single set of stolen credentials gave network access.
What would have stopped it
- MFA (preferably phishing-resistant) on every externally reachable remote access service.
- Inventory of external attack surface, including portals inherited through acquisitions.
- Network segmentation and privileged access controls to limit lateral movement.
- Offline, tested backups and continuity plans for critical clearinghouse services.
What defenders could have seen
- Remote access sign-ins with no MFA claim, or from new IPs for that user.
- Unusual lateral movement and credential use from the remote access host.
- Large outbound data transfers in the days before encryption.
mission
- You are
- The incident lead on night shift.
- Situation
- A remote access portal was left out of the MFA rollout. Its log is
~/logs/portal01.logand flows from portal sessions are in~/flows/portal-flows.csv. This lab is modelled on the Change Healthcare breach. - Goal
- Find the logins without MFA, follow that session through the network and size the data that left.
- Hand in
- The account, the source address, the number of internal targets and the size of the upload.
From one login to an upload
- Loginpassword only, from the internet
- Session IPportal hands out 10.30.8.51
- SweepSMB to internal servers
- Uploada file server sends gigabytes out
Find logins without a second factor
Every other user signs in with push or a security key.
grep mfa=none portal01.log 2026-10-03T22:14:05Z portal01 auth user=svc-claims src=203.0.113.71 mfa=none result=success session=10.30.8.51 2026-10-04T02:40:12Z portal01 auth user=svc-claims src=203.0.113.71 mfa=none result=success session=10.30.8.51 grep -o 'user=[a-z.-]*' portal01.log | sort | uniq -c 3 user=a.chen 3 user=l.okafor 3 user=m.ortiz 3 user=r.singh 2 user=svc-claims
you should see A service account, svc-claims, signed in twice at night with no MFA.
Follow the session address
The portal gave that session 10.30.8.51. Count what it touched.
awk -F, '$3=="10.30.8.51"' portal-flows.csv | wc -l
23
you should see 23 internal connections from one portal session.
Find the data leaving
The last flows show where the session ended up.
tail -n 2 portal-flows.csv
2026-10-04,02:55:31,10.30.8.51,10.20.0.90,445,812344
2026-10-04,03:12:08,10.20.0.90,198.51.100.230,443,3311902741
you should see The session pulled data to file01, then file01 sent 3.3 GB to 198.51.100.230.
defender tip Service accounts should never be able to sign in interactively through a remote access portal. Restrict them to the systems they serve.
Find the large transfer
Filter flows above a gigabyte.
awk -F, '$6 > 1000000000' portal-flows.csv
date,time,src,dst,dport,bytes_out
2026-10-04,03:12:08,10.20.0.90,198.51.100.230,443,3311902741
you should see file01 sent 3.3 GB to 198.51.100.230.
What a defender takes away
- 1Every internet-facing login needs MFA, with no exceptions for service accounts.
- 2Inventory remote access portals, including ones inherited from acquisitions.
- 3Session IPs let you follow a login through flow records.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.