IntelliOSPANDAModule|AITool / Campaign Snapshot

Kali365

A Deeper Look at the PhaaS Platform

Campaign snapshotOAuth tokensPhishing platform

Published

21-Jun-2026

Brief Version

v1.0

Updated

0x via AI Monitoring Agents

Next AI Monitor

Pending AI monitoring agent assignment

Brief ID

PANDA-CTAS-KALI365-2026-001

Template

Campaign, Tool or Actor Snapshot Template v1.0

Research Framing

Field

Value

User Topic

Kali365 Microsoft 365 OAuth device-code Phishing-as-a-Service actor, tool, and campaign snapshot.

One-Sentence Description

Kali365 is an emerging Microsoft 365 phishing-as-a-service platform that packages OAuth device-code abuse, token capture, and MFA-bypass risk into a lower-friction criminal service.

Source Coverage

Tier	Checked	Useful Hits	Used	Not Used
Tier 0 - Most Trusted	3	3	3	0
Tier 1 - Authoritative	4	4	4	0
Tier 2 - High-Value Research	2	2	2	0
Tier 3 - Corroborating News	2	1	1	1
Tier 4 - Community Signal	0	0	0	0
Tier 5 - Custom Source (defined by user)	0	0	0	0
Tier 6 - Custom Integrations with API/Keys	1	0	0	1
Tier 7 - Inner Discovery / Carved URLs	0	0	0	0
Tier 8 - Expansion Research	8	8	8	0
Total	20	18	18	2

Kali365 Campaign / Tool Snapshot

Field	Snapshot Value
Type	Phishing-as-a-Service platform / tool ecosystem
Status	Emerging, publicly warned by IC3; not a single named threat actor group or one campaign.
First Seen	IC3 states Kali365 was first observed in April 2026. ¹
Distribution	Reported primarily through Telegram-linked subscription or panel access and attacker-facing infrastructure; this page intentionally avoids seller handles, channel names, payment instructions, panel URLs, and acquisition details. ^{1, 4, 16, 17}
Core Capability	Device-code lures, OAuth/access-token capture, Microsoft 365 account access, AI lures, templates, dashboards, and automation. ^{1, 4, 15, 16, 17}
Who Built / Runs It	Unknown from the public sources used here. IC3 and retained public reporting describe Kali365 as a PhaaS platform or service ecosystem, but they do not identify a confirmed developer, administrator, operator identity, real-world person, company, or named threat group behind it. ^{1, 15, 16, 17}
Kali Linux Affiliation	No source used in this snapshot establishes any affiliation between Kali365 and Kali Linux, Offensive Security, or the Kali Linux penetration-testing distribution. Treat the shared word "Kali" as a name-collision risk, not evidence of connection. ^{1, 23}
Known Victims	No named victim organizations are published in this snapshot. Victimology remains category-level: Microsoft 365 users and organizations.
Campaign vs Tool	Kali365 is best treated as a tool/service platform sold to or used by multiple criminal operators, not as the exclusive name of one intrusion campaign or one attributed actor.
Likely User Ecosystem	Public sources do not identify specific users, but the service model fits lower-to-mid level operators, BEC crews, initial-access brokers, and cybercriminals seeking Microsoft 365 account access.
Attribution Boundary	The sources used here do not attribute Kali365 exclusively to FIN7, Scattered Spider, a Microsoft Storm cluster, or any other named threat group.

1-Topic

This snapshot profiles Kali365 as a Microsoft 365-focused phishing-as-a-service ecosystem that packages OAuth device-code abuse, token capture, lures, templates, dashboards, and campaign tooling for criminal operators. ^{1, 4, 15, 16, 17}

The core defensive question is whether a user was induced to enter an attacker-supplied code into Microsoft's legitimate verification flow, producing token/session or OAuth artifacts that can survive ordinary password-reset playbooks. ^{1, 5, 6, 18}

Treat the page as a tool/campaign profile, not as a victim list or actor attribution claim. Public sources used here do not identify a confirmed operator identity, named victim organizations, complete panel inventory, acquisition path, or stable Kali365 IOC set.

2-Persona / Audience Lens

Audience	What This Snapshot Should Help Them Do	Best Use
Executives / Risk Leaders	Understand why Kali365 is primarily a Microsoft 365 account-takeover and BEC-investigation risk, not simply another phishing email.	Decide whether to brief users, fund scoping, and prioritize identity controls.
SOC / IR Teams	Identify device-code abuse, preserve evidence, hunt token/session activity, and scope Microsoft 365 resource access in BEC or cloud-account-takeover investigations.	Run investigation and containment without relying on password reset alone.
IAM / M365 Administrators	Translate the threat into Entra ID, OAuth consent, Conditional Access, session, and application-governance controls.	Tighten authentication-flow policy and revoke suspicious access artifacts.
Counsel / Claims / Client Advisors	Frame Kali365 primarily as BEC-adjacent Microsoft 365 account takeover and cloud-data exposure; ransomware is a downstream or larger-incident question only when local evidence supports it.	Support scoping calls, privilege-aware communications, and client triage.

3-BLUF

Kali365 is best treated as a PhaaS platform/tool ecosystem, not a single named threat actor group or one campaign. ^{1, 15, 16, 17}
Its significance is the packaging of Microsoft 365 OAuth device-code abuse into a subscription-style service with lures, templates, dashboards, and automation. ^{1, 4, 15, 16}
The attacker abuses trust in Microsoft's legitimate verification flow by supplying the code and controlling the authorization context. ^{1, 5, 18}
Defense requires token/session revocation, OAuth consent review, Conditional Access controls, and post-authentication Microsoft 365 access scoping; password reset alone is not enough. ^{1, 6, 12, 18}

