# RecruitTrap ran 3,000 fake recruitment logins with browser-in-the-browser popups and live MFA relay

Source: https://startwithidentity.com/blog/2026-08-14-recruittrap-browser-in-the-browser-recruitment-phishing/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

CTM360 documented RecruitTrap, a campaign of more than 3,000 phishing URLs deployed over two months. The lure is a recruitment process, impersonating real recruiters at over 50 organizations across 14 sectors, with marketing roles disproportionately targeted because those accounts reach advertising platforms and corporate social profiles. The credential page uses browser-in-the-browser: a rendered popup with a spoofed address bar and padlock that looks like a genuine Google or Facebook sign-in window but is drawn inside the attacker's page. On mobile it presents as a full-screen login instead. The kit harvests Google and Facebook credentials, relays MFA codes in real time, and filters out personal email domains to keep corporate addresses.

## Why it matters

Browser-in-the-browser defeats the advice most security awareness training gives. "Check the URL" fails when the URL bar is a `div`, and "look for the padlock" fails when the padlock is an image. The user is doing exactly what they were told to do and arriving at the wrong answer, which is worth remembering before the incident review calls it a training failure.

Real-time code relay is the other half, and it is the reason [OTP relay](https://startwithidentity.com/techniques/otp-relay-social-engineering/) has become standard kit rather than a specialist technique. A one-time code entered into an [attacker-in-the-middle proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/) is used before it expires; the factor works exactly as designed and changes nothing.

[Passkeys](https://startwithidentity.com/glossary/passkey/) and hardware-backed [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/) break the campaign at the mechanism rather than the awareness layer, because the credential is bound to the real origin and simply will not produce an assertion for a spoofed one. There is no code for a user to relay. Pair that with monitoring for lookalike recruitment domains and correlating unusual sign-ins against recruitment-themed mail. If someone did enter credentials, changing the password is the least important step: revoke sessions, and review OAuth grants, because a [consent grant](https://startwithidentity.com/techniques/oauth-consent-phishing/) survives every credential change you make.

Source: [The Hacker News](https://thehackernews.com/2026/08/ctm360-uncovers-over-3000-recruitment.html)