Phant0m is a PowerShell script and targets the Windows Event Log Service in Windows operating system.

Because the most traces of a possible attack remain in the operating system logs. If we targeting Event Log Service first of all, let’s remember how services working on Windows operating system. When you look at the task manager, you see a lot of svchost.exe. If we are interested in Windows’ own services, we need to know how svchost.exe works and why?

Svchost is essential in the implementation of so-called shared service processes, where a number of services can share a process in order to reduce resource consumption. Grouping multiple services into a single process conserves computing resources, and this consideration was of particular concern to NT designers because creating Windows processes takes more time and consumes more memory than in other operating systems, e.g. in the Unix family.¹ This means briefly that; On Windows operating systems, svchost.exe manages the services and services are actually running under svchost.exe’s as threads.

P.S: If you want to get more detailed information about the threads I would recommend you to read this, Processes, Threads, and Jobs in the Windows Operating System.

Phant0m works briefly as follows;

1. Detect the process of the Windows Event Log Service in the target operating system.
2. Get thread list and identify the Windows Event Log Service thread IDs.
3. Kill all threads about the Windows Event Log Service.

If Phant0m runs successfully, Windows Event Log Service will not work. So the target system will not be able to collect logs and will not be able to send logs because it can not collect logs. At the same time the Windows Event Log Service will appear to be running because the svchost.exe process for the Windows Event Log Service has not been stopped but only the related threads have been stopped. This is the main advantage and purpose of Phant0m’s. The service stops, but everything seems to be working.

If you want to do something like Phant0m does, you need to detect service name from thread ID. There are two ways I know, you can follow. In short, the first way is to get the subProcessTag value from Windows Event Log Service threads in their Thread Environment Block (TEB). The second way is to detect the DLLs used by the Windows Event Log Service threads.

Getting subProcessTag Value From TEB

When each service is registered on a machine running Windows Vista or later, the Service Control Manager (SCM) assigns a unique numeric tag to the service (in ascending order). Then, at service creation time, the tag is assigned to the TEB of the main service thread. This tag will then be propagated to every thread created by the main service thread. For example, if the Foo service thread creates an RPC worker thread (note: RPC worker threads don’t use the thread pool mechanism more on that later), that thread will have the Service Tag of the Foo service.²

If you want to use this way, you need to use NtQueryInformationThread API to get the thread’s TEB address, after then you need to read the SubProcessTag from the TEB. You can do NtReadVirtualMemory and I_QueryTagInformation APIs.

You can access sample code from here, HOWTO: Use I_QueryTagInformation.

Walking Threads Stack

We can access stack of thread and search for which DLLs are used by the specific thread. Windows Event Log Service uses wevtsvc.dll. Full path is %WinDir%\System32\wevtsvc.dll. If the thread is using that DLL, it is the Windows Event Log Service’s thread. That’s the way Phant0m uses.

Killing Threads

Whichever way you prefer, if you have identified threads of Windows Event Log Service you can go to the killing stage. This section is easier and faster, you need to three API for killing threads. You can do that OpenThread, TerminateThread and CloseHandle APIs.

You can access Phant0m’s code on GitHub and watch the video on YouTube about using Phant0m.