Compromised vendor mailbox → reply-chain phishing → client compromise
Take over a vendor / partner mailbox via AITM phishing. Reply to an existing thread with a malicious link — trust transferred from the genuine prior conversation defeats most user training.
§ Context
Assumed environment: a B2B relationship where vendor and client exchange documents regularly. Vendor mailbox compromised via earlier AITM / device-code phishing.
§ Steps
- 01Payload runs on client workstationExecutionT1059— Command and Scripting Interpreter
- 02Send from compromised mailboxInitial AccessT1566— Phishing
- 03Client opens (real thread, real sender)ExecutionT1204— User Execution
- 04Find active client conversationCollectionM365-EWS-EXFIL— Exchange Web Services (EWS) Exfil
- 05Compromise vendor mailbox (AITM)Initial AccessPH-AITM-EVILGINX— AITM Phishing — Evilginx / Modlishka
- 06Draft reply with malicious link / attachmentInitial AccessEM-CONVERSATION-HIJACK— Conversation Hijacking / Reply-Chain Attack
§ References
- T1059Command and Scripting Interpreter
- T1566Phishing
- T1204User Execution
§ Frequently asked
- What is the "Compromised vendor mailbox → reply-chain phishing → client compromise" attack path?
- Take over a vendor / partner mailbox via AITM phishing. Reply to an existing thread with a malicious link — trust transferred from the genuine prior conversation defeats most user training. It chains 6 steps drawn from real-world offensive-security techniques.
- What starting position does this attack require?
- The first step is Payload runs on client workstation (T1059) — a execution primitive. Assumed environment: a B2B relationship where vendor and client exchange documents regularly.
- What is the final impact of this kill-chain?
- The final step lands on Draft reply with malicious link / attachment (EM-CONVERSATION-HIJACK), which falls under Initial Access. From here, an operator typically pivots into post-exploitation or maintains persistence.
- How can defenders detect or prevent this attack?
- Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.
§ Related dossiers
- Shared techniques3
FIDO2 caBLE hybrid → phone authenticator hijack
Attacker phishing site shows the legitimate FIDO2 QR. Victim scans with their phone authenticator. The link completes the WebAuthn ceremony in the attacker's browser — they're now signed in as the victim.
- Shared techniques3
Header smuggling → gateway sees vendor, mailbox sees attacker
Crafted RFC-edge headers cause SPF/DMARC to validate against one From while Outlook renders the other — slips past Microsoft Defender / Proofpoint and lands as a 'verified' message.
- Shared techniques3
Gatekeeper bypass → unsigned binary execution
Deliver a payload that strips the com.apple.quarantine xattr (via .dmg with no quarantine attribute or an archive format that doesn't preserve xattrs) — Gatekeeper never prompts.
- Shared techniques3
Browser-in-the-Browser → credential theft on a trusted page
Render a fake SSO popup inside the attacker page that looks like a real OS browser window. Victim types their credentials into the attacker's DOM.
- Shared techniques3
AITM phishing (Evilginx) → M365 session theft → mailbox exfil
Reverse-proxy phishing kit intercepts the entire login flow including MFA. Stolen session cookie → access M365 mailbox / SharePoint without retriggering auth.
- Shared techniques3
OAuth device-code phishing → M365 access without a fake page
Initiate a device-code flow against login.microsoftonline.com; send the code + url to the victim via email or chat. Once they enter it, attacker gets access + refresh tokens.