Secure Downloading of Package Files with Tanium

As you are building content, specifically packages, for Tanium, you may find you need to add one or more files related to the package.  Often times you want to have TLS to secure those and thus download them via HTTPS.  If you’re like me your organization has it’s own certificate authority and you sign your own website certificates.  As such you must give Tanium your CA certificate in order to validate the any of your webservers signed with this custom CA.  This is extremely easy to do…

Certificate Chain

Tanium stores the authorized certificate chain within a subdirectory of the Tanium Server…  \Program Files\Tanium\Tanium Server\Apache24\conf\installedcacert.crt

Tanium reserves the right to change this file as they see fit… thus we must copy this file to a new location and add the text version of our companies CA into this file and save it to a new location. 

For my “company”, Moran IT… Our public certificate looks like this in text form:

Moran Certificate Authority

The first two lines are just a marker… simply copy/paste the above orange text into the installedcacert.crt file and save it as \Program Files\Tanium\Tanium Server\Apache24\conf\mit-installedcacert.crt

If you have any issues getting a text version of your CA certificate… Read up on reformatting a certificate:

Modify Registry and Restart Services

Now we need to tell Tanium where our newly modified CA chain file is.  Browse to HKLM\Software\Wow6432Node\Tanium\Tanium Server     And edit the TrustedCertPath variable by adding a “mit-“ to the beginning of the filename.


Now we just need to restart the Tanium Server and Apache services to have our new certificate authority chain load.


The topic I just covered is detailed in the Troubleshooting_Packages kb article over in the Tanium KB, but I find a personal walkthrough can be helpful.

If you are using any packages that download files from, you will need to copy the above orange text into your installedcacert.crt file to allow that download to happen properly.  Otherwise you will always receive the “SSL cannot be verified…” error.

One last thing as well, you will likely need to add to your whitelisted URLs.  This can be done within the Console->Administration->Whitelisted URLs    then “Add New URL Expression as follows:


Tanium Client Hardening

In any security environment, the first thing that I am asked for is a way to protect the Tanium client from end-user tampering.  This is a very common request when it comes to security related software.  An innovative TAM at Tanium has built a solution pack which is documented on the community site called “Client Service Hardening”.  This solution pack contains a collection of sensors, packages and saved questions related to locking down the Tanium Client service and the file system on Windows endpoints.  I would like to explore that solution below.

Acquiring and Importing the Solution

Just like any of the solution packs available from Tanium, to receive a copy of the solution xml, you need to contact your Technical Account Manager and they’d be glad to share it with you.

Once you have the ClientServiceHardening.xml, import it by browsing to your Console->Authoring->Import Content. 


Overwrite any database duplicates, although you should not see any unless you’ve imported an older version of this solution pack like I have.

Using the Solution

ch2The first thing you’ll notice after importing is a new Dashboard Group.  This group wraps a few dashboards together that pertain to hardening the Tanium Client service on your endpoints.  Particularly the following three areas:

  1. 1. Hiding the Tanium Client from the Add/Remove Programs Control Panel Applet.
  2. 2. ACLs for the Client Service itself
  3. Tanium Client directory permissions.

You should implement all three of these in order to fully lock down the Tanium Client Service.  Let’s look at and implement each one sequentially.

Hide from Add-Remove Programs

The first thing we will impellent is to hide the Tanium Client from the Windows Add-Remove Control Panel Applet.  This is extremely easy to do.  Select the Hide From Add-Remove Programs dashboard…


After the questions have completed, right click the “No” answer within the Tanium Client Visible in Add-Remove Programs answer grid.  Choose to “Deploy Action” and the Client Service Hardening – Hide Client from Add-Remove Programs should be the default package selected… then step through the action deployment.  I’d recommend setting this package to reoccur at least once a day in order to catch systems that might not be online right now.  In my infrastructure, I’ve configured the action to reoccur every 6 hours since I have laptops coming on and off throughout the day.  ch4I also know this is a Windows-Only action, thus my Action Group is “All Windows Computers”.  Note that the action group was configured ahead of time and only has a single computer group configured with “Operating System contains Win”.  This action group gives me assurances that this action will only run my windows systems and not my Linux or Mac systems.  This action group could have easily been something else like only “Workstations”, “Laptops”, etc.

Now as this action runs within my environment, the Tanium Client will disappear from the Add-Remove Programs list.

Locking down the Tanium Client Service

The next thing to configure is the ACLs on the Tanium Client service.  This will prevent users and/or administrators from stopping the Tanium Client service.  Implementing this is also an easy thing to do… Open the Control Service State Permissions dashboard…


Please note that if an end-user has administrative privileges on an endpoint, it is entirely possible they also have advanced knowledge of ACLs and will be able to reset these permissions in order to stop the service.

