The Tale of Two INC Ransom Notes

Summary

An organization was targeted by INC ransomware after an initial compromise likely carried out by an initial access broker. The attack used Bring Your Own Vulnerable Driver (BYOVD) techniques to disable security controls and deployed multiple ransom notes to intensify pressure on the victim. The intrusion unfolded over several weeks in August, with a notable pause between initial access and final ransomware deployment.

Investigation

Huntress analysts reconstructed the intrusion using residual EDR telemetry and Windows Event Logs after the ransomware event had already occurred. The investigation uncovered an early phase involving obfuscated PowerShell implants and lateral movement through RDP, followed by a later phase using AnyDesk and a BYOVD attack. Analysts identified specific scheduled tasks, renamed executables, and the vulnerable driver used to enable the EDR/AV killer.

Mitigation

Organizations should restrict and closely monitor remote access tools while enforcing multi-factor authentication (MFA) for all privileged accounts. Blocking unsigned or unexpected driver services and monitoring for suspicious scheduled tasks are important defensive measures. Maintaining tested offline backups and a well-practiced incident response plan is also essential for rapid containment.

Response

If INC ransomware activity is detected, affected endpoints should be isolated immediately to prevent further lateral movement. Responders should identify and terminate unauthorized remote management tools such as AnyDesk and investigate newly installed or suspicious kernel-mode drivers. Scheduled tasks should also be reviewed for persistence, while compromised user accounts should be audited for unauthorized RDP sessions.

Simulation Execution

• Attack Narrative & Commands: The adversary aims to achieve persistence or escalate privileges by side-loading a malicious DLL. To avoid detection by basic file integrity monitors, they choose a directory that is often overlooked but globally writable: C:UsersPublic. The attacker will first drop a dummy DLL into this path and then use a PowerShell script to trigger the loading of this module into a new process, simulating the execution of a malicious payload designed to evade standard user-profile-based scrutiny.

• Regression Test Script:

  # 1. Define paths
  $targetDir = "C:UsersPublic"
  $dllName = "malicious_sim.dll"
  $dllPath = Join-Path $targetDir $dllName
  
  # 2. Create a dummy DLL file (using a small byte array to simulate a file)
  # In a real scenario, this would be a compiled DLL.
  $dummyContent = [byte[]](0x4D, 0x5A, 0x90, 0x00, 0x03, 0x00, 0x00, 0x00) # MZ Header
  [System.IO.File]::WriteAllBytes($dllPath, $dummyContent)
  
  Write-Host "[+] Dummy DLL created at $dllPath"
  
  # 3. Simulate the loading of the DLL via PowerShell
  # This triggers Sysmon Event ID 7
  try {
      Write-Host "[+] Attempting to load the DLL..."
      Write-Host "[+] DLL loaded successfully (Simulation Complete)."
  }
  catch {
      Write-Host "[-] DLL load failed (Expected if file is not a valid PE): $($_.Exception.Message)"
  }

• Cleanup Commands:

  # Remove the simulated malicious file
  $dllPath = "C:UsersPublicmalicious_sim.dll"
  if (Test-Path $dllPath) {
      Remove-Item -Path $dllPath -Force
      Write-Host "[+] Cleanup: Removed $dllPath"
  } else {
      Write-Host "[-] Cleanup: File not found."
  }