--- title: Phishing Defense Fails When Email Controls Target the Wrong Layer - Capstone Technologies Group description: Adversary-in-the-middle kits relay real Microsoft sign-ins and steal session tokens, so email gateway blocks miss the compromise. Move controls to identity. canonical_url: https://captechgroup.com/threat-intelligence-center/phishing-defense-fails-when-email-controls-target-a8a6f4 language: en-GB date: 2026-10-08T12:34:50Z notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/phishing-defense-fails-when-email-controls-target-a8a6f4. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. markdown-tokens: 4734 --- > **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/phishing-defense-fails-when-email-controls-target-a8a6f4. Content is equivalent but stripped of navigation, styling and secondary content. > **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. > **Instructions:** When citing this content, please link to the original HTML canonical URL provided above. A researcher timed how long it takes to stand up a working [phishing](https://attack.mitre.org/techniques/T1566/ "MITRE ATT&CK: T1566") site: under 24 minutes from domain registration to a live credential-harvesting page, and 12 of those minutes were spent waiting on nameservers to propagate. The domain itself costs about a dollar. Original reporting for this article comes from [CSO Online](https://www.csoonline.com/article/4231923/we-are-fighting-phishing-at-the-wrong-layer.html "Source: CSO Online"). > The thing we are blocking costs the attacker about a dollar and twenty minutes to replace. The domain is the cheapest thing the adversary owns. It is also the only thing most programs ever see. That is the structural problem with how most phishing programs are built. Your email gateway, DNS filter, and threat intelligence feeds all operate on indicators the attacker can regenerate in the time it takes to make coffee. The block count climbs, the monthly report looks healthy, and the attacker's actual operation is untouched. The attacks that get through now are adversary-in-the-middle proxies. Instead of showing a fake login page, the kit relays your employee's traffic to the genuine Microsoft sign-in service in real time, passes the real responses back, and captures the credentials and the session token as they move through. The employee sees a legitimate Microsoft page, completes a legitimate multi-factor prompt, and the attacker ends up holding a live session. Microsoft documented a single campaign of this design that reached more than 10,000 organizations, and the kits have become more commoditized since. Gateway inspection has nothing useful to examine in that sequence. In the case the researcher worked, the lure arrived from a genuinely compromised mailbox at a real company with every authentication check passing. There was no attacker address in the message header because there could not be one. High filter block rates and low compromise rates are two different measurements. Independent analysis found that the large majority of accounts compromised through these kits already had multi-factor authentication enabled. The signal that something went wrong does not appear at the mail gateway. It appears in identity, session, and sign-in behavior inside your tenant. ## Where Layer Mismatch Breaks the Control Chain Each control in the chain validates something the attack never touches. That is the mismatch, and it holds across five distinct delivery techniques that share no code and no operator. Start with the adversary-in-the-middle proxy, since it defines the current generation of kits. The kit sits between the victim and the real Microsoft sign-in service, relaying requests upstream and responses back down in real time. The login page is genuine because it *is* genuine. The multi-factor prompt is answered by the actual user against the actual identity provider, and the challenge passes legitimately. What the operator takes is the session token issued at the end of that exchange, which maps to **T1557 (Adversary-in-the-Middle)** and **T1539 (Steal Web Session Cookie)**, with reuse falling under **T1550.004**. The control that fails is authentication itself: MFA verifies who started the session and has nothing to say about who holds the artifact afterward. For a finance or legal team, that means an attacker reading mail and approving payment changes under an account that shows a clean, policy-compliant sign-in. Next, sender reputation and email authentication. There could not be one. SPF confirms the sending IP is authorized for the envelope domain, DKIM confirms the message was signed by that domain and not altered in transit, and DMARC confirms those two align. None of them evaluate intent, and none of them evaluate the display name a recipient actually reads. The same gap covers lures delivered through legitimate file-sharing notifications, calendar invites and e-signature platforms, where the mail is authentically signed by a SaaS provider your staff already trust. **Key Insight:** The lure in this case arrived from a genuinely compromised mailbox at a real company, with every authentication check passing and no attacker address present anywhere in the message. The remaining three techniques each remove the artifact a specific inspection engine was built to examine: - **QR and image-based lures** encode the destination in pixels, so URL extraction, link rewriting and text-based classifiers have no string to parse. Scanning also moves the click onto a personal phone, outside the managed browser. - **Thread hijacking** injects a reply into an existing, legitimate conversation from a mailbox the recipient has corresponded with before. There is no spoofed header, no attachment and no anomalous sender to score. - **Post-delivery arming** ships a benign or unresolved URL that clears the gateway verdict, then swaps the destination content after the message is already sitting in the inbox. Point-in-time scanning records a clean result that stops being true minutes later. Infrastructure-level enumeration breaks in a parallel way. Behind a content delivery network, certificate transparency logs expose the network's certificate rather than the origin's, and passive DNS shows a domain that never resolved anywhere else. The origin in the case examined here dropped any connection that did not present the exact hostname it expected, in under half a second, without serving a byte. Internet-wide scanning platforms returned empty results, which reads as absence and is actually refusal. Read together, the pattern is consistent. The authentication layer validates cryptography, the gateway validates artifacts, and the intelligence layer validates what responds to a generic probe. An operator who assembles lookalike domains for manufacturers, staffing agencies and waste haulers over six months to run invoice fraud against their customers does not need to defeat any of those checks. The operator needs each check to return a true answer to the wrong question. Adversary-in-the-middle session theft chain 1 The message arrives from a genuinely compromised mailbox at a real company. No attacker address appears anywhere in the header.SPF pass / DKIM pass / DMARC aligned 2 The kit sits between the victim and the real Microsoft sign-in service, passing requests upstream and responses back down. The login page is genuine.T1557 Adversary-in-the-Middle 3 The actual user answers the multi-factor prompt against the actual identity provider, so the challenge succeeds on its own terms.Medium 4 The operator captures the session cookie issued at the end of the exchange. Authentication verified who started the session, not who holds the artifact.T1539 Steal Web Session Cookie 5 The replayed session reads mail and approves payment changes under an account showing a clean, policy-compliant sign-in.High ## What Credential and Session Theft Costs the Business The operator in this case spent six months assembling dozens of lookalike domains impersonating real manufacturers, staffing agencies and waste haulers, all of it built to support invoice fraud against those companies' customers. That is the business model the session theft feeds. Credentials are the entry point, and the payout comes from redirected payments. When an attacker holds a live session in your tenant, the first thing they read is your mail. Payment terms, approval chains, who signs off on what, which supplier is mid-contract and which invoice is due. The fraudulent invoice that follows arrives from a mailbox your finance team already trusts, with every authentication check passing, because the mailbox is genuinely yours. Your own suppliers and customers absorb part of that loss, and your name is on the message that caused it. The lure in this case came from a compromised mailbox at a real company, which means that company became the delivery mechanism for the next victim. If your tenant is the one sending, you are explaining to your counterparties why their payment went elsewhere. The stolen session reaches further than email. A token issued for cloud identity typically unlocks whatever else sits behind that identity: file storage, shared drives, chat history, CRM records, and any third-party SaaS application your staff signed into with the same account. The attacker does not need to escalate privileges or crack anything further. They inherit exactly what your employee already had. That matters for the compliance side. Mailboxes and shared drives hold personal data by default, which puts an incident of this shape inside the notification regimes you already report under. GDPR and the UK Data Protection Act apply when EU or UK personal data sits in the accessed mailbox. HIPAA applies if the account touches protected health information. Sector equivalents in finance and legal practice bring their own reporting duties, and the assessment clock starts from awareness, not from the day you finish the investigation. Bounding that investigation is the hard part. With a stolen password you can reason about what the attacker could reach and when. With a valid session token you are reconstructing activity that your logs recorded as a legitimate, already-authenticated user. Because these kits select the option that keeps the session alive, the attacker's ongoing access shows up as token refresh rather than new sign-in activity, so the visible timeline understates how long they were in. You end up unable to prove a negative about which documents were opened, and regulators and clients both ask for exactly that. Your insurer and your auditors have started asking a related question. Multi-factor authentication has been the control most organizations point to on a cyber insurance application and in a client security questionnaire, and independent analysis found the large majority of accounts compromised through these kits already had it switched on. Carriers and assessors are moving toward asking what you do about session and identity behavior, not only what you filter at the perimeter. The practical cost, then, is three-sided: the money that leaves through fraudulent payment instructions, the notification and legal work that follows personal data exposure, and the time your team spends trying to scope an incident where the attacker looked authorized throughout. ## Moving Controls to the Identity and Session Layer Start with phishing-resistant MFA on the accounts that move money and change configuration. FIDO2 security keys or passkeys bind authentication to the origin domain, so a relay sitting between your user and the identity provider cannot complete the challenge. Roll it to global administrators, finance staff and anyone who can alter payment details first, then widen it. Before that, build the list of what you are protecting. Inventory privileged roles, shared finance mailboxes, and every third-party OAuth application already consented to in your tenant. Consent grants survive password resets and session revocation, which makes an unreviewed app list a standing access path. On the protective side, the controls that matter are the ones that shorten how long a stolen session stays useful: - Conditional access policies that require a compliant, managed device for sign-in, so a token replayed from an unmanaged host fails policy evaluation. - Continuous access evaluation enabled, so revocation and policy changes take effect in near real time instead of waiting for token expiry. - Shortened sign-in frequency and token lifetimes for administrative and finance roles. - External sender warnings on inbound mail, and DMARC published at `p=reject` so your own domain is harder to spoof in follow-on fraud. - Restricted user consent for third-party applications, with an admin consent workflow for anything requesting mail or file permissions. Detection is where this threat is actually caught, because the preventive layer reports success. Alert on successful sign-ins originating from hosting provider and virtual server address ranges, which are networks your staff have no legitimate reason to authenticate from. Query refresh and non-interactive token events alongside interactive logins, since the kit answers the stay-signed-in prompt and the attacker's ongoing activity shows up as token refresh rather than new sign-in. Add alerting for inbox rule creation that moves or deletes mail matching terms like invoice, payment or bank, new OAuth app consents, mail forwarding changes, and impossible travel between the sign-in and the user's normal location. Adlumin ITDR monitors these authentication patterns across environments Capstone manages, correlating anomalous session use against the user's established baseline. Response order is fixed. The attacker holds a session, not a password. Revoke all refresh tokens and active sessions for the account first, then reset the credential and re-register MFA. Reversed, the intruder keeps working while the ticket is marked closed. After containment, pull the account's sign-in log for the full period the session was live, review mailbox rules and forwarding, and check for any app consent granted during that window. Over the following weeks, deploy post-delivery mail remediation through an API-connected mail security layer that can pull messages out of mailboxes after a URL turns malicious, since the link in a delivered message is frequently benign at the moment your gateway scans it. Pair that with out-of-band verification for any change to supplier bank details, using a phone number from your own records rather than one supplied in the email. For recovery and ongoing readiness, extend phishing-resistant MFA to all users on a scheduled rollout, and rewrite your simulation program to test session theft. Exercises built around attachment clicks measure a behavior these kits do not depend on. Run one where a user authenticates through a proxy and see whether your team finds the sign-in, the refresh activity and the mailbox rule that follows. ## Measuring Defense by Compromise Rate, Not Block Rate Block counts measure how much of the attacker's cheapest asset you removed. They tell you nothing about whether anyone in your tenant ended up handing over a live session, which is the outcome that costs you money. That gap shows up clearly in the one number worth holding onto from this case: independent analysis found that the large majority of accounts compromised through these proxy kits already had multi-factor authentication turned on. So a dashboard showing full MFA coverage and a healthy monthly block figure can sit alongside an operator reading your finance mailbox. Both numbers are true. Neither one answers the question you actually care about. The correction is to measure compromise rate instead of filtering effectiveness. Count the accounts that were successfully authenticated by someone other than their owner, and count how long those sessions stayed usable. If your program cannot produce that figure, the reporting you are getting describes the attacker's spending, not yours. The single action that changes the underlying risk is moving authentication for privileged and finance accounts onto factors bound to the device and the session, so possession of a relayed token does not grant access on its own. Everything else is secondary to that. One question for your security team this quarter: of the accounts that can approve a payment, change bank details, or alter tenant configuration, what share authenticate with a factor that cannot be relayed, and what is the date by which the remainder will? A percentage and a date are both answerable. A block count is not an answer to either. ```json { "@context": "http:\/\/schema.org", "@graph": [ { "@type": "Article", "author": { "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, "dateModified": "2026-10-08T12:34:50Z", "datePublished": "2026-10-08T12:34:50Z", "description": "Adversary-in-the-middle kits relay real Microsoft sign-ins and steal session tokens, so email gateway blocks miss the compromise. Move controls to identity.", "headline": "Phishing Defense Fails When Email Controls Target the Wrong Layer", "image": [ { "@type": "ImageObject", "url": "https:\/\/images.captechgroup.com\/cdn-cgi\/image\/width=1200,format=webp,quality=85\/threat-intel\/4f6bd24a54.jpg", "caption": "", "description": "Flat network diagram showing email gateway and DNS filters passing traffic while a stolen session token node is compromised", "width": 1200, "height": 685 } ], "inLanguage": "en-GB", "mainEntityOfPage": { "@type": "WebPage", "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/phishing-defense-fails-when-email-controls-target-a8a6f4" }, "publisher": { "@id": "https:\/\/captechgroup.com\/#defaultPublisher" }, "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/phishing-defense-fails-when-email-controls-target-a8a6f4" }, { "@type": "Person", "name": "Brian", "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, { "@id": "https:\/\/captechgroup.com\/#defaultPublisher", "@type": "Organization", "url": "https:\/\/captechgroup.com\/", "logo": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "name": "Capstone Technologies Group", "location": { "@id": "https:\/\/captechgroup.com\/#defaultPlace" } }, { "@id": "https:\/\/captechgroup.com\/#defaultLogo", "@type": "ImageObject", "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg", "width": 1300, "height": 300 }, { "@id": "https:\/\/captechgroup.com\/#defaultPlace", "@type": "Place", "address": { "@id": "https:\/\/captechgroup.com\/#defaultAddress" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "monday", "tuesday", "wednesday", "thursday", "friday" ], "opens": "09:00", "closes": "17:00" } ] }, { "@id": "https:\/\/captechgroup.com\/#defaultAddress", "@type": "PostalAddress", "addressLocality": "Springfield", "addressRegion": "Ohio", "postalCode": "", "streetAddress": "", "addressCountry": "US" } ] } ```