Monitoring and Alerting on Privileged Activity

If you cannot see what your privileged accounts are doing, you cannot protect your organisation. Credential vaulting and just-in-time access dramatically reduce the risk of privileged account compromise, but they do not eliminate it entirely. Monitoring and alerting on privileged activity is the detective control that catches misuse, detects compromised accounts, and provides the forensic evidence you need when something goes wrong. Without it, an attacker who gains privileged access can operate undetected for weeks or months — the average dwell time for advanced threats.

This lesson explains how to define alert rules for anomalous privileged account behaviour and how to integrate privileged session logs with your SIEM or log management platform so your security team has real-time visibility into every administrative action.

What to Monitor

Privileged activity monitoring should cover three categories:

1. Authentication Events

• Privileged account logins — every login by an admin account, including time, source IP, device, and location.
• Failed login attempts — multiple failed attempts on a privileged account may indicate a brute-force or credential-stuffing attack.
• Logins from unusual locations or devices — an admin who normally logs in from London appearing in a different country warrants investigation.
• Logins outside business hours — a Domain Admin login at 3am on a Sunday, unless during a scheduled maintenance window, should trigger an alert.
• MFA bypass or failure — any privileged login that skips or fails multi-factor authentication.

2. Privilege Escalation Events

• New members added to privileged groups (Domain Admins, Enterprise Admins, Global Admins, local administrator groups).
• Role activation in Azure PIM or equivalent JIT systems.
• Changes to role definitions or permission boundaries.
• Service account permission changes.
• New service principals or application registrations with privileged permissions.

3. Administrative Actions

• Group Policy changes in Active Directory.
• Security policy modifications (firewall rules, Conditional Access policies, audit settings).
• User creation, deletion, or modification by admin accounts.
• Mailbox access by administrators (a common indicator of insider threat or compromise).
• Database administrative operations (schema changes, bulk data exports, backup modifications).

Defining Alert Rules

Not every privileged action needs an immediate alert. The goal is to define rules that surface genuinely anomalous behaviour without creating so much noise that your team ignores them. Here are practical alert rules to start with:

Critical Alerts (Respond Immediately)

• New member added to Domain Admins or Global Admin — This should never happen without a change request. Alert immediately and investigate.
• Break-glass account used — Emergency access accounts should only be used in genuine emergencies. Any use triggers an immediate investigation.
• Privileged login with MFA bypass — An admin login without MFA suggests credential compromise or policy misconfiguration.
• Audit log clearing or tampering — An attacker covering their tracks is one of the strongest indicators of active compromise.
• Privileged session from a Tor exit node or known malicious IP — Geographical anomalies on admin accounts are high-confidence indicators.

High-Priority Alerts (Investigate Within One Hour)

• Privileged login outside business hours — Without a corresponding maintenance window or on-call schedule entry.
• Multiple failed privileged login attempts — More than five failed attempts in ten minutes suggests attack activity.
• Service account interactive login — Service accounts should never log in interactively. If one does, it’s being misused or compromised.
• Bulk user modifications by a single admin — Creating or deleting more than ten accounts in an hour is unusual and warrants review.

Medium-Priority Alerts (Review Daily)

• Privileged role activation frequency anomalies — An admin who normally activates their role twice a week suddenly activating it five times a day.
• Admin accessing systems outside their normal scope — A server admin accessing HR databases, for example.
• Password rotation failures — Credentials that fail automatic rotation may indicate connectivity issues or manual interference.

Integrating with Your SIEM

Privileged activity logs must flow into your central security monitoring platform — whether that’s a full SIEM (Splunk, Microsoft Sentinel, IBM QRadar, Elastic SIEM) or a simpler log management solution. Here’s how to approach the integration:

