RE: Evading Autoruns PoCs on Windows 10
Last September, Chris Bisnett and I presented research at DerbyCon which highlighted a handful of techniques and bugs we discovered that allowed attackers to evade detection from SysInternals’ Autoruns application.
The research was well received, inspired a some fellow researchers to develop their own derivatives, and helped ignite the LOLBAS/LOLBins conversation. However for a few, the presentation left some questions/concerns over the viability of the tradecraft when taken at face value.
@ConsciousHacker’s blog highlights this extremely well as he diligently attempted to reproduce each technique we disclosed. If you didn’t read it, I’d highly encourage it:
Squiblydoo INF Autoruns Technique
Some of the most common tweets and comments I received was on the INF Scriptlets technique that used the RegisterDlls/UnregisterDlls directives to trigger scriptlet execution.
As highlighted in the ConsciousHacker blog, this was especially interesting but frustrating without more context on the primitives needed for this tactic to succeed:
In this scenario, both HKLM and HKCU Run Key Values were used to launch the following command with no avail:
rundll32.exe setupapi,InstallHinfSection ModelsSection 128 shady.inf
The first possible cause of this failure may have been the InstallHinfSection function within setupapi.dll requiring administrative privileges in order to successfully install a device (the fantastic bug/feature disclosed by Vectra caused Microsoft to refactor all kinds of low-privilege device installation routines). Since Run Key Values are executed as the user at login and administrative users with UAC enabled will only run under medium integrity, this requirement would not have been satisfied. When executed on my janky Windows 10 RS2 VM from a Scheduled Task running as SYSTEM, I get sweet victory with no Driver Signing Enforcement issues. If anyone sees differently, please hit me up on Twitter so we can put a nail in this coffin…
InfDefaultInstall.exe Autoruns Technique
The next most commonly asked question related to missing digital signature warnings. Within ConsciousHacker and bohops’ equally amazing blog, this came up when exploring the InfDefaultInstall.exe technique.
As you can see below, hope was abandoned on Windows 10 largely due to OPSEC concerns:
Considering this headache, I can totally understand why folks would opt for other LOLBins that provide more stealth (see CMSTP.exe, IEadvpack.dll, and MANY others). For the DerbyCon presentation, we probably should have:
- Clarified that InfDefaultInstall.exe is an auto-elevating application (requestedExecutionLevel is set to “requireAdministrator” within its manifest file) and will trigger a UAC prompt if not executed correctly.
- Demonstrated Authenticode-based digital signature enforcement is like swiss-cheese if you have administrative rights.
Although there’s a handful of sexy ways to get around this pop-up (see Matt Graeber’s SIP Hijacking research), I’m old fashioned and absolutely fine with tainting the local Certificate Authorities. To accomplish this, we’ll need to generate a self-signed test certificate, catalog sign our INF script with this cert, and install the certificate within the local Root and TrustedPublisher CAs. The following repo has a simple PowerShell proof of concept to demonstrate this functionality:
When executed with high integrity privileges, our certificate is politely added to the CAs without fuss or pop-ups and the following command runs successfully:
InfDefaultInstall.exe shady.inf
Despite all the effort, we’re only rewarded by yet another pop-up :) Although your payload could easily hunt for the window and quickly terminate it before causing alarm, maybe it’s best to treat InfDefaultInstall.exe as what it always was: a low hanging piece of tradecraft ideal to prove a concept at DerbyCon.
Parting Thoughts
I hope you enjoyed the follow up blog and learned something from the explanations detailing why these techniques may not have worked when testing at home. Windows is a complex beast and it takes time to appreciate all of the hurdles that could stop exciting research dead in its tracks. With that said, I plan to put an end to this thread of research with one final blog highlighting how these techniques can be leverage for additional success (and additional failure :) Stay tuned!
