CAPEC-662 Adversary in the Browser (AiTB): How the Attack Pattern Works and How to Defend

An adversary in the browser changes what a user sends and what a user sees after TLS, MFA and the login page have all done their jobs. MITRE CAPEC-662 describes an attacker who uses a trojan, a malicious extension or injected code to sit inside the browser and observe, filter or alter traffic between the user and a web application, while showing the user the transaction they expected. Older names for the same idea are man in the browser, boy in the browser and man in the mobile. This guide explains how the pattern works, how it differs from network and phishing-proxy attacks, and the server-side, endpoint and browser-policy controls that blunt it. It is written for security architects, endpoint and browser administrators, fraud and detection teams, and application owners who run high-value web transactions. For how CAPEC itself is structured, see the MITRE CAPEC Guide.

Key takeaways

• Encryption and MFA still work, which is the problem. CAPEC-662 notes that the attack succeeds even when SSL/PKI and multifactor authentication are present, because the attacker acts inside the authenticated session, before encryption and after decryption.
• The trojan comes first. Every variant needs code on the endpoint: a malicious extension, an injected DLL, a modified hosts file or a trojan mobile app. Extension control and endpoint hardening remove most of the attack surface.
• Defend the transaction, not only the login. Out-of-band confirmation that shows the real amount and payee on a separate device, plus server-side transaction monitoring, is the control that still holds when the browser itself is lying.
• Browser pivoting needs privilege. MITRE ATT&CK T1185 notes that pivoting through a victim browser typically needs SeDebugPrivilege or high integrity, so standard user rights and injection telemetry are high-value controls.
• The session is the identity. An AiTB inherits cookies, single sign-on sessions and client certificates, so short session lifetimes, device-bound sessions and fast revocation limit what one compromised browser can reach.

What CAPEC-662 describes

CAPEC-662 is a Standard-level attack pattern in CAPEC 3.9, rated likelihood High and typical severity Very High. It is a child of the meta pattern CAPEC-94 Adversary in the Middle (AiTM), and it can follow CAPEC-185 Malicious Software Download and CAPEC-542 Targeted Malware. The related weaknesses are CWE-300 Channel Accessible by Non-Endpoint and CWE-494 Download of Code Without Integrity Check. CAPEC maps it to MITRE ATT&CK T1185 Browser Session Hijacking.

The CAPEC execution flow has two phases. In the experiment phase the adversary gets a trojan onto the victim system (phishing, drive-by download or a malicious extension posing as a legitimate one) and then inserts itself into the communication channel as a routing proxy between the two components. In the exploit phase it observes, filters or alters data of its choosing. CAPEC lists these prerequisites: a trojan is installed, two components are communicating, the attacker understands the communication mechanism, strong mutual authentication is not used between the components, and for browser pivoting, SeDebugPrivilege and a high-integrity process are available.

The variants CAPEC groups under AiTB

The man in the mobile variant links naturally to the Android Banking Trojans Guide, and regional families such as Grandoreiro and Melcoz, both listed as T1185 procedure examples by MITRE, are covered in the Latin American Banking Trojans Guide.

How AiTB differs from related patterns

AiTB is often confused with network interception and reverse-proxy phishing, and the controls differ.

Passkeys are still right, but they do not close AiTB. Once code runs in the authenticated browser, what remains is keeping code out, detecting it, limiting the session and confirming intent on a channel the browser cannot touch.

Where it shows up

• Online banking and payments: the classic case. CAPEC's own example describes a malicious plugin that inflates a funds transfer, redirects it to the attacker and then rewrites the confirmation page so the victim sees the original details. OWASP's man-in-the-browser page describes the same submit-and-restore sequence and notes that the server cannot tell the altered form from a genuine one.
• Corporate intranet and SaaS: browser pivoting lets an attacker browse internal sites as the user. ATT&CK T1185 names SharePoint and webmail as examples, and notes that pivoting may bypass two-factor authentication.
• Credential and data harvesting: CAPEC cites Agent Tesla, used in 2020 against oil, gas and energy organisations, with form grabbing, keylogging, clipboard capture and screenshots.

Detection

