MadApe: A Phishing Kit That Turns PDF Lures Into Microsoft Device Code Sign-Ins

MadApe is a device code phishing kit: document lures in at least nine languages send victims to Microsoft's real sign-in page, and the attacker's client receives the token.

It arrives as business email with a file attached, made to look like a SharePoint file-sharing notice. The file holds a link to an intermediary page. That page shows a device code and opens Microsoft's own device login page, where the victim enters it. Nothing on the last page is fake, and no password is ever asked for.

How does MadApe turn a PDF into a Microsoft token?

The attachment looks like a SharePoint notice

Group-IB describes a PDF styled as a SharePoint file-sharing notice. It carries an embedded link to an intermediary page. The observed filenames are business documents: payment reports, invoices, contracts, proposals and account statements, and some include organisation-specific names.

The Hebrew-language emails were the first Group-IB identified, and it reports that they target recipients in Israel. The email channel matters for defence: every step that follows starts with a message in an inbox.

The page shows a code and opens Microsoft's login

After the intermediary page, the victim reaches a page that displays a device code. Group-IB reports that clicking the code copies it to the clipboard, and that the Open File button opens Microsoft's own Device Login portal at microsoft[.]com/devicelogin. The kit's pages submit the code to an /api/code/entered endpoint. Group-IB also found logic that checks /api/code/status/<ID> every five seconds, although a conditional check stopped that loop from running in the instances it analysed.

Microsoft's sign-in finishes the job

The device authorization flow was built for devices without a browser. The standard, RFC 8628, has the device show a code and a verification address, and the user completes the sign-in on a second device. The standard also warns that an attacker might send an email telling a target to visit the verification address.

Group-IB reports that if the victim completes the authorization, the attacker-controlled client can receive an access token for the granted permissions, and possibly a refresh token. That is the whole attack. The sign-in is real, the MFA prompt is real, and the token goes to the wrong party. Group-IB adds that this makes the workflow look more trustworthy than conventional credential phishing.

How is the lure built to keep working?

One redirect variable behind the file

Group-IB found that the intermediary page keeps its destination in a single JavaScript variable, targetUrl, and that the destination differs between samples. AegisAI's reading: an operator can point the same attachment at a new phishing host by changing that value, so a flagged host does not mean the lure document is spent. Group-IB's report does not say how often this happens.

Document themes in at least nine languages

Group-IB catalogued filenames in English, Hebrew, German, Portuguese, French, Spanish, Polish, Finnish and Icelandic. Its table shows that not every lure is a PDF: the Finnish and Icelandic examples are Word files.

Six page templates behind one flow

Group-IB documented pages themed as SharePoint, OneDrive, Microsoft Teams, Adobe Acrobat, DocuSign and a generic Microsoft sign-in. Some sit behind human-verification challenges that Group-IB lists as text-based CAPTCHAs, text entry, image selection and press-and-hold controls, all completed on the client side. Group-IB also describes anti-analysis code that blocks browser developer-tool shortcuts. The brand changes. The device code step does not.

How large is the MadApe infrastructure?

155 root domains, 97 with phishing components

Group-IB observed phishing components on 97 of the 155 root domains: on dedicated subdomains only for 33, on URL paths only for 54, and in both places for 10. It found no component on the other 58 during the investigation and treats them as staged infrastructure that had not yet been put to use.

Registration patterns link the domains

Dynadot registered 133 of the 154 domains with a registrar on record, which is 86.4 percent. Separately, 105 of the 152 domains with a full creation timestamp (69 percent) shared that timestamp with at least one other domain. The largest group was ten domains registered on 18 August 2026 at 23:48:21 UTC.

A decoy site and an operator panel

Several root domains serve the same decoy website, branded C2S Logistics, Global Supply Chain Solutions. Group-IB says the decoys are built from the same HTML template. It also found the kit's operator panel, a login page titled Mad Ape with a custom ape logo, on at least five domains. The earliest panel instance it saw was on householdwares[.]co on 19 August 2026.

How can organisations protect Microsoft 365 from device code phishing?

Block the flow where there is no business need

Microsoft's Conditional Access guidance recommends getting as close as possible to a unilateral block on device code flow. It advises auditing existing use first, allowing the flow only for documented, secured cases such as legacy tooling that cannot be updated, and testing the policy in report-only mode before switching it on. Emergency access accounts are excluded from such a policy, and the exclusion list needs regular audit. The setting is the Authentication flows condition, with Device code flow selected and access blocked.

A block is not a clean-up

Group-IB warns that enabling a blocking policy should not be assumed to end existing access at once. For a confirmed compromise it advises revoking sessions and refresh tokens and removing persistence: device registrations, inbox rules and OAuth grants. A password reset alone does not cover those.

Read the sign-in logs for the flow itself

Group-IB advises reviewing Microsoft Entra sign-in logs for unexpected device code authentication and correlating them with phishing link clicks and later mailbox or file activity. Without that correlation, one successful sign-in looks like any other.

Why standard controls miss it

Password-focused defences have nothing to catch. The device code page has no password to harvest, and the final sign-in is on a real Microsoft address, so a reputation check on that destination comes back clean. Staff trained to check the address bar find the right one.

Link scanning is also weaker than it looks. Group-IB's intermediary pages need a click and a short delay before the next page loads, which may stop a scanner limited to the first URL. A verdict on the first link says little about the page a person reaches three steps later.

The flow is not unique to this kit. Threat Watch has covered it in Wazza and SkyW4lker. Group-IB does not compare MadApe's internals with those kits, so the overlap is in the technique, not shown in the code. What stays constant across them is the abuse of the real sign-in, and that is where the message has to be judged.

How AegisAI protects against it

This is AegisAI's own reading, framed for email delivery because Group-IB's analysis starts from emails with an attachment. The reporting does not describe every campaign's delivery.

Aegis does not classify infrastructure. It classifies intent. A lure with no attacker-owned infrastructure still has to ask the recipient to do something on the attacker's behalf, and that request is what gets classified, independent of how clean the destination URL is.

AegisAI's agents evaluate the message and the destination it points to together, and pull a malicious message out of mailboxes before users see or click it. More on how that works: inbound email security.

When a lure or a compromised session is caught, the response compounds: the message is withheld at classification, copies already delivered are retracted, rewritten links refuse a late visit, the account's outbound and internal mail gets rescanned, and lateral phishing attempts to colleagues are blocked at the same bar rather than treated as a fresh, unrelated message.

What the reporting does not tell us

Victim counts. Group-IB gives no number of compromised accounts or organisations. It treats names found in subdomains, paths and lures as intended targets, not confirmed compromises, and says its backend identifiers count records, not victims.

Sending infrastructure. The coverage reviewed for this article describes the attachment, the redirect and the pages, not the sending domains or mail providers. Sender-based detection cannot be built from it.

Attribution. The reporting ties the domains together by shared template, registration pattern and panel. It names no threat actor.

First seen. The Hacker News recap gives a first-observed date of 7 January 2026 that Group-IB's report does not state. Group-IB's earliest panel sighting is 19 August 2026. This article uses neither as a start date.

Indicators published by Group-IB

These come from Group-IB's indicator list and code samples. They are written with [.] so they cannot be clicked. Infrastructure churns, so treat them as historical context and hunting leads, not a live blocklist.

MITRE ATT&CK mapping

This mapping is AegisAI's own reading of the reported behaviour. Group-IB's page lists no technique IDs.

Recommendations for defenders

FAQ

References