GeorgeGinx: A Phishing Kit That Hides Device Code Lures Behind Adobe Links

GeorgeGinx sends victims through a genuine Adobe Shared Link before a Microsoft device code sign-in page, so every address in the chain belongs to a company that filters trust and the attacker can potentially gain account access without a password.

Device code phishing is an attack in which the attacker requests a sign-in code from Microsoft and persuades the victim to enter it on Microsoft's genuine device login page, which issues the account's tokens to the attacker's waiting session.

ANY.RUN describes GeorgeGinx as an active phishing-as-a-service operation in its roundup of October 2026 attacks, published on 3 November. The same roundup covers two other kits built on the same sign-in flow: SkyW4lker, which Threat Watch took apart in October, and Mir0Auth, which uses a fake DocuSign page where GeorgeGinx uses Adobe. The kits compete on the lure. GeorgeGinx's lure is a link that nobody has a reason to distrust.

How does GeorgeGinx hide device code phishing behind Adobe links?

ANY.RUN's roundup describes the GeorgeGinx chain in one line: a legitimate Adobe Shared Link that redirects victims to a Microsoft device code phishing page. The steps below combine that description with how the device code flow itself works, as ANY.RUN documents it for an earlier kit and as the OAuth device authorization standard defines it.

1. The attacker's side asks Microsoft for a device code, a short code meant for signing in on devices without a keyboard.
2. The victim receives a link that opens a genuine Adobe Shared Link, an address on Adobe's own domain.
3. Behind that Adobe link, a redirect chain leads on to a Microsoft device code phishing page.
4. The victim enters the code on Microsoft's genuine sign-in page, signs in and completes MFA.
5. Microsoft issues access and refresh tokens to the session that requested the code, which belongs to the attacker.

What ANY.RUN's inspection found behind the link

ANY.RUN says its researchers used In-Browser Data Inspection, a feature of its own sandbox, to examine the HTML DOM activity and the HTTP requests behind the Adobe link, which is how they investigated the redirect chain. Further investigation uncovered an administration panel on an attack server, which ANY.RUN says gave additional insight into the infrastructure. The roundup does not describe what the panel does and publishes no address for it.

How do I protect Microsoft 365 from device code phishing?

Block the device code flow for everyone who does not need it. Microsoft's guidance is to get as close as possible to a unilateral block, to audit existing use first, and to allow the flow only in well documented and secured cases such as legacy tooling that cannot be updated. The Conditional Access policy targets the authentication flows condition, starts in report-only mode and excludes emergency access accounts.

Then watch for the sign-ins that still happen. ANY.RUN's guidance for the sister kit SkyW4lker is to monitor Microsoft Entra ID logs for unexpected device code authentication, and to correlate authentication events with phishing indicators to identify potential account compromise.

What this means for a security team

This section is AegisAI's analysis. For a company on Microsoft 365, the risk is a full mailbox and its files in the hands of someone who never knew the password. In the sectors ANY.RUN names, that mailbox holds payment approvals, patient or customer records and the credentials of other systems, and the usual next steps are invoice fraud and phishing sent from the compromised account to colleagues and partners.

Three questions settle the exposure: do the link policies treat shared-document domains as safe by default, is the device code flow blocked for staff who do not need it, and does the incident playbook revoke sessions and tokens rather than only reset the password.

Why standard controls miss it

This section is AegisAI's analysis. Link controls that judge a destination by its domain reputation have no reason to object to a genuine Adobe address, and many organizations allow shared-document domains because staff use them every day. The sign-in that follows is genuine too: Microsoft's page, the real user, a real MFA prompt. ANY.RUN's own advice from the investigation is to inspect where external links ultimately lead, which is a judgment about the whole chain rather than the first address. ANY.RUN published no GeorgeGinx domains to block, so what remains to judge is the message and the path its link takes.

How AegisAI protects against it

AegisAI has not observed this campaign. ANY.RUN does not say how the Adobe link reaches victims, so the approach below is how AegisAI treats a lure of this shape when the link arrives by email.

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.

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.

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.

See a link like this investigated How inbound protection works

How AegisAI stops credential phishing, 48 seconds

Recommendations for defenders

• Create a Conditional Access policy that blocks the device code flow for all users, audit existing use first, run it in report-only mode, and keep named exceptions for emergency access accounts and documented legacy tooling.
• Stop treating shared-document domains as safe by default: judge a shared link by where it ultimately leads, not by the domain it starts on.
• Alert on device code sign-ins in Microsoft Entra ID logs, and treat one that follows an emailed document-sharing request as a likely compromise.
• In the incident playbook, revoke sessions and refresh tokens, then review mailbox rules and app consents; a password reset alone does not end token-based access.
• Tell staff that no real document share asks them to type a code into a Microsoft sign-in page, and give them one way to report it.

FAQ