4-Executive Summary

Kali365 is a Microsoft 365-focused phishing-as-a-service platform that abuses OAuth device-code authorization to obtain access-token material and bypass normal MFA expectations. Public sources support treating it as a tool/service ecosystem used by multiple criminal users, not as one named threat actor, intrusion set, or campaign. ^{1, 15, 16, 17}

The mechanism is what makes Kali365 different from older fake-login kits. The victim may be sent to Microsoft's real verification page and asked to enter a code that originated from the attacker's workflow. The attacker's objective is authorization and token access, not just a copied password. ^{1, 5, 18}

That design changes the scoping problem. A user can honestly say they used a real Microsoft page and still have participated in an attacker-controlled authorization flow. Responders need to investigate Entra ID sign-ins, device-code events, token issuance, OAuth consent grants, active sessions, mailbox/file access, Teams activity, and Graph/API activity after the suspected authorization. ^{1, 2, 18}

Treat this as an identity incident if users report unsolicited device-code prompts or suspicious cloud-document lures. A password reset can be part of cleanup, but reliable containment requires token/session revocation, sign-out or forced reauthentication, OAuth consent and enterprise app review, Conditional Access assessment, and Microsoft 365 resource-access scoping. ^{1, 6, 12, 18}

Expansion Research Add

Expansion research adds why Kali365 is generating attention: panelized infrastructure, templates, API endpoints, billing/subscription features, and affiliate-style operations make a known technique easier to run and scale. That is different from proving named victims, exact operator identity, or a complete marketplace map. ^{15, 16, 17}

5-AI Agent Delta Updates

Update Time	Agent / Monitor	Delta Type	Evidence / Change	Action Required
Initial publication	No AI delta monitor attached	Baseline v1.0	No post-publication delta has been applied yet. This row reserves the snapshot for future AI-agent monitoring updates.	None yet

This card is intentionally present as a placeholder. When a PANDA AI agent is attached to monitor Kali365 updates, source changes, new indicators, victimology, infrastructure shifts, or official corrections should be recorded here before the snapshot is republished.

6-Why It Matters

7-Timeline

Date / Period	Event	Source-Backed Meaning
April 2026	IC3 says Kali365 was first observed.	Establishes Kali365 as an emerging named PhaaS platform. ¹
May 21, 2026	IC3 publishes the Kali365 PSA.	Authoritative public-warning anchor. ¹
June 2026	Expansion research describes Kali365 panels, templates, infrastructure, and ecosystem features.	Adds technical and operational texture beyond the PSA. ^{15, 16, 17, 18}

8-How The Tool Works

This card explains the reported Kali365 service lifecycle for defensive scoping. It intentionally avoids seller handles, acquisition instructions, payment steps, panel URLs, and operational details that would help someone obtain or run the tool.

Kali365 Attack Snapshot

Kali365 attack lifecycle from Telegram-linked discovery through subscriber setup, target selection, device-code request, lure generation, delivery, authorization, token capture, resource access, and panel tracking.

Step	Reported Tool / Operator Activity	What Defenders / Scopers Should Ask
0. Discovery / Access	Public reporting indicates a threat actor can encounter Kali365 through Telegram-linked promotion and then use subscription or panel-style access to operate attacker-facing infrastructure. This page does not provide acquisition instructions. ^{1, 4, 16, 17}	Ask whether any internal investigation has found Telegram, marketplace, panel, or infrastructure references, but do not publish handles or acquisition paths.
1. Subscriber Setup	The service is described as packaging AI-generated lures, templates, tracking dashboards, OAuth token capture, and campaign management for lower-skill operators. ^{1, 4, 15, 16, 17}	Frame Kali365 as a rented service ecosystem, not necessarily a single actor or one intrusion campaign.
2. Target Selection	A subscriber selects Microsoft 365 users or organizations and prepares a cloud/document-themed pretext.	Collect target list context from the client: affected users, roles, mailboxes, executives, finance teams, administrators, or exposed shared mailboxes.
3. Device-Code Request	The threat actor or rented Kali365 panel initiates a fresh legitimate OAuth 2.0 device-code request to Microsoft's `/devicecode` endpoint and obtains a short user code plus backend device code tied to Microsoft's real verification process. ^{5, 18}	Hunt Entra ID for device-code or device-authorization events around the user-report timeline.
4. Lure Generation	The panelized workflow reportedly supports generated lures and templates that can make the device-code request look like a normal document, cloud, or business workflow. ^{1, 4, 15}	Preserve the email or message, headers, screenshots, link text, code, sender, recipient, and delivery time.
5. Delivery	The target receives a phishing message containing an attacker-supplied device code and instructions to use Microsoft's real verification page.	Ask whether the user entered the code, whether MFA was completed, and exactly when the interaction occurred; device codes are short-lived, so timing matters.
6. Authorization	The victim may authenticate on a real Microsoft page and authorize the attacker-initiated flow, making the event look more legitimate than a fake-login-page phish. ^{1, 5, 18}	Review sign-in logs, authentication-flow evidence, client/application identifiers, user context, and conditional access outcomes.
7. Token Capture	The attacker-side workflow polls Microsoft's OAuth 2.0 `/token` endpoint with the backend device code; after victim authorization, it can receive OAuth access/refresh-token material for Microsoft 365 access. ^{1, 5, 18}	Revoke suspicious sessions/tokens, inspect refresh behavior, and do not rely on password reset alone.
8. Resource Access	Token-backed access may be used against mail, files, Teams, Graph/API, or other Microsoft 365 resources depending on permissions and session state.	Scope Exchange, SharePoint, OneDrive, Teams, Graph/API, mailbox rules, forwarding, downloads, deletions, and suspicious outbound messages.
9. Panel Tracking / Follow-On	Expansion research describes dashboards, templates, API endpoints, billing or subscription functions, and post-compromise tooling as part of the broader Kali365 ecosystem. ^{15, 16, 17}	Treat the incident as potential account takeover/BEC exposure and preserve evidence before containment changes.

