This report details the analysis of a fully operational Adversary-in-the-Middle (AiTM) credential-harvesting kit targeting Microsoft 365 and Entra ID identities. The attack involves a three-to-five stage funnel starting from financial, recruiting, and document related domain name themes. The funnels typically begin with an anti-analysis CAPTCHA gate to filter sandboxes. This is followed by a corporate email harvest stage that builds trust by dynamically rendering the victim's employer logo and filtering out personal email addresses. The final stage is a pixel-perfect, AiTM reverse proxy of the Microsoft sign-in page, which brokers the live authentication flow and successfully intercepts every credential, Multi-Factor Authentication (MFA) code (including Push, TOTP, and SMS), and post-authentication session cookie. Traditional MFA methods offer no defense against this pattern, as the kit captures the session cookie after the MFA challenge succeeds. Origin-bound authenticators such as FIDO2, passkeys, or Windows Hello for Business may be effective countermeasures.

The campaign has been active since at least December 2025. Evidence suggests the web kit has also been used to target major corporations that use customized authentication portals, as seen in tests against an @amazon.com address, and further domain pivots link the threat actor to fake login pages impersonating companies like Black Rock, Nvidia, Foxconn, Exxon, and Costco. Additionally, the kit includes a sandbox cloak/driver layer that uses JavaScript to evade automated analysis.

‍

Details

Credential Harvest Adversary-In-The-Middle Kit

The captured kit is a credential-harvesting funnel that targets Microsoft 365 / Entra ID identities. It is configured as three sequential pages on two look-alike domains: a CAPTCHA-styled gate at rfg-documentfiles[.]com/, an "Identity Verification" page at rfg-documentfiles[.]com/auth/verify-access that filters out personal mail providers and harvests a corporate email, and a pixel-perfect clone of Microsoft's ConvergedSignIn page at login.documentfiles-rfq[.]com/oauth that operates as an adversary-in-the-middle (AiTM) reverse proxy against the real login.microsoftonline[.]com.

The first page exists to filter out sandboxes and URL scanners. The second page harvests a confirmed corporate email address and renders the victim's employer logo to build trust. The third page brokers the live Microsoft authentication flow: every credential, every MFA code, and the post-authentication session/refresh cookies are passed through attacker-controlled endpoints. Push, TOTP, and SMS MFA do not prevent compromise here, because the kit captures the issued session cookie after the challenge succeeds. Only origin-bound authenticators (FIDO2, passkeys, Windows Hello for Business) defeat this pattern.

‍

‍

Stage 1: Anti Analysis Gate

Landing Pages

Landing pages o commonly appeared as LinkedIn pages either directly as a ‘Redirecting, please wait…’ page that then redirects to a quick security check using a sliding puzzle piece, or the landing page itself is the security check.'

filedocx[.]homes

Redirects to

https[:]//www.accounts-recruitmentportal[.]com/

Completing slider security check redirects

https[:]//billing.rfq-quotationportal[.]com/PoNfjoSB?rwf=QWJ9WwKgZMUCOzZTwMLb6JbrcJwb-43K4rmuT321hVmWqIqUusAG9s9FHTsctR7dWCxOkf-9Du_16lm_8Zewl6DVsx0K7i0

At this phase, there are multiple variations of next stage pages. 
‍

Stage 2: Corporate Email Harvest

Variation 1: An email input box that loads the icon and company name. Example inputting a fake Amazon email address:

Variation 2: A download file link that loads another page similar to variation 1

Clicking download button then loads https[:]//secure.rfq-quotationportal[.]com/oauth?tid=20350817-04103455-65209132-55023327

Variation 3: Additional human verification check that proceeds to a fake LinkedIn sign-in page

‍

Stage 3: Adversary in the Middle reverse proxy of Microsoft sign-in

Entering a company email address then attempts an adversary-in-the-middle (AITM) with the specified company’s Microsoft organization sign-in page. In one case we used an @amazon.com address, and the resulting direction was to the Amazon employee midway-auth login page:

