TrustedInstaller, stopping Windows Defender

27 de September de 2021 Por

Often, during an intrusion process it can be useful to have the ability to disable the defense measures of the target computer. For those pentesters who have already tasted the joys of Microsoft’s default on-board security solution, Windows Defender, you will agree with me that it has improved substantially since its first releases, especially the latest cloud-enabled versions for Windows 10. Therefore, it is very likely that we will face this antivirus during an intrusion process, sooner or later.

Very briefly, the main component of Windows Defender is the “WinDefend” service, in charge of launching the continuous monitoring process “MsMpEng.exe” and loading its engine “mpengine.dll“, so if we are able to stop that service, we will be stopping its execution to a large extent.

For those of you who have ever tried to stop it, they will have noticed that it is not possible to stop it either as an Administrator user or even as a SYSTEM user.

It is true that it can be disabled, but not stopped (the service continues to run), through the graphical interface, but this option does not interest us since our malware will often not interact with the system in this way.

With this in mind, in the following lines we will see how to stop the antivirus service programmatically and we will present a PoC that you can easily include as a module in your favorite post-exploitation tool.

In order to understand the “internals” of the action we are going to carry out, we must be clear about two concepts: what is a Token and what is TrustedInstaller (TI).

Token

A token within the Microsoft Windows operating system is a security element that identifies processes and threads when they want to perform actions on securable system objects (files, registers, services…). In other words, it is like showing your ID card when you want to enter a discotheque.

It stores, among other things: the integrity level, the user to which the process belongs, the privileges and the groups. We will not go into more detail, since what matters to us is precisely the latter, the groups to which the process/thread that presents this security token belongs.

Note that a process or a thread that has the appropriate permissions and privileges can impersonate another user, this is called impersonating. Therefore our application can copy and/or use the token of another thread/process as long as we have permissions to open the remote process and obtain its token handler with the appropriate permissions (Impersonate/DuplicateToken).

Now that we know what a Token is and what we can do with it, let’s introduce the second concept, TrustedInstaller.

TrustedInstaller

For those of you who have ever tried to delete a file from the system and have not been able to do so, even if you are SYSTEM or Administrator, the owner of the file (TrustedInstaller) must have caught your attention. Well, TrustedInstaller is a fictitious group created by the SCM (Service control Manager) at boot time, constituting what is called a “Service Group”.

In other words, each service that is part of a modern Windows operating system has a dummy group that matches its name. This functionality is useful to provide access to all the securable objects (files, pipes, registers, tokens…) of the system that a service process can use, thus reducing the overhead introduced by checking the token against all the DACLs of the object.

So, as we have mentioned, TrustedInstaller is not only a group but also a service, and we can find it in the list of services on the computer as such, normally stopped, since it is started only when “Windows Update” requires to perform an update.

An astute reader at this point will think: well, this process and this group have a great power… It is true, even more than SYSTEM in the system. It is in our interest. As a curiosity, and if we want to differentiate between the real groups/users and the fictitious ones created by the SCM, we must look at the “Domain”, which is the prefix that appears before the user/group.

Normally the real ones are preceded by the prefix “NT AUTHORITY” while the synthetic service ones are preceded by “NT SERVICE”.

But let’s not lose focus of our goal: to stop the WinDefend service. Let’s see what protections it has.

On a Microsoft Windows operating system, everything is a securable object, and a service is no less, so it presents a set of DACLs and protection permissions. Let’s see what they are:

As you can see in the image above, the only security identity capable of stopping the Antivirus service (Full control) is itself and the TrustedInstaller service. It makes sense, since in order to update itself, TrustedInstaller.exe must be able to stop the antivirus and copy the new files. Note that not even the Administrator or SYSTEM group is able to do this.

As a first approach to our objective we could think of borrowing the token from “MsMpEng.exe” itself and impersonate it, since it presents the group “NT SERVICE/WinDefend”, but this is not possible since this process is a PPL (Protected Process Light) type process and therefore we will not be able to obtain a process handler that allows us to finally read its token, not even with debugging privileges (SeDebugPrivilege).

Therefore, we already know that only if we get a Token with the IT group included in it will we be able to stop the Antivirus service. Our next target is therefore the IT service.

First, we will start the service as administrators and will inspect the opening permissions of the process.

Perfect. It seems that it works for us, since to be able to access the token, we need access at the opening level of the process that contains PROCESS_QUERY_INFORMATION, PROCESS_QUERY_LIMITED_INFORMATION or PROCESS_ALL_ACCESS (Full control).

In addition, it should be noted that this process is not protected with PPL so it would allow us, a priori, to carry out its opening. How is it possible that Microsoft does not protect such an important process in the system? It is a feature, not a bug ¯\_(ツ)_/¯.

But it’s not that pretty. We require the use of the SeDebugPrivilege privilege, since the integrity level of the TI process is SYSTEM and that of our application is High, so it is below. Remember that to check if an object can access another one, first we check the Mandatory Integrity Control and then the Discretionary access control, in this case we comply with the second one but not the first one. SeDebugPrivilege allows us to skip both, but only for the opening of the process (OpenProcess).

Let’s inspect now the permissions of the primary token of the IT process, since in order to use it and impersonate it, it must allow us to do so through the IMPERSONATE permission for our user.

Being Administrators we see that it is not   

Here is the last open door that leads us to the way to stop Defender. As a summary we are going to see the series of calls to the WinApi that we need to achieve our goal.

In the following link you have the proof of concept based on a fork of “slyd0g” and the main iindea of “tiraniddo” modified in the achievement of the System token. Possibly, not even these authors are the original intellectuals, however, pull their references for more info.

https://github.com/lab52io/StopDefender

The good thing about this technique is that the Defender does not come back to life until one of the following tasks is executed (about 24h). If we wanted to disable it completely until the next reboot we would only have to disable them as IT, an exercise that is left to the reader.

Finally, note that there are multiple other ways to get a token from TrustedInstaller, which involve changes in how to get the token from System, even going as far as forging a token that presents this group without needing to steal it from the TrustedInstaller.exe process. However, this seems to me the most straightforward and simple, without requiring modification of services.

Happy hacking!

References

See also in: