Incident Response in Action: Tracing a Microsoft 365 Account Lockout to a Hidden OneDrive Scheduled Task
A user's account was locking out with no obvious cause. What looked like a simple helpdesk ticket turned into a multi-layer forensic investigation across Active Directory, Microsoft 365 audit logs, OneDrive, and a secondary RADIUS authentication source - revealing an active attacker foothold.
The Alert
A professional services organization with a Microsoft 365 environment and on-premises Active Directory reported that a senior staff member's account was locking out repeatedly - multiple times per day, with no pattern the IT team could identify. The user hadn't changed their password. No failed login attempts were visible in the basic Azure AD sign-in logs. The helpdesk had reset the password twice. The lockouts continued.
When the client escalated to SOClogix, the initial assumption was credential stuffing against the account from an external source. What the investigation revealed was significantly more sophisticated - and more dangerous.
The Investigation
Azure AD Sign-in Logs - The Surface Level
The standard Azure AD sign-in log showed successful MFA completions from the user's expected device and location. No obvious anomalies. This is where most investigations stop - and why this attacker had remained undetected. The lockouts were not coming from failed external authentication attempts. They were coming from somewhere inside.
Unified Audit Log - Pulling the Full Picture
SOClogix pulled the Microsoft 365 Unified Audit Log (UAL), which captures a much broader range of activity than the basic sign-in log - including file operations, OAuth activity, and service-to-service authentication events. Within the UAL, we found a pattern of file sync operations originating from a device that had not been enrolled in the organization's Intune MDM. The sync was accessing a specific OneDrive folder the user had no memory of creating.
OneDrive - The Persistence Mechanism
Inside the folder identified in the UAL, SOClogix found a Windows Scheduled Task definition file (.xml) that had been synced from the attacker's device into the target user's OneDrive. Because the user's workstation was configured to sync their full OneDrive library, this task file had been written to disk on the user's machine. A separate scheduled task on a compromised endpoint was then importing and registering this task, which ran as the user's credentials against an internal service - generating repeated authentication attempts and triggering the lockout policy.
RADIUS / NPS Logs - The Secondary Auth Source
Cross-referencing with the on-premises Network Policy Server (NPS) logs revealed a secondary authentication stream. The task was authenticating against a legacy VPN service that still used RADIUS with NPS - a protocol path that bypasses modern Conditional Access policies entirely. This is how the attacker had established a reliable, repeating authentication channel that the Azure-centric monitoring tools couldn't see. The lockouts were a side effect: the legacy protocol had a lower lockout threshold than the modern one.
The Complete Attack Chain
Attacker obtains valid credentials (likely through phishing or credential marketplace)
Uses credentials to authenticate to Microsoft 365 from a non-enrolled device, completing MFA via real-time phishing relay (adversary-in-the-middle)
Gains access to the user's OneDrive - plants a Scheduled Task XML file inside a synced folder
Task is imported on the user's workstation via a previously compromised endpoint on the same network
Task runs repeatedly using the user's credentials against a legacy RADIUS/NPS-backed VPN service
Repeated auth attempts against legacy protocol trigger account lockout policy - the first visible symptom
Key insight: The lockout was not the attack - it was an artifact of the attack. Without pulling the full audit layer across AD, M365, and NPS simultaneously, the root cause would have remained invisible. A standard "reset password and monitor" response would have left the persistence mechanism untouched.
Containment & Remediation
Revoked all active sessions for the affected user account and force-reset credentials
Removed the planted Scheduled Task XML from the user's OneDrive and confirmed no other files had been dropped
Identified and isolated the compromised endpoint that had imported and registered the task
Disabled the legacy RADIUS/NPS authentication pathway for the VPN service - migrated to modern auth with Conditional Access
Applied OneDrive access restrictions to prevent sync from non-enrolled devices
Conducted full audit of other accounts for similar OneDrive-based persistence indicators
Confirmed no evidence of data exfiltration during the attacker's access window through DLP log review
Why This Investigation Matters
Microsoft 365 investigations require pulling from multiple, separate audit surfaces - Azure AD sign-in logs, the Unified Audit Log, Exchange message traces, OneDrive activity, and in hybrid environments, on-premises AD event logs and NPS/RADIUS logs. No single dashboard shows all of these simultaneously. Attackers who understand this gap deliberately operate across the seam between cloud and on-premises visibility.
This case is a clear example of why a help desk reset is not an incident response. The lockout was the symptom. The persistence mechanism was the problem. And finding it required depth across three separate authentication systems that most IT teams - and many MSSPs - don't correlate together.
Dealing with a suspicious account or unexplained lockout?
Our IR team is available 24/7. We'll pull the full audit picture across your AD and M365 environment - not just the surface-level sign-in log.