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.

Right?

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
• THINSTALL_BIN
• THINSTALL_CACHE_DIR
• THINSTALL_SANDBOX_DIR
• THNOCMDLN
• TS_CMDLINE
• TS_CWD
• TS_DESKTOP
• TS_LOGGING_ENABLED
• TS_MODN
  • TS_MOD0
  • TS_MOD1
  • …
  • TS_MODN
• TS_OPTIONS
• TS_ORIGIN
• TS_ORIGSHOWWINDOWVALUE
• TS_SBCLEANUP
• TS_SBCLEANUP_CONTINUE
• TS_SOURCE
• TS_SUBPROC
• TS_UPDATE_N
  • TS_UPDATE_0
  • TS_UPDATE_1
  • …
  • TS_UPDATE_N
• TS_UPDATE_THINREG
• TS_UPDATE_CMDLINE
• TS_USER_SID

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:

• TS_DEBUGGED
• TS_EXECUTE_EXTERNAL
• TS_SVCINIT

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
• TS_LOG_FILENAME
• TS_SKIP_APPSYNC
• TS_TOKEN_INTEGRITY_LEVEL
• TS_WAITINIT

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:

• TS_UPDATE_N
• TS_UPDATE_CMDLINE

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.

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.