RecruitTrap Phishing Turns Fake Interviews into BitB Credential Traps

Recruiter outreach is designed to earn attention. In the RecruitTrap phishing campaign, it became the opening move in an identity attack.

Documented by CTM360, RecruitTrap involved more than 3,000 phishing URLs observed over two months and impersonated recruitment workflows associated with more than 50 organizations across 14 sectors. The campaign used Browser-in-the-Browser (BitB) phishing to imitate Google and Facebook authentication windows, while more advanced flows could relay MFA challenges in real time.

Another detail makes RecruitTrap particularly relevant to enterprises: the phishing kit filtered for corporate email accounts. Marketing professionals were the most frequently observed targets.

RecruitTrap at a glance

How RecruitTrap turns recruiter outreach into a BitB attack

RecruitTrap begins with unsolicited recruiter emails or meeting invitations that may reference the recipient’s professional background.

Victims are then directed into one of two main workflows. One uses a counterfeit Calendly-style scheduling page that can reproduce employer branding and publicly available information about real recruiters. Another presents a branded recruitment portal where users select an interview time and provide contact details.

Both paths eventually offer Google or Facebook authentication.

BitB windows imitate legitimate authentication

Instead of opening a genuine authentication window, RecruitTrap can render a fake one inside the malicious webpage.

This Browser-in-the-Browser phishing technique reproduces visual elements such as an address bar and padlock. Because these elements belong to the webpage rather than the browser itself, the attacker can display a convincing URL while the victim remains on the phishing site.

On mobile devices, the same deception can appear as a full-screen counterfeit login page.

This undermines familiar phishing advice based solely on visually checking a login window or padlock.

Svelte and Socket.IO make the phishing flow interactive

CTM360’s analysis of one Calendly-themed URL found a Svelte/SvelteKit front end operating as a state machine.

The kit could move victims through CAPTCHA checks, usernames, passwords and different two-factor authentication stages. A browser-specific identifier stored in sessionStorage maintained the session, while a persistent Socket.IO connection allowed the backend to control which screen appeared next.

In practical terms, this allowed RecruitTrap to respond to the victim during authentication instead of behaving like a static credential-harvesting page. The infrastructure also filtered incoming users, with CTM360 observing personal email domains being rejected while corporate accounts were allowed to continue.

RecruitTrap can relay MFA challenges in real time

More advanced RecruitTrap flows could continue beyond password collection.

Credentials submitted through the counterfeit interface could be used against the legitimate service. If another authentication step appeared, the phishing flow could present the corresponding MFA challenge to the victim.

CTM360 observed support for steps including OTPs, phone number matching and suffix verification.

If authentication succeeded, the flow described by CTM360 could result in an authenticated session. The victim could then be redirected to a legitimate Calendly page, making the preceding interaction less obviously suspicious.

The technique demonstrates an important distinction: MFA remains essential, but not every MFA method provides the same resistance to real-time phishing.

Why RecruitTrap filters for corporate and marketing accounts

RecruitTrap’s filtering behavior makes its enterprise focus unusually explicit.

Rather than collecting every email address, the observed kit rejected personal domains while advancing corporate accounts. Marketing professionals represented the largest share of targets observed by CTM360.

That targeting can be particularly consequential because marketing identities may have legitimate access to advertising platforms, corporate social media, email services, customer information and other business systems.

The campaign also exploits a difficult boundary for security teams. Job hunting is a personal activity, but employees may respond to recruiters using the same browsers and endpoints they use for work. A recruiter message therefore does not necessarily appear inconsistent with normal user behavior.

How reusable Calendly lures helped RecruitTrap scale past 3,000 URLs

CTM360 identified more than 3,000 RecruitTrap phishing URLs during the two-month observation period, with roughly 96% of identified pages using a Calendly theme.

The separate branded recruitment flow appeared across 116 unique hosts. Across 813 deduplicated registered domains, .cfd was the most common top-level domain, followed by .com.

The phishing templates could also be rebranded with different employer names, recruiter identities, backgrounds and authentication providers while retaining the underlying workflow.

This reusable infrastructure allowed the same BitB and authentication techniques to support numerous recruitment lures.

What RecruitTrap confirms and what remains unknown

The available research confirms fake recruitment workflows, BitB authentication interfaces, corporate-account filtering, credential collection and the ability of advanced flows to relay MFA challenges.