OAuth 2.0 Element	Legitimate Flow	Kali365-Style Abuse / Defensive Meaning
Requesting device / client	A real device or app asks Microsoft for a code so a user can authorize it.	The “device” can be an attacker-controlled software client, backend, or panel session. The victim is not authorizing the attacker’s physical laptop; they are authorizing the attacker-controlled client/session.
`/devicecode`	Microsoft returns a short user code, backend device code, verification URL, and expiration window.	The panel supplies the short user code and real Microsoft verification URL to the victim in a lure. The code is fresh and legitimate, not guessed or reused.
Microsoft verification page	The user enters the code on Microsoft’s real page and completes normal sign-in and MFA.	The page can be legitimate while the authorization context is attacker-controlled. “Real Microsoft page” does not equal “safe request.”
`/token`	The requesting client polls Microsoft until the user authorizes or the request expires.	After authorization, Microsoft returns OAuth access/refresh-token material to the requester. Responders should revoke sessions/tokens and review OAuth grants, not stop at password reset.

Microsoft device-code authorization is legitimate: a device or client requests a user code and device code, the user enters the code on a real Microsoft verification page, and Microsoft issues tokens to the requesting client after authorization. Kali365-style abuse reverses the trust relationship. The attacker-controlled “device” is best understood as a software client, backend, or panel session that creates the fresh Microsoft authorization request first, sends the victim the attacker-supplied user code, and receives OAuth token material if the victim signs in and approves the flow. The attacker is stealing session/token access, not necessarily the password itself. ^{5, 6, 18}

9-Term Glossary

Term	Meaning In This Snapshot	Why It Matters
PhaaS	Phishing-as-a-Service: a criminal service model that packages phishing infrastructure, templates, dashboards, delivery support, or automation for other operators.	Frames Kali365 as a service ecosystem, not only a single phishing email.
Device-code flow	A legitimate OAuth flow where a user enters a short code on a verification page so a requesting device or client can receive tokens. ⁵	The legitimate flow is what Kali365-style activity abuses.
OAuth token	An access artifact issued after authorization that can allow Microsoft 365 API, mailbox, file, or app access depending on scopes and session state.	Explains why password reset alone may not contain the event.
Refresh token	A token used to obtain new access tokens without re-entering the password during an active session or policy-valid state.	Supports longer-lived account access if not revoked.
AiTM	Adversary-in-the-middle phishing that proxies authentication and can steal session material.	Useful adjacent comparison, but not identical to device-code abuse.
Conditional Access authentication flows	Microsoft controls that can govern authentication-flow behavior, including device-code flow conditions. ⁶	Relevant prevention and reauthentication control surface.

10-TTPs

TTP	MITRE	Tactic	Detail
Phishing lure with device-code instructions	T1566	Initial Access	Cloud/document-themed lure gives the victim an attacker-supplied code and sends them to a legitimate Microsoft verification page. ^{1, 3, 11}
OAuth/access-token capture	T1528	Credential Access	The attacker seeks Microsoft 365 token/session access rather than only a password. ^{1, 2, 12}
Valid account/session use	T1078	Initial Access / Persistence	Post-authorization access may resemble ordinary user activity unless correlated with token, app, and resource-access telemetry. ^{1, 14}

13-IOCs / Observables

This section is limited to field identification and hunting leads for Kali365-style device-code abuse. The key question is whether an unsolicited lure led a user into a Microsoft device-code authorization flow, followed by suspicious OAuth token, session, consent, or Microsoft 365 resource activity.

How To Identify This Attack

User reports an unsolicited code, document-sharing lure, or instruction to visit a Microsoft verification page.
Entra ID shows device-code or unusual authentication-flow activity around the user report.
Unexpected OAuth consent, enterprise app, delegated permission, or refresh-token/session behavior appears.
Mailbox, SharePoint, OneDrive, Teams, or Graph/API activity follows the suspected authorization event.

Primary Evidence To Preserve

User report, lure text, screenshots, message headers, and delivery timeline.
Entra sign-in logs, authentication-flow fields, token issuance, and risk events.
Unified Audit Log, mailbox audit logs, app-consent history, and enterprise app changes.

Artifact	What To Look For	Why It Matters
User report	Unexpected code, urgent document/cloud lure, or request to visit Microsoft verification page.	Establishes exposure and timing before logs are cleaned up.
Entra ID sign-in logs	Device-code / device-authorization flow, unusual client/app, unfamiliar location, high-risk user activity.	Primary identity evidence for Kali365-style abuse.
Token and session state	Access/refresh token issuance, unusual refresh behavior, active sessions that persist after the user report.	Password reset alone may not evict active token/session access.
OAuth consent / enterprise app	Unexpected app consent grants, new enterprise apps, unusual scopes, delegated permissions.	Confirms whether authorization created durable access paths.
M365 resource access	Exchange, SharePoint, OneDrive, Teams, Graph/API access following suspicious authorization.	Separates account exposure from confirmed data or business impact.

No stable Kali365 blocklist set is published here. This snapshot does not publish specific Kali365 domains, IP addresses, hashes, OAuth client IDs, Telegram handles, or victim names. Treat the rows above as behavioral observables and scoping leads, not complete IOCs.

Containment Control Effectiveness

