Endpoint malware

Overview

This playbook covers AV/EDR detections for malware families that do not have a dedicated playbook. It applies to alerts such as:

• '<MalwareName>' malware was detected / was prevented / was detected during a scheduled scan
• '<Name>' detected on one endpoint
• Malware incident / Malware detection involving one user
• Multiple threat families detected on one endpoint
• Suspicious files incident on one endpoint
• Unwanted software incident on one endpoint
• Endpoint attack notifications (drive-by download, infostealer campaigns)

Rimecud, Gamarue, and Jenxcus are USB-propagating worm families that ARE covered by this playbook — see playbooks/index.md for the alert-title routing.

The critical distinction is prevented vs. detected (executed). “Prevented” means AV blocked the threat before execution — low impact. “Detected” or “detected during a scheduled scan” means the file existed on disk and may have executed — higher impact requiring deeper investigation.

Key tables and columns

Table	Use	Key columns
DeviceEvents	AV detection events (AntivirusDetection, OtherAlertRelatedActivity)	DeviceId, DeviceName, ActionType, FileName, FolderPath, SHA256, InitiatingProcessFileName, AdditionalFields
DeviceFileEvents	File creation, modification, and download telemetry	DeviceId, FileName, FolderPath, SHA256, FileOriginUrl, FileOriginIP, InitiatingProcessFileName
DeviceProcessEvents	Process execution — did the malware run?	DeviceId, FileName, ProcessCommandLine, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
AlertEvidence	Pre-extracted entities (hashes, files, devices, users)	EntityType, EvidenceRole, SHA256, FileName, DeviceId

Important: AV/EDR detection events appear in DeviceEvents, not in DeviceFileEvents. For file creation/modification telemetry, use DeviceFileEvents. For detection and alert-correlated activity, use DeviceEvents.

Investigation steps

These supplement the general triage-ladder in docs/investigation.md.

1. Pull alert evidence. xdr incidents show <id> --expand alerts — extract the malware name, file hash (SHA256/SHA1), file path, device, user, and the detection verdict (prevented/detected/blocked). The alert category and mitreTechniques fields provide threat classification context.

2. Determine the verdict: prevented or executed? This is the most important determination.

   • Prevented / Blocked: AV stopped the threat before execution. Confirm no process with the file’s hash ran on the device.
   • Detected (including scheduled scan): The file was on disk. Check DeviceProcessEvents to determine if it executed:

   xdr library run ttp_malware_execution --param device_id=<device-id> --param sha256=<malware-hash> --param start=<start_minus_24h> --param end=<end>

3. Trace the delivery vector. How did the malware arrive on the device?

   xdr library run qry_delivery_vector --param device_id=<device-id> --param sha256=<malware-hash> --param start=<start_minus_24h> --param end=<end>

   • FileOriginUrl present → downloaded from web (check the URL).
   • InitiatingProcessFileName of outlook.exe / chrome.exe / msedge.exe → email attachment or web download.
   • File in a USB-related path → removable media (this playbook already covers USB-propagating worms — see the Rimecud/Gamarue/Jenxcus routing in playbooks/index.md — continue with the delivery-vector steps below, focusing on removable-media indicators).
   • FileOriginUrl empty and InitiatingProcessFileName is explorer.exe or an archiver (7z.exe, winrar.exe, tar.exe, etc.) → file was extracted from a container archive. The MOTW is on the parent archive, not the extracted file. Pivot to the archive:
     1. Infer the archive name from the flagged file’s FolderPath (e.g. flagged file in Downloads\OMEGA-REL_6.5.0.95\ → archive is likely OMEGA-REL_6.5.0.95.zip in Downloads\).
     2. Widen the time window to 1–7 days before the alert — the archive may have been downloaded well before extraction triggered the AV detection.
     3. Broad search — find all recently-downloaded archives on the device:

        xdr hunt run "DeviceFileEvents | where Timestamp between(datetime(<start_minus_7d>) .. datetime(<alert_time>)) | where DeviceId == '<device_id>' | where ActionType == 'FileCreated' | where isnotempty(FileOriginUrl) | where FileName endswith '.zip' or FileName endswith '.iso' or FileName endswith '.7z' or FileName endswith '.rar' or FileName endswith '.msi' | project Timestamp, FileName, FolderPath, SHA256, FileOriginUrl, FileOriginReferrerUrl, FileOriginIP, InitiatingProcessFileName | order by Timestamp desc | take 20"

     4. Narrow search — if you know the archive filename from the folder structure:

        xdr hunt run "DeviceFileEvents | where Timestamp between(datetime(<start_minus_7d>) .. datetime(<alert_time>)) | where DeviceId == '<device_id>' | where FileName =~ '<archive-filename>' | where ActionType == 'FileCreated' | project Timestamp, FileName, FolderPath, SHA256, FileOriginUrl, FileOriginReferrerUrl, FileOriginIP, InitiatingProcessFileName | order by Timestamp asc"

     • FileOriginUrl on the archive = download source URL.
     • FileOriginReferrerUrl = referring website stamped by the browser (the page the user was on when they clicked the download link).
     • InitiatingProcessFileName = browser that stamped the MOTW (e.g. msedge.exe, chrome.exe, firefox.exe).
     • External URL → internet-sourced; internal domain or empty FileOriginUrl on the archive itself → the zip arrived via a file share, email attachment, or USB — look further upstream.

