How Active Directory Alert Profiles Work

1. How does the InfraSOS platform handle events

Active Directory Alert Profiles allow users to build workflows based on the events collected by the host machine where the Agent service is installed, including the events triggered on the Active Directory domain controllers. Basic flow on how the Agent service can fetch events depicted on the schema diagram below. For example, in the common scenario, a user can have two domain controllers (DC1 and DC2), which are configured as forwarders of Windows Events (WEF) and a separate server (InfraSOS agent server) which will be configured as a collector of Windows Events (WEC).

Please note that to avoid missing important alerts, you must configure forwarding of specific events for which alert profiles have been configured to the server with the Agent service installed.

The Agent service periodically checks the ForwardedEvents log and reads only these events that were configured in the Alert Profiles InfraSOS portal page. All other events will not be touched.

Collected events will be transferred via secure connection to the infraSOS platform. 

All details about events are stored in an encrypted way, so users can be sure that any sensitive information is secure and will not be read by anybody except company users on the Active Alerts page.

2. How Event ID and Provider Name combination works

A Provider is the component that emits the event.

Examples:

• Microsoft-Windows-Security-Auditing
• Service Control Manager
• Microsoft-Windows-Kernel-Power
• Application Error

Technically, a provider is: an EXE, DLL, or driver; registered with Windows Eventing; has its own namespace of Event IDs

An Event ID is just a number defined by that provider.

Important: Event IDs are NOT globally unique; The same Event ID number can mean completely different things for different providers

Example:

Event ID 1

• From Service Control Manager → service start/stop related
• From Microsoft-Windows-Kernel-Power → power or sleep-related
• From Application Error → app crash details

We need to use a combination of Event ID and Provider name, because Windows resolves events like this:

(Provider Name, Event ID) → Message Template

The message text that the user can see in Event Viewer is loaded from: the provider’s message DLL, indexed by Event ID. So, Event ID 4624 means “An account was successfully logged on”, ONLY because the provider is Microsoft-Windows-Security-Auditing. Event ID 4624 from another provider would be meaningless or invalid.

How do we use it in our service?

When a user creates an Alert Profile, he must define Event ID and Provider Name fields which will be used in the query to search for required events. 

Also our platform checks the existence of provider metadata for specified Provider and returns event attributes that can be used in the Filters and Alert Details Message.

Agent service has a predefined list of logs that will be checked for events: Application, Security, System, Setup, Active Directory Web Services, DFS Replication, Directory Service, DNS Server, HardwareEvents, Key Management Service and the main log for checking events from other servers - ForwardedEvents.

3. Event receiving delay

Active Directory is a distributed system composed of multiple Domain Controllers (DCs). While directory data (users, groups, policies) is replicated between Domain Controllers, Windows Event Logs are not replicated.

Key points:

• Each event is written locally on the Domain Controller where it occurs
• Event Logs are local to each server
• Active Directory replication does not include event logs

Example

Consider a domain with three Domain Controllers:

• DC-1
• DC-2
• DC-3

If a user authentication request is handled by DC-2, the corresponding event (for example, Event ID 4624 or 4625) will be recorded only in the event log of DC-2.

The same event:

• will not appear on DC-1 or DC-3
• will never be replicated to other Domain Controllers

This applies to many important domain events, including:

• Successful and failed logons
• Kerberos authentication events
• LDAP operations
• Account lockouts
• Password changes
• Replication and directory service errors

If the Agent service is installed on a regular Windows Server (not a Domain Controller) and reads only local event logs, it will:

• see events generated only on that server
• not see events generated on Domain Controllers
• even if the server is joined to the domain

This is expected Windows behaviour. Being a member of the domain does not grant access to domain-wide events automatically. The Agent service should be installed on the server, which is configured as a collector server and will collect events from the domain controllers.

The Agent service is responsible for:

• read events from the ForwardedEvents log
• aggregate events coming from all Domain Controllers for configured Alert Profiles
• ensure consistent and complete event processing

However, event forwarding is not instantaneous.

Why a 15-Minute Processing Delay Is Used

Event forwarding involves:

• network delivery
• buffering on Domain Controllers
• batching and asynchronous processing

Because of this, some events may arrive at the collector with a delay. To ensure that all events generated on any Domain Controller are successfully forwarded, the Agent service intentionally introduces a 15-minute delay before processing events.

