It’s long overdue, I’ve published on Sunday the version 13.95 of the Autoruns module.
You can find the digitally signed version on the PowerShell Gallery
I’ve written some release notes on GitHub as well on this page that highlights the changes and fixes in this release.
I won’t repeat the “basics” about how to install it that you can find on the main page of the project. I’d like here to focus on the main changes:
- Support for user shell folders
The original Microsoft Autoruns.exe executable added
support for user Shell folders redirections
last year (see release notes).
The Autoruns module had a check in “$($env:AppData)\Microsoft\Windows\Start Menu\Programs\Startup” assuming that both Startup value in the User Shell folders and Shell folders registry key haven’t been hijacked.
The other issue with that code was that it was still not compatible with the -User parameter introduced in version 13.90.1
I also fixed a third issue. When there’s a file located in these folders, it’s found even if its hidden attribute is set. I simply added a -Force switch to the Get-ChildItem cmdlet.
Get-PSAutorun -Logon | Where Path -match 'Shell\sFolders'
It displays the non expanded value of the Startup value under the ‘User Shell folders’. This value is expanded in this ‘Shell folders’ key. The code checks what’s in this path.
If it’s an executable, it shows this file and if it’s a shortcut, it follows it and displays its target.
Here’s what the original Autoruns shows when there are files in the location:
Here’s what the Autoruns PowerShell modules shows:
- New -Raw parameter
As described in issue #56, the main idea is the avoid manipulating and trying to prettify found artifacts. The -Raw parameter aims at displaying artifacts “untouched”.
It’s therefore incompatible with the -ShowFileHash and -VerifyDigitalSignature parameters. That’s why there’s a 2nd parameterset added to the main function to handle this incompatibility.
Let’s see it in action:
Get-PSAutorun -Raw | ogv -PassThru
Here’s a sample output of scheduled tasks
Here’s a sample output of drivers and services
- New -PSProfiles parameter
This is what I merged from the experimental branch. PowerShell profiles can used in offensive or defensive way.
PowerShell profiles are currently not considered as a persistence mechanism by the original Autoruns.exe from Microsoft although they should.
PowerShell profiles can be used a persistence mechanism. It’s has demonstrated here.
PowerShell profiles have been used a persistence technique by the Turla group and PowerShell profiles is an attack technique listed in the MITRE matrix.
Get-PSAutorun -PSProfiles
NB:What the Get-PSAutorun function displays may not be exhaustive because it depends on the host. The Visual Studio Code (VSCode) host is not handled currently for example and will not in the output. (See more about_profiles)
>_ 