https[:]//midway-auth.amazon[.]com/login?next=%2FSSO%2Fredirect%3Fclient_id%3Dhttps%253A%252F%252Fidp.federate.amazon[.]com%252F%253Fpostureless-deny-otp%26redirect_uri%3Dhttps%253A%252F%252Fidp.federate.amazon.com%252Fapi%252Fv1%252Fintermediate%26response_type%3Did_token%26scope%3Dopenid%26nonce%3DP260510163738259IADQ6LQQ5X695HS%26state%3Dus-east-1_P260510163738259IADQ6LQQ5X695HS_f67bdfdf-f2c3-478d-8993-bfb5c4655b44&require_digital_identity=false

‍

Other variations of the Stage 2 sites were also seen redirecting to Amazon’s employee IdP federate site at https[:]//idp.federate.amazon[.]com/api/saml2/dynamic-logical-idp/entra-prod-tenant/amazon-com/v1/sso

Notably, multiple other large companies had similarly customized auth redirects, suggesting the web kit has also been used to target other companies using their own managed employee authentication portals. 

One test used a fake address with no real auth, so the Microsoft AITM attempt failed and the site redirected to the real midway-auth[.]amazon[.]com sign-in page. Otherwise, the site code appeared to be configured to steal the session.

‍

Code Breakdown

Stage 1: Anti-Scan

The stage 1 sliding position puzzle piece

On drag-end, the verifier POSTs the slider position together with the navigator.webdriver flag. The server decides whether the next page is the real funnel or a benign decoy. A flagged automated client gets status:'bot' with a benign URL, and a real visitor gets status:'success' with the stage-2 URL. The client cannot tell the difference.

‍

‍

tage 1 also kicks off a web worker that computes a server-supplied seed/difficulty challenge. It likely serves two purposes: it consumes CPU on rapid-fire scanners, and it forces the verify token to come from a browser that actually executed JavaScript (JS) in a worker, which may filter out simple URL crawlers.

‍

‍

Stage 2: Corporate Email Funnel

Corporate email filter:‍

A hard-coded list of 25 free-mail domains is rejected by the client code. Only addresses outside that list are allowed to advance.

‍

Dynamic logo render (Clearbit + S2 favicon):‍

On a passing email, the page paints the employer's logo next to the domain. The lookup is keyed on the email domain alone — Clearbit and Google return logos for any well-known company. This is the literal LogoKit primitive documented by Cyble, SecurityAffairs, and Resecurity.

‍

Funnel:

‍

The harvested email and the URL token are sent to /api/final-url, which returns a per-victim stage-3 URL. The email is on the attacker's server before any password is requested.

Stage 3: 

‍

$Config — every MS endpoint rewritten‍

This is the AiTM mechanic in one object. In a legitimate sign-in, these URLs all resolve under the real login.microsoftonline.com. However, on the attacker’s site, every authentication-bearing endpoint points at the attacker host. Microsoft's own JS bundles (loaded from the real aadcdn.msauth.net for parity) read these URLs at runtime and POST credentials/MFA codes to them.

‍

‍

The three URLs that matter most for credential capture are urlPost (the password lands here), urlGetCredentialType (lets the attacker steer the federation/passkey decision so the user is not redirected to a real IdP), and urlGetOneTimeCode (the MFA OTP). The redirect_uri on www.documentfiles-rfq[.]com/landingv2 is where the post-auth OAuth code / id_token is delivered.

The two endpoints that matter most for harvest:

• urlPost:  Microsoft's converged login JS (loaded from aadcdn.msauth.net) submits the password to whatever $Config.urlPost says. With this rewrite, every typed password is POSTed to the attacker's server first.
• urlGetCredentialType: controls how Microsoft decides if the user is federated, has a passkey, or needs a password. Owning this endpoint lets the attacker steer every UI branch (and prevents a redirect to a real federation IdP that would expose the proxy).
• urlGetOneTimeCode: the field where the user types the SMS / authenticator OTP. Forwarded straight to the attacker, who replays it to the real Microsoft within the same proxied session and pockets the resulting ESTSAUTH / ESTSAUTHPERSISTENT cookie.

