Application restart #1

I'm a pretty carefree guy, experimenting with all kinds of weird applications from dubious sources. The domain and the network is pretty well secured, but my virtual lab computers are like people in the old west; unregulated and easily killed off if they become to unwieldy.

Still, when something suspicious happens I wan't to know why, because of course I wan't.

Some time ago the following dialog suddenly popped up when I logged in to my work computer;

What? No, I would not like to allow Regedit.exe to make changes to my device. Searching through the startup locations with Sysinternals excellent Autoruns didn't reveal anything and concurrent logons did not start Regedit.exe. Probably, it was launched by the RunOnce registry key. Difficult to troubleshoot when the traces are gone.

Weeks later it appeared again! What program is causing this? Why does it want to start Regedit.exe? How do I find out when it only happens once every month or so? None of my coworkers have had the same experience and even though I have a black belt in Google-fu searching the web was hard, only resulting in how to use Regedit. I know this already!

Then it appeared on my clean virtual lab computer, not in any way related to my domain joined work computer. Luckily I had just done a snapshot of it and Regedit.exe wanted to start every time I restored. Finally some progress! Using my incredible skills I finally found the culprit using Procmon, the greatest tool of all time;

Indeed it was a RunOnce registry key and the name of it, "Application Restart #1" is the clue. Since some version ago (who knows which, versioning sucks) Windows restarts select applications that were running when the computer was shut down. Not only during forced restarts from updates, but when you manually shut down the computer. Apparently I am not very good at closing programs before shutting the PC down.

Not all programs are restarted and how Windows decides this is still a mystery to me. It's a badly documented feature with a badly thought through workaround. This is what Microsoft Answers says about it.

Regardless, Regedit.exe, or any program requiring elevation, should not be started automatically!

Or is it requireing? Require-ing? Reqiruing? My Google-fu might not be as advanced as I thought.

Different minds, different worlds. A case study.

The giants in the new world are called Google, Apple or Microsoft. In the old ages, they were called Siemens or Asea Brown Boveri.

Lets compare their philosophy when it comes to deliver software products. I've made an easy to understand table comparing a typical Google program, such as Google Earth, with software from ABB or Siemens, such as ABB Automation Builder or Siemens Totally Integrated Automation Portal (say it quickly five times).

Google	ABB and Siemens
Small msi or single file setup.	Ginormous installer, dozens or even hundreds of smaller setups, wrapped in a launcher, difficult or impossible to install without the wrapper.
Installs in under 1 minute.	Takes hours. Often takes a different amount of time to install each time, even on the same clean computer. Fails unpredictably.
Silent install with simple parameters.	Nope, never in a million years. Even autoclicking through the install is difficult, because the control IDs change or buttons are not real buttons.
Just works.	Doesn't work. Drivers bluescreen! Actually crashes regsvr32! Has issues with UAC and Credential Guard, can't install in Console 0, and even has problems with long filenames. I mean, long filenames, seriously?
Seamless automatic updates.	Requires elevation for updates nobody is asking for, and also for add on modules you are asking for but are not included in the offline install.
Secure.	Requires full permission in its many many Program Files folders and can't be installed elsewhere, breaking AppLocker security. Confusing number of processes requiring firewall exceptions.
Distinctly different programs each with a clear purpose.	Several identical looking programs with no description of what they are for or what the differences are.
Just download.	After registering an account and finally finding the correct program using a horrible search engine, you are told you don't qualify to download their precious software.
Just install and run.	After finally installing you are told you need to apply for a license or to put a hardware dongle into the USB. Who pirates engineering software?
Usually a free version, the paid version costs a few dollars.	Costs a fortune.
Program is contained in one folder.	Installs everywhere, including the root of the drive. Computer is never the same again.
Modern look and feel.	GUI like it's 1999.
Explore the entire world.	Automates something something, except itself.
Steals your soul.	Forces you to slowly descend into madness.

The requested execution level require administrator!

Executables that make changes to the system requires higher privilegies. Users will normally be asked to give admin credentials, and even members of the local administrator group will be asked for consent before elevating to a higher level of privilegies.

This is great!

However, some applikations require administrative privilegies even though they do NOT make or need to make any system changes.

That is retarded!

It actually lowers the overall security because if you don't know how to handle it users will have to be given, or some users might even have the balls to demand, administration rights.