1. Identify your log sources — Active Directory event logs (Security event log on domain controllers), Azure AD sign-in and audit logs, PAM vault logs (CyberArk, Delinea, BeyondTrust), cloud platform admin activity logs (Azure Activity Log, AWS CloudTrail, GCP Admin Activity), firewall and VPN logs for admin session tracking.
2. Configure log forwarding — Use native connectors (Microsoft Sentinel has built-in connectors for Azure AD, Microsoft 365, and most PAM platforms), syslog forwarding for on-premises systems, or API-based collection for cloud platforms.
3. Normalise the data — Ensure privileged account events from different sources use consistent field names (username, source IP, action type, target system) so your correlation rules work across platforms.
4. Build correlation rules — Combine events from multiple sources. For example: “Admin activates Azure PIM role” + “Same admin accesses server via RDP within 10 minutes” + “Bulk file copy from that server” = potential data exfiltration alert.
5. Create dashboards — Build a privileged activity dashboard showing: number of privileged logins per day, JIT activations and durations, credential checkouts from the vault, failed privileged login attempts, and open alerts.

Key Log Sources by Platform

• Active Directory — Windows Security Event Log on domain controllers. Key event IDs: 4728/4732 (member added to security group), 4720 (user account created), 4726 (user account deleted), 4672 (special privileges assigned to new logon).
• Azure AD / Entra ID — Sign-in logs and Audit logs, available via the Azure Portal, Microsoft Graph API, or direct Sentinel integration.
• CyberArk — Vault audit log and Privileged Session Manager recordings, exportable via syslog or the CyberArk REST API.
• AWS — CloudTrail for API activity, GuardDuty for threat detection, and IAM Access Analyzer for permission analysis.

Why This Matters

Detection is the safety net beneath your preventive controls. No matter how well you implement JIT access, credential vaulting, and PAWs, determined attackers will eventually find a way in. Monitoring ensures you detect that intrusion in minutes or hours rather than weeks or months. The difference between a contained incident and a catastrophic breach often comes down to how quickly you spotted the anomalous privileged activity. For SMEs, even basic monitoring — alerts on privileged group membership changes and after-hours admin logins — provides significant detection capability at minimal cost, especially when using cloud-native tools like Microsoft Sentinel or AWS GuardDuty that require no infrastructure investment.

What to Do Now

• Enable audit logging on all domain controllers, Azure AD tenants, and cloud platform accounts if not already active.
• Configure alerts for the five critical alert rules listed above — these are your highest-value detections.
• Forward privileged activity logs to your SIEM or log management platform.
• Build a privileged activity dashboard showing daily login counts, JIT activations, and credential checkouts.
• Assign a team member to review the privileged activity dashboard daily during the first 90 days.
• Test your alerts by performing a controlled privileged action (e.g., adding a test account to Domain Admins) and verifying the alert fires correctly.

Evidence to Collect

• Alert rule configurations showing triggers, thresholds, and notification channels for privileged activity alerts.
• SIEM dashboard screenshots showing privileged activity monitoring views.
• Log source inventory documenting which systems forward privileged activity logs to the SIEM.
• Sample alert notifications showing the alert fired and was investigated.
• Monthly report summarising privileged activity metrics: total logins, JIT activations, failed attempts, alerts triggered, and mean time to investigate.
• Test records showing controlled alert validation exercises.

Common Mistakes

• Alert fatigue — Setting alert thresholds too low generates hundreds of daily alerts that nobody reads. Start with a small number of high-confidence alerts and expand gradually.
• Monitoring without response — Alerts that fire but are never investigated provide zero security value. Ensure every alert has a defined owner and response procedure.
• Ignoring service account activity — Organisations often focus monitoring on human admin accounts but ignore service accounts, which are frequently more powerful and less watched.
• Not correlating across sources — A privileged login on its own may be benign. Combined with a VPN connection from an unusual location and a large file transfer, it becomes suspicious. Correlation is where the real detection value lies.
• Logging without retention — If your logs are overwritten after 30 days but the average attacker dwell time is 21 days, you may lose critical forensic evidence. Retain privileged activity logs for at least 12 months.

---

Knowledge Check

---