Action	Effect Against Device-Code / Kali365-Style	Effect Against AiTM / Reverse-Proxy	Operational Note
Password reset	Low. The attacker may not have stolen the password; token or session material can remain valid.	Low to medium. Useful if credentials were captured, but stolen sessions may remain active.	Do not stop here.
Revoke active sessions/tokens	High. Directly targets the OAuth/session artifact used for continued access.	High. Helps invalidate stolen session material and force renewed authentication.	Priority action.
Sign out everywhere / force reauthentication	High. Forces the user and suspicious sessions through fresh policy evaluation.	High. Reduces the window for reused stolen sessions.	Pair with review.
Revoke suspicious OAuth consents and app grants	High where consent/grant artifacts exist.	High where app grants or delegated access were abused.	Collect evidence first.
Conditional Access + phishing-resistant MFA	High as prevention and reauthentication control.	High, especially against replayable MFA and session-theft paths.	Tune by tenant.

Bottom line for responders: a password reset can be part of cleanup, but it is not reliable containment for device-code token theft or AiTM session theft. The response must include token/session revocation, sign-out or forced reauthentication, OAuth consent review, and post-authentication access scoping. ^{1, 5, 6, 12, 14, 18, 22}

14-Threat Actor Glossary

Name / Label	Classification	How To Use The Label	Boundary
Kali365	PhaaS platform / tool ecosystem	Use when discussing the source-backed service model, device-code/OAuth abuse path, AI lures, templates, dashboards, and Microsoft 365 token-access risk. ^{1, 4, 15, 16, 17}	Not a confirmed single actor group.
Kali365 operators / subscribers	Criminal users of the service	Use for the likely users running campaigns from or around the platform.	Public sources do not identify a definitive customer list.
Device-code phishing operators	Technique-based grouping	Use when evidence supports OAuth device-code abuse but not the Kali365 brand specifically. ^{1, 2, 5, 18}	Do not over-attribute tenant logs to Kali365.
Kali Linux	Unrelated legitimate Linux distribution	Use only to avoid brand confusion; no retained source establishes affiliation with Kali365. ^{1, 23}	Not a threat actor label here.

17-Exploitable Technology Risks

Risk Area	Why It Is Exploitable	Control / Scoping Priority
Device-code authorization	Attackers can initiate a legitimate device-code flow and pressure a user to enter the supplied code on Microsoft's real verification page. ^{1, 5, 18}	Review authentication-flow policy, risky sign-ins, user reports, and device-code events.
OAuth consent and app grants	Unexpected delegated permissions or enterprise app grants can create durable cloud-access paths beyond a simple password.	Audit consent grants, enterprise apps, delegated permissions, and admin-consent workflow settings.
Token and session persistence	Token/session artifacts can remain useful after a password reset unless sessions and suspicious grants are revoked. ^{1, 6, 12, 18}	Revoke sessions/tokens, sign out affected users, force reauthentication, and scope post-authentication access.
Microsoft 365 workload access	Mailbox, file, Teams, SharePoint, OneDrive, and Graph/API activity can follow authorization and may look like normal user activity.	Correlate Entra ID, Unified Audit Log, Exchange, SharePoint, OneDrive, Teams, and Graph/API evidence.

18-Social Media / Community Signals

Signal Type	Status In This Snapshot	Use / Boundary
Telegram-linked distribution	Retained as source-backed distribution context from official and vendor reporting. ^{1, 4, 16, 17}	Do not publish seller handles, channel names, payment details, invite links, or acquisition steps.
X / LinkedIn / Reddit / forum chatter	No social-community claims are promoted as findings in this static snapshot.	Treat future social posts as leads only until tied to reliable public reporting or local evidence.
Operator marketing claims	Not promoted as fact without independent corroboration.	Do not use claimed pricing, scale, customer count, or victim lists unless independently validated.

16-Decision Ready Actions

Priority	Response Action	Likely Owner	Evidence Boundary
1	Preserve user reports, phishing messages, screenshots, headers, and identity logs before cleanup.	SOC / IR	Needed to distinguish exposure, authorization, access, and impact.
2	Review Entra ID sign-ins for device-code flow, token issuance, unusual clients, high-risk users, and unexpected OAuth consent.	IAM / SOC	Core evidence for Kali365-style abuse.
3	Revoke suspicious sessions/tokens, remove unauthorized OAuth grants, sign out affected users, and force reauthentication. A password reset can be part of cleanup, but it is not reliable containment by itself. ^{1, 5, 6, 12, 14, 18, 22}	IAM	Containment requires invalidating access artifacts, not only passwords.
4	Scope Exchange, SharePoint, OneDrive, Teams, and Graph/API access after the suspicious authorization.	IR / M365 Admin	Confirms or refutes mailbox/file/data access and BEC/fraud risk.
5	Tune Conditional Access authentication-flow controls and user consent governance: block or challenge device-code flows from untrusted locations, require phishing-resistant MFA for sensitive users, and limit device-code use to justified clients or compliant devices where feasible.	IAM / Security Engineering	Microsoft documents authentication-flow controls relevant to device-code risk. ⁶

12-CVE / Vulnerability References

Question	Snapshot Answer	How To Use It
Is Kali365 a CVE?	No. Kali365 is a reported PhaaS/tool ecosystem and Microsoft 365 identity-abuse workflow, not a software vulnerability identifier.	Avoid presenting this as a patch-management issue.
Is device-code authorization vulnerable?	The OAuth device-code flow is legitimate Microsoft identity-platform functionality. The risk here is attacker misuse of a real authorization flow, not proof that Microsoft's documented flow is itself a CVE. ^{5, 6}	Focus on policy, detection, consent, token/session revocation, and user training.
Is there a KEV entry?	No KEV-listed vulnerability is part of this snapshot’s source-backed Kali365 finding.	Do not use CISA KEV status as the primary triage filter for this identity threat.

