Kali365 Toolkit Weaponizes Microsoft Authentication Against US Companies

Kali365 is a device code phishing kit that abuses Microsoft's own authentication flow, and ANY.RUN telemetry records more than 80 public sessions tied to the campaign every week — with the United States as its primary geographic target. (Source: The Hacker News)

The mechanics matter here, because nothing about the login page is fake. The victim sees a lure impersonating a trusted business service — SharePoint, OneDrive, or DocuSign — and is then redirected to Microsoft's real device login portal, where they are asked to enter a code the attacker generated.

ANY.RUN telemetry records more than 80 public sessions linked to Kali365 each week, with the United States emerging as its main geographic target.

When the victim approves that code, Microsoft issues access and refresh tokens to the attacker's session. Those tokens grant continued access to Microsoft 365 email, documents, and cloud resources — meaning the attacker holds working access to your tenant without ever knowing a password.

ANY.RUN's Threat Intelligence Lookup shows the campaign active across manufacturing, technology, healthcare, government, consulting, and MSSPs. That last category is worth noting: a compromised managed service provider account carries access into the environments it administers.

For leadership, the business consequences follow directly from what a mailbox contains and controls:

• Financial fraud — compromised email supports invoice manipulation, payment redirection, and business email compromise.
• Sensitive data exposure — corporate email, internal files, customer information, and confidential documents become readable.
• Operational disruption — unauthorized access to cloud services interferes with daily communications and business processes.
• Compliance and reporting obligations — exposure of regulated or customer data triggers notification duties.

The detection problem is the part that raises response costs. Because the victim authenticates on Microsoft's legitimate page, the sign-in activity can look routine at first, and there are fewer of the obvious phishing indicators your team is trained to spot. That delay gives attackers a longer window to use trusted access before anyone confirms an incident occurred.

Attack Chain: From Initial Access Through Lateral Movement

The pivot point in a Kali365 intrusion is token issuance. Once the victim approves the attacker-supplied device code, Microsoft mints an access token and a refresh token — and those artifacts are delivered to the attacker's device, not the victim's. No credential ever transits attacker infrastructure, which removes the reverse-proxy layer that adversary-in-the-middle kits normally need.

That distinction matters for how this shows up in your environment. MFA is not bypassed or defeated; it is satisfied by the legitimate user, on the legitimate portal, as part of a flow they believe they initiated. The resulting sign-in carries a valid second factor and a compliant authentication record.

Mapped to MITRE ATT&CK, the chain runs roughly as follows:

• T1566 – Phishing: a lure page impersonating a trusted business service brings the target into the flow.
• T1528 – Steal Application Access Token: the device code grant hands the attacker access and refresh tokens tied to a real account.
• T1550.001 – Use Alternate Authentication Material: Application Access Token: the attacker authenticates to Microsoft 365 services with the stolen token rather than a password.
• T1078.004 – Valid Accounts: Cloud Accounts: subsequent activity runs with the victim's legitimate permissions.
• T1114 – Email Collection: mailbox access supports reconnaissance for invoice manipulation and payment fraud.

Persistence comes from the refresh token. Because the grant sits alongside the password rather than depending on it, access continues for as long as that refresh token stays valid — the attacker re-mints access tokens on demand without prompting the user again. For the business, this means an account can remain compromised after the phishing page itself is dead and the original lure URL is offline.

From there, movement is lateral inside the tenant rather than across endpoints. Token-bearing access reaches mail, SharePoint and OneDrive content, and other cloud resources the account can already touch, which is why containment is harder than a straightforward credential theft case: there is no malware on a workstation to quarantine and no anomalous password to reset.

The forensic problem follows directly. The authentication event lands on Microsoft's real endpoint, so the sign-in record looks routine on first review, and detection lag gives the attacker more working time before the incident is confirmed. ANY.RUN's research places the actionable signal earlier in the chain — in the lure page, the redirect path, browser behavior, in-page scripts, and the attacker-controlled hosting infrastructure that fronts the campaign.

Kali365 operators rotate domains, URLs, and hosting infrastructure as campaigns evolve, so indicators pulled from one confirmed case can go stale before they are applied across the rest of the environment.

That rotation cadence sets the shelf life on atomic indicators. Domains and URLs recovered from a single incident are short-lived artifacts; the behavioral pattern — a business-service lure that terminates in a device code prompt — persists across infrastructure changes.

Targeting recorded in ANY.RUN's Threat Intelligence Lookup spans manufacturing, technology, healthcare, government, consulting, and MSSPs. The MSSP presence is worth noting on its own: a provider tenant compromised through an approved device code exposes the administrative relationships that reach downstream client environments, extending a single approved prompt well past the original organization.

Business and Operational Impact for Targeted Sectors

ANY.RUN's Threat Intelligence Lookup data places Kali365 activity across manufacturing, technology, healthcare, government, consulting, and MSSPs. That spread tells you something about the operators' intent: they are not chasing a single vertical, they are chasing mailboxes with signing authority and file shares with client data in them.

