Red Team Web App Tactics — Phishing into Apps, Lateral Movement, Persistence

Pentest vs red team

Pentests find specific bugs in scope. Red teams simulate full adversaries — phishing users, evading detection, establishing persistence, achieving specific business-impact objectives. The goal isn't a long bug list; it's understanding whether your security operations actually detect and respond to a sophisticated adversary.

This tutorial walks through how a web-app-focused red team operates, with defensive takeaways at each stage.

Stage 1 — Reconnaissance with intent

Beyond technical recon (tutorial 7), the human reconnaissance:

• Organization chart — LinkedIn, regulatory filings, press releases. Who's the CFO? Who manages IT? Who's a developer with access?
• Communication patterns — Twitter, conference talks, Slack communities. How does the company talk? What's the internal vernacular?
• Tech stack inference — job postings reveal what they use ("Django, AWS, Stripe, Snowflake experience preferred")
• Vendor relationships — what services do they use? Identifiable via DNS, email signatures, vendor mentions
• Timing — when's quarterly close? When does the CEO travel? When are security teams thinly staffed (holidays, conferences)?

Crafting the pretext

Effective phishing pretexts are specific. Examples successfully used:

• "Hi [Finance Manager], following up from [actual conference target attended last month] — please review the attached invoice for the vendor we discussed."
• "Hello, this is [name of actual IT vendor]. We have a critical patch for your VPN. Please log in here to apply."
• "DjangoZen security alert: unusual login from [user's actual hometown]. Verify here."

The more specific to the target's actual context, the higher the success rate. Spear phishing at this level returns 30-70% click rates in unprepared environments.

Defense

• Periodic OSINT review — search what your company looks like from the outside
• Threat hunting — assume adversaries have done this; look for indicators in your logs
• Employee training focused on "specific to me" lures, not generic warnings
• Reporting culture — easy to report suspicious emails, no shame in being targeted

Stage 2 — Initial access via web app

For modern targets, the most common initial vectors:

Targeted phishing → web app login

Email sends user to a fake login page (perfect clone of real). User enters credentials and MFA code. Attacker forwards in real-time to real login page, completes auth, captures session cookie.

Modern tooling: Evilginx2, Modlishka. Transparent reverse-proxy attack frameworks. Bypass TOTP MFA almost trivially.

Phishing → OAuth consent

Email links to a real OAuth authorize URL for an app the attacker registered. User authenticates with their real provider (Google, Microsoft), grants consent. Attacker now has a long-lived access token.

Credential stuffing → existing weak account

Username from one breach + password from another breach matches your user. No phishing needed.

Browser exploit / malware → cookie theft

User browses to attacker-controlled page. Browser exploit or malware grabs cookies (no MFA needed since the session is already authenticated).

Defenses against initial access

• Phishing-resistant MFA (WebAuthn / FIDO2) — defeats Evilginx-style transparent phishing because the auth challenge is bound to the actual domain
• Approval workflows for OAuth apps — block unknown apps from being authorized by users
• Conditional access policies — require additional verification for logins from new devices/locations
• Browser security baseline — managed browser, security extensions, alerts on dangerous downloads
• Session cookie hardening — short lifetimes, IP binding, secure attributes

Stage 3 — Persistence inside accounts

Once an account is compromised, attackers want to maintain access even if the password is changed or session is revoked.

Add a new MFA method

Attacker adds their own TOTP enrollment to the account. Even if the user resets their password, attacker still passes MFA.

Defense: notify on MFA changes, require step-up auth for MFA modifications, periodic audit of registered MFA methods.

Add a recovery email

Attacker sets their own email as a recovery option. If user does full account reset, recovery email is the bypass.

Defense: require recent password verification to add recovery options, notify on changes.

Add an OAuth app

Attacker authorizes their own OAuth app with broad scopes. Long-lived token, not affected by password change.

Defense: admin approval for OAuth apps, periodic review of authorized apps per user, scope minimization.

Add an API key / personal access token

If the user has a developer account, attacker generates a personal access token with broad scopes. Doesn't expire with password change.

Defense: API key expiration, scope minimization, audit of issued tokens, anomaly detection on API usage.

Modify connected services