Detection has two halves: the endpoint, where the trojan runs, and the application, where altered transactions arrive. Neither alone is enough.

Endpoint and browser telemetry

MITRE's detection strategy for T1185 (DET0507, analytic AN1398) looks for a process that gains high integrity or special privileges such as SeDebugPrivilege, opens a browser process with write or inject rights, and modifies it with a remote thread or DLL load. The log sources it lists are below.

Add browser-level signals: extension installs and permission changes reported by your browser management console, extensions installed outside the allowlist, developer mode turned on, remote debugging enabled, and changes to the hosts file or system proxy settings. The Browser Forensics Guide covers where these artefacts live after the fact.

Application and fraud signals

• Behavioural mismatch: a transaction whose amount, payee or timing departs from the user's history, or a new payee added and paid in the same session.
• Interaction anomalies: form submissions faster than human input, fields changed after the last user interaction, or a page structure on the client that does not match what the server rendered (where you deploy client-side integrity checks).
• Confirmation mismatch: the user declines an out-of-band confirmation because the amount or payee shown is not what they entered. Treat each decline as a likely compromised endpoint, not as user error.

For payment service providers in the EU and EEA, Article 2 of Commission Delegated Regulation (EU) 2018/389 already requires transaction monitoring that takes account of, among other factors, signs of malware infection in any session of the authentication procedure and known fraud scenarios.

Metrics that show the controls work

• Percentage of managed browsers enforcing an extension allowlist (blocklist set to all, with named exceptions).
• Percentage of user endpoints where users hold no local administrator rights.
• Declined out-of-band confirmations per month, and the proportion traced to a confirmed endpoint infection.
• Median time from detected browser injection to session revocation across the identity provider and key applications.

Prevention and hardening

Control mapping

Browser policy settings

Chrome and Edge share the same extension policy names. These are customer-side settings in your management tooling:

• ExtensionInstallBlocklist set to *: blocks all extensions by default. Blocked extensions already installed are disabled and users cannot re-enable them. In Chrome, all unpacked extensions are blocked under this setting.
• ExtensionInstallAllowlist: the named exceptions to the blocklist. Review each entry for the hosts and permissions it requests.
• ExtensionSettings: finer control, including blocked_permissions, runtime_blocked_hosts to stop all extensions touching your banking, payment and admin domains, and installation_mode to block a whole store.
• ExtensionInstallForcelist: force-installs approved extensions. Note from the Edge documentation that it overrides the blocklist, so treat this list as privileged configuration.
• RemoteDebuggingAllowed: set to disabled. When unset, users can enable remote debugging through command-line switches, which gives other local code a control channel into the browser.
• DeveloperToolsAvailability: value 2 blocks DevTools for users who do not need them; value 0 (the default) keeps DevTools away from policy-installed extensions.

For wider baselines see the Browser Extension Security Guide and the Browser Security Hardening Guide.

Application-side controls

• Dynamic linking of confirmation to content: Article 5 of Regulation (EU) 2018/389 requires that, for remote electronic payments, the payer is made aware of the amount and payee, the authentication code is specific to that amount and payee, and any change to either invalidates the code. Outside the EU this is still the right design: confirmation on a separate device that displays what the server will actually execute.
• Avoid SMS as the confirmation channel for high-value actions: CAPEC's man in the mobile variant exists specifically to capture SMS codes. Prefer an app-based confirmation or hardware signing that shows the transaction details.
• Device-bound sessions: Chrome's Device Bound Session Credentials binds a session to a private key held in secure hardware such as a TPM where available, with short-lived cookies refreshed only with proof of possession. It targets cookie export and replay; Google's documentation cautions that malware present at registration may extract the key, and it does not stop malware driving the live browser on the same device.

Where identity fits

An adversary in the browser does not need your password: it borrows the identity already loaded into the browser. That includes SSO session cookies for the identity provider, OAuth tokens held by single-page apps, client certificates, and any API keys or tokens a developer pastes into a web console. A privileged administrator browsing from a general-purpose workstation therefore exposes every system that session can reach. Keep privileged browsing on Privileged Access Workstations with no third-party extensions, keep tokens out of browser storage where you can (see the Browser Storage Security Guide), and make sure your incident runbook revokes sessions at the identity provider and in each downstream app, not just a password reset. The Infostealer Threat Guide covers the overlapping malware families that steal the same material for use elsewhere.

