Get more info about Edge Chromium

    • Context

If you go on https://aka.ms/EdgeEnterprise, you can download and deploy the new Edge-Chromium

On this page, you’ve first to choose a channel/build from the first drop-down menu:

Then you’ve to choose for what platform, you need the binary:

And you can hit the download button and/or get the latest policies’ templates.

    • Problem

At work I’ve some requirements for maintaining browsers. I need to know when there’s an update available and what it fixes.
I’m already following what Google, Mozilla and Microsoft (for built-in Edge-Html and IE11) do but the new Edge-Chromium (aka ChrEdge) is another beast.

    • Solution

It appears that the source code of the page https://aka.ms/EdgeEnterprise contains some JSON data used to build the above drop-down menu and help select the channel, build, platform to be downloaded.
This JSON data much more data than what appears in the GUI.

I’ve built some helper functions to extract and expose all this data from the blob that is JSON formatted in HTML .
It requires PowerShell 6.x or greater because the code uses the -AsHashtable switch from the ConvertFrom-Json cmdlet.
After this core function named Get-MSEdgeEnterpiseData used to extract the JSON blob and convert it back to real JSON data, I could build the following functions:

  1. Get-MSEdgeEnterpiseBuild to mimic what the first drop-down menu does,
  2. Get-MSEdgeEnterpisePlatform to mimic what the 2nd drop-down menu does,
  3. Get-MSEdgeEnterpiseDownloadInfo to enhance and add metadata about the artifacts to be downloaded
  4. Get-MSEdgeEnterpisePolicy to retrieve the info about policies templates files
  5. Get-MSEdgeEnterpiseEdgeUpdateInfo to return info about the Edge Updates (only present in the JSON blob and not exposed in the GUI)

All these functions can be found in the following gist named MSEdgeChromium.ps1

Let’s see it in action!

# Show the version of PowerShell
$PSVersionTable

# Load the functions by dot-sourcing
. ~/Documents/MSEdgeChromium.ps1

# Show what the raw JSON looks like
 Get-MSEdgeEnterpiseData | fl *

# Show all the builds from the Dev and Stable channels
Get-MSEdgeEnterpiseBuild -Channel Stable,Dev

NB: Notice for example the ExpectedExpiryDate and PublishedTime properties that aren’t exposed in the HTML page.

# Show the first 2 builds from the Stable channel for the Windows x64 platform
Get-MSEdgeEnterpisePlatform -Channel Stable -Platform 'Windows x64'|
Select -Last 2

# Show only the latest version released
Get-MSEdgeEnterpisePlatform -Channel Stable -Platform 'Windows x64' -Latest

# Use the Get-MSEdgeEnterpiseDownloadInfo function to
# Add the metadata about the artifact to be downloaded
Get-MSEdgeEnterpisePlatform -Channel Stable -Latest |
Get-MSEdgeEnterpiseDownloadInfo

# Get the latest policies file published and
# Use the Get-MSEdgeEnterpiseDownloadInfo function to
# Add the metadata about the artifact to be downloaded
Get-MSEdgeEnterpisePolicy -Latest |
Get-MSEdgeEnterpiseDownloadInfo

# Get the latest Edge Update published and
# Use the Get-MSEdgeEnterpiseDownloadInfo function to
# Add the metadata about the artifact to be downloaded
Get-MSEdgeEnterpisePolicy -Latest |
Get-MSEdgeEnterpiseDownloadInfo

NB: This channel named ‘Edge Update’ is hidden and not presented in the web page at all for the moment…

Bonus: Last but not least, if you work behind a proxy, you may want to add more proxy related parameters to the Invoke-WebRequest cmdlet like the -Proxy parameter on line 32 of MSEdgeChromium.ps1

About AutoRuns version 13.95


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)