Recently Discovered Evil Chrome Extensions

On December 16th, Threat Intelligence researches from Avast discovered several browser extensions that contained privacy invading malware. Read the press release here. 

In the press release, Avast summarizes the embedded malware's capabilities in the following paragraph.

Users have also reported that these extensions are manipulating their internet experience and redirecting them to other websites. Anytime a user clicks on a link, the extensions send information about the click to the attacker’s control server, which can optionally send a command to redirect the victim from the real link target to a new hijacked URL before later redirecting them to the actual website they wanted to visit. User’s privacy is compromised by this procedure since a log of all clicks is being sent to these third party intermediary websites. The actors also exfiltrate and collect the user’s birth dates, email addresses, and device information, including first sign in time, last login time, name of the device, operating system, used browser and its version, even IP addresses (which could be used to find the approximate geographical location history of the user).

In response, Kolide has created a new Check called Evil Chrome Extension - Browser History Sniffer which detects all reported compromised Chrome extensions from the Avast report.  We suggest immediately enabling end-user notifications on this Check.

If users have one or more of any extensions, they will receive a notification that looks like the following:

If you have any questions or concerns about this check, please reach out to us at or via the Intercom widget on the bottom-right corner of the Kolide  application.

For your convenience, below is a list of the Chrome Extension identifiers extracted from the links in the press release.


Native Mac M1 Kolide Agent Now Available!

Happy Holidays, Kolide Members!

It has been a little over 5 weeks since Apple announced the M1 based Macs, and while we already have had a number of these devices enroll in Kolide using our intel-based agent, we are pleased to report that we are now distributing our agent so it runs natively on M1 based Macs. 

Going forward, all Kolide agents on version 0.11.15 or greater will be built as a universal binary, which will ensure that no matter which Mac you have, the binary will execute a native instruction set. This new native build should resolve the occasional instability we've seen running on the Intel-based agent under Rosetta 2. 

While this is an important milestone, you will still need Rosetta 2 on M1 Macs to run the osquery portion of our agent. We look forward to a future where this won't be necessary, and will keep you apprised of any relevant announcements from the osquery team. With that said, in our testing, osquery continues to run great on M1 Macs with Rosetta 2 emulation.

How to Upgrade

If you already have the agent installed on the M1 based Mac, you likely don't need to do anything! If it hasn't already, the new version of the agent (0.11.15) will automatically install through the auto-update process. 

However, if your M1 Mac hasn't checked into Kolide for a while, or you see you haven't received the update yet, we encourage you to re-install the agent. You can request a new agent installation package via the following mechanisms:

1. If you have the Slack app enrolled, simply message the app the command enroll and you will receive an up-to-date package for your selected environment.

2. If you are a Kolide admin, you can access the installation packages by browsing to the Downloads section of the app.

Mac M1 Data Quality Improvements

After the M1 Macs were released, we noticed a few discrepancies in the reporting data about the status of the Find My Mac feature and battery health. Kolide has resolved these issues in our agent and back-end.

Please let us know if you have any questions or concerns about M1 Macs! From all of us at Kolide, we hope you all have a safe and happy holiday season!

Notify Admin When Device Comes Online

In Kolide, when a device is offline, you can still enqueue work like Live Queries or Re-Checks so that they run as soon as the device returns. While this is useful, it can be hard to remember to go back into the app and view the output of all that enqueued work because you can never be sure when the device has finally checked-in again.

To help with this common situation, we introduced a feature for Kolide admins where they can opt-in to receive a Slack notification when a specific device comes online.

To use this feature, simply browse to any offline device's overview page and look at the header near the online/offline status indicator. If your Slack integration is enabled and there is a Slack identity associated with your Kolide admin account, then you should see a bell. Click the bell, and it will "light-up", indicating that you (and only you) will be notified the next time a device is online. 

Once the device comes back online, you will receive a notification in Slack, and the bell icon will disappear. This Slack notification only occurs once, so if the device goes offline and then back online a second time, you won't receive an additional notification.

As you might expect, each time a Kolide administrator either creates or cancels these online notification requests, a corresponding audit log entry is generated.

We hope you find this feature useful. Please let us know if you have any feedback, comments or suggestions.

Kolide Side Dishes

At Kolide, we typically ship changes and improvements to the product multiple times a day. The vast majority of these changes are modest improvements not worthy of their own change-log post, but together, they can make a big difference.

While we are working on some 25-pound-turkey sized features we plan on announcing soon, we thought we'd let you dig into some of these side-dishes first! Enjoy.

UX Improvements

Tools Menu

Depending on your level of access to Kolide, you may notice a new item in the main navigation called "Tools". This menu now houses all of the useful features of the product that don't quite need top-billing, but also do not belong in the "settings" section of the website.

