Imagine attackers renting Microsoft 365 session-hijacking tools for less than a typical SaaS subscription. NovaCookies charges about $320 monthly, offering real-time credential relay, MFA bypass, and anti-detection features that render traditional perimeter controls ineffective. When phishing kits use legitimate infrastructure like Docusign envelopes and Microsoft sign-in endpoints with adversary-in-the-middle techniques, your users won't realize they're under attack until it's too late.
This template provides a configuration for session-based security controls to counter these tactics. You're not stopping the phish from landing; you're preventing the stolen session from causing damage.
What This Configuration Does
This template sets up conditional access policies, session timeout rules, and device trust requirements to limit what an attacker can do with a hijacked Microsoft 365 session. It assumes the attacker has valid credentials and has bypassed MFA through a relay attack. Your goal is to make the stolen session useless or detectable within minutes.
The template addresses three attack phases:
- Initial access: The attacker uses stolen session tokens to authenticate.
- Lateral movement: The attacker tries to access sensitive resources or pivot to other accounts.
- Persistence: The attacker attempts to maintain access or establish backdoors.
Prerequisites
Before implementing this configuration, ensure you have:
- Azure AD Premium P1 or P2 licenses for conditional access
- Microsoft Defender for Cloud Apps for session monitoring
- Intune or another MDM solution for device compliance checks
- Administrative access to Azure AD conditional access policies
- A pilot group of 20-50 users for initial deployment
- A documented baseline for normal session duration and access patterns (review Azure AD sign-in logs for the past 30 days)
You'll also need executive approval for session timeout policies that may interrupt user workflows. Test with your pilot group first, then expand.
The Configuration Template
Conditional Access Policy: Session Control for High-Risk Sign-Ins
Policy Name: Block Unmanaged Device Access to Sensitive Resources
Assignments:
- Users: All users (exclude break-glass accounts)
- Cloud apps: Microsoft 365 (Exchange, SharePoint, Teams)
- Conditions: Device platforms = All; Locations = Any; Sign-in risk = Medium or High
Access Controls:
- Grant: Require device to be marked as compliant
- Session: Sign-in frequency = 1 hour; Persistent browser session = Never
Enable policy: Report-only (for testing), then On
Session Timeout Rule: Force Re-Authentication
Azure AD Token Lifetime Policy:
{
"TokenLifetimePolicy": {
"Version": 1,
"AccessTokenLifetime": "01:00:00",
"RefreshTokenMaxAge": "04:00:00",
"RefreshTokenMaxInactiveTime": "01:00:00"
}
}
Apply this policy to your Microsoft 365 service principals. It forces re-authentication every hour and terminates inactive sessions after 60 minutes. Yes, users will complain, but the alternative is letting an attacker maintain access for days.
Defender for Cloud Apps: Session Monitoring Rule
Policy Name: Flag Impossible Travel with Resource Access
Activity Filters:
- Activity type: File download, mailbox access, admin activity
- Location: Flag if sign-in location changes by more than 500 miles within 1 hour
Actions:
- Alert security team
- Suspend user account (optional, use with caution)
- Require step-up authentication for next action
Device Compliance Policy: Trust Only Known Devices
Intune Compliance Settings:
- Require encryption: Yes
- Require firewall: Yes
- Maximum allowed threat level: Low
- Mark non-compliant devices after: 0 days
Non-Compliance Actions:
- Send email to user: Immediately
- Block access: After 1 hour
Attackers using stolen sessions typically operate from unmanaged devices. This policy makes those devices useless for accessing protected resources.
How to Customize It
Adjust session timeout based on user role. Your finance team accessing sensitive data should have a 30-minute timeout. Your sales team might need 2 hours. Create separate conditional access policies for each group.
Tune the impossible travel threshold. The 500-mile rule works for most organizations, but if you have remote workers who travel frequently, increase the threshold or exclude their accounts during known travel periods. Document these exceptions.
Add application-specific controls. If attackers are targeting specific apps (the NovaCookies campaign focused on Microsoft 365), create app-specific policies. For example, require device compliance for SharePoint but allow unmanaged device access to Teams for external collaboration.
Exclude break-glass accounts. You need at least two emergency access accounts that bypass all conditional access policies. Store their credentials in a physical safe, not a password manager. Test them quarterly.
Phase the rollout. Start with report-only mode for two weeks. Review the sign-in logs to identify false positives. Then enable blocking for your pilot group. Monitor helpdesk tickets. Expand to the full organization only after you've addressed the top three user complaints.
Validation Steps
After deploying the configuration, validate it's working:
Test session timeout: Sign in to Microsoft 365 from a compliant device. Wait 61 minutes without activity. Attempt to access a SharePoint file. You should be prompted to re-authenticate.
Test device compliance blocking: Sign in from a personal device that isn't enrolled in Intune. Attempt to access Exchange email. You should receive an access denied message with instructions to enroll the device.
Test impossible travel detection: Sign in from your office location. Use a VPN to simulate a sign-in from a different country within 30 minutes. Access a SharePoint file. You should trigger an alert in Defender for Cloud Apps within 15 minutes.
Review false positive rate: After one week, check your conditional access sign-in logs. Calculate the percentage of blocked sign-ins that were legitimate users. If it's above 5%, your policies are too restrictive. Adjust the device compliance requirements or session timeout duration.
Measure time to detection: Ask your security team to simulate a session-hijacking attack using a test account. Measure how long it takes for your monitoring tools to flag the suspicious activity. Your target: detection within 10 minutes of the first anomalous action.
Research from Island showed that 49.2% of organizations targeted by NovaCookies were in the United States, and nearly 90% of phishing lures used .vu domains to appear legitimate. Your users won't spot these attacks. Your session controls need to catch what your users miss.
This configuration won't stop the phish from landing. It stops the attacker from using what they stole. Test it, tune it, and deploy it before the next campaign hits your environment.
