How Attackers Actually Get In: The Five Doors We Keep Leaving Open

By Randy Becker, VP and Principal Security Architect, Blue Mantis

I ask executives the same question when I meet them for the first time. What keeps you up at night?

I expect to hear ransomware. Or data theft. Or a regulator. What I almost always get instead is a version of this: I don’t know what I don’t know.

That answer is more honest than most vendor marketing, and it is also the entire reason my job exists. My team gets paid to legally break into companies. We find the weaknesses, we prove they are exploitable instead of theoretical, we document exactly how to fix them, and then we push hard to make sure someone actually does. So when I tell you how attackers are getting in, I am not summarizing a threat report I read. I am describing what we do on Tuesday.

I want to make an argument in this post that I know will annoy some people, including a few on my own team: the way most breaches begin has almost nothing to do with sophistication, and the reason they succeed has almost nothing to do with your tooling. Nearly every intrusion I have worked started with something that was already known, already documented, and already sitting in somebody’s backlog.

Let me back up and give you the story that made this real for me.

The client who told us exactly how they would be breached

We were hired to test a critical web application. The kind where people’s well-being genuinely depends on it working correctly. The client told us up front that they had secured it every way possible, and I believed them. Smart team, serious effort, real investment.

We asked what actually worried them. They were specific: direct authenticated access. That was the fear.

We made their worst fear real that night. Admin access to the client-facing app from the outside, and access to all the sensitive data behind it.

Nobody on that team was careless. They just could not see the vulnerability from where they were standing. And that is the whole job. You already know what you are afraid of. Somebody just has to go check whether you are right.

A quick note on where these numbers come from

I want to be transparent about my sources, because I think a lot of security content is quietly circular. The five entry points below come from industry breach data: Verizon’s DBIR primarily, plus Mandiant, Microsoft, and Sophos. That is a far larger dataset than any single firm can produce, mine included.

What we add is two things. First, incident response, meaning what clients call us about without being prompted, which tells you what is actually landing on organizations that look like yours. Second, what happens after the foothold, because that is my team’s daily work and I do not have to speculate about how fast initial access becomes domain admin.

Where I am giving you an industry number, I will say so. Where I am giving you my own observation, I will say that too, and you should weigh it accordingly.

The three numbers that frame everything

Three moments in the same breach.

How they get in. The single most common way into an organization today is not a stolen password. It is an unpatched flaw in something exposed to the internet. Roughly one breach in three now starts there.

What it becomes. Two years ago, about a third of breaches turned into a full multi-step chain ending in ransomware and data theft. Last year it was about half. Today it is closer to two-thirds.

How it spreads. Credentials, still. Four breaches in ten involve stolen credentials somewhere in the chain, more than any other single element.

Sit with that middle number for a second, because it is the one that changed my thinking. It is not telling you that more attacks are happening. It is telling you that more of them are going all the way. The gap between foothold and disaster is closing, and it is closing because of what happens after the initial access, which is exactly the part most programs are least prepared for.

The idea that runs through all five doors

Before I get to the list, here is the thread that ties it together, and if you take one concept from this post, take this one.

In a lot of these attacks, nothing malicious ever executes.

There is no malware for your EDR to catch. The attacker signs in as a real user. They use legitimate remote support tools, the same ones your help desk uses. Or they come in through a connection you built on purpose, for a good reason, and approved.

Every control you own asks its question and gets an acceptable answer. Is the binary signed? Yes. Did authentication succeed? Yes. Did the user consent? Yes. Nothing failed, so nothing alerted.

It all looks authorized because technically it is authorized.

Door 1: The internet edge

Appliances, VPNs, web apps, APIs, and the assets nobody remembers deploying or why.

For years we told IT teams the same thing about edge devices. Patch inside the vendor’s window and you stay ahead. I no longer think that is true, and it has nothing to do with how fast your team works.

Threat actors are building working exploits faster than vendors can ship fixes. We saw it last August with Citrix. We saw it this June with a Check Point VPN flaw exploited for weeks before there was an advisory, let alone a patch. Neither of those was a patching failure. There was nothing to patch.

