GhostCode Phishing Kit Bypasses Microsoft 365 MFA to Hijack Accounts in 78 Seconds

GhostCode is a newly identified phishing kit that turns a normal Microsoft 365 sign-in into an account takeover. It does not need to steal a password. Instead, it persuades people to approve a login that gives criminals access to their work account.

The campaign began with ordinary-looking messages submitted through business contact forms. Attackers posed as procurement staff, followed up with a request to sign a non-disclosure agreement, then sent a WeTransfer link holding a password-protected HTML attachment.

The file presented a document-sharing lure and directed the recipient to a Microsoft device-code sign-in. Analysts at eSentire identified the activity in late August and named the kit GhostCode. The name reflects its hidden code and the use of GHOSTnet-linked infrastructure during device enrolment.

eSentire said in a report shared with Cyber Security News (CSN) that the operation used a business-email-compromise style pretext to make the request appear routine.

The risk is immediate because the victim completes authentication, including multi-factor authentication, on a legitimate Microsoft page.

GhostCode then receives the resulting token, sends the victim to a decoy NDA, and begins operating before the victim has reason to suspect a problem. The case underlines why device code phishing campaigns are difficult to spot using familiar password-theft warning signs.

The campaign shows how trust in a familiar identity page, rather than a technical flaw, can become the attacker’s advantage. For cloud-dependent organisations, that distinction turns a routine approval request into a serious account-security event. It can unfold before investigators review the first alert.

GhostCode Phishing Kit Bypasses Microsoft 365 MFA

GhostCode abuses the OAuth device authorization process, which is intended for devices such as smart televisions that cannot easily display a full sign-in screen.

Its server requests a code using the Microsoft Authentication Broker application ID, inserts that code into a polished fake document portal, and asks the target to authenticate it. The user is effectively authorising the attacker’s device.

The attachment makes inspection harder. It is padded with junk data, breaks visible text with HTML comments, and keeps its redirect address encrypted until the correct password is supplied.

After the victim reaches the phishing server, a browser challenge and location checks filter automated scanners. This approach resembles techniques previously documented in the EvilTokens phishing service, but GhostCode combines them with targeted contact-form outreach.

Once the sign-in is approved, the kit uses residential proxy addresses selected to match the victim’s location. That makes the Microsoft prompt less alarming and can weaken location-based alerts.

In the observed intrusion, attackers made nine successful API calls, registered three devices in 78 seconds, and obtained a Primary Refresh Token in 32 seconds. That token can support sign-on across Microsoft 365 services without asking the user to authenticate again.

Containing a Fast-Moving Identity Attack

Speed matters because simply revoking a stolen token may not remove devices already registered in the tenant. The researchers found that enrolled devices remain until administrators explicitly disable or remove them.

Teams responding to suspicious device-code activity should invalidate tokens, reset affected credentials, review newly enrolled devices, and check mail and cloud-access logs for follow-on activity.

The recommended control is to block device-code authentication through Conditional Access for everyone who does not genuinely need it, while allowing tightly defined exceptions for approved service or provisioning workflows.

Organisations should also apply device-compliance controls where suitable. This reduces the number of employees who could be tricked by the same method used in passkey-themed phishing attacks.

Security teams should alert on successful device-code events followed by anomalous scripted requests or several device registrations from one non-interactive session. They should also hunt for device names matching a first-name, last-name, company-domain and hexadecimal suffix pattern.

User awareness remains important: an unexpected request to copy a code into a Microsoft page should be treated as suspicious, particularly as Microsoft 365 session theft campaigns continue to focus on tokens rather than passwords.

Indicators of Compromise (IoCs):-

Type	Indicator	Description
Domain	bjssourcing[.]com	Lookalike sender domain used in the procurement-officer pretext
Domain	greenlightdlstribution[.]com	Related impersonation domain registered during the campaign period
Email address	jeremyarcher@voewo[.]com	Disposable address associated with registration of a related lookalike domain
Domain	voewo[.]com	Domain tied to disposable registration personas
File name	3arhCt9c0p.html	Password-protected HTML attachment used as the document-sharing lure
URL	hxxps://chartered.flipbookonlinevault[.]com/scanna/200e61bfe54c92fb720c77c3a1661bc0/b5ea87c2ddac3aa141bc6794b8993d1e43bd064eaae591719612becea0d106d7	Decrypted relay URL used for tracking, filtering, and redirection
URL path	/scanna/file001//	Additional observed campaign path on the same relay infrastructure
Domain	chartered.flipbookonlinevault[.]com	Relay and bot-filtering infrastructure hosting the encrypted redirect destination
Domain	account-access-rc3uenqi.elitechiropracticandrehab[.]com	Device-code phishing server hosted under a likely compromised site
URL path	/turnstile?return_url=%2F3OnOQubA2bS4o26p3MRXyYV3XuUZ6...	Cloudflare Turnstile path used before serving the phishing portal
API path	/api/harvester?action=geoip	Backend request used to assess victim location and set proxy routing
API path	/api/harvester?action=get_code	Backend request used to obtain a device authorization code
API path	/api/harvester?action=poll	Backend request used to poll for completed device authentication
Application ID	29d9ed98-a469-4536-ade2-f981bc1d605e	Microsoft Authentication Broker application ID abused in the device-code flow
User-Agent	python-requests/2.34.2	Scripted request signature seen during token use and post-authentication activity
IP address	82.33.39[.]74	Residential proxy IP observed during token use
IP address	151.225.227[.]193	Residential proxy IP observed during token use
IP address	176.253.248[.]175	Residential proxy IP observed during token use
IP address	94.9.97[.]142	Residential proxy IP observed during token use
IP address	86.132.13[.]219	Residential proxy IP observed during token use
IP address	81.96.174[.]54	Residential proxy IP observed during token use
IP address	90.215.55[.]70	Residential proxy IP observed during token use
IP address	92.40.47[.]84	Residential proxy IP observed during token use
IP address	5.230.71[.]51	GHOSTnet-associated IP observed during final Intune enrolment
Device ID	4e537622-2514-48b8-84ed-0139549cfab0	First attacker-registered device
Device ID	6c290bcc-62d3-40bd-a774-816109af6729	Second attacker-registered device
Device ID	5e83a216-f67e-43b8-a129-f67666a001dd	Third attacker-registered device, later enrolled in Intune

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC