Hunt-Sleeping-Beacons: identify beacons

by do son ·

identify beacons

Hunt-Sleeping-Beacons

The idea of this project is to identify beacons which are unpacked at runtime or running in the context of another process.

To do so, I make use of the observation that beacons tend to call Sleep between their callbacks. A call to sleep sets the state of the thread to DelayExecution which is taken as a first indicator that a thread might be executing a beacon.

After enumerating all threads whose state is DelayExecution, multiple metrics are applied to identify potential beacons.

Metrics

  1. If the beacon does not make use of file-backed memory, the callstack to NtDelayExecution includes memory regions that can not be associated with a file on disk.
  2. If the beacon uses module stomping, one of the modules in the callstack to NtDelayExecution is modified

Projects, such as Threadstackspoofer, hook Sleep to spoof the callstack or to use another technique to wait between callbacks. Thus, I added two more metrics:

  1. Inline Hooks of Sleep can be fingerprinted by enumerating memory areas marked as private (not shared) storing the .text segment of Kernel32. This also applies if the hook is removed temporarily
  2. Since a beacon spends more time waiting for commands than actually executing code, it can be fingerprinted by comparing the fields KernelTime and UserTime of SYSTEM_THREAD_INFORMATION. Initially, I thought that the time sleeping would count as time spent in Kernelmode, but it turned out the other way. I am not sure why :’P Additionally, both fields increase only after the operator executed some commands with the beacon. Also here, I am not sure why :’P

To decrease false positives, I decided to considerate only processes with loaded wininet.dll or winhttp.dll. Additionally, I had to ignore jitted processes (.NET) and modifications to ntdll.dll which also seems to happen legitimately. Metric three and four are still applied though.

Download