Speaking of tools, the "Reporting DB" feature listed here is a feature we are currently beta testing with a few customers. If you are interested in being able to programmatically access all of the data we collect about a device in inventory, and eventually build your own reports on that data with SQL, please reach out to us via Intercom or and we'd be happy to include you in our next round of testers!

Log Pipeline

The biggest change here is Log Pipeline, a feature that allows you to unlock the full power of the osquery daemon we deploy in the Kolide agent. This feature is now easier to find and users with access to it can also access other related features like creating FIM categories, configuring osquery options, and setting up your own custom decorators! 

As users of the Log Pipeline ourselves, we think all these items living together is a much more intuitive experience. Let us know what you think!

Improved Context For Slack Notifications

When an end-user successfully fixes a failing check, Kolide shows them a congratulatory message. Sometimes though, depending on the timing of the message, or where the message appeared, there might be some confusion about what device this message is referencing.

After a customer pointed this out, we decided to add some additional context to these messages so it's always clear which device Kolide is congratulating you about!

Search By Device and Person ID

If you are a regular user of our API (or are just really good a remembering numbers you see in your browser's location bar), you may have tried to lookup a device or person by their Kolide generated ID in our global search bar. Starting today, searching for both devices or people by their ID will now function as you would expect!

Performance Improvements

Live Query

If you are a regular user of Live Query, you may have noticed that devices now return up to 10x faster after querying them, and present any informational warnings or errors without requiring a page reload! Kolide now better leverages websockets to deliver this information at a much faster pace.

Device CSV Exports

We had reports from several customers that exporting the list of devices via CSV could take a long time. After investigating the issue we were able to improve the speed of this export by over 100x!

Improved User To Device Association

We've made some changes to how we build custom package and optimized our initial device data population routines to improve the accuracy and the speed in which we are able to assign users to a device. Additionally, the file names we generate for the custom packages are also now much shorter!

API Changes

Based on a customer request, we've now added a product_image_url following field to the device API endpoint. In many cases (and in all cases on Apple products), this new field features the visage of the exact hardware model enrolled in Kolide. For those of you creating your own internal experiences, these device images can help give you and your end-users the confidence that they are viewing the right device.

Speaking of product images, we've also now added updated product images for all of the new M1 Macs released by Apple earlier this months, and we've changed many of the icons on the widgets featured in the device detail pages to match the changes in macOS Big Sur!

On the log pipeline side, we've also now added the remote_ip, device_owner_email, and device_owner_type, to the kolide_decorations object in the logs emitted by our product in the log pipeline. This will allow you to easily correlate device activity with specific individual for potential integrations with IDP and authentication services.

We at Kolide hope you are all having a safe, healthy, and joyful holiday season. As always, please reach out with suggestions and feedback. Many of the improvements here were generated from customers just like you!

Introducing the Kolide Slack Home Tab

Kolide recently upgraded its Slack app to take advantage of a new feature called the Home Tab. This new tab allows Slack applications to create a persistent surface where they can display important information to a user that isn't structured like a conversation.

Kolide plans on using this area to increase the discoverability of end-user-focused features. We want to give device owners a clear and easy way to access important information about the security of their devices, without having to remember to type specific commands.

Our initial implementation offers end-users the following:

  • Convenient access to the Privacy Center  
  • A button to easily access the device enrollment workflow
  • Visibility into their assigned devices including their open security recommendations

Here is what it looks like!

As we roll-out new user-focused security features in Kolide, the Home Tab will grow more and more important. We envision this tab being the key place for end-users to start and manage their Kolide journey.

Please stay tuned for future updates!

Improvements Enrolling Personal Devices in Kolide

Many of our customers use Kolide to verify the security of an employee's personal devices. Thanks to Kolide's user-friendly stance on privacy, we've always been a great solution for the Bring Your Own Device (BYOD) use-case.

With that said, Kolide is working on several new features (like our upcoming MDM), where the distinction between a user-owned device and an organization-owned device will be even more important. 

To that end, today we are excited to announce an official way to flag devices as User Owned. This flag can be set either by a Kolide administrator, or by a user during the Slack-based enrollment process. Once this flag is set, a device cannot be re-assigned to any other user in the system.

Changes to Onboarding

Starting today, when you onboard a new user to Kolide via Slack and enroll a device, they will be asked about the device's ownership. Based on this selection, Kolide will generate a custom package that will set the device's ownership mode correctly.

Here is what the flow looks like when you choose the option, "I own this device"

Once the user downloads and installs the package, Kolide will automatically assign it to them and mark it as user-owned. 

Note: We have renamed the installers Slack app command to enroll. Both commands now initiate this same enrollment workflow as shown above.

Manually Marking Devices User Owned

While the new onboarding flow is nice, you may have a few existing devices that need to be marked as user-owned. 

To do this, simply go to the device you want to mark, click Actions in the upper-right corner and choose Mark User Owned... This will open a modal that will allow you to confirm the switch.

Once the switch is made, the end-user will be notified via Slack and the device will be marked as "User Owned" with a badge in the header.

User-Owned Devices & Privacy

You may be familiar with Private Mode, which restricts the visibility a Kolide administrator has into a device to just the results of Checks.  This mode will remain separate from User Owned and both modes can be applied independently to each device. Depending on your requirements, it may make sense for all user-owned devices to be marked Private as well.

Changes to API

To help users of our API differentiate private and user-owned devices, we've added two new attributes are now available when querying devices in the API privacy and owned_by. We have also introduced a new Webhook event devices.personalized that fires when an administrator manually marks a device as User Owned.

Please see the API documentation for more information.

Future Plans for User-Owned Mode

Right now, the only functional change in marking a device User Owned is that Kolide will not allow you to re-assign it to someone else. While that doesn't sound like a big deal today, Kolide has several planned features with its upcoming MDM that will require informed consent, from an end-user before they can be used. It's important that end-users understand that this consent process cannot be circumvented by re-assigning the device to someone else, especially for devices that they own.

As always, if you need any help, have questions, or concerns please let us know and we will address them as soon as possible.

New Linux Checks: Gnome Screenlock & Unsupported Ubuntu

Happy October everyone! 

As part of our commitment to improve Check support on Linux, Kolide is excited to announce the immediate availability of two new Checks for Linux systems.

The first is the Ubuntu OS Version Unsupported Check which uses Canonical's official Launchpad releases API to detect versions of Ubuntu that are no longer formally supported. An unsupported version of Ubuntu may not receive critical security patches, so it is important that end-users upgrade their OS right away. If Kolide detects a version of Ubuntu that is not considered "active" by Canonical, it will generate a failure.

The second check is Gnome Screenlock Disabled/Insecure. Like the Mac and Windows counterparts, this Check ensures that not only are the lock settings enabled, but that the screen will correctly sleep in a reasonable amount of time. Specifically, this Check ensures that:

  • The screen sleeps within 10 minutes or less of idle time
  • A password is required to resume using the device if the screen is off for 5 minutes or greater
  • Both the screenlock and sleep idle settings are correctly enabled

In the future, Kolide is hoping to expand the support of these Checks to other popular window managers and flavors of Linux. Keep your eyes peeled for future announcements. As always, if you have questions or feedback, please reach out!

Improved User Slack Messages

Kolide is excited to announce a significantly improved experience for end-user Slack messages. 

End-user messages are arguably the most important part of Kolide's platform. It's important that the messages are easy to understand and are highly actionable.

One area that needed improving was the experience of sending messages to a user with a lot of similar failures for the same Check. Before this change, Kolide would send a user separate messages for each failure, even if those failures had nearly identical resolution instructions.

This was not ideal for many reasons. First, most people did not realize they were sent multiple messages, and would only read the last one. Even if they did realize, they would have to interact with every message to resolve those failures. 

To change this, we wanted to design an experience that respected the user's time, and made fixing multiple similar failures as easy as possible. Let us walk you through how it works. 

Below is an example failure notification. Notice how Kolide has detected 2 unique failures on this device. Now when you click "More Info / Resolve"...

instead of getting two separate messages for each failures, you will now get a single Slack message that looks like the following:

Note that all of the actionable failures are listed at the end of the message with the ❗emoji/symbol.

Now, when a user clicks "I've fixed it. Check again" Kolide will recheck each failure listed at the end of the message and strikethrough the ones that the user has fixed.

Kolide has updated all of our message templates to accommodate for this new format. Of course, if you see anything not looking like it should, please let us know.

Bonus: Improved Escalation Message

While we implemented this new Slack message user experience, Kolide took the opportunity to improve how failure escalations to administrators are displayed in Slack.

Instead of simply showing the full failure message, we now have a compact notification that includes the most important details.

When you click on "Show Full Notification", we take advantage of Slack's new modal feature to display the full message the user was shown. This allows you to keep the channel nice and tidy for your other teammates.

We hope you enjoy these improvements. We have a lot more planned for the Slack app in the near future!

Upcoming Changes to API Pagination

For everyone building tooling atop our Beta API, we have some upcoming changes to announce! 

Here is the quick summary:

  • To improve the API's performance we are changing how pagination works
  • The new cursor-based pagination is available starting today. Docs are here.
  • Our old pagination scheme will continue to work until Friday Nov 6th, 2020. Make sure you update anything that uses the old pagination by then.
  • If you have any issues with the new pagination, please let us know via Intercom or right away.

New Pagination Details

In an effort to improve performance, we're changing our pagination strategy for API endpoints that return collections of results. 

Complete details and the documentation can be found at the link included at the bottom of this post, but the condensed version is: We're moving from simple page-number-based pagination to cursor-based pagination. This means that instead of making requests like this:

curl --request GET \
  --url "" \
  --header 'accept: application/json'

# -> 
#  page: 2, 
#  last_page: 3,
#  data: [
#       {...}
#   ]

in the future, you'll make API requests using a cursor= query parameter to specify pages of data past the first page: 

curl --request GET \
  --url "" \
  --header 'accept: application/json'
# ->
# {
#  pagination: {
#    next: "",
#    next_cursor: "ABCDJ",
#    current_cursor: "JDCBA",
#    count: 25,
#  }
#  data: [...]

Because no one likes to re-write their tools while worrying about downtime, we are doing a staged roll-out. The API currently behaves as it always has with respect to pagination: if you supply a page= query parameter, or only specify search and per_page, the API will use and respond with the existing page-number-based pagination. The original pagination scheme will continue to work until Friday Nov 6th, 2020. Make sure you update anything that uses the old pagination by then.

However, if you specify a cursor= query parameter (even a blank one, see the examples above), the API will use cursor-based pagination, and will respond with the new pagination information described above. This means that you can update your API clients to prepare for the coming updates, without worrying that your existing workflows and automation will be broken while you feverishly re-write them.

For full documentation and details, see

Improved Check: Windows Screen Lock Disabled/Insecure

This is a follow-up post to the announcement we made about the macOS Screen Lock Check. In that macOS Check we really dug deep into the spirit of what Screen Lock means beyond just ensuring the setting for the feature is enabled.

While we already had a Windows Screen Lock check, it wasn't nearly as thoughtfully put together as the macOS one. To rectify this, we have shipped a new replacement check called Windows Screen Lock Disabled / Insecure.

Like its macOS sibling, a Windows Device needs to meet the following conditions to pass.

  1. The "On resume, display logon screen" setting is checked under the Security and Privacy pane in the Screen Saver Settings panel OR the "When PC wakes up from sleep option" is selected in under the "Require sign-in" header in the "Sign-in options" section of Windows Settings
  2. Your system must either be configured to sleep or activate the screensaver after 15 minutes of idle time, regardless if it is running on battery or directly connected to an electrical outlet.

This Check replaces the original check and has a new ID and URL. Don't worry though, we have ported over your tags and notification options to the new Check.

We encourage you to take a look at the new Check and enable notifications so that your users can better secure their devices.

New Inventory - Screenlock Configs

In addition, we have also exposed data about Windows Screenlock configurations in Inventory. You can find this Inventory item at:

In this Inventory Item we expose the following columns:

  • Screensaver Lock Enabled - True if the 'On resume, display logon screen' option is checked under the Screen Saver Settings control panel.
  • User Screensaver Idle - The amount of time in seconds before the Screen Saver is initiated. This is controlled by the dropdown labeled: 'Wait: ... minutes minutes' on the Screen Saver Settings control panel.
  • Requires Password on Wake AC - True if the setting Require Sign-in dropdown is configured to 'When PC wakes up from sleep' in the Sign-In Options screen. By default this dropdown controls both AC and Battery settings but they can be different if configured manually via RegEdit or Group Policy.
  • Requires Password on Wake Battery - True if the setting Require Sign-in dropdown is configured to 'When PC wakes up from sleep' in the Sign-In Options screen. By default this dropdown controls both AC and Battery settings but they can be different if configured manually via RegEdit or Group Policy.
  • Max Device Sleep Idle - The worst-case scenario for how long the device can be left idle before the configured Power Plan will initiate device sleep (either on AC or Battery power)
  • Device Sleep Idle AC - The amount of time in seconds (or "Never") the computer must be idle while connected to power before it goes to sleep. Controlled by Power Plan Settings.
  • Display Sleep Idle Battery - The amount of time in seconds (or "Never") the computer must be idle while running on Battery power, before it goes to sleep. Controlled by Power Plan Settings.
  • Lid Close Action AC - Describes the behavior of mobile devices (laptops) when the physical lid is closed on AC power. Controlled by the Control Panel: 'Change what closing the lid does'. May be one of the following options: (Nothing, Sleep, Hibernate, Shutdown). 
  • Lid Close Action Battery - Describes the behavior of mobile devices (laptops) when the physical lid is closed on Battery power. Controlled by the Control Panel: 'Change what closing the lid does'. May be one of the following options: (Nothing, Sleep, Hibernate, Shutdown) 

As always, let us know if you have any questions, concerns or feedback about this Check!

Show Previous EntriesShow Previous Entries