In this guide, we detail the different methods for reconstructing a cybersecurity incident timeline using data from Microsoft Defender for Endpoint, Microsoft 365 Audit Logs, and system-level telemetry. We include PowerShell queries, registry and GPO auditing, and CMD-based verification techniques to assist with incident analysis and reporting.
You may be wondering why this is important. To put it simply, when a security incident hits, your priority isn’t just cleanup (though that’s important), it’s also understanding what really happened so you can prevent it from recurring. A clear timeline shows:
- Root cause and exposure window: Where the security incident started and how long threat actors had access to it
- Compliance evidence: Many regulations (such as GDPR and HIPAA) require proof of when and how a breach occurred.
- Insurance or legal support: Proper documentation strengthens claims or investigations.
- Operational validation: Helps you see what worked (or didn’t) in your defenses
💡 Note: Think of it as putting together a crime scene investigation, but with Defender for Endpoint, Microsoft 365 Audit Logs, and system telemetry as your evidence.
📌 Recommended deployment strategies:
Click to Choose a Method | 💻 Best for Individual Users | 💻💻💻 Best for Enterprises |
| Method 1: Incident review in Defender Security Center | ✓ | |
| Method 2: Microsoft 365 Audit Logs (Compliance Center/PowerShell) | ✓ | |
| Method 3: PowerShell queries (Defender API + local logs) | ✓ | ✓ |
| Method 4: Device event logs via CMD/Event Viewer | ✓ | |
| Method 5: Registry checks for persistent attempts | ✓ | |
| Method 6: Group Policy for advanced audit logging | ✓ |
💡Note: These methods are not separate ways of doing the same thing. Instead, each method highlights a different data source or technique—but they are also not a step-by-step process. Some MSPs may only use certain sources depending on their environment. We recommend implementing only the necessary methods that match your environment.
Creating a detailed security incident timeline
Method 1: Incident review in Defender Security Center
Defender Security Center is your starting point for any investigation. It groups alerts into incidents that show how threats unfolded.
📌 Use Cases: This is your initial detection point and helps you quickly identify an incident.
📌 Prerequisites:
- The device must be onboarded into Microsoft Defender for Endpoint.
- Security permissions to view incidents in the portal.
Steps:
- Go to Microsoft 365 Security Center. If you are using endpoint management software, you can access it directly through the platform.
- Select the relevant incident.
- Review the:
- Detection timestamp
- Device name and user context
- Threat classification and source
- Lateral movement or affected systems
- Open the Advanced Hunting tab to explore correlated activity.
- Export findings either as a CSV or PDF for your timeline report.
Method 2: Microsoft 365 Audit Logs (Compliance Center/PowerShell)
Audit logs give you visibility into what users (or attackers) did across Microsoft 365 resources.
📌 Use Cases: This method allows you to track suspicious logins, file access, or mailbox activity. You can also use this method to trace privilege escalations (such as role changes, admin activity).
📌 Prerequisites:
- Unified Audit Logging is enabled in Microsoft 365
- Role permissions to access Microsoft Purview Audit.
Steps:
- Go to the Audit log search portal. This can usually be accessed through your endpoint manager, if you are currently using one.
- Search by:
- User email or object ID
- Incident timeframe
- Activities: FileAccessed, MailboxLogin, RoleAssignmentChange, etc.
- PowerShell equivalent:
Connect-IPPSSession
Search-UnifiedAuditLog -StartDate “2025-07-01T00:00” –
EndDate “2025-07-01T23:59” -UserIds “[email protected]”
- Export results and sort chronologically.
Method 3: PowerShell queries (Defender API + local logs)
PowerShell lets you combine cloud-based Defender telemetry with local endpoint logs for deeper correlation.
📌 Use Cases: This method helps pull security events from Defender API for automation.
📌 Prerequisites:
- PowerShell 5.1+ and Graph module installed
- Permissions to query Defender API (SecurityEvents.Real.All)
- Local admin rights on the endpoint
- Need a refresher? Sign up for this free crash course, PowerShell for IT Ninjas.
Steps:
- Open PowerShell.
- Execute these commands, as needed:
- Defender hunting via Graph API:
Connect-MgGraph -Scopes “SecurityEvents.Read.All”
Invoke-MgGraphRequest -Method GET -Uri “https://graph.microsoft.com/v1.0/security/alerts” |
ConvertFrom-Json | Select-Object id, createdDateTime, title, severity, status
- Local Defender logs:
Get-WinEvent -LogName “Microsoft-Windows-Windows Defender/Operational” |
Where-Object { $_.TimeCreated -gt (Get-Date).AddHours(-24) } |
Select TimeCreated, Message
💡 Tip: Use this to correlate endpoint telemetry with cloud-detected threats.
Method 4: Device event logs via CMD/Event Viewer
Local event logs help you dig further into logons, system activity, and script execution that may not show up in Defender or M365.
📌 Use Cases: This method allows you to see system crashes, restarts, or shutdowns during the attack window. You can also use this method to review PowerShell script execution as a possible attack vector.
📌 Prerequisites:
- Local admin rights on affected machines
- Security and PowerShell logging enabled
Steps:
- Open an elevated Command Prompt.
- Execute these commands in order.
- Account logon events (Event IDs 4624 (An account was successfully logged on), 4625 (An account failed to log on), 4648 (A logon was attempted using explicit credentials)):
wevtutil qe Security “/q:*[System[(EventID=4624 or EventID=4625 or EventID=4648)]]” /c:10 /f:text
- System events (startup/shutdown/errors):
wevtutil qe System /c:10 /f:text
- PowerShell activity:
wevtutil qe “Microsoft-Windows-PowerShell/Operational” /c:20 /f:text
Method 5: Registry checks for persistent attempts
Attackers often modify Registry keys to ensure their tools run automatically after a reboot.
📌 Use Cases: This method detects unauthorized startup programs and spots any Registry tampering.
📌 Prerequisites:
- Registry auditing enabled (via GPO or Security Policy)
- Event logging is configured for registry changes.
Steps:
- Press Win + R, type regedit, and click Enter.
- Check common persistence paths:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
This affects all users on the system. Malware here will launch for every account that logs on.
- HKCU\Software\Microsoft\Windows\CurrentVersion\Run
This affects only the current user. Persistence is tied to a single compromised user profile.
💡 Threat actors sometimes prefer HKCU because it’s stealthier and doesn’t require admin rights. So, it’s best practice to look for both paths.
- Look for Event ID 4657 in Security logs (Registry value modification).
- Cross-reference suspicious entries with activity from Defender or M365 audit logs.
Method 6: Group Policy for advanced audit logging
📌 Use Cases: This ensures critical logs exist for future incidents. You can also use this method to strengthen coverage across high-value servers and workstations (perfect for compliance reporting!).
📌 Prerequisites:
- GPO management rights
- Domain environment (recommended, though local policy works too)
Steps:
- Press Win + R, type gpedit.msc, and click Enter.
- Go to: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies
- Enable:
- Audit Logon Events
- Audit Object Access
- Audit Process Tracking
- Audit Policy Change
- Apply policies across key servers and workstations.
⚠️ Things to look out for
| Risks | Potential Consequences | Reversals |
| Log retention gaps (Defender, M365, or local logs) | Missing activity from the attack window; incomplete timeline | Extend retention policies (e.g., Purview audit log E5 = 1 year); centralize logs in SIEM. |
| Event log rollover (Security/System logs) | Older evidence overwritten by new events | Increase log size via GPO; offload logs to a collector. |
| Disabled or misconfigured auditing | No registry/file/privilege events captured | Verify GPO settings for auditing; enable Advanced Audit Policy Configuration. |
| False positives (legit apps in Run keys, unusual logons) | Wasted investigation time or accidental disruption | Cross-reference entries with software inventory and known user behavior. |
| Over-collection of data | Hard to spot the real malicious activity | Use filtering in PowerShell/Advanced Hunting to narrow down queries. |
Additional considerations when creating an Office 365 audit log
- Log retention: Ensure logs are retained for at least 90–180 days (depending on compliance needs).
- SIEM integration: Consider centralizing all logs into a SIEM for correlation.
- Time synchronization: Ensure all systems are synced via NTP (w32tm /query /status) to avoid timeline inconsistencies.
- Documentation: Keep a standard timeline template for incidents.
Troubleshooting common issues
- Missing logs: Logging wasn’t enabled or logs rolled over.
- To resolve this: Verify auditing in GPO, increase log size, or centralize logs in SIEM.
- No Defender data: Device not onboarded or excluded from protection
- To resolve this: Check onboarding in Security Center and review exclusion policies.
- Audit log errors (M365): Unified Audit Log not enabled or license limits retention
- To resolve this: Enable audit logging in Purview and check your license (E5 = 1 year retention, non-E5 = 180 days).
- Time discrepancies: Systems not synced, leading to timeline gaps
- To resolve this: Run w32tm /query /status and configure NTP sync across all systems.
- Export/import issues: CSV exports are not sorting correctly.
- To resolve this: Re-export via PowerShell and sort by TimeCreated or CreationDate.
- Too much noise: High event volume hides the real indicators.
- To resolve this: Use filtering (event IDs, user filters, KQL queries) to narrow results.
NinjaOne services
NinjaOne, the automated endpoint management platform, can help you build a more detailed cybersecurity incident timeline. Here’s how:
- Centralized log collection: NinjaOne allows you to collect Windows Event, Defender Operational, and PowerShell logs at scale on a schedule, so evidence doesn’t roll off.
- One-to-many PowerShell orchestration: You can run parameterized scripts across selected devices/tenants and capture JSON/CSV/text results. Outputs can be attached to tickets, archived, or forwarded via webhooks for immediate analysis.
- Automated evidence bundles: Kick off playbooks that grab key event IDs, Defender hits, registry autoruns, and time-sync status in one pass.
- High-signal detection and alerting: Alert on repeated 4625s, Defender detections, ScriptBlock hits, or registry changes collected by scripts.
- Safe response automation: Scripted actions can remove malicious autoruns, kill processes, isolate a host, or rotate local creds with pre-checks.
- Better logging by policy: Push increased log sizes, ScriptBlock/Transcription logging, and advanced audit categories via scripted deployments.
- Cross-tenant scale for MSPs: Reuse the same collections, alerts, and playbooks across all clients with tags and scoped device groups.
- Asset and exposure context: Pivot from an alert to inventory details like OS level, patch age, and software presence.
- Incident tagging, reporting, and exports: Tag devices, tickets, and artifacts with an incident ID and export evidence bundles (CSV/JSON/ZIP).
- Integrations and governance: Use webhooks/APIs to push/pull data with SIEMs, ITSM, and chat tools; enrich timelines with Graph/Defender queries via script.
Protect your environment with a detailed Microsoft 365 audit log
Reconstructing a cybersecurity incident timeline isn’t just a single action. It requires combining evidence of Defender incidents, Microsoft 365 audit activity, and endpoint telemetry.
We’ve listed six methods for you to try, but we need to reiterate that these strategies are not entirely independent of each other. Use the right method for your specific needs, and refer to our recommended deployment strategies table for more information.
Related topics:
- What Is Incident Response?
- What is Cybersecurity?
- Understanding Windows Defender Application Control (WDAC)
- 12 Most Common Types of Cyber Attacks: How to Spot and Prevent Them
Quick-Start Guide
NinjaOne can help build a Cyber Security Incident Timeline using logs from Defender and Audit Logs. Here are some key points:
Incident Timeline Creation
NinjaOne provides robust log collection capabilities for creating a security incident timeline:
- Windows System Logs
- Collect Windows Event logs from:
- Application log
- Security log
- System log
- Focus on the specific timeframe of the alert/incident
- Collect Windows Event logs from:
- Log Collection Across Different Operating Systems
- Windows Systems: Full Windows Event Logs
- macOS Systems:
- System logs
- Application logs
- Security and authentication logs
- Linux Systems:
- System logs
- Authentication logs
- Application-specific logs
- Additional Evidence Collection
- PCAP Files (network captures)
- Antivirus alert definitions
- Any additional relevant information from the customer
Integration with Security Tools
NinjaOne integrates with security tools like:
- Bitdefender GravityZone
- SentinelOne
- CrowdStrike
These integrations allow for comprehensive threat detection, logging, and timeline reconstruction.
Recommended Process
- Gather logs from the affected devices
- Collect logs from relevant security tools
- Identify the incident timeframe
- Correlate logs and events
- Create a chronological timeline of the security incident
For a comprehensive incident timeline, you’ll want to collect logs from multiple sources and carefully analyze the sequence of events.