Those findings should not be extended beyond the evidence.

The reporting does not establish that every RecruitTrap URL successfully compromised an account, that every target completed MFA or that downstream data theft occurred in every case.

No specific threat actor attribution has been publicly established in the material reviewed for this article.

How enterprises can reduce exposure to RecruitTrap-style phishing

RecruitTrap shows why phishing defense cannot depend exclusively on whether users can visually recognize a fake login page.

Organizations should consider several complementary controls:

• Prefer phishing-resistant authentication where supported. FIDO/WebAuthn-based authentication, including passkeys and compatible security keys, uses public-key cryptography and binds credentials to the legitimate relying party, making authentication resistant to credential phishing and real-time relay through a phishing origin.
• Require trusted device posture for sensitive applications. Access policies can evaluate whether a device is managed and compliant rather than relying only on successful authentication.
• Verify unexpected recruiter outreach independently. Users can confirm recruiters and job openings through official corporate channels before following supplied authentication links.
• Teach users to distinguish browser UI from webpage content. A URL or padlock drawn inside a webpage is not the browser’s real security interface.
• Monitor authentication and session activity. Identity-provider and service telemetry should be used to investigate suspicious cloud authentication behavior.

Password managers can provide another useful signal: stored credentials generally will not autofill when the actual origin does not match the legitimate service.

Featured resource

Strengthen identity and access management with Hexnode

Explore how Hexnode brings identity, access controls and endpoint management together to help organizations secure access to corporate resources.

Download the whitepaper

Where Hexnode fits against RecruitTrap’s identity attack path

RecruitTrap is primarily an identity phishing campaign, so the most relevant Hexnode controls sit around device compliance, authentication and access policy. Endpoint investigation plays a secondary role if suspicious activity reaches a managed device.

Hexnode UEM: add device posture to access decisions

For organizations using Microsoft Entra ID, Hexnode UEM can provide device-compliance information for Conditional Access decisions.

Administrators can define compliance criteria for managed devices, while Entra Conditional Access can require supported devices to be marked compliant before granting access to protected resources.

For a RecruitTrap-style attack, this introduces another access condition beyond possession of usable credentials.

Hexnode UEM should not be positioned as detecting RecruitTrap or credential phishing. Its role is establishing and enforcing managed-device posture that can contribute to access decisions.

Hexnode IdP: evaluate identity and device posture together

Hexnode IdP is relevant because RecruitTrap directly attacks authentication. It can combine identity-based access controls with device compliance information to add device trust to access decisions rather than relying on credentials alone.

This matters in a RecruitTrap-style scenario because credentials successfully relayed through a phishing flow do not necessarily establish that the device attempting access is trusted. When compliance-based access policies are configured, access to protected resources can be restricted for devices that do not meet the required compliance criteria.

MFA remains one component of this layered approach. Because RecruitTrap’s advanced flows could relay phishable MFA challenges, combining identity verification with device posture provides an additional access-control layer.

Hexnode XDR: investigate and contain endpoint threats after access

Hexnode XDR serves as a secondary endpoint security layer in this scenario. RecruitTrap’s documented attack chain centers on browser-based credential phishing, so XDR should not be positioned as the control that detects the initial BitB or MFA-relay activity.

If a compromise subsequently results in malicious activity on a covered endpoint, Hexnode XDR can detect and investigate endpoint threats, including malicious process and file activity. Security teams can then use supported response actions such as terminating harmful processes, quarantining malicious files or isolating affected endpoints.

This makes Hexnode XDR an endpoint detection, investigation and containment layer for malicious endpoint activity, complementing identity and device-trust controls applied earlier in the access path.

RecruitTrap makes the login window part of the lure

RecruitTrap’s defining feature is not simply its use of fake recruiter messages. The campaign carries the deception through the authentication process.

A credible recruiter identity establishes trust. A familiar scheduling workflow reinforces it. A BitB window imitates browser security signals. An interactive backend can then keep the victim engaged through additional authentication steps.

For enterprises, the lesson is straightforward: a convincing login is not necessarily a trusted login, and successful authentication should not always be the only condition for access.

Combining stronger authentication with managed-device posture, access controls, identity monitoring and endpoint investigation where appropriate gives defenders additional opportunities to limit the impact of RecruitTrap-style attacks.