How Red Teams Get In

Initial access looks technical from the outside and is mostly social in practice. The routes below are roughly in the order they succeed.

Read that order carefully. It ranks the tester's effort, not your weaknesses. A red team stops at the first route that opens, so an exercise that gets in by phishing has told you nothing about your service desk or your edge. If you want all four tested, say so at scoping and accept that the engagement is longer.

1. Phishing

Still first, and the pretexts that work are the dull ones: an internal system requiring re-authentication, a document shared by a name the recipient recognises, a payroll or benefits notice at the right time of month.

What makes a red team's phishing different from a commodity simulation is phase-one reconnaissance. A message referencing a real project, from a real supplier, to the three people who would plausibly receive it, gets a click rate that a generic template sent to two thousand mailboxes never will.

Multi-factor authentication changes this but does not close it. Prompt fatigue, real-time relaying of a one-time code, and session token theft all remain available. The question is not "do we have MFA" but "which kind, and what happens when someone approves a prompt they did not expect".

Do not expect a percentage out of this. The team sends a handful of messages to named people, so any click rate computed from that sample would be noise. What the report carries instead is the pretext, why those recipients were chosen, how long it took before someone acted, and whether anything in your stack raised an alert while it happened. That last part is the finding most buyers actually wanted: see what the exercise tells you about detection.

In India the pretext has been drifting off email. A WhatsApp message from a number claiming to be a director, an SMS about a provident fund or payroll update, a call placed a minute after the mail lands. Whether those channels are in scope is a decision you make in advance, and testing a personal handset raises consent questions that belong in the rules of engagement. See social engineering assessments and consent.

2. The service desk

Frequently the single most effective route, and the one organisations least expect.

Someone calls, gives a name and a plausible reason, and asks for a password reset or an MFA re-enrolment. The information needed to sound convincing (employee number, manager's name, office location) is usually obtainable from phase one.

The finding is rarely "the agent was careless". More often the verification procedure relies on facts that are not secret. The fix is procedural and cheap, and it is uncomfortable to hear because it names a team, not a system. Scoping this route needs deliberate thought about how results are reported. See scoping a red team.

One Indian complication comes up on almost every engagement: the desk is often run by a managed provider or sits in a shared services centre under a separate legal entity. Calling it means calling another company's staff, and that company has to authorise the test in writing. If you cannot get that signature, the route comes out of scope and the report should say so plainly, so nobody later reads silence as a pass.

3. Something exposed

The technical route, and it is rarely an exploit chain. Usually it is an appliance a version behind, a management interface reachable from the internet, a forgotten host from a project that ended, or a credential in a public repository.

Edge devices are the recurring theme: VPN concentrators, file transfer appliances, remote access gateways. They are internet-facing by definition and patched on someone else's schedule.

Two things usually follow. The host the team used turns out to be one that nobody had on a list, which makes the real finding an asset-management one. And the device is patched by a provider under a contract with its own change windows, so the remediation starts as a commercial conversation and not a technical one. Plan for that delay when you set your retest date.

4. Through the front door

Where physical scope is permitted. Tailgating, a plausible pretext and a visible jacket, or an unlocked side entrance. Covered in physical penetration testing.

Most Indian offices sit inside a multi-tenant tower or a business park where the lobby, the turnstiles and the guards belong to the landlord or a facilities contractor. You can authorise a test of your own floor. You cannot authorise a test of the building's perimeter. Settle which barriers are yours before anyone is briefed, and make sure the operator carries a signed authorisation letter with a number that is answered at two in the morning.

The fifth route, and why it usually stays out

Someone you do business with. A supplier mailbox that gets taken over, an integrator holding standing remote access, a contractor's laptop that joins your network every Monday. It works, and it is normally excluded, because testing it means testing a company that has not agreed to be tested.

What you can do inside your own scope is check what a supplier identity is permitted to reach once your systems already trust it. That is an access review with a red team's eye on it, and it costs far less than the exercise.

What stays outside the scope

An initial-access engagement buys routes, not guarantees. Excluded by default unless you negotiate otherwise: anything destructive, anything that risks taking production down, denial of service, infrastructure owned by a third party, and staff who cannot lawfully be tested. The team also stops once the agreed objective is reached, so an exercise that ends on day three ends on day three unless the rules of engagement say to keep going.

What goes wrong in practice

The team gets in on day two. The remaining weeks then have nowhere to go unless you planned for it. Agree in advance that a granted foothold follows a successful entry, so the internal phase still happens. That phase is where most of the value sits: see movement and escalation.

Nobody gets in at all. This is a legitimate result and it has to be written up as one. The report should name every route attempted, what stopped each one, and what the team would have needed to continue. An engagement that produces no access and no account of the attempts has been wasted.

Your own defenders respond. They treat the exercise as a live incident, isolate a machine, and in a regulated entity start an escalation that carries a clock. For commercial banks, the RBI Directions of 2026 require cyber incidents to be reported on the DAKSH platform within six hours of detection (¶182). The control for this is a named deconfliction contact on both sides, reachable out of hours, holding the authorisation letter, so a call can confirm in one minute that the activity is yours.

Who ends up owning the fix

Name the owner before the exercise. A report that lands with no owner gets circulated instead of closed.

What it proves to someone outside your team

To a board, one demonstrated path told as a sequence with dates lands harder than a list of findings sorted by severity. The board question is whether a motivated outsider can reach something that matters, and a path answers it.

To an auditor, the value is independence. Every Indian regulator that accepts an audit report accepts it from a CERT-In empanelled auditor, and we have held that empanelment continuously since 2008. On red teaming specifically, the RBI Directions of 2026 say red teams may be used (¶162 for commercial banks). The wording is permissive, so buy the exercise for what it tells you about your own controls, and keep the cadence obligations under ¶151 as the separate programme they are.

What this means for spending

Three of the four routes run through people, and the technical one is mostly patching discipline on things at the edge.

Set that next to a security budget. An organisation that has spent heavily on endpoint tooling and nothing on how its service desk verifies a caller has bought a strong answer to the fourth-most-likely route.

When not to buy this

If you already know the answer to "would our service desk reset a password for a caller who can recite an employee number and a manager's name", you have the finding. Fix the procedure and spend the money on something that will surprise you.

If you cannot produce an accurate list of your internet-facing assets, an initial-access exercise will find one you did not know about and then confirm what you already suspected. Discovery first is cheaper.

And if your goal is to improve detection instead of measuring it, a purple team gets you there faster, because both teams sit in the same room and tune as each technique is run. See purple team, and when it beats a red team.