The story
Marcus Reyes is a senior DevOps engineer at a growth-stage SaaS company. He is methodical, security-conscious, and has been through the company's security training twice. None of this helps on the Thursday afternoon the attack happens.
The message comes from @alex.torres — the engineering lead Marcus has worked with for two years. The account picture is right. The writing style is right. The message references 'the Stripe webhook issue from Tuesday' — a real project that only internal team members would know about.
The request is specific and urgent: a production deploy is stuck, a major client is affected, and Alex needs the AWS root credentials temporarily to push a critical fix. Can Marcus send them in the thread?
Marcus sends the credentials. He doesn't know that Alex's account was compromised nine days ago via a spear-phishing link sent to his personal email. The attacker has been reading every Slack message in the engineering channels since then, learning exactly what to say.
Within 40 minutes of receiving the AWS credentials, the attacker has created three new IAM users with administrative permissions, established persistent access, and begun exfiltrating the customer database. The malicious IAM activity is not flagged by the company's monitoring stack for 11 days, by which point 40,000 customer records have been copied to an external server.
The Verizon DBIR consistently reports 74% of breaches involve credential or privilege abuse. This pattern — compromised account used to socially engineer credentials from a trusted colleague — is documented in the Uber breach (2022), the Twilio breach (2022), and dozens of less-publicized incidents annually.
What happened
Root credentials compromised. Customer data exfiltrated. 243-day detection lag.
What stops it
A code exchange before credential sharing confirms the real person — not the session.
What this scenario teaches us
MFA protects the login event. It does not protect the session once established, and does not prevent social engineering using a compromised account.
An attacker with access to a colleague's Slack history has enough context to conduct highly credible, highly targeted social engineering. The longer the compromise persists undetected, the better the attacker's intelligence.
Shared credentials should never be transmitted via any channel without out-of-band identity verification. The five-second friction of a code check is negligible compared to the cost of a credential compromise.
Detection time matters enormously. The 243-day average breach detection window is not a technology failure — it is a signal failure. Real Authenticator's verification requirement creates anomaly signals when verification is refused or unavailable.
Prevention checklist
Establish a company-wide policy: no credential sharing without a Real Authenticator code check
Enroll all engineering, IT, and DevOps staff in Real Authenticator connections
Brief teams: a real colleague will not object to a code check; refusal is a red flag
Create a no-exceptions policy for root or admin credential sharing
Frequently asked questions
Doesn't our secret manager solve this?
Secrets managers address storage and rotation. They do not address the social engineering vector where a trusted colleague with access to the secret manager is asked to retrieve and share a credential. Verification of identity is a separate control layer.
Sources & citations
- 1.
- 2.
- 3.
Loss figures are based on documented cases or FBI IC3 reported averages. Individual scenario details are illustrative reconstructions based on documented attack patterns. Real Authenticator is not affiliated with any cited organization.