So here is my position, stated plainly: internet exposure is now a permanent risk you manage, not a problem you solve. You can reduce it. You cannot eliminate it. Anything you expose carries a risk you cannot fully size, because you do not know whether a flaw exists in it right now, whether someone has already found it, or whether the fix arrives before the attack. The clock is not yours.

Now let me give you the other side, because my own team pushes back on this and I think they are right to.

It is not binary. Most of what actually gets compromised had a patch available. And that June flaw only worked if you still had a deprecated protocol enabled, so anyone who had already retired it was immune to an unpatched zero day. Hygiene still buys you a lot. What I would say is that your defenses have to assume the exposed system gets compromised anyway, and then ask what you actually control: how much you expose, whether you can see it, and whether you would know if something went wrong.

Which brings me to the engagement that made me care about this one more than any other.

We were running an external pen test. A tester on my team found an exposed admin interface, confirmed it was vulnerable, and was ready to exploit it. Before we did, the client emailed us a ticket from their MDR provider asking whether the activity they were seeing was us. Their firewall was creating user accounts.

It was not us. A threat actor had already compromised that firewall. We were second in line, and that is not the first time we have found ourselves in that position.

We told the client to take it offline. We could not get them to act. We could not get them to respond at all. So our tester stayed on it, I called the MDR provider directly and talked my way through to somebody with the authority to do something, and between the two of us we got it shut down. They did not get hit with ransomware that week.

Three things I want you to take from that. The detection worked and the response did not. Nobody in the chain had a clear view of the device that mattered. And nobody had the authority to act at 2am, which is precisely when they needed it.

EDR does not run on your firewall. Logging on edge devices is frequently either not configured or not going anywhere anyone reviews. In this case they had logging. They were doing the right things. It was not a capacity problem, it was a diligence problem.

What my team actually finds here. When we get in from the outside, it is almost never an exploit. It is an exposed web service, an API, or an authentication weakness where MFA was simply never applied. Somebody shipped it and everyone moved on. The second thing we find is assets nobody owns: a service from a marketing campaign three years ago, systems that arrived through an acquisition and never made it onto an asset list, sometimes with bad things already on them. Almost every organization I have tested has some of these, including ones with genuinely mature security programs.

One more, because it is instructive. A client had a local account on their firewall for VPN access. Not federated, no identity provider, no MFA. Created because it was convenient, then forgotten. The credentials ended up for sale on the dark web, and the way the client found out was that a federal agency contacted them directly.

Here is the part I think about. The client called us because they assumed the outreach was a scam. Someone claiming to be from a three-letter agency, telling you your credentials are being sold, does sound exactly like a pretext. It was legitimate. The credentials worked. You would be horrified if I told you what the username and password were, and you can probably guess.

Two lessons. Local accounts on edge devices sit outside every control you have built. No MFA, no conditional access, no onboarding or offboarding, and usually no logging anyone reads. And if you would not recognize a legitimate law enforcement notification, decide that in advance, because you may only get one.

My 90 day advice here is deliberately not “patch faster.” Build the inventory. Put MFA on everything that authenticates from the internet. Prioritize what is actually being exploited in the wild over raw CVSS. Get edge logging into your SIEM. And delete what you do not need, because removal is the fastest risk reduction available to you.

Worth noting: we are already seeing roughly 50% more critical vulnerabilities to patch than last year, and I expect that to keep climbing.

Door 2: Credentials and sessions that were sold before you noticed

This one is a market, not an attack.

Infostealers run on machines you do not control. Personal laptops, contractor devices, home computers that touched your network once. Sometimes, uncomfortably, on managed corporate devices. They take everything the browser had: saved passwords, and session cookies. The cookies are the part that matters. The output gets bundled into what are called stealer logs and sold in bulk.

Industry data puts it at 73% of ransomware victims having some form of prior credential exposure like this. On our pen tests we search the dark web for the client’s name as a matter of routine, and we tell them what we find.

Here is the part that breaks most incident response plans. A stolen session token never sees a login page. No password required. No MFA prompt. The attacker arrives carrying a token that says authentication already happened. You reset the password and they may still be inside.

Then it gets worse. The first thing a competent threat actor does inside an account is register their own MFA method. At that point they do not need the stolen session anymore, because they have a legitimate way back in. If they register a passkey or a security key, that survives your password reset, because it was never tied to a password. Same with device registration, where the primary refresh token is bound to the device rather than the credential.

