A fake job offer is one of the oldest lures in phishing. What CTM360 documented this month in a campaign it calls RecruitTrap is not old at all: a fake browser window convincing enough to fool the browser itself, wired to a live backend that watches each victim’s login attempt and decides, screen by screen, exactly which multi-factor prompt to throw at them next.
What RecruitTrap Actually Built
CTM360 tracked more than 3,000 phishing URLs over a two-month window, each one impersonating a recruiter or a hiring process tied to one of over 50 real organizations spanning 14 industry sectors. The campaign does not target résumé submitters broadly. It filters specifically for corporate email accounts, discarding personal addresses that reach the page, because a Gmail or Yahoo login is worth far less to the operators than a working set of enterprise credentials.
The lure starts ordinarily enough: an unsolicited email or meeting invitation, styled to look like it comes from a recruiter at a recognizable company, referencing the target’s professional background and inviting them to schedule an interview. Nothing about that message needs to spoof a domain. A lookalike domain, a compromised mailbox, or simply a convincing display name is enough to get the click, because the actual theft happens after the click, not in the header.
Why a Fake Browser Window Beats a Fake Login Page
Browser-in-the-browser, or BitB, is a technique that renders a popup window inside the page itself, complete with a fake address bar, fake window chrome, and a URL that looks correct because it is drawn with HTML and CSS rather than issued by the actual browser. A user checking for the padlock or glancing at the domain in the address bar sees exactly what they expect to see, because none of it is real.
RecruitTrap’s version runs on a Svelte and SvelteKit front end that moves the victim through staged scenes: CAPTCHA, username, password, and then one of several two-factor methods. What makes it dangerous is the layer underneath. A persistent Socket.IO connection ties each session back to the attacker’s backend in real time, letting an operator, or an automation acting as one, watch what the victim’s real account demands and select the matching challenge screen on the fly. If the target’s organization uses an authenticator app, the fake page asks for an authenticator code. If it uses SMS, the fake page asks for SMS. The kit is not guessing which MFA method to fake. It is being told.
Where DMARC Sits in This Chain
DMARC, SPF, and DKIM answer a narrow question: is this message authorized to claim it came from this domain. RecruitTrap’s opening email does not need a favorable answer to that question in order to work. A lookalike domain carries its own valid SPF and DKIM records and can publish its own DMARC policy without contradicting anything, because it is not claiming to be the real company’s domain, only something that looks like it at a glance. A compromised mailbox at a real recruiting firm passes every authentication check for the same reason the Azure Monitor and Google Cloud abuses covered here in past weeks did: the infrastructure sending the message is legitimate, even when what it is sending is not.
Once the email does its one job, getting a click, DMARC has nothing left to check. The credential theft, the MFA relay, and the account takeover all happen on infrastructure DMARC was never built to see: a phishing site with its own domain, its own certificate, and its own real-time backend.
What This Means for Your Program
Treat BitB as a training gap, not just a technical one. Users are taught to check the address bar. A convincing browser-in-the-browser popup defeats that specific habit by faking the thing they were told to trust. Training needs to cover that a legitimate SSO or OAuth popup should be verifiable by dragging the window partially off the parent page, since a fake window rendered in HTML cannot cross that boundary.
Watch for recruitment-themed lures against professionals who publish their job function publicly. RecruitTrap’s filtering for corporate accounts and its focus documented by CTM360 suggests targeting driven by publicly available professional information, the kind found on networking sites and company directories.
Don’t assume MFA alone closes the gap. A relay that watches which challenge a real account requires and mirrors it back defeats MFA as a standalone control. Phishing-resistant methods, such as FIDO2 hardware keys or passkeys bound to the origin, are not spoofable by a fake window the way a one-time code is.
Keep DMARC enforcement where it belongs, at the front door. A strict p=reject policy stops someone from directly spoofing your own domain in a recruiter-themed lure aimed at your employees or your candidates. It does nothing to stop a lookalike domain or a compromised third-party mailbox from doing the same job, so pair it with domain monitoring for close variants of your own name.
The Takeaway
RecruitTrap is not a DMARC failure. It is a reminder that phishing has moved further downstream from the inbox than authentication protocols were ever meant to reach, using a browser illusion good enough to survive the one check most users still remember to make. Authenticating the message that opens the door was always a separate problem from defending what happens once someone walks through it.
Excello Mail gives you continuous visibility into your DMARC reports, so you know exactly which sources are authenticating under your domain while attackers build ever more convincing fronts for the credential theft that happens after the click. Sign up for free to Excello Mail and put real monitoring behind the authentication layer you control.