« Microsoft IIS Connection Strings Decryption Kerberos Traffic from Unusual Process »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Untrusted DLL Loaded by Azure AD Connect Authentication Agent

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Untrusted DLL Loaded by Azure AD Connect Authentication Agent

edit

Identifies the load of an untrusted DLL by the Azure AD Connect Authentication Agent, which may indicate an attempt to persist or intercept credentials passing through the Pass-through Authentication service.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.library-*
  • logs-windows.sysmon_operational-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Resources: Investigation Guide

Version: 107

Rule authors:

  • Elastic
  • Matteo Potito Giorgio

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Untrusted DLL Loaded by Azure AD Connect Authentication Agent

Possible investigation steps

  • Is the loader the expected Azure AD Connect PTA service on the expected host?
  • Focus: process.name, process.executable, process.code_signature.subject_name, process.code_signature.trusted, and host.id.
  • Implication: escalate if the loader is not the standard Microsoft PTA service binary or its signer/path differs from the recognized sync-host installation; lower suspicion only when the loader is the expected service on a recognized Entra Connect host. Identity does not clear the DLL load.
  • What module loaded, and does its identity and path fit a recognized component?
  • Focus: dll.path, dll.hash.sha256, dll.code_signature.subject_name, dll.code_signature.trusted, and dll.pe.original_file_name; compare the module path with the service path from step 1 to assess side-loading from temp, download, user-writable, UNC, or paths outside the expected service directory.
  • Implication: escalate when the module is untrusted, renamed, newly signed by an unexpected publisher, or outside the service’s expected directory tree; lower suspicion only when hash, original name, signer status, and path fit a recognized agent component or security tool loaded by this service.
  • Was the module recently dropped, renamed, or placed by a different process?
  • Focus: dll.Ext.relative_file_creation_time, dll.Ext.relative_file_name_modify_time, and file events where file.path equals the alert dll.path on host.id. !{investigate{"description":"","label":"File events for the loaded module","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}}
  • Hint: if recency fields or file events are absent, treat provenance as unresolved rather than benign; expand the time range to the creation or rename time when the recency fields point outside the default pivot.
  • Implication: escalate when a different process recently wrote, renamed, or timestomped the DLL; lower suspicion when provenance shows a recognized updater or tooling writer that explains this maintenance event on the sync host.
  • Does the service’s startup and lineage context fit normal Azure AD Connect operations?
  • Focus: process start event for process.entity_id: process.parent.executable, process.parent.command_line, and process.command_line. !{investigate{"description":"","label":"Process start for the authentication service","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate if the service was started, restarted, or manipulated by an unusual parent, script, or interactive admin tool; lower suspicion when lineage matches normal service-control or agent-update activity.
  • Was the service handling sign-ins around the load, and which identities may have been exposed?
  • Focus: if Windows Security authentication telemetry is collected, recover the service session from process.Ext.authentication_id, then query events on host.id where winlog.event_data.TargetLogonId matches it.
  • Hint: this exposure pivot depends on an additional data source that may not be collected on every PTA host; read winlog.event_data.TargetUserName, source.ip, event.outcome, and winlog.event_data.AuthenticationPackageName. Missing authentication telemetry is unresolved, not benign.
  • Implication: escalate credential exposure when successful sign-ins or repeated attempts overlap the load because a malicious module could access PTA credentials handled by the service; bound exposure as lower only when authentication records show the service was idle and the module, provenance, and lineage evidence also fit benign activity.
  • If earlier findings remain suspicious, do additional module loads or related alerts show broader service or host compromise?
  • Focus: related alerts for the same service process.entity_id. !{investigate{"description":"","label":"Alerts associated with the same service process instance","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: review related alerts for host.id only if local evidence remains suspicious; test one adjacent variant: signed-but-new DLLs in the same PTA service tree. !{investigate{"description":"","label":"Alerts associated with the Azure AD Connect host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Implication: escalate scope when the same service process or host has service-tampering, credential-access, persistence, or unusual module-load alerts; keep scope local only when local evidence is benign and related-alert review is clean; preserve and escalate if related-alert coverage is unavailable and the module remains suspicious.
  • Escalate when the PTA service loads an unrecognized module, provenance is suspicious, lineage is abnormal, or sign-ins could have been exposed; close only when loader, module, path, writer, and host context all fit a repeatable maintenance pattern on the sync host; preserve and escalate if mixed or incomplete.

False positive analysis

  • Azure AD Connect upgrades, agent reinstallation, or a recognized endpoint-security component can legitimately load modules into the service. Confirm only when dll.hash.sha256, dll.code_signature.subject_name, dll.path, process.parent.executable, writer provenance, and host.id align with the same maintenance or tooling workflow, and no adjacent service-tampering alerts appear. If this is a first-seen pattern and records are unavailable, keep it unconfirmed rather than closing on a partial match.
  • Build exceptions only after the benign workflow is fully confirmed, using host.id, exact dll.path, stable dll.hash.sha256, and the recognized process.parent.executable or writer process. Avoid exceptions on process.name, user.id, or all untrusted modules alone.

Response and remediation

  • If confirmed benign, reverse containment and document host.id, process.entity_id, dll.path, dll.hash.sha256, and the recognized maintenance or tooling context. Create an exception only if that same pattern recurs across prior alerts.
  • If suspicious but unconfirmed, preserve the alert export, service process identity, loaded DLL sample and hash, writer evidence, and surrounding Windows Security records. Apply reversible containment first, such as removing the host from PTA rotation or restricting administrative access, and escalate to host isolation only if likely credential exposure or broader host tampering is confirmed and the outage impact is acceptable. Do not delete the DLL or stop the service before collecting evidence.
  • If confirmed malicious, use endpoint response to isolate the host if it is available; otherwise escalate with host.id, process.entity_id, module path and hash, writer process, and the potentially exposed identity set to the team that can remove the server from service. Before stopping the service or deleting files, collect the DLL, any feasible memory capture, and related dll.path artifacts. Review other PTA or Azure AD Connect hosts and identities that authenticated around the load before eradicating the unauthorized module and persistence artifacts, then rotate or reset confirmed or likely exposed Azure AD Connect, PTA, or user credentials and revalidate the service configuration before returning the host to rotation.
  • Post-incident hardening: restrict write access to the Azure AD Connect Authentication Agent directories, review administrative access to the PTA host, retain image-load, file, process, and authentication telemetry, and record which telemetry sources limited the investigation.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
library where host.os.type == "windows" and process.name : "AzureADConnectAuthenticationAgentService.exe" and

not dll.code_signature.trusted == true and
not dll.path : (
    "?:\\Windows\\assembly\\NativeImages*",
    "?:\\Windows\\Microsoft.NET\\*",
    "?:\\Windows\\WinSxS\\*",
    "?:\\Windows\\System32\\DriverStore\\FileRepository\\*"
)

Framework: MITRE ATT&CKTM

« Microsoft IIS Connection Strings Decryption Kerberos Traffic from Unusual Process »