Start with the fraud path, because it is the fastest to monetize. Access to a corporate mailbox supports invoice manipulation, payment redirection, and business email compromise — all conducted from a real account, inside real threads, using your own formatting and vendor history.

If your finance team receives updated banking details from an internal address on an existing thread, the usual verification instinct does not fire. The money moves before anyone questions it, and recovery of a completed wire depends on how quickly the receiving bank cooperates.

Data exposure scope is defined by what the compromised identity could already reach. Corporate email, internal files, customer information, and confidential documents are all in play, which means the exposure boundary is your permissions model, not the attacker's skill.

• Healthcare: mailboxes and SharePoint libraries routinely hold patient identifiers and clinical correspondence, putting HIPAA breach notification obligations into scope once unauthorized access is confirmed.
• Consulting and professional services: the exposed files belong to your clients, so a single account compromise becomes a set of client notification conversations.
• Manufacturing: supplier correspondence, pricing, engineering documents, and production schedules sit in the same tenant as the payment approvals.
• Government: records access and constituent data draw oversight attention that extends well past the technical incident.
• MSSPs and technology providers: a compromised account with downstream customer context turns your incident into your customers' incident.

That last case is the supply-chain dimension. If you deliver managed services, your tenant contains privileged context about client environments, and buyers will ask whether their data was in reach — a question you need log evidence to answer, not assurances.

Operational disruption arrives differently than it does with ransomware. There is no encryption event to declare; instead, unauthorized access to cloud services interferes with daily communications and business processes while the account remains apparently functional. Your teams keep working in a tenant someone else is also working in.

Response cost is where this campaign is unusually expensive. The source is direct about why: fewer obvious phishing indicators delay detection and make containment more complex. Because the authentication itself looks routine, confirming what happened means reconstructing sign-in and token activity across the tenant rather than pointing at a malicious attachment.

For your CFO, that translates into forensic hours, outside counsel, and a longer period of billable investigation before anyone can scope the breach. For your legal team, it means the hardest question — what did they actually access — takes days of log review to answer, and notification clocks run during that review.

Regulatory scrutiny compounds it. Sign-in logs are the primary evidence in an identity compromise, so the depth and retention of your authentication telemetry becomes a compliance question as much as a security one. Organizations that cannot produce a defensible access timeline end up notifying more broadly than the facts may have required, because they cannot prove the narrower story.

Reputational exposure follows the notification, not the intrusion. Exposure of regulated or customer data triggers reporting obligations and affects trust with the parties who received the fraudulent mail from your domain. In sectors where clients hand you their sensitive data by contract, that conversation determines renewal decisions.

Detection and Immediate Response Actions

Start with a single query against your Entra ID sign-in logs, because device code authentication is rare in most organizations and easy to isolate. In Microsoft Sentinel or Defender advanced hunting, run:

SigninLogs | where AuthenticationProtocol == "deviceCode" | project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, DeviceDetail, ResultType

Any hit deserves review. The pattern to look for is a sign-in where the user's normal workstation and the IP address issuing the token do not match, or where the geography of the approving user differs from the geography of the resulting session. That mismatch is the clearest artifact this technique leaves behind, and it is the difference between catching the intrusion at hour one and finding it after a fraudulent payment clears.

• Pull AADNonInteractiveUserSignInLogs for the same accounts — refresh token use appears here, not in the interactive log, so a review limited to interactive sign-ins will look clean.
• Query AuditLogs for OperationName has "Consent to application" and "Add app role assignment" to surface OAuth grants added during the same window.
• Check CloudAppEvents for new inbox rules, mass file downloads from SharePoint and OneDrive, and mailbox forwarding changes tied to the same session ID.
• Review Entra ID Protection risk detections for unfamiliarFeatures and anomalousToken against the affected user.

For containment, a password reset alone does not end the session. You need to revoke the refresh token: run Revoke-MgUserSignInSession -UserId This email address is being protected from spambots. You need JavaScript enabled to view it. in Microsoft Graph PowerShell, then reset credentials and re-register MFA methods. Sequence matters — revoke first, because a token that is still valid can be exchanged for a new one after the password changes.

Then close the flow. Create a Conditional Access policy using the authentication flows condition set to block device code flow for all users, with an exception group for the handful of accounts that legitimately need it — shared conference room devices, IoT provisioning, and CLI tooling on headless hosts. Most organizations discover that group is empty. Enable Continuous Access Evaluation in the same policy set so revocation propagates in near real time instead of waiting for token lifetime expiry.

Identity telemetry is where this class of attack becomes visible, and in environments Capstone manages, Adlumin correlates authentication events across Microsoft 365 to flag token use that does not match the user's established device, network, and timing pattern — the anomaly that a valid MFA claim otherwise hides.

