Beyond good ol’ Run key, Part 101

This is a bit unusual way of establishing persistence.

We don’t add any Registry entries. We also don’t really drop any malicious executable files, unless we have to (fileless malware could establish a persistence this way).

How?

By leveraging the omnipresent files: unins000.dat and unins000.exe that are dropped by any setup program that is built using the InnoSetup installer.

One can build a small InnoSetup script e.g. like this:

[Setup]
AppName=test
AppVersion=1
DefaultDirName=.
DefaultGroupName=test
[Run]
Filename: "c:\windows\system32\calc.exe"
[UninstallRun]
Filename: "c:\windows\system32\notepad.exe"

After installing the .exe, we can collect the unins000.dat and unins000.exe that are generated during this session. They ensure that Notepad is executed when the application is uninstalled. Attacker could simply ‘borrow’ these and place these in a folder where there are already existing files unins000.dat and unins000.exe (typically under c:\Program Files, or c:\Program Files (x86) subfolders).

We need to replace unins000.exe too, because the custom-made unins000.exe files that are dropped by installer may have dependencies that our unins000.dat doesn’t resolve.

Once the user tries to uninstall the program that relies on InnoSetup uninstall process, the unins000.exe will process the content of the unins000.dat and will run the Notepad.

Since the unins000.exe is clean, and only the unins000.dat is really the bad guy here, it is a sort of Lolbin, or Lobinstaller. Security companies are forced to either detect the malicious content inside the .dat file, or rely on behavioral analysis.

Obviously, another trivial persistence method that is related to Uninstallation process, and one I believe I have not discussed before here, and one which is actually not related to InnoSetup per se, is to modify the Uninstall/QuietUninstall strings for the programs installed on the system.

While they typically point to the native uninstallers, there is no problem in replacing them with commands that can run any other program:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<program name>=<string>

and

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\QuietUninstallString\<program name>=<string>

Anytime someone runs the uninstaller, they will run the command of attacker’s choice. Again, the good news is that one needs rights to mod these entries since they are under HKLM key.

Too much % makes Event Viewer drunk

Update:

After I posted it Daniel Bohannon provided a link to his earlier research (March 2018) where he described the very same problem. He has some interesting examples so please have a look!

Old Post:

This is a short post about a funny side effect of using the % sign and how these are being interpreted by Windows Events Log Viewer.

When you use this character as a part of a file name, or as a Registry data the program will assume these % signs are referring to actual parameters and will resolve them into actual strings.

I know it doesn’t make any sense, so let’s do a test.

Name your program %1.exe. Run it. This is what the Viewer will show:

Now try to add this Registry value:

reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run /v Foo /t reg_sz /d test%1%2%3%4%5%6%7%8%9%10%100

The result? Very strange details:

What about naming the program %1%2%3.exe?

Look at the image and the command line. One is: C:\Test\2019-01-27 22:28:29.601{670b5bbc-308d-5c4e-0000-00105f407c03}.exe, and the other “C:\Test\Incorrect function.The system cannot find the file specified.The system cannot find the path specified..exe”.

Only the viewer is fooled, because the actual data is logged properly (although there is an inconsistency in the way %s are doubled in command line) — one just needs to go to Details tab and see what it really shows:

That’s it. Yet another quirky behavior to be aware of.