Karma-X Blog

Introduction:

Today we tackle the challenge of detecting stealthy sleeping beacons. These beacons have behaviors that cause delays in execution for stealth. Our focus is on identifying subtle, yet critical, signs of execution.

Core Detection Technique:

We start by zeroing in on beacons that utilize Kernel32!Sleep, which in turn calls Ntdll!NtDelayExecution, leading the thread into a Wait:DelayExecution state. To detect these, we enumerate all threads in this state and scrutinize their call traces. The red flags are in the details – anomalies like unknown or modified modules and evidence of module stomping.

Confronting Foliage and AceLdr:

Next, we address the challenge posed by Foliage and its variants like AceLdr, which cleverly avoid the Wait:DelayExecution state. Instead, they encrypt themselves while waiting and initiate execution delays through a sequence of APCs to Ntdll!NtContinue. This cunning tactic changes the thread state to Wait:UserRequest’. To catch them, we shift our focus to spotting abnormal APC-initiated calls to Ntdll!WaitForSingleObject. AceLdr, for instance, reveals itself when we find threads in Wait:UserRequest’ state with return addresses pointing to Ntdll!KiUserApcDispatcher.

Decoding Waitable Timers Callbacks:

Our journey doesn't stop there. We also dive into the world of sleep encryption methods that use waitable timers, like Ekko. The trick here lies in first locating the callback dispatcher in ntdll.dll and then leveraging RtlCaptureContext’ for an in-depth stack analysis. The telltale sign of these methods is found in threads in `Wait:UserRequest’ state, especially those with return addresses to the dispatcher.

Conclusion:

Detection Is a constant game of cat and mouse, requiring us to persistently innovate and refine our methods to stay ahead of attackers. Karma-X even has further techniques that it keeps close to the chest to detect AceLdr and similar malware.

References:

Github: Hunt-Sleeping-Beacons