BlackTree Security · Infrastructure · Automation · AI
Security · 24 Aug 2026 · Rob Nidschelm

The Recruiter’s Identity Was Real. The Login Window Wasn’t – Intel 471 Pre-Webinar

The recruiter’s identity was real. The interview page was not. Operation Fake KickOff turns the promise of a job into a live, operator-controlled attempt to steal Google Workspace credentials, relay multi-factor authentication and obtain access to the victim’s current employer.

Intel 471 says the campaign has used 232 phishing domains and 80 command-and-control servers while impersonating 52 organisations across 15 industries. The operation began in April 2025, according to the company’s investigation, and was still deploying active phishing pages at its 7 July 2026 intelligence cutoff.

The latest lures borrow the visibility of the 2026 FIFA World Cup. That theme explains the name, but it can obscure the more important point: FIFA and the other impersonated brands are usually the bait, not the ultimate target. The kit rejects personal email providers and pushes victims to enter a corporate address. The valuable asset is access to the organisation where the candidate already works.

Intel 471 will present its investigation in a 30-minute webinar on 26 August 2026 at 12:00 ET, which is 18:00 in Madrid. Its published research already reveals a campaign that deserves attention before the session begins.

The interview invitation begins on trusted infrastructure

Operation Fake KickOff does not depend on a crude email from an obviously unrelated server. Intel 471 observed the operators abusing legitimate marketing and delivery services including Salesforce, SendGrid and Zoho. Independent research by Team Cymru senior adviser Will Thomas documented one chain that moved through PeopleForce, Salesforce Marketing Cloud’s ExactTarget infrastructure and the Wise Agent customer-relationship platform before reaching a phishing site hosted through Netlify.

That sequence matters because each intermediate service can look routine to an email gateway, web proxy or user. A click-tracking domain owned by a recognised software company is not proof that the destination is safe. It only proves that a legitimate redirection feature is being used.

Public reporting has not established whether every abused SaaS account was created by the attacker, compromised from a legitimate customer or obtained through some mixture of both. Abuse of a platform also does not mean the platform itself was breached.

The final lure is more personal. Fake messages use the names and profile photographs of real recruiters connected to the impersonated organisation. A recipient is invited to schedule an interview through a page designed to resemble Calendly or a corporate recruitment portal. The branding, recruiter and job context reinforce one another.

The login window is part of the page

When a target clicks “Continue with Google,” the page displays what appears to be a Google authentication pop-up. It is not a separate browser window and it is not served by Google. HTML, CSS and JavaScript inside the malicious page reproduce the chrome of a browser window, including the address bar and familiar sign-in design.

This is the browser-in-the-browser technique, commonly shortened to BitB. The fake window can display a convincing Google hostname because its address bar is only a visual element controlled by the phishing site. The browser’s real origin remains the attacker’s domain.

The first filter is unusually revealing. Intel 471 found a hardcoded list that rejects addresses from Gmail, Yahoo, Outlook, Hotmail, iCloud, Proton Mail, AOL and other consumer services. A personal address produces an artificial validation error. A business address allows the workflow to continue.

That is campaign logic, not form validation. The operator is spending infrastructure and live attention on accounts that can open corporate email, files, SaaS applications and identity-connected services.

The phishing page talks back

The kit’s most consequential feature appears after the password is entered. The page sends the credentials and victim telemetry to an attacker-controlled backend, then polls a session-specific endpoint every three seconds. The operator can test the credentials against the real service, see which authentication challenge appears and instruct the fake page to show the matching prompt.

Intel 471 identified separate routes for four common challenges:

  • Email: a fake Google verification screen asks for a code delivered to the victim’s mailbox.
  • Authenticator: the page requests the six-digit time-based code generated by Google Authenticator.
  • SMS: the victim is prompted to enter the text-message code.
  • Google prompt: the page tells the victim to approve the sign-in and select a number shown on screen. This component polls for operator instructions every 500 milliseconds.

