Browser-in-the-Browser phishing: the sign-in window that isn't a window.
You click "Sign in with Microsoft". A familiar pop-up opens with the padlock, the address login.microsoftonline.com and the usual sign-in box. You type your password. The pop-up was never a window. It was a picture of one, drawn inside the attacker's page.
In short
- A Browser-in-the-Browser (BitB) page draws a fake browser window (title bar, padlock, address bar) with ordinary web code, and puts the attacker's sign-in form inside it.
- The address you read in that window is just text. The page you are really on is still the attacker's.
- Modern kits copy Chrome down to the details: the address without
https://, the host in dark text and the path in grey, a window you can drag and resize, the browser name in the title bar. - Many kits add a human step: "Verifying your account…", then a one-time code request, so the attacker can relay your MFA code in real time.
- What helps: passkeys or security keys, a password manager that refuses to fill, and protection that looks at the page you are actually on rather than at what the page draws.
What we saw
A browser protected by ByteMantle reached a page on gme.henrysullivandocudywyq[.]com. It pretended to be an online invitation: a blurred card in the background and the message "To view the invitation, please select your email provider below and log in". Six buttons followed: Outlook, Office365, Gmail, Yahoo Mail, AOL and Other Mail.
Each button opened a convincing Chrome pop-up in the middle of the page. Here is what the page did to make it believable:
- A real-looking title bar. "Microsoft 365 Sign In — Google Chrome", with minimise, maximise and close buttons. The page read the browser's name from the user agent, so an Edge user saw "— Microsoft Edge".
- An address bar that copies Chrome exactly. A padlock, then
login.microsoftonline.comin dark text and/common/oauth2/v2.0/authorize?client_id=…in grey. Each visit got a fresh random session number, so the address never looked recycled. - Window behaviour. You could drag the window by its title bar, resize it from any edge and double-click to maximise it. On a phone it slid up from the bottom like a native sheet.
- The sign-in page inside. The form was the attacker's own page, loaded in a frame inside the fake window: careful copies of the AOL, Yahoo, Google and Microsoft sign-in pages, plus a generic "Sign in to Email". The frame was locked so that nothing in it could escape the window or open a real one.
- A memory. If you refreshed, the fake window came back at the same step, with the same address.
- A waiting room. After you submitted, the window closed and a "Verifying your account" screen appeared. Behind it, the page could show "Login successful", "Verification failed, try again" or a request for the code just sent to your phone, with a five-minute countdown.
That last step is the part that defeats SMS and app codes: while you wait, the attacker tries your password on the real service and, if it asks for a code, asks you for it. The page is ready for that from the start: as soon as a sign-in page opens, it checks back with the attacker's server every three seconds, at addresses named after Telegram. The attacker sees each visitor arrive and steers the page from a chat app.
How to tell a fake window from a real one
A real browser window is drawn by the browser, outside the web page. A fake one lives inside the page, and that has consequences you can check in a few seconds:
- Drag it off the page. A real pop-up can leave the browser window and sit over your taskbar. A fake one stops at the edge of the page.
- Look at your taskbar or window switcher. A real pop-up appears there as its own window. A fake one does not.
- Click the padlock. In a real window it opens the site's connection details. In a fake one it does nothing, or nothing Chrome-like.
- Check the address of the page you started on. Your browser's own address bar, at the very top, still shows the attacker's domain while the fake window is open.
- Watch your password manager. It fills
login.microsoftonline.comonly on the reallogin.microsoftonline.com. If it stays silent on a page you are sure you have used before, stop.
What actually stops it
TipPasskeys and security keys are the strongest answer. They are tied to the real domain, so a sign-in form on another domain cannot use them, however perfect it looks.
- Phishing-resistant sign-in (passkeys, FIDO2 security keys, Windows Hello for Business). A one-time code can be typed into the wrong place; a passkey cannot.
- A password manager with autofill on, and the habit of treating "it didn't autofill" as a warning.
- Protection in the browser that judges the real page. The fake window can lie about its address. The browser always knows the true one.
How ByteMantle helps
ByteMantle runs inside the browser and looks at the page you are really on, including every frame inside it:
- It recognises the fake window. A sign-in form held inside an overlay that shows browser wording or an identity provider's sign-in address is treated as what it is: a credential lure. The full phishing warning opens.
- Sign-in forms in frames are checked too. The form in the fake window is still a page on the attacker's domain. ByteMantle compares the brand the page presents (Microsoft, Google, Yahoo and 46 others) with the domains that brand really owns, and warns when they do not match.
- The warning takes over the whole tab, not the fake window, so the attacker's page cannot dress it up or hide it.
- Domain and site risk. A young domain raises the risk of a page that asks for a password; the extension icon shows the domain's age in days, and the console shows which other browsers in your organization reached the same site.
- One incident, not five alerts. In the console, every finding from the same site on the same device becomes one incident with a timeline, the frames involved and the other devices that reached the site, so your team sees the whole attempt at once.
In this case ByteMantle flagged the provider pages the user opened, and the user went back to safety from the warning.
Indicators
| Type | Value |
|---|---|
| Domain | henrysullivandocudywyq[.]com (registered 5 September 2026) |
| Host | gme.henrysullivandocudywyq[.]com |
| Paths | /signin.php, /outlook/signin.php, /yahoo/signin.php, /aol/signin.php, /email/signin.php, /processmail.php, /process.php, /success.php, /success1.php |
| Operator channel | /check_telegram_updates.php, /check_telegram_updates2.php |
| Kit assets | /outlook/assets/ms-loader.css, /outlook/assets/ms-loader.js (loaded by the AOL, Yahoo, Email and Microsoft pages) |
| Page markers | element IDs bwOverlay, bwWin, bwFrame; session storage keys gwBrowserState, gwBrowserDisplayUrl |
MITRE ATT&CK: T1566.002, T1598.003, T1036, T1111.
Questions people ask
Does multi-factor authentication protect me?
A one-time code by SMS or app does not: the page asks you for it while the attacker types it on the real service. Passkeys and security keys do, because they only work on the real domain.
Is "Sign in with Google / Microsoft" itself unsafe?
No. The real buttons open a real browser window on the provider's own domain. The trick only works because the fake window looks the same; the checks above tell them apart.
I typed my password into one. What now?
Change that password at once on the real site, sign out of all sessions there, and check that no new sign-in method or mail-forwarding rule was added. Tell your IT team if it is a work account.
Read the guideAiTM phishing: how attackers bypass MFA
Stop these attacks before anything runs.
Free browser protection for everyone, in Chrome and Edge. One console for your whole company when you need it.