We had a client with a business email compromise who did several of the right things. Reset credentials, revoked refresh and session tokens. The attacker still had access, and nobody could work out why until they called us. The threat actor had socially engineered the help desk into registering a YubiKey on the account. The password reset was never going to fix that.

We do the same thing on engagements. Get into an account, register our own MFA, then use Teams to impersonate the user, which opens several more doors. On one engagement that path led to an admin account and from there to the password vault.

Containment is four steps, not one. Reset the password. Revoke session and refresh tokens. Audit every registered MFA method and remove anything you cannot account for. Audit registered devices. My actual recommendation to clients is stronger than an audit: delete every MFA method and make the user re-register from scratch. Then you are not relying on your ability to tell a legitimate authenticator from an attacker’s.

Skip those last two steps and you do not evict the attacker. You just inconvenience them.

Question to answer for yourself: would you get an alert if a new MFA method were registered on an account in your environment right now? If you do not know, that is the follow-up.

The fix here is mostly process, not product. Session revocation needs to be a named step in your IR runbook, not something a good analyst happens to remember at 2am. Same for MFA method and device audits. And if you are not certain your containment process actually evicts someone, that is worth testing before you need it.

Door 3: Your help desk

If you take one door from this post, take this one. It is what clients are calling us about most right now, and it is the hardest for your tools to see.

Mandiant documented a group that went from a phone call to your help desk to domain admin in under 40 minutes, with no malware. Marks and Spencer’s chairman spoke publicly about attackers impersonating an employee and talking a third-party service desk agent into resetting their credentials.

Note the third party. If your service desk is outsourced, the standard that matters is theirs, not yours. And there is a decent chance nobody at your company has read it.

So, a question. If someone calls your service desk right now and says they are an employee, locked out, phone lost, what must happen before their MFA gets reset?

If the honest answer is “it depends on the agent,” then your perimeter is a person under time pressure who is measured on how fast they close tickets. That is not a criticism of the agent. It is a design problem, and it is one of the cheapest things on this entire list to fix.

We run service desk social engineering assessments, and we have successfully registered new MFA methods using acquired credentials and Teams messages. The pattern we see is not careless agents. It is that the procedure was never written down. Query five agents and you may get five answers, and one of them is good enough to get in.

Since some of you reading this are our managed services clients, let me answer the obvious question directly instead of leaving you to wonder. Our service desk does not make judgment calls on identity. It runs a defined process, and identity checks can run through a verification tool tied to the authenticator you already hold, Duo or Microsoft Authenticator. The agent confirms you against something you have, not something you tell them. That configuration is your choice and it is not one size fits all, and stricter standards can be applied to privileged accounts. If you are a client and you do not know your current standard, ask your service desk supervisor or your customer success manager, or email me and I will get you the answer.

If you are not a client, ask whoever runs your service desk the same question, get the answer in writing, and compare it to what you assumed. That comparison is usually the interesting part.

The version now showing up in Teams

Attackers are messaging and calling users in Teams from an external tenant, posing as IT support. They register an IT-sounding domain so the account name reads correctly. Most of these calls run for a couple of minutes. In one incident, the gap from first Teams contact to ransomware deployment was under 17 hours.

Why does this work when the same lure fails over email? Because email has spent 20 years teaching everyone to be suspicious. Teams has not. There is an external flag right there in the conversation, and the whole attack depends on one person not processing it.

And listen to what the attacker actually asks for. It is never “run this attachment.” It is “let me start a remote support session, just approve the prompt.” Then comes Quick Assist, AnyDesk, or ScreenConnect. All signed, all legitimate, and often permitted precisely because your own help desk uses them. They are the same tools we use on engagements.

A real example. A client received four Teams calls in one day. Three users declined. One accepted. And before any of it, those users had been getting mail-bombed, which is the setup: it manufactures the IT problem so the support call makes sense.

The user accepted, the attacker asked to share screen, the user approved, the attacker ran a script. Local workstation collection, then standard Active Directory enumeration, then an outbound connection attempt. That is where the MDR platform caught it and isolated the device.

