School districts, universities, and state and local government agencies share something that makes them high-value targets for threat actors: large, distributed user populations, federated identity environments, and Microsoft 365 tenants running at institutional scale. When a phishing campaign successfully compromises a single account at a K–12 district or county government, the blast radius — student data, personnel records, financial systems, critical infrastructure access — is significant.
This spring, the Forsyte Guardian 365 SOC has been tracking three active campaigns hitting Microsoft 365 environments. None of them exploit a new vulnerability. All three exploit trust — turning signals your users and your email gateway treat as safe into the delivery mechanism for the attack. Here’s what each campaign does, why standard defenses are falling short, and what IT and security teams at education and government organizations should do right now.
Campaign 1: Self-Send Spoofing — When the Email Looks Like It Came from Inside Your District or Agency
What’s happening: Attackers are sending email that appears to originate from within your own organization. The From: address displays your own domain — a message that looks, at a glance, like internal communication from a colleague, a department, or your IT help desk.
The payload varies. Our SOC has observed spoofed credential-harvesting pages, OAuth application consent prompts that silently establish backdoor access to a compromised identity, and malicious attachments delivered directly in the message body.
Why this is especially dangerous for education and government: K–12 districts and higher education institutions regularly communicate via district-wide email blasts, administrative announcements, and IT notifications — exactly the communication patterns these lures mimic. Government agencies face similar risk: employees are conditioned to act on internal email quickly. Spoofed messages impersonating HR, payroll, finance, or IT are highly effective in these environments.
Why standard defenses miss it: Strict SPF, DKIM, and DMARC enforcement will fail these messages — but most education and government Microsoft 365 tenants aren’t running DMARC at p=quarantine or p=reject. That’s often a deliberate choice: third-party senders, student information systems, grant management platforms, and other legitimate services can break under strict DMARC alignment. When DMARC isn’t enforcing, Exchange may still deliver the spoofed message — to the Inbox or to Junk. Both are dangerous. Users routinely retrieve internal-looking messages from Junk to act on them.
What to do:
- Deploy DMARC at the strongest enforcement level (p=quarantine or p=reject) your environment can support, and work methodically through the third-party sender exceptions.
- Enable SPF with a hard fail (-all) record.
- Rotate to 2048-bit RSA DKIM keys if you haven’t already.
- Configure Defender for Office 365 anti-phishing policies with custom and owned-domain impersonation protection — set matching messages to quarantine.
- Use the Tenant Allow/Block List to block known malicious spoofing pairs targeting your domain.
- Run Attack Simulation Training campaigns using these exact lure types so your users have seen it before it reaches them for real.
Campaign 2: Kali365 AiTM — Stealing the Session Cookie Instead of the Password
What’s happening: The second campaign uses Kali365, a recently identified phishing-as-a-service platform built around adversary-in-the-middle (AiTM) token theft. The attacker stands up a convincing replica of the Microsoft sign-in page. When a user navigates to it and attempts to log in, the fake page acts as a silent relay — forwarding the user’s credentials and MFA challenge to the real Microsoft endpoint in real time.
From the user’s perspective, the login succeeds normally. From the attacker’s perspective, every step of that exchange — including the session cookie Microsoft issues after successful authentication — is captured.
Why this matters for schools and government agencies: AiTM attacks don’t defeat multi-factor authentication. They wait for MFA to complete, then walk through the authenticated session. This is critical context for education and government IT teams: if your MFA posture is your primary account security control, Kali365-style attacks render it insufficient on its own. Higher education institutions that have invested in MFA rollouts as a ransomware defense measure should understand this gap.
Post-compromise, attackers use stolen session cookies to access email, cloud storage, and administrative portals — often pivoting within the environment to escalate privileges or establish persistence before detection.
Why standard defenses miss it: Because the authentication exchange is real — only the intermediary is malicious — sender reputation and DMARC checks don’t flag the initial phishing lure. Native Microsoft detection for AiTM is improving but not comprehensive. Guardian 365 maintains custom detection rules and IOC feeds for this campaign to supplement native Defender capabilities.
What to do:
- Deploy and tune Token Protection Conditional Access policies so session tokens cannot be replayed on devices other than the one they were issued to.
- Enforce device compliance for authentication, and configure user-risk and sign-in-risk remediation policies to block or step up suspicious post-authentication activity.
- Enable OAuth App Governance to surface highly privileged, unverified app consent that may indicate a backdoor was established.
- Restrict user-driven app consent so OAuth applications cannot be granted access without administrator involvement — a critical control in education environments where students and staff may inadvertently consent to malicious applications.
Campaign 3: Weaponized File Shares — When the Threat Arrives in a Genuine Microsoft Email
What’s happening: The third campaign is arguably the most difficult to detect because the notification email delivering the malicious content is sent by Microsoft — not spoofed, not proxied. Real.
Attackers either compromise a legitimate Microsoft 365 user account (often using a stolen session cookie from a campaign like the one described above) or stand up their own Microsoft 365 tenant. They then use SharePoint Online or OneDrive to share a malicious file with their target. Microsoft’s platform generates and sends the sharing notification email on the attacker’s behalf — from an authenticated Microsoft sending infrastructure, passing DMARC, passing sender reputation checks, and arriving in the inbox looking exactly like the file-share notifications your users receive every day.
Why this is a significant risk for education and government: Collaboration via SharePoint Online and OneDrive is routine at universities, school districts, and government agencies. Faculty share curriculum. Administrators share policy documents. Government staff share reports and forms via OneDrive links. The volume of legitimate file-share notifications in these environments is high — which is precisely what makes malicious ones so difficult to spot.
This attack pattern resurfaces periodically. Forsyte has covered it in depth previously — see our post Defending Against “Legitimate Infrastructure” File-Sharing Phishing Campaigns for a full breakdown.
What to do:
- Implement Exchange transport rules to detect and flag or quarantine anomalous sharing notifications — including rules targeting high-volume no-reply senders like noreply@sharepointonline.com when sharing activity patterns are inconsistent with normal behavior.
- Tighten external sharing policies in the SharePoint Online admin center. Users who have no legitimate need to receive external file-share notifications can be scoped out of that flow entirely.
- Review and restrict which external domains your users can accept sharing invitations from.
- Forsyte has also developed proprietary Exchange transport rule–based blocking mechanisms for these attacks. Contact sales@forsyteit.com to discuss deployment in your environment.
Forsyte has also developed proprietary Exchange transport rule–based blocking mechanisms for these attacks. Contact sales@forsyteit.com to discuss deployment in your environment.
The Bigger Picture for Education and Government Security Teams
These three campaigns share a common thread: each one turns a trusted signal into the attack vector. An email from your own domain. The real Microsoft login experience. An authentic Microsoft file-share notification. The threat in each case isn’t a new zero-day — it’s the deliberate manipulation of the controls and habits your users and your gateway already rely on.
For K–12 districts and higher education institutions operating with lean IT and security staff, and for state and local government agencies managing sprawling Microsoft 365 environments across departments, the challenge isn’t identifying the right defenses — it’s having the bandwidth and expertise to implement, tune, and monitor them continuously.
That’s what Guardian 365 is built for. Our MXDR Verified SOC team monitors identity events, maintains custom detection rules for active campaigns, and actively deploys protective controls across your Microsoft 365 environment — so your team doesn’t have to absorb that operational burden alone.
If you have questions about how Advisory G365-TA-2026-005 applies to your district, institution, or agency, we’re happy to walk through it with you. Reach out at sales@forsyteit.com or request a Data Security Assessment to see where your Microsoft 365 environment stands today.
