The Defender's Advantage
In our previous article, we walked through the Kali 365 attack toolkit — the collection of open-source tools that security professionals (and attackers) use to probe Microsoft 365 tenants. We traced the attack chain from external reconnaissance through initial access, internal enumeration, and privilege escalation. If you haven't read it, the summary is this: your M365 tenant is almost certainly more exposed than you realise, and the tools to find and exploit those weaknesses are free and widely available.
But here is where the story gets more reassuring. Unlike many attack surfaces, Microsoft 365 security is not primarily about patching vulnerabilities — it is about configuration. The attacks that Kali 365 tools execute succeed not because Microsoft has shipped broken software, but because the default settings of M365, combined with years of organic growth and convenience-driven decisions, leave specific, well-understood gaps. And because the gaps are well-understood, the controls that close them are also well-understood. There is no zero-day required to defend against Kali 365. There is no obscure technical knowledge needed. You need six things to be correctly configured, and the defender who has all six in place will stop the Kali 365 attack chain at every stage.
This article is the checklist. Work through it, verify each control in your own tenant, and you will have closed the doors that Kali 365 is designed to walk through.
The Six Controls That Stop Kali 365
1. Phishing-Resistant MFA on All Privileged Accounts
This is the single most impactful control. The Kali 365 toolkit's o365spray performs password spraying, but if every account is protected by MFA, a correct password is worthless. More critically, the Device Code Flow phishing attack — the most dangerous technique in the toolkit — is stopped cold by Conditional Access policies that block the device code flow for all users. Standard SMS MFA is not sufficient (it is vulnerable to SIM-swapping); FIDO2 hardware keys or Microsoft Authenticator with number matching are the recommended standards for privileged accounts.
2. Conditional Access: Block Legacy Authentication
Legacy authentication protocols — SMTP AUTH, POP3, IMAP, Basic Auth — do not support MFA. An attacker who finds an account with a weak or reused password can authenticate directly via these protocols, bypassing every MFA policy you have set. AADInternals specifically targets legacy authentication endpoints because they skip Conditional Access entirely. A single Conditional Access policy that blocks all legacy authentication protocols closes this door completely. Microsoft has deprecated Basic Auth in Exchange Online, but legacy protocols can still be enabled at the application level and are frequently found in older tenant configurations.
3. Guest Access and External Sharing Governance
ROADtools and GraphRunner, once an attacker has any valid token, will enumerate all SharePoint sites and their sharing configuration. In most unmanaged tenants, they find what they are looking for almost immediately: sites shared with "Everyone" or "Everyone except external users," anonymous sharing links that give read or edit access without authentication, and guest accounts from former partners and contractors that are still active years after the relationship ended. The fix is threefold: block anonymous sharing links at the tenant level, enforce guest access review policies, and audit existing sharing permissions. These are configuration changes, not complex technical interventions.
4. Data Loss Prevention Policies with Full Coverage
Once GraphRunner has enumerated accessible SharePoint content, the next question is what is in those files. DLP policies are the mechanism that detects and controls the movement of sensitive information — financial data, personal identifiers, health records, credit card numbers. But DLP only works where it is configured. Many organisations have DLP enabled for email but not for SharePoint and OneDrive. Some have DLP in "test mode" that generates alerts no one reviews. Full DLP coverage means policies that apply across all workloads, in enforcement (not audit) mode, with alerts routed to a security operations queue that is actually monitored.
5. Sensitivity Labels Applied to High-Value Content
Sensitivity labels are the primary mechanism for classifying and protecting M365 content. A document labelled "Confidential" with encryption applied will remain encrypted even if an attacker extracts it via GraphRunner — the file is useless without the decryption key, which requires authentication to retrieve. But labels must actually be applied to content to provide this protection. Auto-labelling policies — which scan SharePoint libraries and OneDrive folders and apply labels to matching content automatically — are the most effective way to achieve broad coverage without relying on users to manually classify every document. Without labels, Kali 365 tools treat a confidential board paper and a public marketing document identically.
6. Privileged Identity Management and Admin Account Hygiene
AADInternals' most powerful capabilities target privileged accounts. If there are Global Administrator accounts with no MFA, or service accounts with Global Admin rights that were created for a past implementation and never decommissioned, a Kali 365 engagement will find them and exploit them. The remediation has three parts: enable Microsoft Entra PIM (Privileged Identity Management) so all privileged roles are just-in-time rather than permanent; enforce MFA as a Conditional Access requirement for all admin roles (not just as a user setting, which can be disabled); and conduct a full audit of all accounts holding Global Admin, Exchange Admin, SharePoint Admin, and Compliance Admin roles, decommissioning any that are not actively used and justifiable.
Verifying Your Controls: The Hard Way vs the Smart Way
You can verify each of these six controls manually by navigating through the Entra ID portal, the SharePoint Admin Centre, and Microsoft Purview — checking each setting, each policy, each role assignment one by one. For a tenant of any significant size, this process takes days and requires deep familiarity with each administrative interface. It is also error-prone: without a structured checklist and consistent scoring methodology, it is easy to confirm that a policy exists without verifying whether it is actually enforced in the way it needs to be.
The smarter approach is to let an automated tool do the audit in minutes and present the results as a structured, scored assessment. This is precisely what Copilot SafeScan is designed for.
"The Kali 365 toolkit is a checklist written by attackers. SafeScan is the same checklist, run from the inside, before the attacker gets there." — Copilot 365 Security Practice Lead
How SafeScan Maps Directly to the Kali 365 Attack Surface
SafeScan connects to your Microsoft 365 tenant using a read-only consent-based authentication flow — the same Microsoft Graph API that Kali 365 tools use, but requesting only the minimum permissions needed to read your security configuration. The scan runs entirely in the background, takes five to fifteen minutes depending on tenant size, and produces a scored dashboard across six security domains that map precisely to the six controls described in this article.
The Identity & Authentication domain covers MFA enforcement, authentication method configuration, and conditional access policies — directly countering the initial access techniques used by o365spray and TokenTactics. The Conditional Access domain verifies that legacy authentication is blocked and that admin role access requires PIM activation — countering the authentication bypass techniques in AADInternals. The Guest Access and External Sharing domain audits every sharing configuration that ROADtools and GraphRunner are designed to enumerate. The Data Loss Prevention and Sensitivity Labels domains assess the policies that limit what an attacker can do with content once they have access to it. And the Privileged Identity domain reviews every admin role assignment and PIM configuration that AADInternals targets for escalation.
For every checkpoint that returns a Red or Amber status, SafeScan provides a plain-English explanation of the risk, the specific configuration responsible, step-by-step remediation guidance, and — for the most common findings — ready-to-run PowerShell scripts that apply the recommended fix. The path from "we know we have a problem" to "the problem is fixed" is as short as the technology allows.
The Copilot Dimension
All of this matters considerably more the moment you add Microsoft 365 Copilot to your tenant. Every overshared file that SafeScan identifies as a risk in your SharePoint environment is a file that Copilot can surface in a natural language query response. Every admin account without MFA that SafeScan flags is an account whose Copilot interaction history is accessible to any attacker who compromises it. Every missing DLP policy is a gap through which Copilot-retrieved sensitive data can flow without detection.
The Kali 365 attack chain and the Copilot deployment readiness assessment are, in many ways, the same assessment seen from two different angles. The attacker asks: "what can I find in this tenant?" The SafeScan audit asks: "what should not be findable that currently is?" Answering the second question definitively — before an attacker has the opportunity to explore the first — is the security posture that every Copilot deployment should start from.
Your Next Steps
If you have worked through the six controls described in this article and want to know definitively where your tenant stands against the Kali 365 attack surface, the path forward is straightforward:
- Run a SafeScan. The free tier covers all six security domains and produces a scored dashboard in under fifteen minutes. No software installation, no agent deployment, no IT change required — just a read-only Microsoft consent flow.
- Prioritise Red findings first. The SafeScan dashboard surfaces critical findings first. Every Red item is a control that the Kali 365 toolkit would exploit in an actual pen test. Close the Reds before moving to Ambers.
- Use the remediation scripts. SafeScan's PowerShell remediation scripts are production-ready and include detailed comments explaining what each command does and why. They can be run directly by your IT team or used as a starting point for your change management process.
- Schedule quarterly rescans. M365 configurations drift. New applications are granted permissions, SharePoint sites are shared for convenience and never reviewed, admin roles accumulate. A quarterly SafeScan run gives you a continuous security posture picture rather than a point-in-time snapshot.
- Brief your Copilot deployment as a security gate, not a convenience step. If your SafeScan returns Red findings, do not deploy Copilot until they are resolved. The combination of an unsecured tenant and an AI assistant that can surface all of its content is the most dangerous configuration possible.