Here is the uncomfortable part, and it is the real version rather than the tidy one. The EDR and MDR platform did not flag the call, the script, or the enumeration. Microsoft’s own tooling detected the Teams call and the activity running alongside it. Two sensors on the same endpoint with different views. One saw the human interaction and the commands, the other caught the outbound connection and isolated the machine. No single sensor saw the whole thing.

Three takeaways. Three of four users did the right thing, so the training is partially working, and partially is not good enough, because the attacker needs one. The enumeration was not sophisticated, it was built-in Windows commands. And this is not a story about bad tools.

Detection of malicious binaries is genuinely better than it has ever been. So attackers did what attackers do. I compare them to ants and cockroaches: every control we build, they route around. Verizon’s data shows legitimate remote monitoring software appearing in breaches up 240% year over year, while traditional backdoor command and control activity is down. Defenders got good at catching the old tooling, so the tooling changed.

One specific control worth naming: you can restrict which external domains can reach your people in Teams. Some organizations never turn it on. Others turn it on, hit a broken conversation with a customer or vendor, turn it off, and never revisit it. I understand the tradeoff. But if external Teams is wide open right now, that is not a setting, it is an entry point. And the control that matters most is not blocking local admin rights. It is a rule about who is allowed to start a remote support session at all, plus an alert when one of those tools launches on a host where it has never run before.

The cheapest fix in this entire post is writing your MFA reset standard down, including a callback to the number you already have on file. Not a number the caller gives you. Not an email.

One more thing on this door. If your team treats the mail bombing and the support call as two separate tickets, you are missing the attack.

Door 4: MFA bypass

This is the door that upsets security teams the most, because they did everything they were told to do and users are completing MFA correctly while bad things happen anyway.

Adversary in the middle, in four steps

The user clicks a link to a domain the attacker controls. What loads is not a static fake login page. The attacker’s server sits in the middle and relays the real sign-in flow between the user and Microsoft, live, in both directions.

The authentication is real. The MFA prompt is real. The domain is not.

The user enters their credentials, gets the MFA prompt, and completes it correctly. MFA is working exactly as designed. When the session cookie comes back, the attacker captures it. The user is logged in, nothing looks wrong, and there is nothing to report.

The attacker now holds a valid session. No password needed again. No further MFA prompt, unless the session gets revoked or a stronger control blocks the replay.

And this is sold as a service, with support included. You do not need the skill to build it. You need a payment method.

Password reset is not containment. They took a token. Revoke the session. Remove any MFA method you cannot account for. Remove any registered device. If they got app consent, revoke the grant. Fix only the password and you have left the attacker’s path fully intact.

Device code phishing, which breaks the mental model

Let me set this up for anyone not seeing it yet.

Device code flow exists for a genuinely good reason. If you have signed into Netflix on a smart TV, you have used it. The TV shows a code, you enter that code on your phone, the TV works. It is how you authenticate on things with no keyboard: TVs, printers, conference room displays.

Now the attack. There is no TV.

The attacker asks Microsoft for a code and waits. They wrap it in a lure, a Teams invite, an IT alert, a document, whatever earns a click. You go to the real Microsoft page. Real URL. You enter the code, your real password, your real MFA, maybe your real security key. Everything works, because everything is legitimate.

And Microsoft does exactly what it is designed to do. It grants access to the device that requested the code, which in this case is the attacker.

Think about what is absent. No fake Microsoft page. No lookalike domain. No credential form. Nothing for an email scanner to find. Nothing for the user to spot.

For those of you who have deployed hardware keys, there is a nuance that matters. This does not defeat MFA. It gets the victim to complete MFA on the attacker’s behalf. The key does precisely what it should, on Microsoft’s own page. The problem is not the key. The problem is that the authentication flow is allowed at all.

The fix is not a project, it is a conditional access decision. Microsoft’s own guidance is to get as close as you can to blocking device code flow outright, then permit narrow, documented exceptions. Most of your users have never needed it. Ask yourself why any of them would.

The honest version of “phishing-resistant MFA”

You will hear phishing-resistant MFA sold as the answer to all of this. Let me give you the honest read from someone who abuses this for a living. It is not the answer, but it is close to the most valuable thing on your identity roadmap.