4. Build the process tree. Understand what the malware did (or tried to do):

   xdr library run qry_process_tree --param device_name=<device-name> --param hours=2

   Look for: child processes spawned by the malware, persistence mechanisms, lateral movement attempts.

5. Scope the threat. Check if the same hash appears on other devices:

   xdr library run qry_file_hash_scope --param sha256=<malware-hash>

   Multiple devices with the same hash indicate a broader campaign or worm-like propagation.

6. Check for persistence (if malware executed). Look for registry modifications and new services:

   xdr library run ttp_new_service_creation

   Also check DeviceRegistryEvents for run keys:

   xdr library run ttp_registry_persistence --param device_id=<device-id> --param start=<start> --param end=<end>

7. Check for network indicators (if malware executed). Look for C2 or data exfiltration:

   xdr library run ttp_dns_beaconing

   Check DeviceNetworkEvents for outbound connections from the malware process.

Pivots

From	To	Why
File hash → other devices	qry_file_hash_scope library query	Blast radius — how many devices have this file?
Device → process tree	qry_process_tree library query	What did the malware do after landing?
File → delivery vector	DeviceFileEvents by SHA256	How did the malware arrive?
Device → registry changes	DeviceRegistryEvents by DeviceId	Did the malware establish persistence?
Device → network activity	DeviceNetworkEvents by DeviceId	C2 or exfiltration from the compromised device
Malware process → child processes	DeviceProcessEvents by InitiatingProcessSHA256	What processes did the malware spawn?

Common false positives

• EICAR test file. Used for AV testing. The alert will reference EICAR_Test_File explicitly.
• Potentially unwanted applications (PUA). Adware, bundleware (e.g., BrowserModifier, Diplugem, ZoomInfo, OneStart). Lower risk than trojans — assess whether the software is authorized by IT policy.
• Dual-use tools. Legitimate remote access tools (TeamViewer, AnyDesk), archiving tools, or system utilities that are also used by attackers. Check context — was the tool installed by IT or by a suspicious process?
• Compressed/archived malware that wasn’t extracted. Malware inside a zip/iso detected during scan but never extracted or executed. Verify no extraction event occurred.

Containment recommendations

Containment depends on whether the malware executed:

If prevented / blocked (no execution):

• The threat is neutralized. Confirm the hash doesn’t appear on other devices via qry_file_hash_scope. If isolated, this can often be closed as informational.

If executed or execution is uncertain:

1. Isolate the device.

   Suggest: xdr device isolate <device_id> --comment "<reason>" — prevents lateral movement and C2 while preserving evidence.

2. Run AV scan.

   Suggest: xdr device scan <device_id> — ensure the threat and any dropped files are cleaned.

3. Check for persistence and remove it. Malware that executed may have created services, scheduled tasks, or registry run keys that survive reboot.

4. If the malware is an infostealer (ChatGPTStealer, InfoStealer, NSteal, etc.):

   Suggest: assume credentials on the device are compromised. Reset the user’s password, revoke tokens, and rotate any service account credentials stored on the device.

5. Collect investigation package for high-severity incidents.

   Suggest: xdr device collect-package <device_id> — full forensic data for deeper analysis.