Finding & Removing Malicious Google Chrome Extensions Via KACE K1000

Quest KACE K1000 (Former Dell Product), allows you to create “customized” inventory rules that provide flexibility to run commands, whether through standard command prompt, or other methods.

For this particular use case, we’re trying to identify what Chrome extensions are installed in our non-domain endpoints that we’re managing. If you are dealing with domain-joined systems, I’d recommend managing these extensions via Google Chrome’s GPO which can be found in my past article.

If you don’t use KACE K1000 in your environment, you can still follow the article and later skip to the “For non-KACE users” section to accomplish the same thing.

Within KACE we’re going to create a custom inventory rule to return the extensions found under my user appdata directory: C:\Users\pdelgado\AppData\Local\Google\Chrome\User Data\Default\Extensions

I found the easiest way to do this is to use the dir command within command prompt, with the /b syntax.

dir /bC:\Users\pdelgado\AppData\Local\Google\Chrome\User Data\Default\Extensions”  which returns the following:

Reference for Dir:

/b Use this option to show the dir results using “bare” format, which removes the typical header and footer information, as well as all the details on each item, leaving only the directory name or file name and extension.

The equivalent of powershell is this:

Get-ChildItem -Path “$($env:LOCALAPPDATA)\Google\Chrome\User Data\Default\Extensions” -Name

Within Kace, create a custom inventory rule and call it “Google Chrome Extensions”

Navigate to Inventory > Software > Choose Action > New 
provide a script name: Google Chrome Extensions
Highlight all of your Windows OS under Supported Operating Systems

Enter the following as the custom inventory rule:

ShellCommandTextReturn(dir /b “C:\Users\pdelgado\AppData\Local\Google\Chrome\User Data\Default\Extensions”)

Save it!

This will run that command on each endpoint that matches that path and will save the output to the KACE database. Note: This is assuming that your non-domain systems are using the same username. If your usernames are all different throughout the environment, I don’t think this will work. I played around with dir /b “%LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions” but this did not work. I’m assuming it’s because the KACE agent is running as SYSTEM user context.

Moving on, you should see the list of extensions when you look at custom inventory rules results when looking up an endpoint.

Identifying Extensions:

Google chrome comes with certain extensions by default, in addition there are legitimate extensions such as Adobe PDF readers, or anti-virus extensions added by legitimate products. I spent some time identifying the known extensions via Google Chrome Extensions site; Although some extensions follow an old ID convention or the Google URL store has changed.

Here they are:

Extension Name Extension ID
 Google Slides aapocclcgogkmnckokdopfmhonfmgoek
 Google Docs aohghmighlieiainnegkcijnfilokake
 Google Calendar #old extension ejjicmeblgpmajnghnpcppodonldlgfn
 Google Docs ghbmnnjooekpmoecnnnilnnbdlolhkhi
 Google Drive apdfllckaahabafndbhieahigkjlhalf
 Youtube blpcfgokakmgnkcojhhkbfbldkacnbeo
 Google Sheets felcaaldnbdncclmgdcncolpebgiejap
 Google Chrome Web Store nmmhkkegccagdldgiimedpiccmgmieda
 Gmail pjkljhegncpnkpknbcohdijeoejaedia
 Chromecast pkedcjkdefgpdelpbcmbmeomcjbeemfm
 Google Search coobgpohoikkiipiblmjeljniedjpjpf
 Google Translate aapbdbdomjkkjkaonfhkkikfgjllcleb

I like interacting with the KACE database directly via Mysql Workbench; therefore, I created a SQL script to easily identify the known extensions when creating reports. This made it easy to identify the unknown extensions and also spotting nefarious extensions that shouldn’t be running in the environment:

Note: this assumes that you created the custom inventory software rule and named it “Google Chrome Extensions”.

Here’s the SQL script which will allow you to create an easy-to-read report:

Creating KACE Report for Google Chrome Extensions

Navigate to Reporting > Reports > Select the Drop down menu and select New (SQL) 

Provide a title and paste the SQL code provided earlier:

Save it.

Next, run the Report

You should see a report of your endpoints along with the extensions:

As you can see, it’ll be easy to identify unknown extensions.

Although it’s nice that we have visibility over our endpoints, this doesn’t stop the malicious extensions installed from running. The next step is to eradicate those extensions.

Removing unwanted Google Chrome Extensions

Now that we have a good idea of the known good extensions, we can remove all unwanted extensions. To accomplish this, I wrote a Powershell Script and also briefly modified a well known extension written by “bellows” at Spiceworks that removes Google Chrome extensions.

The first Powershell script “GoogleChromeExtensions.ps1” will query the Extensions directory and will exclude the “known expected” extensions and will return only the extensions not found under this list. The list of “unknown or unwanted” extensions will then be passed on to the “Get-ChromeExtensions.ps1” Powershell Script that will start removing each one at a time. This script will remove the extension folder contents for this path, and will also remove registry entries under HKCU\SOFTWARE for those extensions.

Here’s the “Get-ChromeExtensions.ps1” script. The only thing I modified was the path to the extensions as Dell KACE will run as SYSTEM and the script won’t work if you don’t deploy it this way. (Note: You may also run scripts as the user context, but I didn’t test this route).

The Modified line is this one: $extension_folders = Get-ChildItem -Path “C:\Users\pdelgado\AppData\Local\Google\Chrome\User Data\Default\Extensions”  

Deploying the script via KACE

Navigate to Scripts > Choose Action > New 

Provide a name for the script and make sure you “enable” it.

  • Select the Operating system to “Microsoft Windows”.
  • Windows run As “Local System”
  • Check box for “Allow run without a logged-in user”
  • Upload dependencies (GoogleChromeExtensions.ps1) & (Get-ChromeExtensions.ps1)

Under the Tasks section:

On Success : Run a batch file

Provide a script name and paste the following:
powershell.exe powershell.exe -ExecutionPolicy UnRestricted -File .\GoogleChromeExtensions.ps1

Save changes, and deploy!

For non-KACE users

You can run these Powershell scripts without specifying a user, and just grabbing the current logged in user via the %LOCALAPPDATA% variable. Ensure you modify the script with other expected extensions or just remove them all!
Here’s the scripts:

and you may use the original “Get-ChromeExtensions.ps1” script along with the one I created which should accomplish the same thing. Easy as 1,2,3.



As mentioned earlier, the scripts deployed will remove unwanted extensions from the provided file path and registry keys; however the extension itself WILL NOT be removed from the Google Chrome browser. When you re-launch the web browser, the folders will re-appear; however, they wont’ have any content and the extension will not be functional. If you browse to the extensions section of Chrome, you will see the extensions with a status of “This extension may have been corrupted” and thus will not be functional as seen in the image below:

Although we’d like to have the extension completely removed from the user’s visibility, this is the next best thing. To my knowledge there isn’t a way to remove the extensions besides having the user do it manually (correct me if I’m wrong, as there might be a better way). The user may always re-install the extensions; however, you can always have an ongoing-job to continue deleting them.

Thanks for reading! Constructive feedback is always appreciated!



Leave a Reply

1 Comment threads
0 Thread replies
Most reacted comment
Hottest comment thread
0 Comment authors
Chrome Extensions: Bypassing your security - Syspanda Recent comment authors
newest oldest most voted
Notify of

[…] In addition, I wrote another article on Identifying and removing unwanted Google Chrome extensions through powershell which may be accessed here. […]