Does it stop reverse proxy attacks? Yes. With passkeys or FIDO2, the sign-in is cryptographically bound to the real site.

But it only holds if two things are true. First, the weaker methods have to be removed from the account, not deprioritized. Gone. Otherwise the attacker simply requests the fallback. Second, understand what it protects: the authentication event. It does nothing about what happens after a token is stolen, and device code phishing is exactly that second category.

So the control for device codes is not stronger MFA. It is conditional access restricting the flow. That is a configuration decision, not an authentication strength decision.

Four steps, in order: deploy phishing-resistant factors, remove the fallbacks, block device code flow where it is not needed, then protect tokens with device-bound sessions. All of it is tenant configuration.

Door 5: The connections you built on purpose

Third-party involvement in breaches has grown 60% year over year, and third parties now appear in 48% of breaches. Nearly half.

I want to reframe this, because “supply chain attack” makes it sound like weather. It is not weather. Every item in this category is a decision your organization made. Vendor VPN accounts. Your MSP’s privileges. RMM tooling. SaaS applications. App-to-app OAuth. API keys.

I think about this as the app blast radius: not the vendor, but everything the integration can reach. Your CRM and the dozen things plugged into it. Marketing automation. Ticketing. Backup. Monitoring.

And then the genuinely uncomfortable part of the list, which is your security tooling. SIEM connectors, EDR, MDR, cloud posture tools, email security, identity governance, agentless cloud scanning. Those integrations hold some of the broadest read access in your entire environment, and we granted it deliberately. They cannot do the job without it.

So the question is not whether you trust the vendor. You already decided that, and you probably ran a process. The questions are what the integration can actually reach, whether anyone has reviewed what it actually does since the day it was turned on, and how fast you could shut it off.

If one of your vendors were compromised tomorrow and their integration into your environment were used against you, would you see it?

None of this is the vendor’s fault. It is configuration by design, which is the good news, because you can fix it without waiting for anyone.

Now the story.

A client had a site-to-site VPN to a SaaS provider supporting a hosted application. Completely normal setup. We scoped the engagement properly and asked the right questions, and the rules of engagement were accurate. The client just did not correctly identify which hosts were theirs.

We compromised a Linux host running their ERP application, sitting in their provider’s environment. Known vulnerability, working public exploit, published years earlier. Major EDR and MDR tooling was deployed on that host. No alerts. Nothing.

Ten days later the provider asked the client whether someone had accessed that host and run offensive security tooling. Yes. Ten days later. And from that host we reached domain admin, because domain admin credentials were sitting on the machine.

The client was furious with the vendor, and honestly, fair enough. It became a board-level conversation.

But here is where it lands. The scope confusion was ours and theirs. The exploitable vulnerability and the silent EDR were the provider’s. The ten day detection gap was the provider’s. The credentials on the host were somebody’s bad decision years ago. And none of that changes who owns the data. You can outsource the system and the application. You cannot outsource the consequence.

The Salesloft Drift incident followed the same shape. A chat vendor, stolen OAuth tokens, and those tokens used to query customers’ Salesforce instances directly. Salesforce was never breached. No vulnerability exploited, no malware. The tokens were valid and the API calls were routine.

The detection problem is what should worry you. Customers could see that the app had access, because they granted it. What they could not see was what was happening inside that pre-approved flow. And note what the attackers were actually after. Not CRM records. They combed the exposed records hunting for cloud keys, tokens, and passwords that people had pasted into support cases.

Third-party access usually sits entirely outside your onboarding and offboarding processes, and plenty of organizations have no vendor offboarding process at all. Service accounts get MFA exceptions, and those exceptions quietly become permanent.

My 90 day version here is boring, and I am not going to pretend otherwise. Inventory every vendor account, integration, API key, service account, and OAuth grant, and capture six things for each: owner, purpose, privilege level, log source, expiration date, and how you would kill it in a hurry. Most organizations never look at any of this again after deployment.

Doors do not stay separate

I have shown you five doors, and that is not how real intrusions work. They chain, they chain fast, and I expect AI to make them faster.

Here is a composite. I have never seen all of these in a single engagement, but every step is real.