This delay ensures that:

• late-arriving events are not missed
• temporary network or load-related delays are tolerated
• the event dataset is complete and consistent

The Agent service always processes events in a time window that ends 15 minutes in the past, guaranteeing that all relevant events have had enough time to reach the collector.

What This Means for Event Collection

• The Agent service receives all domain events, not just local ones
• Events are collected from every Domain Controller configured to forward their events
• The 15-minute delay prevents data loss caused by forwarding latency
• The ForwardedEvents log becomes the single source of truth for domain activity

4. Event forwarding details

Windows Event Forwarding (WEF) is a native Windows feature that allows event logs from multiple Windows systems (event sources) to be centrally collected on a designated server (event collector).

It is commonly used for:

• Centralized logging
• Security monitoring
• Incident response
• Compliance and auditing
• SIEM ingestion

WEF uses Windows Remote Management (WinRM) and HTTP/HTTPS for communication.

Active Directory replicates directory objects and attributes, but it does not replicate security audit events.

As a result:

• Authentication events exist only on the Domain Controller that processed the request
• Privilege usage and object access are logged only on the originating DC
• Security tampering actions are visible only locally

Therefore, every Domain Controller must forward its events to a central collector.

Failure to do so creates permanent blind spots in security visibility.

We will define which Windows events should be forwarded from all Domain Controllers to centrally collect Active Directory–related activity, including:

• Authentication & authorization
• Account and group changes
• Directory service changes
• Privilege abuse
• Replication issues
• Kerberos and NTLM activity
• Policy changes
• Potential attack indicators

Events that the user might want to forward to the event collector machine (server where the Agent is installed)

Below is the list focused especially on Active Directory Domain Controllers and non-replicated events (authentication, logons, Kerberos, NTLM, live security activity).

Authentication & logon (non-replicated — absolute must have)

Authentication and logon events represent the ground truth of access to the domain. These events record who authenticated, when, from where, and using which method.

Logon / Logoff / Credential usage

Why these events matter

Authentication and logon events represent the most fundamental security signal in Active Directory.

They are DC-local, non-replicated, and are often the first observable indicator of compromise.

These events allow you to:

• Reconstruct exact user and machine access timelines
• Detect brute-force, password spraying, and credential stuffing
• Identify lateral movement (same account authenticating to many systems)
• Correlate access with privilege escalation or data access
• Perform forensic reconstruction after an incident

Without collecting these events from every Domain Controller, you lose:

• Visibility into which DC authenticated the user
• Evidence required for incident response and legal investigations
• The ability to distinguish legitimate vs malicious access

Kerberos  (DC-Local — not replicated)

Kerberos is the primary authentication protocol in Active Directory. Kerberos events provide insight into ticket issuance, renewal, and failures.

Kerberos ticket lifecycle

Kerberos failures

Why these events matter

Kerberos events provide deep visibility into how credentials are used inside the domain.

They are essential for detecting advanced and stealthy attacks that do not rely on password failures.

Kerberos telemetry is critical to:

• Detect Golden Ticket / Silver Ticket attacks
• Identify pass-the-ticket activity
• Track service account abuse
• Detect pre-authentication bypass attempts
• Understand authentication behaviour in hybrid AD / ADFS / Azure AD environments

Attackers often:

• Avoid failed logons entirely
• Reuse valid Kerberos tickets

• Persist long-term using forged tickets

  
  
  

Without Kerberos events:

• Many attacks appear as “normal successful logons”
• You lose the ability to detect credential replay and ticket forgery
• Advanced threats remain invisible

NTLM authentication (DC-Local)

NTLM is a legacy authentication protocol retained for compatibility. Despite its age, it remains frequently abused by attackers.

Critical for:

• Legacy systems
• NTLM relay detection
• Password spraying

Why these events matter

NTLM is a legacy authentication protocol that is frequently abused because:

• It is weaker than Kerberos
• It is often enabled for compatibility
• Many security teams forget to monitor it

NTLM authentication events are vital for:

• Detecting NTLM relay attacks
• Identifying legacy systems and weak configurations
• Tracking credential reuse across systems
• Detecting authentication attempts from unexpected sources

NTLM is commonly used in:

• Lateral movement
• Credential harvesting
• Man-in-the-middle attacks

If NTLM events are not collected:

