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.

PEFix – simple PE file re-aligner

July 9, 2016 in Malware Analysis, PEFix, Software Releases

Every time you dump a PE file from memory its dump is aligned on the memory page size boundary (4096) instead of a typical file alignment boundary which is 512 (except for some PE tricks and less common file alignments).

There are many really cool tools that rebuild PE files directly from memory and do it in an excellent way, but sometimes it’s good to have a simple, stupid script at hand that does the re-alignment only. The re-aligned file can’t be executed, but will make more sense when you load them into IDA. And such stupid script comes handy when images are loaded using manual/reflective loading, and there is more of them in the same process space (or you just have lots of them); rebuilding such memory dumps manually is a pain, so the script that I am attaching to this post will just do this dirty job for you (you can run it as a batch job).

So, say you locate a memory dump where malware hides its PE file, you then dump it f.ex. using Process Hacker, hiperdrop, or any memdumping tool, and then you can run over it (or them) and you should get a ‘.fixed’ file (or files) that will be just a realigned version(s) of your memory dump(s).

Load it into IDA, happy analysis…

In case malware wipes out the MZ/PE markers you can always mod the script a bit to bypass it and still rebuild the file. For completely wiped out MZ/PE markers/header/section table/etc. it’s going to be a manual job although one could think of some heuristics… who knows.. maybe in the next version :).

This is the script.