Beyond good ol’ Run key, Part 143

This entry is a bit convoluted, but it’s still quite interesting. I have discovered it today only to google around and find out someone posted the info about it back in 2013. So, I will describe what they did in 2013 + will add one extra bit.

The trick relies on the way the UserInstStubWrapper API exported by advpack.dll / IEAdvpack.dll works.

When you execute a command like this:

rundll32.exe advpack.dll, UserInstStubWrapper test

the UserInstStubWrapper function will read the value from RealStubPath:

HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\test
RealStubPath=<PATH> (f.ex. c:\windows\notepad.exe)

and execute the program referenced by it (in this case Notepad).

As for the extra, there is a twin function called UserUnInstStubWrapper. This one requires admin privileges to run, but it behaves in a similar manner – f.ex. for the command:

rundll32.exe advpack.dll, UserUnInstStubWrapper test

it will reach out to Registry and fetch the value of RealStubPath as well, but this time the key it accesses will be the name passed via the command line, but slightly modified by adding a suffix .Restore to it:

HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\test.Restore 
RealStubPath=<PATH> (f.ex. c:\windows\system32\calc.exe)

So, a persistence opportunity relies on populating these Registry entries first, and then ensuring one of the following commands is executed during autostart by leveraging any of the existing persistence locations (f.ex. Run key):

rundll32.exe advpack.dll, UserInstStubWrapper test
rundll32.exe advpack.dll, UserInstStubWrapper test
rundll32.exe ieadvpack.dll, UserUnInstStubWrapper test
rundll32.exe ieadvpack.dll, UserUnInstStubWrapper test

If we enable the advpack logging we can see these test log entries:

-------------------- advpack.dll is loaded or Attached ------------------------------
Date: 10/19/2024 (mm/dd/yyyy)	Time: 15:11:52 (hh:mm:ss)
UserInstStubWrapper:
LaunchAndWait: Cmd=c:\windows\notepad.exe
-------------------- advpack.dll is loaded or Attached ------------------------------
Date: 10/19/2024 (mm/dd/yyyy)	Time: 15:11:58 (hh:mm:ss)
UserUnInstStubWrapper:
LaunchAndWait: Cmd=c:\windows\system32\calc.exe
LaunchAndWait: End hr=0x0, c:\windows\system32\calc.exe
UserUnInstStubWrapper: End hr=0x0
-------------------- advpack.dll is unloaded or Detached ----------------------------

Beyond the good ol’ .bashrc entry… Part 3

Update

After I posted it, @netspooky pinged me with some additional info. Apparently, this technique is known since at least 2019 and was demoed by @zer0pwn first. This blog post from MCG describes various offensive techniques focused on .desktop and .directory files.

Old Post

This entry is a courtesy of Stephan, who has discovered that .desktop files can be used for persistence as well. Apparently, an ElectroRAT malware is already using this trick in the wild as well.

To modify a list of startup application, you can follow these steps: aka press ALT+F2 and type ‘gnome-session-properties’ and enter.

Once you add a new entry f.ex.:

you will find the following .desktop file in your user home .config/autostart sub-directory:

According to this tweet, you can modify the:

NoDisplay=false

line to:

NoDisplay=true

and this way the entry will ‘disappear’ from the ALT+F2 GUI dialog box. As far as I can tell, this doesn’t work (tested on Ubuntu 22.04.1).

In any case, add .config/autostart directories to your DFIR analysis workflow.

Once again, thanks to Stephan who brought this to my attention. While we will probably never experience a true ‘year of linux on the desktop’ phenomenon, it’s good to know what the existing, GUI-oriented, non-power-user-oriented Linux desktop experience brings to the table…