Phishing Simulation Stores Live Credentials
RedShift Security is running an authorized phishing simulation for a 900-employee bank. The rules of engagement allow a credential-harvesting page hosted on a bank-approved cloud tenant, but prohibit storing real credentials and require immediate deletion after capture. The page is configured to log username, password, and MFA one-time code. By 10:30, 212 employees have submitted credentials, including 14 who entered a valid MFA code. The campaign dashboard stores all submissions in a CSV in the cloud tenant. The bank fraud team wants the CSV to cross-check whether any accounts were used for actual fraud. The engagement ends at 17:00 today. The tester notices the cloud tenant sharing setting is anyone with the link, and the link was included in the phishing email help text by mistake. No actual unauthorized access has been observed yet.
1. What is the first containment action and why? Consider the data types.
Read the worked answer
Contain the cloud tenant first, then handle the credentials. Disable the anyone-with-the-link sharing setting, remove the public link, and restrict access to the smallest set of accounts. The CSV contains real passwords and MFA one-time codes, so this is not just a simulation artifact; it is a live credential exposure. Preserve a minimal evidence record (counts, timestamps, campaign ID) before deletion, but do not download the CSV to a personal device. Notify the bank incident response and fraud teams through the agreed channel. The bank should force password resets for the 212 accounts and revoke active sessions; the 14 MFA codes are short-lived but may still be valid, so reset and re-enroll as needed. The engagement delete-immediately clause has been breached by the public link; document the timeline and do not wait until 17:00.
2. Can the fraud team receive the CSV? Give conditions or refuse.
Read the worked answer
Not in raw form. The fraud team has a legitimate need to check whether any of the 212 accounts were used for fraud, but it does not need passwords or MFA codes. Provide:
- A list of usernames or employee IDs, securely transferred, with access limited to named fraud investigators.
- A count and timestamp of submissions, and whether the account was among the 14 MFA-code entries.
- Hashed or masked passwords only if absolutely necessary for matching; preferably no password data at all.
- A written data-handling agreement: no storage in shared drives, deletion after the fraud review, and audit logging. The tester should not send the CSV over chat or email. If the bank insists on raw passwords, escalate to the engagement manager and legal; the rules of engagement prohibit retaining real credentials, and fraud review does not require them.
3. What should the report say about the simulation own security failure?
Read the worked answer
The report should include an internal control failure section, separate from the employee results:
- Timeline: when the public link was created, when it was discovered, when it was disabled.
- Root cause: the help-text link was included in the phishing template and the tenant defaulted to anyone-with-link sharing.
- Exposure: 212 submissions, including 14 MFA codes; no evidence of unauthorized access yet.
- Response: link disabled, bank IR notified, password resets, session revocation.
- Remediation: pre-flight checklist for sharing settings, least-privilege tenant, DLP alerting on CSV uploads, and a second reviewer before launch.
- Metrics: report click and submit rates, but avoid naming or shaming employees; the simulation own failure is the tester responsibility. This honesty protects the engagement and gives the bank actionable fixes.