If the operator completes the login, the victim can be redirected to a realistic scheduling confirmation or a legitimate external page. The absence of an error can become part of the deception.

This is the same broad transition BlackTree examined in Phishing Pages Are Becoming Live Operator Consoles. A phishing page is no longer a static form waiting for a password. It is an interactive interface through which an operator can adapt the social engineering to the victim’s real authentication flow.

“MFA bypass” needs a precise definition

Intel 471 describes the toolkit as adversary-in-the-middle infrastructure capable of harvesting credentials and live session tokens. Its webinar page says the operation hijacks sessions in real time and bypasses MFA.

The public technical description clearly establishes real-time relay of passwords and several second factors. It does not publicly document every step by which a completed Google session is transferred to the operator, nor does it show whether every campaign page used a transparent reverse proxy, manual login relay or another session-capture mechanism.

That distinction does not reduce the risk. It prevents the phrase “bypass” from being misunderstood as a cryptographic break in Google Authenticator or Google prompt. The attacker defeats the protection operationally by persuading the victim to complete the challenge while the operator is signing in. A time-limited code is still valid if it is relayed quickly enough. Number matching is still vulnerable when the victim is shown the number generated by the attacker’s own login attempt.

Phishing-resistant authentication changes that equation. Passkeys and FIDO security keys bind authentication to the legitimate web origin, so a fake page cannot simply collect a reusable password or ask the victim to type the cryptographic response. Google describes passkeys as phishing-resistant and allows Workspace administrators to enable passwordless sign-in or restrict passkeys to hardware security keys.

Strong authentication is not the entire answer. Existing sessions, account recovery, newly enrolled devices, delegated applications and unmanaged endpoints remain valuable attack paths. It is, however, a material improvement over SMS, time-based codes and approval prompts that a live operator can relay.

The brand offering the job may not be the victim

Intel 471 found that human-resources consulting represented about 54% of observed phishing infrastructure. Robert Half and Aquent together accounted for roughly half of all observed domains. The researchers also identified impersonation across technology, travel, hospitality, consumer goods, entertainment and other sectors.

That distribution makes sense when the objective is viewed from the attacker’s side. A recognised recruitment agency can plausibly contact people across many industries. A globally known employer creates urgency and aspiration. A sports event creates a burst of hiring stories and public attention.

The victim may also be less likely to ask a colleague or manager whether the approach is genuine. Job searches are private. An attacker can exploit that privacy to isolate the target from the ordinary verification channels used for supplier requests, financial instructions or internal IT messages.

This creates an uncomfortable but necessary security lesson. Organisations should tell employees not to use their corporate identity for external job applications, but they should not turn suspected job-seeking into a disciplinary event. If reporting a suspicious recruiter threatens someone’s employment, the campaign gains a powerful silence mechanism.

Cloud infrastructure makes the campaign look ordinary

Intel 471 mapped 232 phishing domains and 80 backend servers. The domains used predictable combinations of brand names with words such as careers, jobs, hiring, recruiting, talent, calendar, Calendly and schedule call. Most landing-page infrastructure was hosted on Amazon services, including CloudFront and exposed EC2 systems. Netlify also appeared in the domain and hosting trail.

The backends were primarily hosted on Render’s onrender.com infrastructure, with stolen data forwarded to Telegram bots. A single backend was sometimes reused across more than one phishing domain, creating relationships that are more durable than any individual lookalike hostname.

Defenders should not respond by blocking every legitimate cloud or marketing platform named in the research. Those services carry real business traffic. The more useful detection model combines several weak signals: a newly registered recruitment-themed domain, a recognised tracking service, a redirect to an unrelated host, a corporate Google sign-in request and subsequent traffic to a rarely used Render endpoint.

The link to O-UNC-038 is strong, but not conclusive

Intel 471 says Operation Fake KickOff strongly overlaps with activity Okta tracks as O-UNC-038. The shared features include recruitment lures, Google Workspace credential theft, BitB pages, Salesforce ExactTarget abuse, Telegram exfiltration and similar domain-registration patterns.

Okta’s December 2025 report is an important baseline. It described more than 400 domains across several recruitment-themed clusters. One campaign used BitB pages to steal Facebook credentials and exfiltrate them through Telegram. Another rejected personal addresses and targeted corporate Google credentials. Okta explicitly said the observed examples used static credential-harvesting kits rather than the more sophisticated adversary-in-the-middle session theft it discussed as a broader possibility.

The newer Intel 471 analysis adds the live operator loop and dedicated MFA prompts. That may show development within a related cluster, reuse of a common kit or convergence among several actors. Okta also warned that infrastructure differences could indicate multiple independent operators. The public evidence supports overlap, not a definitive identity for the people running the campaign.

What defenders should change now

  • Move valuable Workspace identities to phishing-resistant authentication. Prioritise administrators, executives, finance, HR, developers and anyone with broad SaaS access. Prefer passkeys or FIDO2 security keys over SMS, time-based codes and approval prompts.
  • Require trusted device context for sensitive applications. Google Workspace Context-Aware Access can restrict applications by managed-device status, location, IP address and other context. A correct password and MFA response should not automatically make an unmanaged session trustworthy.
  • Separate job-search guidance from employee surveillance. Tell staff to use personal contact details and official career portals for external applications. Give them a confidential route to report a suspicious recruiter without exposing their career plans.
  • Protect recruiter identities as an attack surface. Monitor lookalike domains that combine the organisation’s name with hiring terminology. Give recruitment teams a standard public verification method and a rapid process for reporting impersonation or misuse of profile photographs.
  • Detect the chain, not only the final domain. Correlate legitimate marketing redirects, newly registered domains, fake scheduling pages, corporate-only login prompts and unusual onrender.com traffic. Review the domain patterns and indicators published by Intel 471 and Will Thomas.
  • Teach the limit of the pop-up test. A genuine authentication window can move beyond the boundaries of its parent page and remains visible when that page is minimised. A BitB element cannot. This is a useful clue, but users should not be expected to defeat a professional campaign through visual inspection alone.
  • Prepare a session-focused response. After suspected interaction, reset the password, revoke active sessions and refresh tokens, review sign-in logs, check newly registered authentication methods and devices, inspect OAuth grants and mail rules, and investigate activity performed after the first suspicious login.
  • Watch for suspicious session-cookie events. Google Workspace can terminate sessions associated with suspicious cookies and exposes related events through its investigation tools. Make sure the relevant alerts reach responders who can act quickly.

Questions the webinar should answer

The public report establishes a large, active and technically adaptive campaign. The 26 August session will be most valuable if it closes the remaining evidence gaps:

  • How exactly does the operator obtain or reuse the final authenticated Google session?
  • Which controls have stopped observed attacks, and which forms of MFA have failed in practice?
  • How many targets completed the flow, rather than merely receiving a lure or visiting a page?
  • Which infrastructure links are stable enough for detection, and how quickly are domains and Render backends replaced?
  • What evidence separates one evolving O-UNC-038 operation from several actors using similar recruitment kits?
  • What supports the assessment that generative AI assisted development beyond verbose comments, emojis and tidy code?

Those questions matter because defenders do not need another warning that fake recruiters exist. They need to know where this operation crosses from convincing presentation into reusable corporate access, which signals survive infrastructure rotation and which identity controls prevent the operator from completing the real login.

The job offer is the delivery mechanism

Operation Fake KickOff is not primarily an attack on recruitment websites. It is an identity attack delivered through the private moment when an employee considers a new role.

The campaign assembles trust from recognisable pieces: a real recruiter’s face, a famous employer, a familiar scheduling page, established SaaS delivery infrastructure and a Google sign-in window. None of those pieces proves legitimacy. Together, they can make a corporate user complete an attacker’s login in real time.

The defensive objective is therefore larger than spotting a fake domain. It is to ensure that a password, an MFA approval and a polished story are still insufficient to create a trusted corporate session.

Sources and further reading

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2026 BlackTree. Independent technical publication.