22-Real World Examples

Example / Finding	What Public Sources Support	Victim / Company Boundary	Scoping Value
Kali365 in the wild	IC3 identifies Kali365 as an emerging Microsoft 365 PhaaS first observed in April 2026, distributed primarily through Telegram, and capable of OAuth token capture, MFA bypass, persistent Microsoft 365 access, AI-generated lures, templates, and dashboards. ¹	No named victim companies are published in the source set used for this snapshot.	Treat the exposed population as Microsoft 365 users and organizations until local telemetry proves impact.
Real device-code abuse	Arctic Wolf and expansion research support real-world device-code phishing outcomes: token capture, mailbox access, malicious inbox rules, and post-authentication abuse patterns that defenders can hunt in Microsoft 365 telemetry. ^{2, 15, 17, 18}	Technique-level victimology does not equal a named Kali365 victim list.	Ask whether the user entered an unsolicited code, whether device-code authentication occurred, and what resources were accessed afterward.
Kali365 operating ecosystem	Expansion research describes panelized infrastructure, lure templates, API endpoints, billing, domain/infrastructure functions, and post-compromise tooling, making Kali365 look like a managed criminal service rather than a one-off lure. ^{15, 16, 17}	Do not publish seller handles, acquisition steps, panel URLs, or unverified victim identities.	Use this to explain why a low-skill operator may still generate polished lures and persistent access.
Known unknowns	Public sources used here do not provide a validated Kali365 customer list, confirmed operator identity, full victim list, reusable IOCs, OAuth client IDs, or a complete campaign count.	Absence of public names is not proof that no victims exist.	Local logs, affected-user interviews, Microsoft 365 audit data, and vendor/law-enforcement coordination determine actual exposure.

Bottom line: public reporting supports real-world Kali365 use and device-code phishing impact, but it does not support publishing named Kali365 victim companies from this source set. Any victim-specific statement should come from the client environment, a validated lookup, law-enforcement notice, or a source that explicitly names the affected organization.

23-Public Victims / Disclosure Matrix

No named Kali365 victim organization is promoted from this source set. The table separates source-backed population risk from unsupported victim naming, so the page stays useful without turning unverified claims into a victim list.

Victim / Population	Confirmed?	Reported / Disclosed By	Boundary
Microsoft 365 users and organizations	Category-level exposure	IC3 and corroborating public reporting describe Kali365 as targeting Microsoft 365 accounts and organizations through device-code/OAuth abuse. ^{1, 2, 3, 4}	This is not a named victim list.
Any locally affected tenant	Requires local confirmation	Client telemetry, user interviews, Entra ID logs, app-consent records, and Microsoft 365 workload evidence.	Name only if the organization publicly self-discloses or authorizes disclosure.
Named public victim organizations	Not populated	No reliable retained source names a specific Kali365 victim organization in this snapshot.	Do not promote forum claims, screenshots, leaked credentials, or operator marketing into confirmed victim rows.

24-KEV and CVE Details

Field	Current Assessment	Action
CVE	No CVE is associated with the Kali365 platform finding in this static snapshot.	Do not route this as a patch-only issue.
CISA KEV	No KEV item drives this Kali365 assessment.	Use identity controls and cloud-account scoping instead of KEV triage.
Identity control plane	The relevant public documentation is Microsoft's OAuth device-code flow and Conditional Access authentication-flow guidance. ^{5, 6}	Review whether device-code flow is allowed and under what conditions.

25-MITRE ATT&CK Lifecycle Mapping

Lifecycle Phase	Kali365-Relevant Behavior	MITRE Mapping	Evidence To Seek
Delivery / Initial Access	Lure delivers an attacker-supplied Microsoft device code or instructions. ^{1, 3, 11}	T1566	Message artifacts, headers, code, sender, target, delivery time.
Authorization	Victim enters code on a legitimate Microsoft verification page, authorizing the attacker-controlled requester. ^{1, 5, 18}	T1528	Device-code sign-in, token issuance, app/client identifiers.
Access / Persistence	Token/session-backed Microsoft 365 activity may continue until sessions and grants are revoked.	T1078	Session state, OAuth grants, mailbox/file/API activity.
Collection / Fraud Enablement	Mailbox, file, Teams, Graph/API, internal phishing, or BEC-style activity may follow.	Tenant-specific	Unified Audit Log, Exchange, SharePoint, OneDrive, Teams, Graph/API, outbound messages.

11-Common Questions Q&A