If the app supports webhooks, integrations, third-party connections: attacker establishes a backdoor connection that delivers events to attacker infrastructure.

Defense: audit of integrations, approval workflows for new integrations, periodic verification of integration endpoints.

Stage 4 — Privilege escalation

Once persisted as a low-privilege user, attackers escalate.

Role abuse

User has more permissions than their job requires (overprovisioned access). Attacker exploits the excess.

Defense: principle of least privilege, periodic access reviews, just-in-time elevation.

Application-level bugs

The compromised user can access features that elevate. "Edit my profile" forms that accept role parameters. Internal APIs without authorization checks.

Defense: server-side authorization on every endpoint, not just client-side UI hiding.

Social engineering inside

Compromised internal account asks help desk for "my password reset" or "my MFA reset." Help desk obliges. Now attacker has more permanent access.

Defense: out-of-band verification for credential/MFA changes, never reset based solely on "I'm locked out" requests.

Token escalation

Low-privilege OAuth token used to authorize a higher-privilege app in the same flow.

Defense: explicit re-authentication for elevated scopes, scope auditing.

Stage 5 — Lateral movement through connected services

Modern SaaS environments interconnect. Compromise of one often pivots to others.

Single Sign-On as pivot

Attacker has access to your SSO provider's session. Now logged into Slack, Google Workspace, GitHub, AWS console, etc., all via the SSO.

Defense: separate, stronger auth for high-stakes services (AWS console requires additional MFA even after SSO), audit logs cross-correlated.

CI/CD takeover

Developer account compromised. Attacker pushes code to a branch, opens PR, exploits CI/CD permissions to deploy malicious code or steal secrets from build environment.

Defense: required code review (no bypass), production deploy approval workflows, ephemeral CI credentials, secret scanning in repos and builds.

Cloud account pivot

Application compromise → instance metadata service → IAM role credentials → cloud account access. (Covered in tutorial 5.)

Defense: scoped IAM roles, IMDSv2 mandatory, network segmentation between app and metadata service.

Vendor / partner account pivot

Compromise of an account that has vendor admin access. Attacker uses your access to your vendor (a SaaS you bought, a service you use) to attack the vendor's other customers, or to harvest data passing through.

Defense: scoped permissions on vendor accounts, audit of cross-account access, vendor SOC 2 review.

Stage 6 — Action on objective

Whatever the actual goal:

• Data exfiltration — bulk export of customer data, source code, IP
• Financial fraud — wire transfers, ACH manipulation, BEC
• Operational disruption — wipe systems, disable services
• Persistence for long-term intelligence — sit silently, observe, exfiltrate strategically
• Reputation damage — public defacement, public leak with PR component

Detection at this stage

If you didn't detect earlier, this is your last chance. Indicators:

• Bulk data downloads
• Unusual database queries
• Large outbound network traffic
• Mass deletion or modification
• Unscheduled administrative actions
• Activity from accounts that should be dormant

Centralized logging + anomaly detection finds these — if you're looking.

Defensive maturity — what red teams reveal

After a red team engagement, the failures cluster into categories:

"We didn't have logs for that"

Missing telemetry. The attack happened, but you can't see it because logging wasn't enabled for that path.

"The alert fired but no one noticed"

Alert fatigue, no on-call rotation, alerts going to dead email distribution lists.

"We saw the alert, didn't escalate"

Triage failed. The first responder dismissed it as noise.

"We escalated, but had no playbook"

No documented response, no clear authority, conflicting decisions.

"We followed the playbook, but it was wrong"

Outdated procedures, missing escalation contacts, broken assumptions.

Each is fixable, but only if you've tested. Red team exercises reveal which category you fall into. Then you fix the broken layer and test again.

Defenses against the full chain

Stacking the controls from this tutorial against the full attack chain:

No single layer stops everything. Combined, they create choke points that slow attackers and give detection time to fire.

Closing — engage red teams when you're ready

Red team exercises are expensive (€30K-€200K+ for serious engagements) and embarrassing (they will find things). They're also the only realistic test of your operational security.

Don't engage one before you've done the basics. They'll waste their time and yours finding obvious bugs that internal audits should catch. Engage when you've done the work and want to see if it's actually enough.

Tutorial 10 covers what to do when the red team — or a real attacker — succeeds.