« NTDS or SAM Database File Copied First Time Seen Account Performing DCSync »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential Credential Access via Trusted Developer Utility

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

Potential Credential Access via Trusted Developer Utility

edit

An instance of MSBuild, the Microsoft Build Engine, loaded DLLs (dynamically linked libraries) responsible for Windows credential management. This technique is sometimes used for credential dumping.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.process-*
  • 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
  • Tactic: Defense Evasion
  • Resources: Investigation Guide
  • Data Source: Elastic Defend
  • Data Source: Sysmon

Version: 214

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Credential Access via Trusted Developer Utility

Possible investigation steps

  • What do the matched source events show about the MSBuild instance?
  • Focus: Timeline source events for process.entity_id — the start-event process.executable and process.command_line plus the library-stage dll.path.
  • Implication: more concerning when MSBuild loads vaultcli.dll or SAMLib.dll from an unusual path or unexpected context; more explainable when Timeline shows a recognized build task loading the library from the default Windows system directory.
  • Is the MSBuild binary and launch chain expected for this host?
  • Focus: process.executable, process.pe.original_file_name, process.code_signature.subject_name, and process.parent.executable.
  • Implication: more concerning when MSBuild is renamed, unsigned, user-writable, outside expected .NET Framework or Visual Studio build roots, or launched by Office, a script host, an archive utility, or another unexpected parent.
  • Does the command line or project path suggest transient or user-delivered build content?
  • Focus: process.command_line and process.working_directory, especially .csproj, .xml, .proj, /logger, or @ response-file paths in temp folders, downloads, removable media, user-profile paths, or network shares.
  • Implication: supports concern when MSBuild runs user-delivered project content, logger DLLs, response files, or inline tasks outside normal compilation; less suspicious when the project resides in a stable source-tree or CI workspace and the build arguments match a recurring compilation pattern.
  • Does the loaded credential library path, trust, and recency fit legitimate development behavior?
  • Focus: dll.name, dll.path, dll.code_signature.trusted, and dll.Ext.relative_file_creation_time.
  • Implication: supports concern when vaultcli or SAMLib loads from user-writable or transient paths, arrives unsigned, or was created shortly before the load; weaker support when the path is the expected Windows system directory and project context supports a recognized credential-management test.
  • Do file writes or child processes show MSBuild acting as a launcher instead of a compiler?
  • Focus: file activity from process.entity_id: written file.path values, especially payloads, scripts, or compiled artifacts in user-writable paths. !{investigate{"description":"","label":"File activity for the MSBuild process and children","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":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: review child starts where process.parent.entity_id equals the MSBuild entity; shell or script-engine children are stronger than normal compiler toolchain children. !{investigate{"description":"","label":"Child processes spawned by MSBuild","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.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: suggests proxy execution when MSBuild drops payloads, stages scripts or compiled artifacts, or spawns shells or script engines. Missing file telemetry is unresolved, not benign.
  • Do MSBuild or its child processes attempt off-host staging?
  • Focus: same-host connection events for the MSBuild process.entity_id or direct children where process.parent.entity_id matches the MSBuild entity, with destination.ip and destination.port. !{investigate{"description":"","label":"Network activity for the MSBuild process and children","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":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: supports containment when suspicious project, DLL, file, or child-process evidence is followed by outbound staging; missing network telemetry is unresolved, not benign.
  • Does the user and host context fit developer or build-runner activity?
  • Focus: user.id, user.domain, process.Ext.session_info.logon_type, host.id, and host.name; compare prior source events for the same user-host cohort.
  • Implication: risk rises when the user-host pair has no recurring build-tool history or when the session type is unexpected; lower only when the user, host, session, and source events fit a bounded developer or build-service pattern.
  • If local MSBuild evidence is still suspicious, does related alert history show the same user or host reusing trusted-utility abuse patterns?
  • Focus: related alerts for user.id, especially trusted-utility abuse, credential access, lateral movement, or launches of "InstallUtil", "RegAsm", "MSHTA", or similar signed proxies; inspect their source events before comparing project paths or destinations. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: compare host.id alert history to assess whether activity is confined to this asset. !{investigate{"description":"","label":"Alerts associated with the 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: suggests broader scope when the same user or host shows trusted-utility abuse, persistence, staging, or credential-access alerts; stays localized when history is limited to the same recognized build or test workflow on this asset.
  • Escalate when MSBuild identity, project path, loaded library, follow-on behavior, user-host context, or alert scope show unrecognized use, credential-library loads from non-standard paths, or payload behavior; close only when all jointly fit a recognized build or test scenario; preserve and escalate when evidence is mixed or visibility incomplete.

False positive analysis

  • Authorized credential-management tests, security-tool validation, or build pipelines compiling code that uses Windows credential APIs can legitimately trigger vaultcli.dll or SAMLib.dll loads. Confirm only when process.command_line, project path, dll.path, process.executable, process.parent.executable, user.id, and host.id align with that same recognized lab or build-pipeline workflow. If records are unavailable, require the same process-identity fields, loaded dll.path, and user.id/host.id to recur across prior alerts before treating the activity as benign.
  • Before creating an exception, validate that process.executable, process.code_signature.subject_name, process.parent.executable, stable process.command_line pattern, loaded dll.path, user.id, and host.id recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on process.name alone, the library name alone, or the host alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and record the confirmed explanation in process.executable, process.parent.executable, project path from process.command_line, loaded dll.path, user.id, and host.id. Create an exception only if that same pattern recurs consistently across prior alerts from this rule.
  • If suspicious but unconfirmed, preserve a case export for the recovered MSBuild process, its command line, project/task files, loaded credential DLL, dropped artifacts, child-process lineage, and confirmed destinations. Apply reversible containment first — temporary destination restrictions or heightened monitoring on host.id and user.id — and escalate to host isolation only when preserved evidence shows meaningful staging or payload risk.
  • If confirmed malicious, use endpoint response actions to isolate the host and terminate MSBuild or its staging child processes after preserving the recovered MSBuild and parent entity IDs, project files, compiled artifacts, child processes, confirmed destinations, and loaded DLL path. If direct endpoint response is unavailable, hand off that artifact set immediately to the team that can isolate the host or block the destinations.
  • Eradicate the malicious project files, inline tasks, payloads, persistence artifacts, and secondary tooling uncovered during the investigation, then remediate the delivery or execution-control gap that allowed MSBuild to proxy the credential-access behavior.
  • Investigate credential exposure based on what the project targeted: review Windows Credential Manager, saved secrets, and local-account exposure on the host, and rotate or revoke affected credentials according to the recovered artifacts and follow-on activity.
  • Review related hosts for the same project-path pattern, library-load combination, child-process behavior, and adjacent trusted-developer-utility abuse before deleting files or removing tooling, and retain process, library, file, and network telemetry needed for future cases.

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
sequence by process.entity_id
 [process where host.os.type == "windows" and event.type == "start" and (process.name : "MSBuild.exe" or process.pe.original_file_name == "MSBuild.exe")]
 [library where host.os.type == "windows" and dll.name : ("vaultcli.dll", "SAMLib.DLL")]

Framework: MITRE ATT&CKTM

« NTDS or SAM Database File Copied First Time Seen Account Performing DCSync »