How to implement

1. Inventory (week 1 to 2): export installed extensions, their permissions and host access from your browser management tooling. Identify users with local admin rights and endpoints without EDR.
2. Audit mode (weeks 2 to 4): build the allowlist from business-justified extensions. Turn on Sysmon Event IDs 8 and 10 with browser-scoped filters (and Event ID 7 scoped to browser images if volume allows) and baseline what normally touches browser processes.
3. Pilot ring (weeks 4 to 6): apply ExtensionInstallBlocklist set to *, the allowlist, RemoteDebuggingAllowed disabled and runtime_blocked_hosts for sensitive domains to IT and security staff first, then administrators.
4. Broad rollout: extend in rings by department. Keep an exception workflow with an owner and review date for each allowlisted extension.
5. Application controls: add out-of-band confirmation with amount and payee for high-value transactions and admin changes, and feed confirmation declines into fraud and SOC queues.
6. Respond: on a confirmed injection, isolate the endpoint, revoke sessions at the IdP and key apps, review transactions made during the window and reimage before reissuing credentials. The Malicious Browser Extension Incident Playbook gives the extension-specific steps.
7. Rollback: if a blocked extension breaks a critical workflow, allowlist it for the affected group with a dated exception rather than removing the global block.

Decision guidance

• Managed workforce versus customers: for your own staff, extension allowlisting and endpoint controls are the main levers. For customers on unmanaged devices you control nothing on the endpoint, so invest in transaction confirmation, behavioural monitoring and fast response.
• Small organisations: start with no local admin rights, ExtensionInstallBlocklist set to * with a short allowlist, automatic browser updates and app-based MFA confirmation from your bank. These need no new tooling.
• Large organisations: add injection analytics in the SIEM, enterprise browser or remote browser isolation for the highest-risk users, and session lifetime policies per application tier.

Common failure patterns

• Treating passkeys as the end of the problem: phishing-resistant MFA stops proxy phishing, not code already running in the authenticated browser.
• Confirmation without content: an approve or deny prompt that does not show the amount and payee lets the attacker swap them, because the user approves what the compromised page told them.
• Open extension stores: no blocklist policy means users can install any extension, including ones that request access to all sites.
• Password reset as the whole response: resetting a password leaves live sessions, cookies and tokens in place. Revoke sessions everywhere the user was signed in.

Framework mapping

Practitioner checklist

• Set ExtensionInstallBlocklist to * with a reviewed allowlist on every managed Chrome and Edge browser.
• Use ExtensionSettings runtime_blocked_hosts to keep extensions off banking, payment, IdP and admin domains.
• Disable RemoteDebuggingAllowed and restrict DeveloperToolsAvailability for users who do not need it.
• Remove local administrator rights from standard users and monitor SeDebugPrivilege use.
• Collect Sysmon Event IDs 8 and 10 for browser processes and alert on non-browser images opening or injecting into them.
• Require out-of-band confirmation showing amount and payee for high-value transactions, new payees and admin changes.
• Revoke sessions at the IdP and each downstream app on any confirmed browser compromise, then reimage.

Standards and references

• MITRE CAPEC: CAPEC-662 Adversary in the Browser (AiTB)
• MITRE ATT&CK: T1185 Browser Session Hijacking
• OWASP: Man-in-the-browser attack
• EUR-Lex: Commission Delegated Regulation (EU) 2018/389 on strong customer authentication
• Microsoft Learn: Use group policies to manage Microsoft Edge extensions
• Google Chrome Enterprise: ExtensionInstallBlocklist policy
• Microsoft Learn: Sysmon
• Chrome for Developers: Device Bound Session Credentials

Related NHI Mgmt Group resources: MITRE CAPEC Guide · MITRE ATT&CK T1176 Software Extensions · Session Hijacking and Cookie Theft Guide · Infostealer Logs and Session Token Abuse Guide