You are browsing the archive for Compromise Detection.

Beyond good ol’ Run key, Part 44

August 19, 2016 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response

In my previous post I described a persistence mechanism that is triggered when someone is connecting to the infected system via RDP.

This is an interesting way to stay alive, but it would be probably much better if we could apply the same logic not to the server, but to the client.

That is – launch a DLL of our choice anytime someone tries to use mstsc.exe…


Not really.

Did I mention testing?

Yet another artifact that seems to be testing-related is this:

  • HKLM\SOFTWARE\Microsoft\Terminal Server Client
    ClxDllPath=<path to DLL>


Adding this to the Windows 10 Registry:


will give us the following result:

test_clientThe c:\test\test_client.dll is loaded anytime we start mstsc.exe.

We don’t even need to connect to the real system. Just launching mstsc.exe is enough,

Beyond good ol’ Run key, Part 43

July 28, 2016 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Incident Response, Malware Analysis

Testing, testing, testing… such an important part of the software development cycle. So important that its components are often referenced in the release code.

The testing functionality in Microsoft products is nothing new. I wrote about it here, and here. And today I will write about yet another component which appears to be testing-related and… can be abused to achieve persistence. This time, on Windows 10 only (have not tested servers).

When Windows 10 accepts the remote desktop session, it queries the following Registry key:

  • HKLM\SYSTEM\CurrentControlSet\Control\
    Terminal Server\AddIns\TestDVCPlugin

If such key exists, the OS will attempt to read the Path value underneath.

Once the Path is read, the DLL that it points to will be loaded via LoadLibrary.

And that’s it! We now have yet another persistent mechanism to load the DLL. Anytime the first remote desktop session is established…

An example of the potential malicious Registry Entry is shown below:


In a test scenario, I created a DLL that – when loaded – creates a c:\test\test_attached file.

The following screenshot shows what happens:

  • The user is logged on (console session) – the two first commands show situation at that moment and no presence of the file created by the DLL
  • The user then logs on remotely (under the same account – rdp-tcp#1 session).
  • The moment user logs on, the c:\test\test_attached file is created – the code is loaded


The c:\test\test.dll is loaded into svchost.exe process and stays resident (until reboot/service restart)