The web kit hijacks Microsoft's well-known Office Home client_id but sends the post-auth code/id_token to www.documentfiles-rfq.com/landingv2. This is a strong signature of an AiTM consent-grant phish operating against the multi-tenant common endpoint.

The web kit body ends with two extra script tags that are not present in the real Microsoft page:

‍

‍

Both scripts reuse Microsoft's own CSP nonce (0FilRYh2jmgi_Id99Cb0Hw) — a strong signal that the attacker proxy reads the real CSP nonce from the upstream response and inlines it into its own injected tags so the browser executes them. The path prefix /s/<sha256>/<sha256>.js matches content-addressed payload hosting common in modern phish kits.

Sandbox cloak / driver

‍

‍

• Tab-title randomisation from a word list: Welcome, Secure, Access, Portal, Login, Account, Verify, Sign In. Likely intended as a low-effort signature evasion against browser-history / EDR string matches that look for fixed phishing titles.
• i0116 and idSIButton9 are the well-known DOM IDs of Microsoft's email field and "Next" button, suggesting the script is purpose-built to drive Microsoft's sign-in UI.
• Auto-typing any @google.com address and clicking Next on page load is most consistent with a cloak / sandbox-detection layer: analyst sandboxes that detonate the URL will see Microsoft return a benign "we couldn't find an account with that user name" outcome (because google.com isn't an Entra-managed tenant), causing the page to look like an accidental misconfiguration rather than a phish. However, using @amazon did work and triggered the next stage, likely because they do have a Microsoft managed tenant.

Cloak script‍

Two scripts are appended to the end of <body>; both reuse Microsoft's CSP nonce. They randomize the page title from a fixed eight-word list, then auto-types the victim provided email address into Microsoft's i0116 email input and clicks the idSIButton9 "Next" button on a 500 ms interval. 

The script is a sandbox-detection / cloak layer. A sandbox that detonates the URL without first passing stages 1–2 will see the script auto-submit the victim’s provided email address, against which Microsoft returns "we couldn't find an account with that user name." This makes the page look like an accidental misconfiguration rather than a phish.

‍

Domain Registration Pivots

Common Website Title: Security Check | Verification Required

Registrar: Hosting Concepts B.V. d/b/a Registrar.eu

Registrant Organization: lovevivah inc

Both Email Domains: 

• openprovider[.]eu
• registrar[.]eu

IP ISP: Linode

The phishing campaign appears to go back to 2025-12, with common domain name themes around job recruitment, investment, finance, business, and documents. 
‍

Sample Shodan Queries:

http.html:"To continue, please solve this puzzle so we know you're a real person"

http.title:"Security Check | Verification Required" http.html:"Professional Network"

http.html:"puzzle-container" http.html:"bg-canvas" http.html:"piece-canvas" http.html:"slider-handle"

http.html:"id=\"bg-canvas\" width=\"300\" height=\"150\"" http.html:"id=\"piece-canvas\" width=\"50\" height=\"50\""

SOA Pivot Rabbithole:

One of the identified domains from the closely aligned domain registration pivot was capivest[.]top, which has an SOA email itzfahim194[@]gmail[.]com. The same SOA email is tied to 94 domains with some overlapping domain name themes going back to mid-2025. Additionally, several domains were observed hosting fake login pages for multiple corporations including Black Rock (black-rock1[.]top), Nvidia (nvidiatechnolodgy[.]top), Foxconn (foxconn-n.net[.]ng), Exxon (exxon-ieo[.]top), Costco (costc0[.]top) and others. These 94 domains are subsequently linked by unique registrant names and other identifiable SOA emails to over 200 domains. 

Many of the domains are seen to host websites with login pages and suspicious characteristics sampled below:

‍

Conclusion

What was captured appears to be a fully working AiTM credential-harvest kit aimed at Microsoft 365 / Entra ID and fronted by a CAPTCHA cloak and a corporate-email filter, active since December 2025.

‍

IOCs