Common Question	Answer	Scoping / Defensive Use
If Microsoft device codes are short-lived, does the attack self-sabotage when a user waits hours or days?	Yes, stale codes can fail. That does not neutralize the attack model; it pushes operators toward urgency, repeated lures, automation, and real-time or near-real-time campaign workflows. Microsoft documents that device-code flow depends on polling, expiration, and token issuance after user authorization. ^{5, 18}	Ask when the user received the lure, when they entered the code, and whether any device-code sign-in or token issuance occurred during the valid window.
How can this work if the user only entered the code on a real Microsoft page?	The page can be legitimate while the authorization context is attacker-controlled. The attacker or panel generates a fresh legitimate Microsoft device-code request, supplies that user code to the victim, and receives token material if the victim completes sign-in and MFA for the attacker-initiated flow. ^{1, 5, 18}	Do not clear the incident just because the URL was Microsoft. Validate the code origin, device-code event, token/session state, and resource access.
Is a password reset enough?	No. A password reset can be part of cleanup, but it is not reliable containment when the attacker has token/session material or unauthorized OAuth grants. ^{1, 6, 12, 18}	Revoke sessions/tokens, remove suspicious OAuth grants, sign out affected users, force reauthentication, and scope post-authentication access.
Can we tell from logs that an event was specifically Kali365?	Usually not from basic tenant logs alone. Logs can support device-code phishing, token issuance, consent, session, and Microsoft 365 access patterns; attribution to Kali365 requires source-backed artifacts, panel/infrastructure evidence, or trusted third-party validation.	Classify the incident by mechanism first. Avoid naming Kali365 unless the evidence supports the platform label.
Are named Kali365 victim companies public?	No named victim organizations are published in this snapshot’s source set. The supported victimology is category-level: Microsoft 365 users and organizations. ^{1, 2, 15, 17}	Use local telemetry, client interviews, validated lookup/notification channels, and law-enforcement or vendor notices for victim-specific conclusions.
Is Kali365 connected to Kali Linux?	No source used here establishes an affiliation between Kali365 and Kali Linux or Offensive Security. Treat the shared word “Kali” as a naming collision unless an authoritative source says otherwise. ^{1, 23}	Avoid brand confusion in client-facing language.
Is this a ransomware threat?	Kali365 is best framed as Microsoft 365 account-takeover, BEC-adjacent, and cloud-data-exposure risk. Ransomware is a downstream possibility only if local telemetry shows broader intrusion or deployment activity.	Separate lure exposure, authorization, cloud access, data exposure, fraud, and broader intrusion into distinct findings.

Expansion Research Add

The most useful Q&A framing is mechanism-first: short-lived codes affect attacker timing, legitimate Microsoft pages do not prove safety, password resets are not complete containment, and platform attribution should not outrun tenant evidence.

15-Talking Points

Technical Audience	Talking Point	Evidence / Action Focus
SOC / Detection	Treat unsolicited device-code prompts as potential account-access events, not just phishing noise. The decisive evidence is the chain from lure report to device-code sign-in, token/session activity, OAuth consent, and Microsoft 365 resource access.	Correlate user reports, Entra ID sign-ins, audit logs, Exchange, SharePoint, OneDrive, Teams, and Graph/API activity.
IAM / Entra Admins	The control question is whether device-code authentication is needed in the tenant and, if so, which users, clients, locations, and risk states should be allowed. Microsoft documents Conditional Access controls for authentication flows. ⁶	Review Conditional Access authentication-flow policies, user consent settings, admin consent workflows, high-risk accounts, and token/session revocation procedures.
M365 Admins	A successful device-code abuse event may look like legitimate cloud activity after authorization. Do not stop at sign-in review; scope mailbox, file, Teams, and API activity after the suspicious event.	Check mailbox access, inbox/forwarding rules, SharePoint/OneDrive downloads or sharing, Teams/internal messaging, and Graph/API access.
IR / DFIR	Preserve evidence before containment changes. Password reset alone is not reliable containment if token, session, or OAuth grant artifacts remain valid. ^{1, 6, 12, 18}	Export relevant sign-in, audit, consent, session, mailbox, file, and user-report evidence; then revoke sessions/tokens and unauthorized grants.
Threat Intel	Classify by mechanism before brand. Device-code/OAuth abuse, AiTM/session theft, and classic credential-harvesting PhaaS create different telemetry and should not be collapsed into one bucket.	Use Kali365 for device-code/OAuth PhaaS context; compare EvilProxy/Tycoon-style activity as AiTM/session-interception context only when supported.
Scopers / Counsel Support	Separate exposure stages: lure received, code entered, authorization completed, token/session issued, Microsoft 365 resource accessed, data or fraud impact confirmed.	Build the timeline from user interview, message artifacts, Entra logs, app consent, token/session records, and workload logs.

Expansion Research Add

Technical teams should resist the shortcut of asking only whether the user clicked a fake-login link. For Kali365-style scoping, the better question is whether an attacker-supplied code produced a Microsoft 365 authorization, token/session artifact, or post-authentication access path.

21-About the Contributors

Contributor	Who They Are / What They Do	Contribution & Why It Matters Here	Sources
FBI / IC3	U.S. cybercrime public-warning and complaint center.	Primary public-warning authority for Kali365, first-observed timing, Microsoft 365 OAuth token-capture framing, Telegram distribution, AI lures, dashboards, and MFA-bypass risk.	¹
Microsoft	Microsoft 365 and Entra identity platform owner.	Explains the legitimate OAuth device-code flow and Conditional Access authentication-flow controls that defenders need to understand and govern this attack path.	^{5, 6}
Arctic Wolf	Security operations and incident-response provider.	Practitioner reporting that adds real-world device-code phishing impact patterns, including token capture, mailbox access, malicious inbox rules, and Microsoft 365 account-takeover implications.	²
Bitdefender / BleepingComputer	Security vendor and independent cybersecurity news outlet.	Corroborate the IC3 warning and translate the Kali365 service model, subscription-style tooling, AI lures, templates, dashboards, and device-code mechanics for broad security audiences.	^{3, 4}
Huntress / Todyl / SpyCloud / cside	Threat research, MDR, cyber intelligence, and web security organizations.	Expansion research on Kali365 panelized infrastructure, templates, API endpoints, billing/subscription functions, domain or lure infrastructure, observed authentication activity, and post-compromise tooling.	^{15, 16, 17, 18}
MITRE ATT&CK / Kali Linux Project	Industry behavior framework and official Kali Linux project source.	MITRE provides common language for phishing, token theft, and valid-account behavior. Kali Linux is included only to clarify there is no sourced affiliation between Kali365 and the legitimate Kali Linux distribution.	^{11, 12, 14, 23}

26-Source Weighting / Relevance

