1. Executive summary
CTM360 reports identifying more than 3,000 recruitment-themed phishing URLs over two months, impersonating recruitment processes linked to more than 50 organisations across 14 sectors; marketing personnel were the predominant targets. The campaign uses counterfeit scheduling portals and Browser-in-the-Browser (BitB) login windows to collect Google or Facebook credentials and relay MFA interactions in real time, potentially giving the operator an authenticated session. For EMEA financial services organisations, the principal risk is compromise of corporate identities with access to advertising, social-media, email, customer-data or other business platforms; the supplied reporting identifies no confirmed EMEA financial-services victim. No CVE is implicated, so no CVSS severity or CISA KEV exploitation state applies; no threat actor has been identified and attribution remains unconfirmed. (The Hacker News)
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item.
The supplied reporting does not establish a client compromise, regulated-service disruption or other item-specific trigger for UK NIS 2018 duties. Any confirmed client account compromise must be assessed separately against the affected entity, service and impact.
3. Technical analysis & attack chain
The following sequence is confirmed within the supplied CTM360-derived reporting but remains dependent on one underlying campaign source.
- Recruitment lure delivery: The target receives an unsolicited email or meeting invitation apparently sent by a recruiter at a recognisable organisation. The message references the recipient’s professional background and proposes an interview or informal discussion.
- Counterfeit scheduling workflow: The link opens either a Calendly-style scheduling page or a brand-specific recruitment portal. The lure may reproduce employer branding and publicly available recruiter names, photographs and job titles. The alternative portal requests a date, time and basic contact information.
- Traffic qualification: CTM360’s analysis of one Calendly-style URL found a Svelte/SvelteKit front end operating as a state machine. CAPTCHA and browser-reload checks filtered traffic before credential collection. The page rejected personal email domains and advanced corporate accounts, indicating deliberate selection of enterprise identities.
- BitB credential capture: Both lure flows lead to a “Continue with Google/Facebook” stage. The page renders a counterfeit authentication window with a spoofed address bar and padlock. On mobile devices, the counterfeit login may occupy the full screen, further obscuring that it remains part of the phishing page.
- Backend-controlled interaction: A browser-specific session identifier is stored in
sessionStorage. A persistent Socket.IO channel allows the backend to select the victim’s next screen, progressing through CAPTCHA, username, password and MFA scenes. No Socket.IO endpoint, transport, port or server address was supplied. - Real-time MFA relay: After credentials are submitted, the operators use them against the genuine service. The phishing page reproduces the corresponding MFA interaction and returns the victim’s input to the operator. Reported supported methods include OTP, phone-number matching and suffix verification.
- Authenticated access and concealment: If authentication succeeds, the operator obtains an authenticated session. The source does not specify whether this involves cookie or token capture, or only completion of authentication in an operator-controlled browser. The victim may then be redirected to a legitimate Calendly page to reduce suspicion.
Technical scope and infrastructure
This is a web-based social-engineering and identity-relay campaign, not exploitation of a reported software vulnerability. No affected software versions, vulnerable components, CVEs or vendor patches are identified.
Approximately 96% of the observed phishing pages reportedly used a Calendly theme. The separate brand-specific portal dataset contained 116 unique hosts; 93.1% reportedly used dedicated or registered hosts, and 50.9% were hosted on AWS EC2 addresses or ranges. Cloudflare was used by many pages to conceal origin infrastructure.
Across 813 deduplicated registered domains, the reported TLD distribution was:
.cfd: 40%.com: 25.1%.info: 15.1%.works: 10.5%.work: 6.3%
Repeated hostnames and infrastructure reuse indicate a shared deployment model. The template could be rebranded by changing the employer, recruiter identity, background, slogan and authentication provider.
No endpoint malware, host persistence, privilege escalation, lateral movement or conventional endpoint command-and-control was reported. Socket.IO controls the phishing presentation; it should not be interpreted as evidence of post-compromise malware C2. Access to advertising platforms, corporate social-media profiles, customer data and email is described as potential value of compromised marketing accounts, not confirmed downstream access or exfiltration. There is no reported ransomware activity.
No actor attribution or MITRE group mapping is present in the supplied material. “RecruitTrap” is CTM360’s campaign/report label, not a confirmed actor identity. A separate Microsoft 365 BitB campaign reported by Unit 42 corroborates the general embedded-fake-window technique, but does not corroborate RecruitTrap’s infrastructure, victimology or attribution. (Help Net Security)
Campaign scale, infrastructure statistics and detailed workflow are single-sourced to CTM360 and repeated by The Hacker News; verify before enforcement.
4. Mitigation & containment
P1 — within 24 hours
- Identify personnel who received recruiter emails, external meeting invitations or scheduling links during the reported two-month window. Prioritise marketing staff and administrators of advertising, social-media, email and customer-data platforms.
- Block exact URLs and domains recovered from client email, proxy, DNS or browser telemetry. Do not block entire TLDs solely from the aggregate distribution above.
- For any user who submitted credentials or completed an MFA interaction, immediately disable or restrict the affected Google or Facebook identity, reset its password from a trusted device and revoke all active sessions.
- Review sign-in and MFA audit records for unfamiliar source addresses, locations, devices and concurrent authentication activity. Remove unrecognised recovery or MFA changes and inspect advertising, social-media, email and customer-data activity.
- Preserve the original message or invitation, complete URL, redirect chain, browser history and identity-provider logs.
- Warn targeted users not to authenticate through recruiter-supplied pages. Users should open the relevant identity provider independently. A password manager refusing to autofill against the displayed origin should be treated as suspicious.
- Endpoint isolation is not required solely from the supplied reporting because no payload or endpoint compromise is described. Isolate only where separate endpoint evidence exists.
P2 — within 72 hours
- Conduct a retrospective hunt for external recruitment messages followed by visits to counterfeit scheduling pages, CAPTCHA-to-login progression, persistent Socket.IO activity and near-synchronous MFA events.
- Deploy phishing-resistant, origin-bound authentication such as FIDO2/WebAuthn or passkeys for privileged business accounts where supported. OTP, phone-number matching and suffix verification should not be treated as phishing-resistant against the reported relay workflow.
- Apply conditional-access restrictions to high-value accounts where the provider supports them, including managed-device requirements and alerts for unfamiliar sign-in context.
- Configure email and web controls to scrutinise external calendar invitations, newly observed recruitment domains and pages presenting embedded identity-provider login interfaces.
- Review the behavioural indicators in §5. Treat TLD, Cloudflare and AWS hosting characteristics as enrichment only; all are heavily used by legitimate services.
P3 — within seven days
- Inventory marketing and communications identities with access to advertising, social-media, email and customer information. Remove unnecessary privileges and separate administrative access from routine user accounts.
- Add alerts and approval controls for advertising spend, social-profile ownership changes, recovery-method changes and customer-data exports.
- Train recruitment-facing and marketing personnel on BitB mechanics: an address bar rendered inside a webpage is not browser security chrome, even when it displays a padlock or legitimate-looking OAuth address.
- Update identity-compromise playbooks to include immediate session revocation and retrospective review of business-platform activity. There is no vendor patch or version pin for this campaign.
5. Indicators of compromise
No indicators of compromise available in the source material.
The reporting supplies aggregate hosting and TLD characteristics but no individual URLs, domains, IP addresses, email addresses or hashes. These traits are single-sourced; verify before enforcement.
Behavioural indicators
| Behaviour | Where to observe | Confidence |
|---|---|---|
| Unsolicited recruiter email or meeting invitation referencing the recipient’s professional history | Email gateway, calendar audit and user reports | Medium — single underlying source |
| Link opens a counterfeit Calendly-style or employer-branded recruitment portal | Proxy logs, browser history and page captures | Medium — single underlying source |
| Page rejects personal email domains and advances corporate identities | Browser capture or controlled analysis | Medium — reported from one analysed URL |
CAPTCHA → username → password → MFA state progression using sessionStorage and a persistent Socket.IO channel |
Browser developer telemetry, web-proxy content capture or sandbox analysis | Medium — reported from one analysed URL |
| Fake Google/Facebook authentication popup with an embedded address bar and padlock; full-screen presentation on mobile | User report, screenshot or browser capture | Medium — single underlying source |
| Genuine-service sign-in and matching MFA interaction occur while the victim remains on the recruitment page | Identity-provider MFA/sign-in logs correlated with browser and proxy timestamps | Medium — single underlying source |
| Successful interaction followed by redirection to legitimate Calendly | Browser history and proxy redirect chain | Medium — single underlying source |
Rebranded recruitment templates across shared hosting, frequently using .cfd, .info, .works or .work |
DNS, proxy and domain-enrichment telemetry | Low to medium — aggregate traits, unsuitable as standalone indicators |
6. Detection
Insufficient indicators to author detection rules.
7. Sources
- The Hacker News, “CTM360 Uncovers Over 3,000 Recruitment Phishing URLs Using Browser-in-the-Browser (BitB) Credential Traps,” 2026-08-14.
- CTM360, “RecruitTrap: Browser-in-the-Browser (BitB) Recruitment Scams,” date not stated in supplied material.
- Help Net Security, “New Browser-in-the-Browser phishing uses fake login popups to steal Microsoft 365 credentials,” 2026-06-10. This concerns a separate campaign and corroborates only the general BitB technique.
8. Adverse Trace position
Adverse Trace assigns Medium operational severity to this advisory, rising to potentially high impact only where a privileged account interacted with the lure and an authenticated session was established. No CVE, CVSS score or CISA KEV state applies, and the supplied material identifies neither a confirmed EMEA financial-services victim nor observed downstream data theft. Campaign scope and infrastructure claims are single-sourced; verify before enforcement. Attribution is unconfirmed and no MITRE-profiled actor is identified. Adverse Trace will monitor for independently corroborated victimology, validated atomic indicators and evidence of post-authentication activity, and will update this advisory if those become available.
Published via PulseTrace — Adverse Trace threat intelligence.