4.9. Scan threads callstack (threads)

Option: /threads

This scan provides another layer of shellcode detection, allowing to capture "sleeping beacons", and others, decrypted just before the execution.

Sometimes the implanted shellcodes cannot be detected by patterns. It happens due to various reasons.

• First of all, the number of patterns for which we can scan is limited, and with some effort, it is possible to write shellcode that does not contain them.
• Another case are so-called sleeping beacons. They are shellcode beacons that are kept in a memory in an encrypted/obfuscated way, and decrypted only before the execution. They are deployed for small periods of time, divided by long periods of sleep. Example: ShellcodeFluctuation. We still have a chance to detect them by patterns: if we scan the process in a loop, eventually we will hit the window of time during which the shellcode is decrypted (example here). However, this is not the best solution if we want to search implants among multiple processes - only when we have some clearly defined suspects.

To cover such cases, and extend the capabilities of shellcode detection, thread scan is added.

This type of a scan does not search for patterns, but instead, walks through all the threads and examines their stack frames, searching for return addresses that lead to unknown memory regions. This may arise suspicion, that the execution will return to a shellcode at some point.

The suspicious region is dumped for further examination. False positives are possible, so the review of the dumped material is required. Keep in mind that at the time of dumping, the shellcode may be in encrypted form. Once we get suspects, we may further scan the process once again in a loop (like shown here), in order to extract the shellcode in a plaintext form.