Skip to main content

After the Foothold: Movement and Escalation

One workstation is not the objective. It is the start of credential harvesting, lateral movement and privilege escalation, and four internal weaknesses make that route fast in almost every network.

By Siddarth G
August 19, 2026 Last updated 7 min read

Initial access gets you one machine belonging to one person. Everything that matters happens next, and it is usually faster than the organisation expects.

It is also the phase where the rules of engagement stop being paperwork, where the exercise creates real clean-up for your side, and where a decision can land on somebody senior within hours.

What the first hour looks like

The first hour is orientation. What domain is this, what tooling is watching, what does this user have access to, where does the interesting data live, and which accounts administer it.

Much of that comes from ordinary directory queries a normal user is permitted to make. So a large part of internal reconnaissance is indistinguishable from legitimate activity, and that is what makes it hard to detect.

Increasingly the same hour includes the cloud tenant. Where the workstation is joined to a cloud identity service, part of the directory is online: groups, application registrations, mailbox permissions, and whatever the user's existing token already grants. Movement can then proceed without touching the internal network at all.

The four things that make it quick

Different estates, same short list.

  • Local administrator password reuse. One password shared across every workstation turns a single machine into all of them. The fix is per-machine randomised passwords: well understood, and still missing more often than not.
  • Over-privileged service accounts. Accounts with rights nobody has reviewed since the application was installed, frequently with passwords that never expire and are recoverable offline.
  • Credentials lying around. In scripts, in scheduled tasks, in spreadsheets on shared drives, in configuration files. Reconnaissance finds these faster than any exploit.
  • Flat internal networks. Where reaching one segment means reaching all of them, initial access and objective are nearly the same event.

None of these is exotic, and none is what security budgets are usually spent on.

Who actually fixes them

Ask before the exercise, because the answer decides whether anything changes after it.

WeaknessWho owns the fixWhat stalls it
Local administrator password reuse Desktop and endpoint engineering Nothing technical. A rollout across every machine, competing with what that team is already mid-way through
Over-privileged service accounts The application owner, not the security team Nobody knows what the account genuinely needs, and finding out risks breaking the application
Credentials in scripts and shares Developers, plus whoever owns the file shares There is no list, and the ones in scheduled tasks belong to people who have left
Flat internal networks Network engineering A programme, not a fix, and it needs an application inventory nobody has

The team that commissioned the exercise owns none of the four. That is the ordinary reason a movement finding survives into next year's report: not disagreement, but a remediation owner who was never in the room at the debrief and has a roadmap of their own. Getting those four owners into that room costs an afternoon.

Staying quiet

A red team is constrained by noise more than by capability. Anything loud gets caught, and getting caught ends the route.

So the tradecraft is about blending: using tools already present on the machine instead of introducing new ones, working within business hours, communicating over protocols that already carry traffic. A penetration test has no such constraint, because it does not care whether it is noticed.

That constraint has a price, and you pay it when you compress the calendar. Quiet movement is slow, so a short engagement buys noise: a team told to reach the objective inside a fortnight takes the loud route, and the detection timeline then measures how you respond to a loud attacker, which you probably already knew. See what a red team engagement costs.

What the team will not do

Expect these to be out of bounds by default, and confirm each in writing:

  • Anything destructive or modifying. Demonstrating access to a database means reading one row. Altering, deleting or encrypting data is out, and so is moving a payment.
  • Persistence that outlives the engagement. Each mechanism is recorded as it is installed and removed at the end, and the list of what went where belongs in the report so your team can verify the removal itself.
  • Bulk collection of personal data. Proving the team reached a customer database does not require extracting it. Agree the evidence standard in advance: a record count, a redacted sample, a screenshot.
  • Systems you do not own. The one that catches people out.

Two patterns make that last item an Indian speciality. Administration is frequently outsourced, so the privileged accounts the team reaches belong to a managed service provider, as does the jump host they are used from, and that provider has signed nothing. And group structures share directories: one legal entity commissions the exercise, escalation crosses into a sister company, and the authorisation covers neither the systems nor the data sitting there.

Both are solvable, and both take weeks if you start when the team arrives at them. Map the ownership boundary during scoping and collect the signatures then.

The credentials it collects are real

By the end of the exercise the team holds passwords, hashes and tokens belonging to named employees and to service accounts running production applications. Ask how that material is held during the engagement and what happens to it afterwards, and get the answer before you sign.

Ask also that the report identify every credential that proved recoverable and where it came from, because that list is your rotation plan. Then carry out the rotation. A service account password pulled out of a script in week two is still in that script, and an attacker reading the same share finds it the same way.

Rotation is the part that gets deferred, because changing a service account password breaks applications and nobody wants to own that on a Friday. Deferring it turns the exercise into a written record of credentials that still work.

When your own defenders call it an incident

Movement is the phase most likely to be spotted, and being spotted is the good outcome. It also starts something.

Your analysts do not know the exercise is running. They will treat the activity as an intrusion and escalate it as one, and in a regulated entity escalation carries a clock: the RBI's 2026 Directions require cyber incidents to be reported on the DAKSH platform within six hours of detection (¶182). Somebody senior has to decide quickly whether what the analysts are looking at is your own red team.

So the engagement needs a named person on your side who knows it is running, is reachable outside office hours, and can check an attribution against the team's own log of what it did and when. A deconfliction line that runs through a shared mailbox will not do.

Plan for what your defenders do next, too. Isolating a host, disabling an account or blocking an address range is the correct response, and it can also cut off a real employee mid-morning. Decide in advance who authorises containment inside the exercise window, and whether the red team pauses when it starts.

On the exercise itself the Directions are permissive: ¶162 says red teams may be used, and the equivalent paragraph in the small finance bank, payments bank and credit information company Directions says the same. Two paragraphs bear on this phase directly. ¶156 puts the credentials and competency of the testing firm and its assigned personnel in scope at every selection, appointment, engagement and renewal, and movement is the point at which those people hold the most access to your estate. Where a CERT-In empanelled auditor is engaged, ¶159 brings CERT-In's audit policy guidelines into the supervisory relationship. The instruments are set out in red teaming under the RBI Directions.

Why this is the phase to detect

Initial access will eventually succeed against anyone. Someone will click something, a credential will leak, an edge appliance will have a bad month. Treating prevention of initial access as the whole strategy assumes a perfect record forever.

Movement is different. It takes time, it touches many systems, and it leaves traces across all of them. It is the phase where a competent defender has the most opportunity to notice, so the detection timeline in the report matters more than the account of how the team got in.

When not to buy this

If you already know the four weaknesses are present, do not commission an exercise to confirm it. Plenty of organisations can answer honestly that local administrator passwords are shared, that the internal network is flat, and that no service account has been reviewed in years. Paying several people for several weeks to write that down produces a report you could have written in an afternoon, and it spends the budget that would have fixed one of them.

This phase earns its cost when you believe the estate is segmented, privileged access is managed and somebody is watching, and you want to know whether the belief survives contact. Where it is not there yet, the money goes further on the fixes, then on a purple team exercise that confirms the detections fire. Come back for the red team when you expect it to be hard.

What that looks like from the defender's chair is in what the exercise tells you about detection.

About the author

Siddarth G

Practice Director — Cybersecurity

Leads Security Brigade's offensive security practice with deep expertise in vulnerability research, penetration testing, and red team operations. Ranked Top 80 globally on Bugcrowd.