• Attackers can move laterally without triggering Kerberos alerts
• You lose visibility into one of the most abused protocols in AD

User & Computer account management

These events record creation, modification, enablement, disablement, and deletion of user and computer accounts.

User account lifecycle

Why these matter

• Detect unauthorized account creation or removal
• Track password abuse and credential recovery attacks
• Identify lockout attacks and lateral movement attempts

Computer account lifecycle

Why these matter

• Detect rogue machine joins
• Identify machine account takeover or manipulation
• Monitor AD trust abuse via fake computer objects

Group membership

Group membership changes are one of the most common and effective privilege escalation techniques in Active Directory.

Group creation, deletion, and membership changes

Why these matter

• Primary signal for privilege escalation
• Detect Domain Admin / Enterprise Admin abuse
• Identify persistence techniques using group membership

Privilege use & object access (DC-Local)

These events show what authenticated identities actually did after gaining access, including permission changes and privileged operations.

Why these events matter

These events show what authenticated identities actually did after logging in.

They are essential for detecting abuse of permissions, stealthy privilege escalation, and directory manipulation.

They allow you to:

• Detect unauthorized permission changes
• Identify abuse of powerful user rights
• Monitor access to sensitive AD objects
• Detect DCShadow, ACL abuse, and stealth persistence
• Correlate access with group membership or policy changes

Attackers frequently:

• Modify object permissions instead of adding group members
• Grant themselves future access silently
• Abuse privileges without creating new accounts

Without these events:

• Privilege escalation may leave no visible trace
• AD object tampering goes undetected
• You cannot prove how persistence was achieved

Domain, Trust & Policy changes

(High-impact, low-frequency events)

These events record high-impact configuration changes that affect the entire domain or its trust relationships.

Why these matter

• Detect domain-level persistence and trust abuse
• Identify stealth configuration changes by attackers
• Required for compliance, forensics, and incident response

DC tampering, Evasion & Health

These events indicate attempts to interfere with Domain Controller operation or security controls.

Why these events matter

These events indicate direct interference with the Domain Controller itself or attempts to:

• Disable logging
• Evade detection
• Establish long-term persistence
• Manipulate system behaviour

They are critical for detecting:

• Log clearing and evidence destruction
• Time manipulation to confuse investigations
• Malicious services or scheduled tasks
• Audit policy tampering
• Attempts to blind security monitoring

Attackers often:

• Clear logs after successful compromise
• Modify audit settings to avoid future detection
• Use scheduled tasks and services for persistence

If these events are missing:

• You may never know that logs were erased
• Security controls may be disabled silently
• Investigations become incomplete or impossible

5. How the custom alert details message works

Users can customize messages that will be displayed in the Alert Details column of the active alert table and include dynamic information that users can get from the event properties. 

The list of attributes can be found by clicking on the “+Attribute” button. This list is populated after querying provider metadata on the host machine where the Agent service is installed. To do that, type the event id and choose the right provider name, and the platform will try to find provider metadata and the list of attributes.

But not all providers have metadata with the list of attributes that the Agent can fetch. In this case, dynamic messages cannot be built, and users should specify some common Alert Details message.

Users can choose any number of attributes from the list and build useful, dynamically changed messages that will represent details from the event.

Configuring detailed alert messages is only possible when the Agent service is online, as we need to update the list of available attributes to provide the best user experience.

So once the user defines a custom dynamic message, the platform updates the configuration on the Agent service side. When the Agent service fetches required events, it uses a provided template to build dynamic messages by replacing the attributes with their values from the event properties. Next, the Agent sends these details to the platform, so users can see useful event descriptions in the Active Alerts table.

6. How filters work

If provider metadata exists in the system, users will be able to use attributes for the events filtration for an alert profile. These filters work in the same way as Nested Filters in AD reports.

To start adding filters, users should click on the “Add a rule” button on the Create new Alert Profile page and add desired rules.

Please note that currently, users cannot update filters after an Alert Profile has been created. Pay extra attention to the filters you want to use.

Users can create complex filters using groups of filters. To create a group, users should click on the “Add a group” button. This will allow users to add multiple rules and combine them using different logical operators.

Filters allow users to select the events that an alert profile should respond to more precisely, thereby filtering out irrelevant events. This will enhance the ability to react to events in a targeted manner and make workflows more efficient.