Source Group	Contribution To This Snapshot	Confidence	Caveat
Official / Authoritative	IC3 establishes the Kali365 warning, first-observed timing, Microsoft 365 OAuth/token-capture framing, Telegram distribution, AI lures, templates, dashboards, and MFA-bypass risk. Microsoft explains the legitimate device-code flow and Conditional Access control plane. ^{1, 5, 6}	High	Official sources do not provide a full marketplace map, named victim list, complete panel inventory, or reusable IOCs.
Vendor / Practitioner	Arctic Wolf, Bitdefender, Huntress, Todyl, SpyCloud, and cside add campaign observations, feature context, panel/infrastructure descriptions, victimology boundaries, and Kali365-specific defensive context. ^{2, 4, 15, 16, 17, 18}	Medium-High	Separate observed telemetry and source-backed analysis from operator marketing claims, affiliate claims, and unverified pricing or scale statements.
Security Media	BleepingComputer corroborates and translates the FBI/IC3 warning for broad security audiences. ³	Medium	Useful for awareness and corroboration, but secondary to official and practitioner sources for technical detail.
Framework / Definitions	MITRE ATT&CK supplies behavior mapping for phishing, token theft, and valid-account use. Kali Linux Project documentation is used only to prevent name-confusion with Kali365. ^{11, 12, 14, 23}	High for definitions	Frameworks and name-confusion sources do not prove Kali365 operations or campaign attribution.
Expansion Research	Expansion sources describe live panels, panel variants, API endpoints, templates, billing or subscription features, domain or lure infrastructure, and observed authentication activity. This is sufficient to discuss platform behavior and operational design. ^{15, 16, 17, 18}	Medium-High	This is not the same as a complete public source-code review, full operator identification, or permission to publish acquisition details.

19-Tier 0 Through Tier 8 Source Summary

Tier	Trust Role	What It Supports	Caveat
Tier 0 - Most Trusted	Industry framework / highest-confidence reference	MITRE ATT&CK mappings for phishing, token theft, and valid-account behavior. ^{11, 12, 14}	Technique definitions and behavior vocabulary, not incident proof.
Tier 1 - Authoritative	Official advisory and platform documentation	IC3 Kali365 warning, Microsoft device-code/OAuth documentation, Conditional Access authentication-flow guidance, and Kali Linux name-confusion clarification. ^{1, 5, 6, 23}	Official docs explain the warning and control plane; local tenant telemetry proves whether it happened.
Tier 2 - High-Value Research	Vendor and practitioner research	Arctic Wolf and Bitdefender add operational context around device-code phishing impact, Kali365 service features, and Microsoft 365 account-takeover implications. ^{2, 4}	Use for technical and operational enrichment while keeping IC3 as the controlling advisory source.
Tier 3 - Corroborating News	Security media corroboration	BleepingComputer corroborates the IC3 warning and translates the mechanism for broad security audiences. ³	Secondary to official and practitioner sources for technical findings.
Tier 4 - Community Signal	Social/community discovery	No promoted social/community signal source was retained for this static snapshot.	Telegram distribution is treated as source-backed distribution context, not as a community-signal citation.
Tier 5 - Custom Source (defined by user)	User-provided source set	No user-defined custom source was added to this static snapshot.	Add only when a user supplies a source for this product.
Tier 6 - Custom Integrations with API/Keys	API-backed discovery	Placeholder for future X/API or other keyed discovery checks.	No API-derived source is promoted in this static snapshot.
Tier 7 - Inner Discovery / Carved URLs	Links discovered inside retained sources	No carved-url source is independently promoted in this static snapshot.	Carved URLs should remain lead-only until retained, read, and source-weighted.
Tier 8 - Expansion Research	Additional public research	Huntress, Todyl, SpyCloud, cside, Proofpoint, and eSentire add panel/infrastructure context, device-code lineage, account-takeover tradecraft, and defensive nuance. ^{15, 16, 17, 18, 19, 20, 21, 22}	Adds insight without proving named victims, full operator identity, complete source-code review, or acquisition details.

20-Source Reconciliation

Question / Tension	PANDA Resolution	Why It Matters	Sources
Core source agreement	The source set consistently frames Kali365 as Microsoft 365-focused PhaaS tied to OAuth/device-code abuse, token-oriented access, Telegram-linked distribution, and lower-friction campaign operation.	Gives high confidence in the basic tool profile even where operator identity and victim details remain unknown.	^{1, 3, 4, 15, 16, 17, 18}
Similarity across sources	Official, vendor, media, and expansion sources all describe Kali365 as a service ecosystem rather than a one-off phishing email.	Supports treating the page as an actor/tool/campaign snapshot instead of a simple phishing-lure note.	^{1, 4, 15, 16, 17}
Tool vs actor vs campaign	Treat Kali365 as a PhaaS platform/tool ecosystem used by multiple criminal customers, not as a single named intrusion set or one campaign.	Prevents false attribution and keeps scoping focused on mechanism, access, and telemetry.	^{1, 15, 16, 17}
Kali365 vs Kali Linux	No source used here establishes any affiliation between Kali365 and Kali Linux or Offensive Security.	Avoids brand/name confusion from the shared word 'Kali.'	^{1, 23}
Fake-login phishing vs device-code abuse	Kali365 should be framed around device-code/OAuth authorization abuse where the victim may interact with Microsoft's real verification page.	Explains why password-only assumptions and fake-domain hunting are incomplete.	^{1, 5, 18}
Device-code vs AiTM telemetry	Device-code attacks may show legitimate Microsoft authorization and token/session behavior; AiTM and reverse-proxy attacks more often add proxy, IP, impossible-travel, client, or session-cookie reuse clues.	Prevents analysts from hunting for only the wrong artifact family.	^{1, 5, 18, 19, 22}
Victim names and impact	Public sources support Microsoft 365 users and organizations as the exposed population, but do not provide publishable named Kali365 victim companies in this snapshot.	Keeps the brief useful without inventing victimology.	^{1, 2, 15, 17}
Indicators vs behavioral observables	No stable public Kali365 blocklist is published here; use device-code events, token/session behavior, OAuth consent, and M365 resource access as hunt leads.	Prevents false confidence from missing domains, IPs, hashes, or client IDs.	^{1, 5, 6, 18}
Password reset as containment	Password reset alone is insufficient; responders must revoke sessions/tokens, remove suspicious OAuth grants, sign out affected users, force reauthentication, and scope resource access.	Targets the actual access artifact instead of only the password.	^{1, 6, 12, 18}

