You are browsing the archive for Anti-Forensics.

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:

TestDVCPlugin0

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

TestDVCPlugin1

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

TestDVCPlugin2

Beyond good ol’ Run key, Part 42

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

The Ease of Access is a place where a computer user can enable the so-called Assistive Technologies (AT). These technologies make life easier for the users with needs and include OSK (On-Screen Keyboard,) Narrator, Magnifier, and a number of other options that are helping to make the work environment better.

AT_ease_of_access_1

Persistence #1

With Windows 8 Microsoft introduced a way to register third-party Assistive Technology applications on the system. All of them are stored inside the Registry under the following branch:

  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Accessibility\ATs

AT_ease_of_access_2

The same branch exists on Windows 7, but the registration is possible only on Windows 8+.

Interestingly, a user can decide to launch the ATs during the log on process. To do so, the following Registry value needs to be created/modified:

  • HKCU\Software\Microsoft\Windows NT\CurrentVersion\Accessibility\Configuration = …

where Configuration is a comma-delimited string list of ATs the user wants to load during the logon process.

As a result, one can achieve persistence by registering the new AT:

AT_ease_of_access_3

and ensuring the Configuration value points to it:

AT_ease_of_access_4

Once these are added the c:\test\malware.exe will be launched anytime the user logs on. And as a bonus, it will also run anytime the desktops switch (f.ex. when UAC pops up). The desktops-switch activity is depending on the TerminateOnDesktopSwitch value which you can read about in the linked article.

Obviously, elevated privileges are required to register the new AT.

Persistence #2

The obvious modification of the technique above could rely on modification of the existing AT entry and changing the executable path of f.ex. Narrator or OSK.

Sort-of-Persistence #1

If you look at how system launches the ATs you will notice that the process responsible for this task is called (not surprisingly) Windows Assistive Technology Manager and is launched from the AtBroker.exe file:

AT_atbroker

The AtBroker starts the ATs using the following syntax:

  • C:\Windows\System32\ATBroker.exe /start <AT name>

f.ex.:

  • C:\Windows\System32\ATBroker.exe /start malware

AT_atbroker2

One could add this command line to any of the typical Startup locations (f.ex. Run key) which – on the surface at least – would appear as if pointing to a legitimate, signed OS binary. Most of security products or analysts looking at such entry would assume it’s a legitimate, clean binary, and unless they understand the context and the connection/relationship with the AT Registry entries they would most likely ignore it (I didn’t test any security product though).

There is another aspect of launching malware this way – AtBroker is spawn by winlogon.exe so if the malware was executed via AtBroker proxy, the process parent wouldn’t point to Explorer which is a parent process to most processes launched manually via GUI. This could give an impression that the malware is a process spawn not by the user, but some system component (which is actually true).  As a result someone reviewing process tree could mistakenly assume it’s legitimate.

Sort-of-Persistence #2

As a side note – the interface of the Easy Access applet in Control Panel (or via Win+U) can be modified using the settings described in the article I linked to.  I have not explored it. Also, the applet itself could be leveraged as a ‘hidden’ persistence mechanism that would activate only when the user launched any of the available ATs manually (either registered, or modified to point to malware). Even if I am not using any of the ATs I do occasionally launch a Magnifier, or OSK. Such user-dependent persistence mechanism could be a ‘last resort’ persistence mechanism used to re-introduce malware on the system somewhere in the future.

As mentioned earlier, elevated privileges are required for all this, but this is not impossible – Escalation Of Privileges is not that hard to achieve as many exploits show.