Credentials from a forgotten local account on a firewall. Session replay, so no password and no MFA prompt. Containment attempted and defeated, because a YubiKey was registered along the way. A Teams call to a user. Then internal escalation, which is my team’s day job, and I will be honest with you: once you have a foothold and a valid identity, the internal environment is usually not the hard part.

Also worth saying: ransomware and domain admin are not the only outcomes.

Business email compromise is over $3 billion in reported losses. No encryption, no ransomware, no outage. Just a payment.

The pattern is patient and it does not look like an attack. The threat actor gets mailbox access and then reads for weeks before writing anything. They learn who approves what and wait for a real invoice thread to reach the approval stage. Then they reply in that thread with new banking details.

The thread is the credential. Trusted sender, real history, real context, and nobody re-verifies a conversation they have been part of for three weeks. From the mail gateway’s perspective this is a legitimate email, because it is one.

The version that turns this into an entry point rather than an outcome is vendor email compromise. Your supplier gets breached, the attacker hijacks a thread, and it arrives from the real address. You did nothing wrong. The email is legitimate. Only the content is not.

The control is process, not technology. Out-of-band verification for any change to banking details, using the callback number you already had, never the one in the email.

Two technical tells worth monitoring: inbox rule creation, especially auto-forward and auto-delete, and new MFA method registration, which points straight back to door three.

And it is not only finance. We had this hit a client’s sales team on an order of laptops, where the attacker redirected the shipment to an address they controlled.

Where AI actually belongs in this

I put this at the end deliberately, because this is not an AI post.

AI is not a sixth door. It makes the five doors faster, cheaper, and more convincing. I am also deliberately using Verizon’s numbers here rather than vendor numbers, for reasons I hope are obvious.

Faster: AI has compressed the gap from disclosure to working exploit from months to hours. That is credible based on everything we have seen recently, and it is the finding behind door one. It is why patch cadence stopped being a defense on its own.

Cheaper: in Verizon’s analysis, the median threat actor used AI across roughly 15 techniques that were already in the playbook, with under 2.5% being rare or novel. So AI is not inventing new attacks. It is running the existing ones at lower cost and higher effectiveness.

More convincing: phishing simulation click rates on voice and text run roughly 40% higher than email. Which means if you are still training users to look for typos and bad grammar, that advice is now actively misleading.

What I would actually do, in order

In 30 days. Write down what has to happen before your service desk resets someone’s MFA, and ask your MSP for theirs in writing. That costs you one email and it closes the door we spent the most time on.

In 60 days. Phishing-resistant MFA for admins, finance, executives, and high-value targets. Not everyone, not yet, because that is probably not realistic. Then remove the weaker fallbacks for those groups, because leaving them enabled undoes the work.

In 90 days. An owner and an expiration date on every vendor account, API key, service account, and OAuth grant.

Then test it. Everything above is a hypothesis until somebody proves it. Pick the door you are least sure about and start there.

If you would rather not do this yourself

I get asked this after most sessions, so briefly, here is where we help.

If you do not know what is exposed to the internet, that is an external exposure assessment and external penetration testing, which finds what is internet-facing, what nobody remembers owning, how it authenticates, and what has no MFA.

For the attack paths in this post, that is penetration testing, red teaming, cloud pen testing, service desk social engineering, and advanced wireless testing. We run the same plays described here, with permissions and rules of engagement agreed up front.

For most of the identity items, an M365 security health check and remediation covers tenant configuration end to end.

For the detection gap, our MDR practice, Mantis Protect, is built around identity and behavioral analytics, because the detections in this post are not products you buy. Somebody has to write the scenario, hunt it, and tune it. That is the difference between monitoring and hunting. Monitoring waits for something to be labeled bad. Hunting looks for what is unusual for you.

Which is the real reason I am not telling you to go buy a better EDR. The gap is not the sensor. The gap is that nobody is asking the context question at 2am.

In most of these attacks, nothing obviously malicious runs. The attacker uses your identities, your tools, and your trust. If your program is built to catch bad software, understand that the threat actors have largely moved on.

Go ask the questions. Then ask for proof.

---

Randy Becker is VP and Principal Security Architect at Blue Mantis, where he leads the offensive and cloud security practice. This post is adapted from a webinar delivered in August 2026. If any of the above applies uncomfortably well to your environment, reach out.