27-Additional IntelliOS Threat Intel Products on This Topic

28-Notes

29-Citations

News Sources Answering The Topic Question

#	Source	Published	Why Used
1	FBI / IC3: Kali365 Phishing-as-a-Service Public Service Announcement	May 21, 2026	Tier 1. Authoritative public warning for Kali365, Microsoft 365 OAuth token capture, device-code lure path, Telegram distribution, AI-generated lures, dashboards, and MFA-bypass framing.
2	Arctic Wolf: Token Bingo: Don't Let Your Code be the Winner	April 24, 2026	Tier 2. Practitioner reporting on large-scale device-code phishing, token capture, mailbox access, malicious inbox rules, and Microsoft 365 account-takeover implications.
3	BleepingComputer: FBI warns of Kali365 phishing service targeting Microsoft 365 accounts	May 25, 2026	Tier 3. Corroborates the IC3 warning and translates device-code phishing mechanics for a broad security audience.
4	Bitdefender: FBI warns of Kali365 phishing kit that breaks into Microsoft 365 accounts	May 22, 2026	Tier 2. Vendor reporting on subscription model, AI lures, templates, dashboards, and reduced operator skill barrier.
5	Microsoft Learn: OAuth 2.0 device authorization grant - Microsoft identity platform	Living documentation	Tier 1. Official Microsoft documentation explaining the legitimate OAuth 2.0 device-code flow, including the /devicecode request, verification URL, user code, device code, /token polling, expiration, and token issuance.
6	Microsoft Learn: Conditional Access: Authentication flows	Living documentation	Tier 1. Official Microsoft guidance describing authentication-flow controls, including device-code flow risk and Conditional Access policy options.
11	MITRE ATT&CK: T1566 - Phishing	Living framework	Tier 0. Industry-standard technique definition for phishing delivery and social-engineering lures.
12	MITRE ATT&CK: T1528 - Steal Application Access Token	Living framework	Tier 0. Industry-standard technique definition for stealing application access tokens, central to OAuth-token abuse.
14	MITRE ATT&CK: T1078 - Valid Accounts	Living framework	Tier 0. Industry-standard technique definition for valid-account abuse after tokens, cookies, or credentials are obtained.

Expansion Research

#	Source	Published	Why Used
15	Huntress: Inside Kali365, a Device Code Phishing Ecosystem	June 2026	Tier 8. Expansion research describing observed device-code activity, panel variants, lure templates, API endpoints, RBAC, billing, domain marketplace, and post-compromise tooling.
16	Todyl: Kali365 PhaaS: Inside the Attack Infrastructure	June 2026	Tier 8. Expansion research describing a live Kali365 operator panel, subscription access, payment claims, and attacker-facing infrastructure observations.
17	SpyCloud: Kali365: Anatomy of a Microsoft 365 Phishing-as-a-Service Kit	June 2026	Tier 8. Expansion research on Kali365 victimology, affiliate claims, operator rebranding, device-code capabilities, and why password resets alone may be insufficient.
18	cside: MFA Didn't Fail, the Trust Model Did: Device Code Phishing and OAuth Token Theft (Kali365)	June 5, 2026	Tier 8. Expansion research explaining device-code phishing, OAuth token theft, trust-model abuse, and detection implications for Kali365-style attacks.
19	Proofpoint: Access Granted: Phishing With Device Code Authorization for Account Takeover	December 2025	Tier 8. Expansion research on device-code phishing as an account-takeover pattern, used here to distinguish the broader technique from Kali365 as a named PhaaS implementation.
20	eSentire: Tycoon 2FA Operators Adopt OAuth Device Code Phishing	May 12, 2026	Tier 8. Expansion research showing device-code phishing adoption outside Kali365, useful as adjacent context for PhaaS-supported Microsoft 365 account takeover.
21	Proofpoint: Device Code Phishing is an Evolution in Identity Takeover	May 2026	Tier 8. Expansion research framing device-code phishing as part of the evolution of identity takeover, not as a technique invented by Kali365.
22	Proofpoint: Evolving Threat: Microsoft AiTM Phishing Attacks	2025	Tier 8. Expansion research on Microsoft 365 adversary-in-the-middle phishing and session-focused account takeover, used only as adjacent BEC/M365 ATO context.
23	Kali Linux: Kali Linux Official Site	Living project site	Tier 1. Official Kali Linux project source used only to clarify that Kali Linux is a separate penetration-testing Linux distribution and is not established as affiliated with Kali365 in the sources used here.

30-Version Change Log

Version	Date	Change	Basis
v1.0	21-Jun-2026	Initial Kali365 Campaign, Tool or Actor Snapshot with source-weighted profile, device-code/OAuth scoping guidance, and response priorities.	Baseline publication
Layout standardization	28-Jun-2026	Aligned the page to the FortiBleed reader standard: 32-card menu model, 12-card default view, 3 default-expanded cards, drawer card settings, no-crop banner rendering, and citation-to-citations-card behavior.	Template update

Kali365 Microsoft 365 OAuth Device-Code PhaaS Brief