An hilariously ironic example is InstallShield, one of the most common msi-editors. I can imagine some tools like the Response Transform Wizard might need admin rights, but otherwise there is no need. Another trouble maker is mmc.exe even though the snap-in you wan't does not. This makes it difficult to save a folder view and give to users to administer groups, for instance. Add to this various third party programs that only need to run as admin because the developer is lazy. Nothing wrong with laziness, unless it gives ME more work.

A program might ask for elevation for various reasons, where the correct and common reason is requestedExecutionLevel in the programs manifest is set to Level=requireAdministrator.

There are other reasons, some of which you can force. You can make a shortcut where you specify Advanced - Run As Administrator. This setting is in the lnk-file and will remain if copied. You can set the executable compability mode to Run As Administrator. This is stored in HKCU or HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers and includes the full path. Therefor it will break if the file is renamed or copied.

If the file lacks a manifest you can just rename the file as setup.exe and Windows will force consent on you. That didn't come out right.

The other way around, running a program that requires admin rights without admin rights, is slightly more convoluted.

There are a couple of ways to do it, where the easiest way is to set the environment variable __COMPAT_LAYER = RunAsInvoker. Note the initial double underscore.

Using a script or by coding it is trivial to make a launcher. In AutoIt:

#NoTrayIcon
#AutoIt3Wrapper_Icon=Some icon preferably same icon as the program this is supposed to launch.ico

$RunAsInvoker_command = 'set __COMPAT_LAYER=RunAsInvoker'

Run(@ComSpec & ' /c ' & $RunAsInvoker_command & ' & start "" /D "' & @ScriptDir & '" ' & $cmdlineraw, @ScriptDir, @SW_HIDE)

Another way to more permanently change the application is to edit its manifest and simply replace level="requireAdministrator" with level="asInvoker" using your preferred manifest editor that works. They don't always work. If the file is signed, not even a hex-editor works.

That is the easy part. Then you need to make sure the program actually works running with only user rights. For this task, you'll need Procmon, the greatest tool ever made. I said that already.

UAC and Admin Approval Mode can be turned off in various ways. DO NOT DO THIS. On the contrary, if it was up to me (it isn't) I would enable Prompt for credentials for ConsentPromptBehaviorAdmin, so that even admins have to enter a password before elevating.

Everybody writes to program files!

Now and then I am given a program to deploy that doesn't work. Just kidding, I get such programs all the time.

Actually, I am quite surprised when something works straight out of the box. I have a hard time fathoming how people without my amazing skills get anything to work on their computer at all.

Well, one of the reasons is that most people are using their home computers with an account that has administrative privilegies. Some people even turn off UAC to get rid of some annoying consent-dialogs.

In a corporate environment, this is a very very bad idea. Ask anyone working at an Iranian nuclear facility. (Full disclosure: I don't have a clue about the infrastructure at any nuclear facility, Iranian or otherwise).

A very common problem I face is programs that require write-permissions in its program folder. Older programs, binaries that does not include a manifest with a requested execution level, have their writes redirected by modern Windows to the users profile, to %localappdata%\VirtualStore. This, however, only works with UAC enabled.

But so far so good, these old crap program works somewhat, thanks to the pile of workarounds that is Windows.

New crap programs does not.

They are getting less and less common but I still get them.

Why not just give users write-permissions, you may ask. Because they don't deserve it I may answer, but that would be wrong. No, it's because it's a major security concern.

Having write access to program or system folders is different than having write access anywhere else, because a malicious program could replace files the user launches, and unlike executables saved on the desktop or the download folder, users don't have a clue what they are launching when starting an already installed program.

Also, it makes further security restrictions like AppLocker a pain to administer. Imagine you manage a restricted environment where users are only allowed to start prior approved programs, that you have tried, tested and deployed. The users are not local administrators, so they can't install anything, and you wan't to configure AppLocker so that they can't even start binaries but the programs you deploy.

Pretty much the only AppLocker rules you would need then are the default rules, like this one:

While this isn't entirely true if you use stuff like Click-to-Run, ClickOnce (stupid names, by the way) or AppV, it covers most of what you need.

However, if only ONE folder that fits within your Allow-rules are writable by users, it all falls apart! Any user or a malicious program can then launch whatever they want, and the added security AppLocker is supposed to provide is to no avail.

Microsoft has a tool, Sysinternals AccessChk that will help you after the fact, but you will need to be the person to avoid installing programs that changes permissions on folders.

If you absolutely MUST, install the program elsewhere. Not in the root directory, but maybe in C:\ProgramData or make a new folder called C:\Program Files Secure.

Or why not C:\Program Files That Suck!

Then you'll need to add new AppLocker rules separately. But it works.