You are browsing the archive for Compromise Detection.

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.


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


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:


and ensuring the Configuration value points to it:


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:


The AtBroker starts the ATs using the following syntax:

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


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


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.

Beyond good ol’ Run key, Part 41

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

Thinstall apps are portable and can be quite handy. They leverage an engine that virtualizes the environment in a way that makes it possible for these awful, bloated apps to be loaded from a single executable.

It’s a cute idea, but the way it is implemented… could be abused for malicious purposes.

And that’s why I am talking about it today 🙂

In the past I talked about abusing perl2exe programs that can act as a launcher for a malicious code. The idea of leveraging Thinstall programs for persistence is similarly crazy and remote and… yeah, desperate really, but hey… the possibilities are out there, so should be investigated.


To my surprise, the Thinstall apps don’t seem to be very well researched. When I ran the example app through my analysis tool, I noticed that many environment variables are being used f.ex.:

  • <name of the thinstal app>_SANDBOX_DIR
  • TS_CWD
    • TS_MOD0
    • TS_MOD1
    • TS_MODN
    • TS_UPDATE_0
    • TS_UPDATE_1

My immediate guess was that some of them could be potentially leveraged to modify the behaviour of the Thinstalled app. While googling for some of them, I could not find too many references – this is the only one that is the most accurate (in Russian) that I could find. The post lists additional 3 environment variables:


This made me poke around more – dumping the memory of the thinstalled app process and running strings/grep over it surely reveals even more TS_ environment variables:

  • TS__ST

This is actually plenty of stuff to research on a rainy day, so for now I will just focus on the persistence mechanisms.

Here are three quick wins in this space:

Persistence mechanism number 1

Looking at the TS_ environment variables we can see that there are two potential candidates for an immediate abuse:


After toying around with it for a bit, I quickly came up with the following combo:

  • set TS_UPDATE_0=1
  • set TS_UPDATE_CMDLINE=c:\windows\system32\notepad.exe

Sure enough, when you set up these environment variables, notepad will be launched from the Thinstall app anytime it starts (this could potentially lead to an escalation of privileges as well).

Of course, to be a real persistent mechanism these environment variables have to be permanently set via Registry (f.ex. HKEY_CURRENT_USER\Environment key).

Note: this persistence mechanism breaks the Thinstall app (the original app doesn’t launch; the update mechanism seems to require a restart of the application so this needs to be done by the program referenced by TS_UPDATE_CMDLINE; it’s a bit like a companion virus)

Persistence mechanism number 2

When launched, one of the first files Thinstall app tries to find is os_debug.dll – if present in the local directory it will be loaded. Hence, dropping a malicious os_debug.dll inside the same folder will ensure the DLL is loaded:



Persistence mechanism number 3

Looking at the other files the Thinstall app is looking for when it starts I discovered that it attempts to enumerate the following folder:

  • %PROGRAM_FILES%\ThinstallPlugins

I created this directory and dropped a random DLL inside it, and sure enough, it was loaded when the Thinstall app started.Thinstall_Plugin

As I mentioned, leveraging Thinstall apps as a persistence mechanism is a very VERY desperate idea, but hey… any chance to investigate (even if superficially) a rarely seen file format is always interesting to me. And I bet there is still more to discover there… On this note, I have added the Thinstall app window class to the Certain Windows… stay classy… post.