Harvesting credentials
Model the capture, the redirect and the login. Find the control that would have stopped it.
Course › Lesson 4 of 7
Exploitation is where the trap springs: the victim's action is turned into something the attacker can use. In the Westfield case study, it's staff entering their passwords on the fake page and the attacker signing in as them. This lesson is also where one control, MFA, would have changed everything.
The case study. This lesson uses the University of Westfield master case study from Cyber Security Fundamentals. If you've followed the earlier lessons you'll recognise the attack; each lesson looks at one stage of it.
Exploitation turns the delivered attack into a real gain for the attacker: a captured credential, code that runs, an account they can use. It sits across ATT&CK's Credential Access and Execution tactics, and often leads straight into Initial Access with a valid account.
Staff who reached the fake page entered their username and password, which the page captured and relayed to the attacker. To avoid suspicion, victims were then redirected to the real SAP ERP page, where they logged in normally. Over several days the attacker gathered thousands of working credentials, and because the portal had no MFA, each password was enough to log in as that member of staff.
| Code | Technique | In this case study |
|---|---|---|
T1056.003 | Input Capture: Web Portal Capture | The fake page recording typed passwords |
T1078 | Valid Accounts | Signing in with a stolen password |
T1036.005 | Masquerading: Match Legitimate Name | Redirecting the victim to the real site |
T1110.003 | Brute Force: Password Spraying | (Task B) trying common passwords |
T1110.004 | Brute Force: Credential Stuffing | (Task B) reusing breached passwords |
Hover over any code in the builder to see ATT&CK's own description.
This is the lesson's key point. For Valid Accounts, ATT&CK lists M1032 Multi-factor Authentication, M1018 and M1027. MFA would have stopped the attack even after a victim typed their real password, because a password alone wouldn't have been enough to sign in. The case study is explicit that the SAP ERP portal had no MFA, which is exactly why the stolen passwords worked. One control, applied to one system, would have broken the chain.
Each task opens in the builder with the scenario beside your graph. Build your graph, press Check my graph for feedback as often as you like, then compare with the model answer. Your work on each task is saved in your browser.
Model the capture, the redirect and the login. Find the control that would have stopped it.
Map the different ways an attacker could end up with a working account, and where MFA stops each.
When you've finished, you can send your graph and its activity log to your tutor with Email to tutor in the builder.