All of your windows systems should report back “Service Control is set to default permissions” just like in my environment pictured above.  Right click on that answer and “Deploy Action”…The default is Client Service Hardening – Allow Only Local Admins to Control Service, however you could lock the service to allow only the SYSTEM account by selecting the Client Service Hardening – Allow Only Local SYSTEM to Control Service package.  I chose to lock it down to SYSTEM since many of my users are configured with local admin privileges and just like before, I will have this scheduled action set to run every 6 hours and only apply to my “All Windows Computers” action group.

Set Tanium Client Directory Permissions

Lastly we need to lock down the folder permissions of the Tanium Client.  This is the file system level permissions which allow users to browse the “…\Tanium\Tanium Client\” client root directory.


Open the Set Client Directory Permissions dashboard and in the single answer grid, right click on the “Not Restricted” answer to “Deploy Action”.

The default action here is Client Service Hardening – Set SYSTEM only permissions on Tanium Client directory.  By default, the Program Files directory is locked down to administrators, thus SYSTEM is the only available configuration package.  Just like with the previous two actions, I will configure this to run every 6 hours and only on my windows systems.


The client hardening techniques covered in this article are very close if not exactly the same security measures that Antivirus and other Vendors take to secure their agents on enterprise endpoints. 

This solution pack also includes packages for resetting the defaults for each of these security configuration settings… so if you want to un-harden the client, it is certainly possible.

Let me know if you have any questions about this article… If you have questions about the content, I encourage you to reach out to and one of their extremely helpful Technical Account Managers would be able to assist.

Ubuntu Patch Management with Tanium

I have more than a dozen Ubuntu servers that perform various jobs.  Some of these systems are considered “production” and keeping the installed packages up to date is extremely important.  For this article I want to discuss how I am upgrading the installed packages on these systems using the Apt-Get utility and the Tanium platform.

I have built a collection of content that was published on the Tanium Community website.  This solution includes multiple sensors, packages and other types of content called Ubuntu Package Management.

Download and Import Content

Visit and click the “Download” button after logging into the Tanium Community website.

Log into your development infrastructures Tanium Console, then browse to Authoring->Import Content, select the downloaded XML file to complete the import process.  It is safe to overwrite any existing sensors as the only one I am using that is not original content is the Operating System sensor.


Dashboard Tour

Now we move onto actually using this content and keeping the packages on your Ubuntu systems updated.   On the “Home” tab of your Tanium Console, you’ll find a new dashboard link appear under the “Other Dashboards” block.


A few saved questions will appear… the left pane shows all packages within your environment that have available updates.  The right pane will list all of the Ubuntu computers you have within your environment.


Available Actions

There are currently two available packages/actions included with the solution pack.  The first is accessible by right clicking on one or more of your Ubuntu systems in the right pane and the default action is Reboot Ubuntu Machine.


The second action is closely tied to the Ubuntu Available Patches sensor as it takes the selected result of that sensor to launch the action.  Thus in the left pane, right click on one of the packages and Upgrade Available Ubuntu Package.


There are other handy actions you can take.  Right clicking on one of the computers, you can drill down into the Ubuntu Available Patches and a list of packages for that one system will appear…Then you can deploy or upgrade a single package from there.  Further right clicking on the computer provides you with the ability to Upgrade All Ubuntu Packages, if that is preferable.

Setting up Scheduled Actions

The Tanium Community site does not allow for the sharing of Saved Actions on purpose.  Thus these must be setup manually.  The first one I’d like to setup is to download the available package updates definitions on a daily basis.  Since most of my systems are online 24×7, having this action run at least once a day is perfect.  To accomplish this, ask the following Tanium question:

Get Is Ubuntu from all machines

It uses the Is Ubuntu sensor which returns one of two answers for your entire infrastructure… True or False.  Right click on the True and deploy the Update Ubuntu Package Definitions package.


I would like this action to occur daily on all of my Ubuntu computers… thus I will be setting up a scheduled action.  I have decided to have the action run between 4am and 5am daily so when I start working and want to check my package status, I have the latest data.


Please note that the Action Group is “Ubuntu”.  This is because I have setup an action group that only includes my Ubuntu systems that I’ve targeted with my “Ubuntu Computers” computer group.



Using the Tanium platform to manage your enterprise is extremely easy.  With a little bit of work and understanding you can put together a solution to accomplish nearly anything you want.

Retrieving Browser History using Tanium

There are many awesome solution packs available for use on the Tanium platform.  One of those solution packs is called Browser History.  It takes advantage of an awesome little utility from NirSoft called, not surprisingly, BrowserHistoryView.  It was written to read the history data of 4 different Web browsers like IE, Chrome, FF, and Safari.

One of the talented engineers over at Tanium wrapped that utility up in content for use on the Tanium platform.  I will go over the basics of setting up and using that content in this article.

Importing Content

Everything with Tanium typically starts by importing content and the Browser History solution pack is no different.  Ask your TAM or contact if you do not have the BrowserHistory.xml solution pack file.

Once you have that xml file, log into your console and browse to the Authoring tab and click the Import button, browse to the xml file and hit ok.


Modify Distribution Package

Since this solution pack requires a 3rd party utility, you must acquire this utility by visiting the 3rd party vendors website.  Browse to the very bottom and download the 32bit version.

Now that you have the utility we need to modify the “Distribute Browser History Viewer” ( package.   Click the “Add Local Files…” button and find the downloaded BrowsingHistoryView.exe and add it to the package.


Edit:  It is entirely possible you are using a Tanium deployment that still has a self-signed SSL certificate.  This would prevent you from adding local files in this manner.  To work around that you have two options, the first is install a trusted certificate on the server which goes well beyond what this article is intended for.  The second is a lot easier but requires you to copy the file to the server.  We’ll explore that option here…

Place the BrowsingHistoryView.exe file into the following directory on the server.  I am calling out the default installation path, but your’s may vary if you changed it during install.

C:\Program Files\Tanium\Tanium Server\Apache24\htdocs\file

Any file within that directory is accessible via the following URL:


Then you can add a URL like the following screenshot:


Distribute Package via Scheduled Action

To follow my personal best-practice of distributing software with a Has-Sensor and a Distribute-Package, I have put together a “Has Browser History Utility” sensor ( that is downloadable directly from the community site.  It is a basic sensor that simply checks the install folder and tells you whether or not the utility exists.  You can then schedule the “Distribute Browser History Viewer” package to all endpoints that report “No”.

Download and import the Has_Browser_History_Utility.xml by going to Authoring and clicking the “Import” button.  Then ask the following Tanium Question:

Get Has Browser History Utility[BrowserHistory] from machines where Operating System contains Win 

The answers you get back should be either Yes or No.  If you have never distributed the package before, likely you will receive all No answers.

Note: Unlike other articles, I have qualified the above Tanium Question by limiting endpoints answering the question to my Windows computers.  I am using the Operating System sensor which is provided via the Initial Content solution pack..  This is to ease the work required on non-windows endpoints, but also since this particular utility only relates to Windows computers there is no need to involve my non-windows systems.


I want to ensure the utility is there when I need it (when I ask for browser history), so I am going to reissue the action every hour.  Only computers that report “No” will launch this scheduled action, thus once 100% of my computers receive the utility, it won’t run unless a brand new windows computer comes online.


Retrieving Browser History

Now that we have this solution all setup it’s time to use it.    The purpose of this solution is to retrieve the web browsing history of computers within my environment.

Legal Notice:  This is very sensitive data and you must use caution when asking for something you might not be authorized to receive.  Pay particular attention to privacy laws in your country and the policies setup for your organization.

Ask the following Tanium-Question to retrieve browsing history data:

Get Computer Name and Browser History from machines where Operating System contains Win


I’ve redacted the personal information for my personal “organization”, however  it does show you enough to know how the Browsing History Solution Pack works.

Tanium Client Deployment Tool

I have recently stood up a half-dozen virtual servers in a new home lab I am building to compliment my home office.  This means I want to get the Tanium Client installed onto these endpoints.  Rather than do it manually, I’m choosing to use the Tanium Client Deployment Tool and install them remotely from my windows workstation.  At the time of this writing v5.0.0.6 was the latest and has a few essential features required for installing the agent onto my new non-windows systems.

Installing the Tool

Installation of the Client Deployment Tool is relatively straightforward.  Launch the installer and click “Install”.  Assuming the default installation directory is acceptable.




Initial Tool Setup

Once you launch the tool there are a few things that need to happen.  The first is the tool itself will prompt you to download the very latest agents for the various OS platform Tanium supports.  Allow that to happen…



Next we will need to point the tool at our server infrastructure in two ways… First by pointing the utility at our file.  This file can be found in the Tanium Server root folder on the server.  Second we’ll need to specify the hostname or IP address of the server we will be pointing endpoints at.  This second value could be the hostname or IP address of a zone server or even an alias that functions differently inside and outside your network.  Lastly if you chose to use a port number other than the default 17472, you’ll need to specify that now.

Install the Agent

For this article we will deploy the Tanium Agent to one of my new Ubuntu 14.04 LTS virtual servers.  My user account on that box has sudo permissions and that is required in order to install new software.


Next we will specify a single endpoint to deploy too.  To do that we change the lower-left tabs to “Computer List” and type in the hostname of the targeted endpoint.  Then change the very bottom left dropdown to “Linux_Mac_Only” to avoid unnecessary timeouts by trying a windows connection and hit the “Analyze” button.


If all works well our tool will report back “Client not installed”.  Select that row and click “Install”. 


All done… The client deployment was successful.  To validate, we can simply log into the Tanium Console and check Administration->System Status to see our new endpoint listed and reporting in.


In Conclusion

The Client Deployment Tool is a great utility for getting the Tanium Agent installed on your endpoints fast.

Recovering License Keys with Tanium

Lately I’ve been exploring the content that is posted in the Tanium Community Repository and found an interesting content pack called License Key Recovery.  For the purposes of this article I will assume you already have a Tanium server setup and have a half dozen or more windows clients reporting into this infrastructure.  In my case I’m using a personal lab deployment Tanium Server v6.2.314.3258 that has various Windows, Mac and Linux endpoints located all around the state of Arkansas.

Acquire and Import the Content Pack

You’ll need the content pack XML which is available from your assigned TAM, if you don’t have one reach out to Tanium Support, I bet they’ll get you the help you need.  After you have the file browse to Authoring and push the “Import Content…” button on the far right.  The import preview window should look something like this:


Update and Distribute Package

This content pack uses an 3rd party utility that is licensed separately from Tanium and can be downloaded/purchased from, you’ll need the enterprise version which includes the command line executable.  After acquiring the software, find the file named RecoverKeysCmd.exe.   The Recover Keys product also uses SQLite which must also be downloaded separately from  (Find the section called Precompiled Binaries for Windows and download the sqlite-dll-win32-x86…)

Edit the “Distribute Recover Keys Utility” package under Authoring->Packages and filter by package name.  Remove both the exe and dll from the Files list and add the newly acquired files by clicking “Add Local Files…” button.


Deploying the Utility

Included in the content pack is a saved action which automatically attempts to distribute the above package every two hours.  However, if you can’t wait that long and want to distribute it immediately, ask the following Tanium question:

Get Has Recover Keys Tool from all machines

Right click on the “No” answer and deploy the “Distribute Recover Keys Utility” for one time distribution… to all endpoints.  Any endpoint not currently online will receive the package command via the scheduled action within the content pack.


Retrieving License Keys

Everything is now prepared for the very fast and easy question you really want to know…

Get License Keys from all machines


In Conclusion…

Utilizing Tanium to take advantage of a 3rd party utility is extremely easy.   Break open the content by editing the packages or sensors and you will see exactly how simple it was to distribute and retrieve the results of the Recover Keys Utility.

CRITs use of MongoDB and starting automatically on Ubuntu

I recently was playing around with CRITs and followed their installation instructions closely (VERY HARD).  They could use some better install scripts to make things smoothly, but what do you expect from a community project.

Anyways, I see in their documentation when it gets to the MongoDB section how to start it at the command line.  Getting past that worked well… but i’m wanting to setup a production style instance which requires the database to start automatically on startup.  Apache (which runs the CRITs UI starts automaticaly by default) but their instance of MongoDB does not.  So i submitted a ticket… which quickly got squashed as “not their problem”.  While I agree this is not their problem, they do want people to use their product, right?  A few bits of documentation on here’s a link to starting MongoDB automatically would have been helpful.  Well… I submit this as that link…

Create /etc/init.d/mongodb with the following info:


# Provides:          mongodb
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: MongoDB

# Change the next 3 lines to suit where you install your script and what you want to call it

# Add any command line options for your daemon here
DAEMON_OPTS="--fork --logpath /var/log/mongodb.log --logappend --nohttpinterface"

# This next line determines what user the script runs as.
# Root generally not recommended but necessary if you are using the Raspberry Pi GPIO from Python.

# The process ID of the script when it runs is stored here:

. /lib/lsb/init-functions

do_start () {
    log_daemon_msg "Starting system $DAEMON_NAME daemon"
    echo 0 > /proc/sys/vm/zone_reclaim_mode
    start-stop-daemon --start --background --pidfile $PIDFILE --make-pidfile --user $DAEMON_USER --chuid $DAEMON_USER --startas $DAEMON -- $DAEMON_OPTS
    log_end_msg $?
do_stop () {
    log_daemon_msg "Stopping system $DAEMON_NAME daemon"
    start-stop-daemon --stop --pidfile $PIDFILE --retry 10
    log_end_msg $?

case "$1" in



        status_of_proc "$DAEMON_NAME" "$DAEMON" && exit 0 || exit $?
        echo "Usage: /etc/init.d/$DAEMON_NAME {start|stop|restart|status}"
        exit 1

exit 0

Change /etc/init.d/mongodb to executable:

sudo chmod +x /etc/init.d/mongodb

and configure it for startup:

sudo update-rc.d mongodb defaults

Now your MongoDB instance that is spoken to in the CRITs documentation will start automatically on boot.