A Shared Arsenal: Identifying Common TTPs Across RATs

Summary

A Splunk post reviews how many remote access trojans and stealer families converge on the same baseline of MITRE ATT&CK techniques. It calls out repeatable behaviors like ingress tool transfer, host and network discovery, registry and scheduled-task persistence, defense evasion, and credential theft. At the same time, it notes small implementation differences that can still help separate families during triage. This approach supports more consistent cross-family hunting.

Investigation

The team mapped about eighteen malware families to ATT&CK, summarized the overlapping TTPs, and included practical code fragments covering persistence, token manipulation, and web-service usage. Examples span WMI queries, Run-key writes, schtasks creation, and PowerShell commands that add Windows Defender exclusions.

Mitigation

The guidance prioritizes technique-centric detections over family names: watch for abuse of common utilities (schtasks, reg, WMI), constrain outbound web service traffic, and harden credential-access controls. It also recommends tightening Windows Defender exclusion policies and alerting on token-privilege changes.

Response

When these techniques are detected, isolate the endpoint, collect key artifacts (registry hives, scheduled-task definitions, command-line logs), and hunt for related IOCs across the estate. Remove persistence, apply indicator-based blocks for known domains and hashes, and expand detections to cover the shared behaviors.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic.

• Attack Narrative & Commands:

  1. Reconnaissance: The attacker enumerates the OS version to verify the target is a Windows machine capable of using Run‑keys.
  2. Payload Preparation: A harmless test executable (notepad.exe) is chosen to avoid actual malicious impact while still representing a typical persistence payload.
  3. Persistence Implant: Using reg.exe, the attacker writes a new string value named ProvingMalware under HKCUSoftwareMicrosoftWindowsCurrentVersionRun, pointing to C:WindowsSystem32notepad.exe. This generates EventID 4657 with the Run‑key path, satisfying the detection rule.
  4. Verification: The attacker queries the registry to confirm the value exists.

• Regression Test Script:

  # -------------------------------------------------
  # Proving – Registry Run‑Key Persistence Simulation
  # -------------------------------------------------
  try {
      # 1. Verify OS is Windows
      if (-not $IsWindows) {
          throw "Script can only run on Windows."
      }
  
      # 2. Define Run‑key path and malicious payload
      $runKey = "HKCU:SoftwareMicrosoftWindowsCurrentVersionRun"
      $valueName = "ProvingMalware"
      $payloadPath = "$env:SystemRootSystem32notepad.exe"
  
      # 3. Write the malicious Run‑key (this triggers EventID 4657)
      New-ItemProperty -Path $runKey -Name $valueName -Value $payloadPath -PropertyType String -Force |
          Out-Null
  
      Write-Host "[+] Run‑key $valueName added under $runKey pointing to $payloadPath"
  }
  catch {
      Write-Error "[!] $($_.Exception.Message)"
  }

• Cleanup Commands:

  # Remove the simulated persistence value
  $runKey = "HKCU:SoftwareMicrosoftWindowsCurrentVersionRun"
  $valueName = "ProvingMalware"
  if (Test-Path "$runKey") {
      Remove-ItemProperty -Path $runKey -Name $valueName -ErrorAction SilentlyContinue
      Write-Host "[+] Cleaned up Run‑key $valueName"
  }