For durable controls, three changes carry the most weight. Move privileged and finance-adjacent accounts to phishing-resistant authentication with FIDO2 security keys or Windows Hello for Business, which removes the code-entry step this kit depends on. Enable Conditional Access token protection so tokens are cryptographically bound to a compliant device and cannot be replayed from attacker-controlled hardware. Restrict user consent to applications so a compromised account cannot grant standing API permissions on its own.

Set app registration governance alongside that: limit who can register applications in the tenant, require admin approval with a documented business justification, and schedule a recurring review of existing enterprise applications and their granted scopes. Feed newly observed phishing indicators from your intelligence sources into SIEM, firewall, and SOAR blocklists on an automated schedule, and re-run retrospective searches against the previous 30 days of sign-in data each time a new indicator arrives.

Hardening Microsoft Authentication Against Kali365 and Similar Threats

The single most effective control against this attack class is a Conditional Access policy that blocks the device code authentication flow outright. In Entra ID, create a policy scoped to All users, set the condition under Authentication flows to include device code flow, and set the grant control to Block. Most organizations have no business requirement for it, and blocking it removes the mechanism the kit depends on instead of asking employees to spot a suspicious request.

If you do have legitimate device code consumers — Teams Rooms, shared kiosk hardware, some CLI and PowerShell tooling — exclude a named group containing only those accounts. Keep the group small, document who owns each member, and review it on a fixed schedule so exclusions do not quietly accumulate into a hole big enough to matter.

Next, shorten the useful life of any token that does get issued. Turn on Continuous Access Evaluation so revocation events and policy changes propagate to Exchange Online, SharePoint, and Teams in near real time, and apply a sign-in frequency requirement to administrative roles and finance staff through Conditional Access. Without CAE, a refresh token can keep working after you reset the password, which is exactly the window an attacker uses to set up mail forwarding or move files.

Then close the older paths that sit alongside modern authentication:

• Block legacy authentication protocols (POP, IMAP, SMTP AUTH, and other basic-auth clients) with a Conditional Access policy, since those endpoints do not honor MFA prompts.
• Require MFA on every human account, including contractors, and enforce certificate- or managed-identity-based authentication for service accounts so they are not sitting on static passwords.
• Restrict user consent so employees can only approve apps from verified publishers requesting low-impact permissions, and route everything else through the admin consent workflow.

Audit what already exists in your tenant. Enumerate current OAuth consent grants and service principals, remove apps nobody recognizes or uses, and rotate client secrets and certificates on the ones you keep. Attackers who obtain tokens frequently register or consent to an application to hold access after the original session is revoked, so an unreviewed consent inventory can preserve their entry long after the phishing page is taken down.

Conditional Access rules that require a compliant device only work when endpoint health signals are trustworthy. SentinelOne maintains and reports that endpoint posture across managed environments, so a device-compliance grant control reflects real protection state instead of a stale enrollment record. That pairing means a token approved from unmanaged hardware fails the policy check even when the user's credentials and MFA are valid.

For response, build a short runbook you can execute the moment an approval is confirmed. Revoke active sessions with Revoke-MgUserSignInSession, reset the password, then check for changes the attacker made after entry: new MFA methods, inbox rules, mailbox delegation, forwarding addresses, and new app consents in the affected window.

Finish with the user-side message, kept narrow enough to be memorable. No legitimate Microsoft workflow asks someone to type a code that arrived in an email, chat message, or document link — codes originate on the device the user is signing into. Train finance, executive assistants, and IT staff on that one rule, and give them a reporting channel that reaches your SOC directly.

Key Takeaway and Next Steps

The takeaway is narrower than "phishing is getting better." Kali365 works because most security stacks treat a successful Microsoft sign-in as evidence of a legitimate user, and identity has quietly become the control plane that everything else in your environment defers to. When authentication itself is the attack surface, the question is no longer whether your email gateway caught the lure.

That changes who owns the problem. Cloud authentication configuration usually sits with an M365 or infrastructure administrator, while threat detection sits with security — and neither group holds a complete picture of which authentication flows are enabled, which applications can request tokens, or who approved that arrangement. Your risk lives in that seam.

The source is explicit that this class of activity presents fewer obvious phishing indicators, which delays detection and makes containment more complex. In practice that means higher response costs and, where regulated or customer data is exposed, reporting obligations you did not plan for.

Organizations using ANY.RUN have reported 94% faster threat triage and up to 21 minutes less MTTR per case — time that directly shortens the window for token abuse.

Your first decision is an ownership decision, not a technical one. Name a single accountable person for your Entra ID authentication posture and give them 30 days to produce a written inventory: which authentication flows are permitted, which third-party applications hold token grants, which accounts can consent on the tenant's behalf, and who signs off on changes.

If nobody in your organization can answer those four questions today, that is the finding. Assign the owner, set the date, and review the inventory when it lands.