You are browsing the archive for Anti-*.

Regedit.exe and a possible race condition

April 1, 2018 in Anti-*, Random ideas

Regedit.exe accepts two less known command line arguments:

  • regserver
  • unregserver

When launched with any of these it will call the advpack.dll!RegInstallW function passing to it one of the section names (called RegExe or UnregExe respectively) that are defined inside the .inf file embedded directly in the regedit.exe file:

The extracted .inf file is first saved into a temporary file with a name %Temp%\RGI<random>.tmp file.

It is then interpreted like any standard .inf file.

One can use these commands to do at least two things:

  • unregister regedit file association – see the pasted info below; other than damage, it may render some system repair more difficult (.reg files can’t be used)
  • attempt to exploit a race condition and swap the temporary .inf file with one of attackers’, forcing regedit.exe to run the .inf file of attackers’ choice; it’s a tricky one to pull of, but the possibility exists

The Regshot diff from running the regedit /unregserver command on a test Windows 7 system is shown below:

Keys deleted:17

Values deleted:14
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.reg\PersistentHandler\: "{5e941d80-bf96-11cd-b579-08002b30bfeb}"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.reg\: "regfile"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regedit\shell\open\command\: "regedit.exe %1"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regedit\: "Registration Entries"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\edit\command\: *%SystemRoot%&#x5C;system32&#x5C;notepad.exe "%1"*
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\open\command\: "regedit.exe "%1""
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\print\command\: *%SystemRoot%&#x5C;system32&#x5C;notepad.exe /p "%1"*
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\open\: "Mer&#x26;ge"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\shell\open\MUIVerb: "@regedit.exe,-310"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}\: "{1531d583-8375-4d3f-b5fb-d23bbd169f22}"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\DefaultIcon\: "regedit.exe,1"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\EditFlags: 0x00100000
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\: "Registration Entries"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\regfile\FriendlyTypeName: "@regedit.exe,-309"

Beyond good ol’ Run key, Part 75

March 28, 2018 in Anti-*, Autostart (Persistence)

This is a little, naughty trick that enables us to achieve persistence in a quite an unexpected way.

When we talk about PATH environment variable, we know that we can set it to a specific variable using the Registry keys:

  • HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
  • HKCU\Environment

The problem with these is that they affect either the whole system, or the specific user. The are also widely known and any attempts of modification will be easily visible.

There is one more.

I actually described it in this series and referred to it twice; the key in question is located here:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

(Note that there is no WOW64 equivalent.)

In the first instance, I was talking about changing the (Default) value for applications to point to a malware, and mentioned the Path value will contain the string that will prepend the PATH for the application.

In the second instance I pretty much described an example of what this post discusses in more detail.

Whatever is included inside the Path variable will be added to the PATH of the program; whether it is prepended or appended is dictated by a presence of an undocumented value AppendPath. If AppendPath exists the content of Path will be appended to the PATH; if it is missing, the value of PATH will be prepended (and this is a default behavior).

As I mentioned one can change the path for pretty much any application (and create new entries for e.g. randomized file entries). While dvdplay.exe discussed earlier is a bad example, because it’s not really used that frequently, one could toy around with more popular apps.

For instances, adding:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
    App Paths\cmd.exe\Path=c:\test

will ensure that whatever program is executed from the terminal will be searched for within the current directory, then c:\test, and then directories listed inside the PATH. Have a look at what happens when you run Notepad from terminal in such scenario:

It’s a perfect condition for a more elaborate PATH companion malware.

The same goes for powershell.exe, cscript.exe, etc.

And there is more.

Any application that uses LoadLibrary will follow the DLL Search Order and as such, may end up loading the DLL from the c:\test directory.  Let’s think of the last scenario for a moment – we could place an EXE in one place, and then drop the DLL in another. The only link for finding the DLL would be in that Registry Key.

The below example illustrates it perfectly.

We add:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\

We then place c:\test\foobar.dll and then run the c:\somefolder\test.exe – the test.exe uses LoadLibrary to load ‘foobar’ DLL and exits (the DLL is loaded w/o providing a path forcing the program to walk through the DLL Search order).

Without looking into the App Paths registry branch, or preserving the environment variables at the time the test.exe program ran, it is going to be impossible to link these two binaries in any way. Collection of samples or ‘combos of samples that work together’ will be also harder.

And yes, you could modify rundll32.exe to point its extra path item to some hidden folder too 🙂