Tanium has gained much popularity in the past few years. Those jumping on the Tanium train need to beware. If your company uses Tanium, your data is at high risk, IMO. Their “peer chain” model, and the lack of encryption of that data, are insecure and should not be trusted.

This article is about Tanium: https://www.Tanium.com/products/

UPDATE: 09 May 2018. The DoD IG is opening an investigation into the acquisition of Tanium: https://media.defense.gov/2018/Apr/17/2001904705/-1/-1/1/D2018-D000CU-0125.000.PDF

UPDATE: 16 Jan 2018.  I’ve received dozens of responses in the last four months about this article via email, phone calls, text, DM, and in person. Here’s a breakdown of those responses:

• 50% viewed the article favorably and stated they would be performing testing
• 13% verified at least one (or more) of the speculated issues
• 27% had already identified all (or the majority of) the speculated issues before reading the article. In some cases, had found many more. They saw the article as confirmation of what they had been seeing.
• 10% berated the article and/or me

I – Prelude

I(a) – Warning: Don’t waste your time

If you have made it an acceptable practice to believe vendor smoke-and-mirrors over evidence, then you might as well stop reading now. This article is only intended for readers that are willing to admit that many vendors fail us and for companies that are willing to invest time verifying vendor (and researcher) claims. For the nay-sayers, your company’s security is at stake. If you care about your stakeholders, you need to be open to the idea that not all vendors provide the level of security they claim to.

I(b) – Purpose of Article

By the end of this article, I hope to bring to light the vulnerabilities associated with not only Tanium, but also all of the peer-to-peer (P2P) EDR architectures on the market: Accelerite Sentient, Fidelis Endpoint, etc. I also hope to inspire other security researchers who have Tanium installed, and Penetration Testers (pentesters) who may have access to an install through their clients, to run this product through the ringer. Don’t forgot to post your successes, screenshots, and exploit code!

I(c) – Approach of Article

To be upfront, I do not have access to a full Tanium install and have not found a free/modest priced solution to acquire it. I initially obtained all information through Tanium’s website. Additionally, I gained access to the client software and a list of customers – a little more than just “information”, but it is minimal, as you’ll see below.

Using information from their website, and logical reasoning, I will provide you with speculations, if you will, that you can test on your own. Because of this, there will be “challenges” to complete for those of you who currently have Tanium installed. Your mission will be to prove (or disprove) these speculations.

UPDATE: 16 Jan 2018. As seen in the above update, 40% of respondents have verified at least one of these speculations, 27% have verified all of them. If you are struggling to verify them on your own, please reach out to me.

This article, for consistency and an attempt at brevity, uses all windows examples. Linux and Mac would suffer the same exact flaws, though, and in many cases, would probably be even more trivial to pull off.

This article focuses solely on attack vectors against Tanium from the endpoint, unless otherwise noted.

II – The Issues

II(a) – Distributed Scripting

The first Tanium feature that one must understand is that it distributes defined scripts (aka sensors) and their parameters to all endpoints, runs the script, and returns the results.

When a “question” (aka query) is run, they run against “sensors” (aka scripts) on the endpoints. “Sensor is a script that is executed on an endpoint” and returns the result. Some “sensors” are “parameterized sensors” and “accept a value specified at the time the question is asked”. Source: https://docs.Tanium.com/interact/interact/questions.html

Ask yourself, “How securely do they treat these scripts and parameters, and why does it matter?”

First, the why it matters. If an attacker can acquire a copy of these scripts, they would get a general idea of what your detection capabilities are. Example: You’re looking for certain processes with certain parameters, or maybe files with certain names or file content, various registry key entries and values, IPs, file hashes, etc. The level of detail would be dependent on how much you write into your sensor/script that is deployed.

For some scripts/sensors an attacker, should they gain access, may not know anything more than the fact you are looking for file hashes (for example). To know more, they would also need to see the parameters being used against the “parameterized sensors/scripts”. If an attacker gains access to those parameters as well, or maybe even instead of the script, they will know exactly what you are looking for: file hash == XYZ (for example).

File hashes is a lame example, as any advanced security team will not waste their time building their custom detection capabilities around traditional “IOCs” (IPs, hashes, domains/URLs, etc). But, that’s another topic! For more info on traditional IOCs vs TTP, read here: https://penconsultants.com/blog/traditional-iocs-suck/

On that note, see for yourself how Tanium is with modern detection capabilities. Google this: “site:tanium.com ttp”. Nothing. Do that for any other major EDR vendor, and you get hits.

Why does all of this matter? If an attacker knows what you are looking for (and what you are suppressing) they can avoid all detections! Read here for more info on that topic: https://penconsultants.com/home/crown-jewels-monitoring-vs-mitigating/.

Where are the scripts stored? Hmmmm, wonder what’s in this “sensors” folder…

Source: https://docs.Tanium.com/client/client/images/client_dir.png

What about the parameters? If you have access to Tanium, and an inquisitive mind, here’s one area you can do a little exploring.

Challenge #1

Goals:

• Find the scripts/sensors
• Find the parameters

Tools needed: including, but not limited to…

• explorer.exe and/or cmd.exe /c dir
• wireshark / tcpdump
• procmon.exe
• powershell’s filesystemwatcher. Head start: https://stackoverflow.com/questions/25940768/using-filesystemwatcher-to-monitor-file-creation-and-copy-it-before-deleted
• For the 31337, you may also find Volatility to be useful here.

Hints:

• Run questions continually while doing this challenge
• The script/sensors ARE sent to the endpoints and may be stored on disk based on the screenshot above.
• The parameters ARE sent to the endpoint and they are for sure run against the scripts/sensors. Are they memory only, or are they possibly written to disk as well (even if just briefly)?
• What other methods can be used to see process parameters? tasklist /v? taskmon?

Answer:

• When you locate the sensors and parameters, you have completed the challenge.

Extra challenge:

• Write at least one exploit to dump the scripts and parameters to stdout.

II(b) – Results

Consider what kind of data the endpoints are sending back up the chain in response to certain questions:

• process lists (potentially with keys and passwords as parameters)
• command line history (again, potentially with passwords and keys)
• user web browsing history
• file listings and content
• netstat
• mapped network drives
• etc.

These are just a few of the built-in search capabilities in Tanium. There were many I saw on their site throughout the examples in the docs. Would you consider any of these examples to be sensitive data? Best case scenario, this data is a treasure trove of recon data for an attacker. How confident are you with your apps and users following best practices to minimize exposure of things like passwords and crypto keys in command history, logs, process lists, etc.? How many times are your vendors telling you to do things that dumb? Is Tanium demonstrating best practice for specifying the password for use in psexec on this page?

source: https://docs.Tanium.com/client/client/client_deployment_tool.html

How often do you think users slip up and put their password in the username field of a prompt, or miss the hidden command line prompt and enter their password as a (invalid) command, etc? If your answer is not often, you have obviously never reviewed detailed log data from your environment.

As we saw above, “sensors” (aka scripts) run on endpoints with/without parameters. Obviously that doesn’t do a lot of good from a detection standpoint unless you see the results. Ask yourself: As a developer, what are the different ways one can capture output from a script that is run? The most secure way would be to capture stdout/stderr directly. Based on what we already know about this vendor, what methods(s) do you think they use?

Challenge #2

Goal:

• Locate the results when “questions” are being run.

Tools needed: including, but not limited to…

• Tools from Challenge #1

Hints:

• Do your recon first. Run “questions” from the console while monitoring activity on the endpoint.
• Are the results being stored anywhere to disk before being used? Are they memory only? If memory only, are they easily discoverable?
• Are there ways to see the results being sent? On the wire and/or temp files and/or slave processes?

Answer:

• Should you complete your challenge, there may be multiple rewards.
• If the information so far has not already given you pause, you are probably missing something.

Extra Challenge:

• Write at least one exploit to dump the results to stdout.

II(c) – Peer Chain

If you haven’t pulled Tanium out of your environment by this point, and/or taken an oath to never purchase a P2P based “security” product again, you must have some serious risks mitigation Kung Fu. Let’s take you up a rank.

Tanium states that their architecture is a peer chain model with up to 100 peers per chain (by default). The default scope for the peer chain is the endpoint’s class C address space, “clients within the boundary of the /24 subnet form a linear chain of 100 clients, and then another chain of 100 clients, and so on”. There is a lot more here, if interested: https://docs.Tanium.com/client/client/client_peering.html

The way the peer chain works: The server asks a “question” (aka query), and sends that to the handful (depending on the size of your network) of “peer leaders”. The peer chain leader forwards that question/query to its next hop peer in its peer chain. The second peer does likewise and so on until each peer receives the question. (https://docs.Tanium.com/client/client/overview.html)

This is a good thing, right?

But, why introduce the latency with the peer chains at all? TCP/IP latency and overhead are rather minimal compared to the volume of data, especially results, that are being sent around the chain. How does the peer chain model make things faster and give the “15 second” speeds?

“By decentralizing data collection, aggregation and distribution down to the endpoint…”. Oh, got it. Each peer dedupes data coming across the peer chain, which reduces the load on the sever by up to 100x.

Wait, what?!?!?

Challenge #3

Goals:

• Answer the following…
• If each workstation is doing data aggregation of the data it’s receiving from its peers, what does that require about its ability to read the plaintext data from its peers?
• Google “password parameter”. How many hits are there describing applications that allow a password to appear as a command line parameter?

Tools needed: including, but not limited to…

• Google

Hints:

• Use logical reasoning

Answer:

• Once you are sufficiently scared about the type of data being passed around the peer chain, realize you will probably never obtain 100% data hygiene, and understand that peers are required to see each other’s plaintext data, you have completed this challenge.

Extra challenge:

• For those with Tanium, unplug your server immediately.

II(d) – Encryption

Let me ask you a question. What makes the best lie? One that has some truth embedded in it, right? IMO, there are a large percentage of vendors who lie to make a sale and keep a customer. There are certainly vendors who are, for the most part, honest at every level. In my many years of experience in the infoSec field, though, the liars far outweigh the honest vendors. Question everything a vendor tells you. The honest vendors will appreciate your questions and be more than happy to prove their statements.

Here’s a great example that Tanium customers should grill the vendor on. “512-bit Elliptic Curve Cryptography is used for queries and actions distributed across the network to prevent man-in-the-middle attacks or other malicious behavior initiated by compromised endpoints”. (Source – broken link as of 2022: https://info.Tanium.com/Platform_Architecture) Notice anything missing? What about the results of those queries? Will that be encrypted? I found no reference to this on their website.

Elliptic Curve Cryptography is a type of asymmetric (or public key) cryptography. For an endpoint to protect data confidentiality and ensure only the server will see that plaintext data, it must encrypt the data with the server’s public key (before sending). Then, and only then, can the endpoint ensure only the server will be able to decrypt with its private key. If that private key were held by anyone other than the server, they would be able to see the plaintext data.

As you should have discovered from the previous challenges, it would be impossible for peers to perform deduplication/aggregation with other peers if they were unable to see cleartext/plaintext data. A logical person should question whether or not the sensitive data from the entire network is being encrypted end-to-end or not. The answer is obvious: it’s not.

In the industry, this would be considered a vulnerability known as a failure to protect data confidentiality. See “Six Elements of Information Security” (circa 1998), “CIA triad” (circa 1988), or “Secure Computer Systems” (by LaPadula and Bell, 1976). Data confidentiality, through encryption, has been a well-respected industry standard for decades. For Tanium, they appear to have excluded encryption…intentionally!

Looking at it from a different angle, ask yourself, would you be okay logging into your bank account over an non-TLS protected connection? And, what about routing that unencrypted traffic through 100’s of your neighbors’ networks? Of course you wouldn’t! But, this is what Tanium is doing with the endpoint’s data which could, depending on your queries, contain the same type of sensitive information.

II(e) – Hashing – Smoke and Mirrors

This one blows my mind. “Clients provide answers…using hashes”. “Example…a value of ‘192.168.1.1’…would instead pass back as…’389956048’” (https://kb.Tanium.com/Asking_Questions). So, instead of encrypting the results/data, they are hashing it?

The first thing to note is that the “hashing” algorithm appears to be something home grown, as opposed to an industry standard (md5, sha1, etc.). In fact, given that it’s a number (in the given example), one may speculate it’s a random number assigned to a unique string, or possibly a sequential number.

What can one speculate about the scope of the hash-2-string mappings if each endpoint is able to dedupe each other’s data?

If the hash-2-string mappings were easily found, does that give you any resemblances of data confidentiality?

Challenge #4

Goals:

• Is the hash-2-string mappings unique for each endpoint, each peer chain, or the same across the whole network?
• Find the hash table.
• Determine how the hash table is made known to new nodes coming online.
• Research and determine for yourself, does data aggregation provide any security/confidentiality whatsoever, or is it strictly for performance gain?

Tools needed: including, but not limited to…

• All the tools from Challenge #1

Hints:

• How about theorizing that the hash-2-string mappings are global and prove/disprove this by collecting samples from different endpoints and across peer chains? If they are not the same, you’d speculate it was unique mappings per chain, and you would repeat your test. If they were still not the same, you’d prove they are unique per endpoint. My guess is, for their aggregation to be effective, it’s at least a consistent hash mapping across a chain, but maybe even globally.
• To find the mappings, you need to first assume that the endpoint must store it somewhere (memory, disk, registry, etc). As with any aggregation protocol, one must generate, record or locate the mappings before the data can be decoded.
• If it’s a consistent mapping across two or more endpoints, then the mapping must be sent between endpoints across the wire.

Answer:

• Once you are confident that hashing provides zero confidentially protection, you have completed this section.

Extra challenge:

• Write at least one exploit to dump the mappings to stdout.

II(f) – Log Verbosity Setting

Don’t you hate it when your instructor spends multiple class periods teaching you things that are a bit manual. And then, just when you conquer the “manual way”, they show you “the easy way”. Enter logs…

Based on this page, https://docs.Tanium.com/client/client/troubleshooting.html#Windows_Registry, the log verbosity level is typically 0 or 1. By setting it to 91+, you “enable the most detailed log levels”.

According to https://docs.Tanium.com/client/client/troubleshooting.html#Logs, the logs will be named log0.txt, log1.txt, log2.txt, etc.

Challenge – #5

Goals:

• Enable the log verbosity and examine what is written to disk.
• Do the logs only contain agent health type information or maybe something more useful to an attacker as well?
• Is it only logging data related to the endpoint you are on, or details of what other endpoints are sending/receiving as well?

Tools needed: including, but not limited to…

• Your favorite method to modify a byte in the registry: regedit, reg.exe, powershell, vbscript, etc.
• Your favorite txt file viewer: notepad++, less, vi, etc.

Hints:

• Things that might be interesting if they were to show up in the logs: Senors/scripts, parameters, hash mappings, results of scripts run, etc.
• Don’t forget to run plenty of queries while performing this test.

Answer:

• When you determine the full extent of what kind of data is in the log, you’ve completed this challenge.

Extra challenge:

• Find and extract any sensitive information the logs may contain and send it to stdout.

II(g) – Subnet

How sure are you that normal workstations are not going to get mixed up in the same peer chain as something more sensitive, like a server?

Checkout some of these screenshots at the bottom and the subnet table…
https://docs.tanium.com/client/client/client_peering.html

Although a /24 seems to be a default subnet mask for peers determining peering partners, it could be even greater (or less) depending on the IP ranges and endpoint count in your environment. The best I can tell, it seems that they like to keep peer chains at about 100 peers.

Do you have things well segmented in your network to ensure sensitive/high value systems are not mixed with easily-popped workstations? Especially if you were required to increase your subnet mask because of performance reasons?

The subnet size is certainly something you can control, but it’s worth thinking about all of the ramifications of these autonomous peering architectures.

II(h) – Recon

What if you could determine if the target had Tanium before you gained access and execution on an endpoint? According to https://docs.Tanium.com/platform_install/platform_install/reference_network_ports.html, TCP-17472 is the default port. This is for sure configurable, but again, who is going to do that? Additionally, not all Tanium clients will have an external facing server. But, if they have Tanium for their external endpoints, you can be fairly confident they’ll have Tanium on internal endpoints as well.

Do you want to see the names of hundreds of Tanium customers? I am releasing this recon code I created, which will scan the entire internet and display the list of Tanium’s customers that have external facing Tanium servers.

https://gitlab.com/J35u5633k/tanium_public

I’m not going to release the full list, but I found over 7,000 IPs running Tanium, with nearly 300 unique customers. Multiple federal/state/county government agencies, military installations, car dealerships, investment companies, an entertainment studio, colleges/universities, computer hardware and software companies, a cable news network, insurance companies, clothing stores, financial institutions, pharmaceutical companies, a steel plant, utility companies, a paint company, and even a fast food company.

This partial list I’m releasing has all government and military customers removed. It only shows the customers which have public references to their use of Tanium (press releases, job listings, linkedIn, etc) and has had the 2nd and 3rd octet of the IP masked.

Although these customers chose to buy Tanium, made their server(s) publicly accessible on the default port, and put it in their own IP space/DMZ (which made attribution easy), at the end of the day, my goal is to make industry safer and more secure (even people and organizations that do ignorant things).

Let’s get back to the endpoint now. I didn’t see a way to change the default name of the Tanium executable. https://docs.Tanium.com/client/client/deploy_package_windows.html.

I assume this might be possible, but maybe not? Regardless, how many of their customers are going to change it, even if it were an option? This should make it trivial to determine if the target has Tanium running when you gain execution on a box.

There are also many default file names and registry keys that can be used during recon to determine if Tanium is present. If only we could obtain a copy of Tanium, install it, and fingerprint it…

II(i) – Any REs out there?

Check out what Tanium has publicly downloadable with no NDA or EULA to click through – all of their client binaries for every OS they support.

https://content.tanium.com/files/deploy/tanium/ClientDeployManifest.json

Based on https://kb.Tanium.com/Table_replacement_for_the_pre_tag, install with…

SetupClient.exe /S /ServerAddress=[server IP] /17472 /KeyPath=c:\[path to file]\Tanium.pub

Specify the IP address of a known Tanium server or testing server. Based on https://docs.tanium.com/platform_user/platform_user/authoring_import_export.html the keyfile is 158 bytes. I played around with this a little bit to get it to install with a fake keyfile, but, based on some errors in the debug logs, I don’t think it “fully” installed. I’ll be playing with this more as time goes on.

Regardless, you now have a running TaniumClient.exe without NDA or EULA! It is very rare to get access to vendor files like this without purchasing first. I looked everywhere, but I couldn’t find any server side binaries. That would truly be a pentester’s dream come true.

III – Anticipated Reactions From the Reader

The following sections include some of my anticipated reactions to these attack vectors.

III(a) – Can Tanium be this bad?

Tanium is the “fastest growing startup”, already valued at 4 billion dollars, and they are in “12 of the top 15 banks”. Everyone is using them, so there’s no way it can be as bad as it seems, right? How can there be this many fundamental flaws in their architecture, yet they have so many believers and followers?

I spent hours trying to find negative information online about Tanium and P2P EDR solutions in general, but came up empty. I wish I knew what was going on. The evidence is pretty clear to me.

My conclusion is that other security researchers just haven’t focused their attention to this emerging market, specifically P2P EDR solutions, such as Tanium. Hopefully this will inspire others, much more knowledgeable than myself, to start poking around more.

III(b) – You need local admin

As you should have seen in the challenges, there appears to be avenues to exploit some of the flaws with no admin access! Based on this article and my testing, it would appear that, by default, pretty much everything is “world readable”.

Because of this (according to their website) Tanium recommends implementing these mitigations to “protect from an attacker”: https://docs.tanium.com/client/client/client_content.html Wow! My interpretation of this is that Tanium feels security is optional.

Some may argue that properly configured permissions and strict access controls would mitigate these attack vectors in this article. The first question I have is why is this not default??? Why is this “client hardening” optional?

The next question I have is do you really think locking things down to local admin/system offers that much protection? Check out this article if you need to be convinced that it does NOT offer that much protection: https://penconsultants.com/home/restricting-to-local-admin-mitigation/.

III(c) – Local admin on X gives local admin on all.

Some may say, if you gain local admin on one endpoint, you can pop any endpoint. This is just false, in many cases. See this article for more information

Why would you need to compromise another endpoint when Tanium is installed? Statistically speaking, you’re going to have access to up to 50 other endpoints’ data wherever you land. The “aggregation” feature of Tanium has just as many benefits for an attacker!

III(d) – These will be fixed with future patches.

You may ask yourself, “Won’t these attack vectors be mitigated soon making this article and the concern irrelevant?” The answer is no.

What would happen to Tanium’s data aggregation if all 100 endpoints in each peer chain started encrypting their “results” before sending it to the server? The answer: there would be a 100x theoretical increase of data hitting the server. Because of this, you would need to scale your servers (up to) 100x at a substantial cost, and/or query speed will suffer dramatically. This would require a complete architecture change.

How long does it take a typical vendor to add new basic features? Weeks, months, years? Never in some cases? How long do you think it would take a vendor to completely rearchitect and rewrite a software product this large from the ground up…assuming they even see a need to, which is highly unlikely. If you were a company valued at 4 billion dollars and racking in hundreds of millions per year, would you think anything was wrong with your model?

With that said, there is unlikely to be any fundamental architecture changes to Tanium for years to come (if ever). Any attempt to “minimize” the risks associated with the fundamental architecture flaws will simply be an arms race with the attacker.

III(e) – We’ll monitor for these attack vectors.

Best case scenario, you’ll be too late. The attacker will be long gone with the goods.

Refer back to this article from above for more info: https://penconsultants.com/home/crown-jewels-monitoring-vs-mitigating/

IV – Conclusions

IV(a) – The cure

It would not be ethical of me to only give ammunition to the offensive side, so I have to help defense answer the question, “What do we do to protect ourselves against Tanium?”

First, stop worshiping the vendor gods. They will surely lead you astray.

Next, find another EDR vendor that (1) does NOT pass any traffic through other peers and (2) has properly implemented endpoint-2-server encryption for anything passing over the wire and anything on disk. EVERYTHING else is secondary to those two requirements.

That is all. Nothing short of that is an intelligent solution to this problem, IMO. If you have another solution, ping me. I’ll include it and give you credit. Don’t be fooled to think this is the only vendor with “15 second response time”. There are many others, some are even faster. And, most of the others have proper end-2-end encryption and point-2-point communication paths.

IV(b) – Thanks

I want to give a shout out to:

• @strandjs inspiring talk at @derbycon 2017 which motivated me to post about this vendor’s incompetency
• My beautiful wife and friends who helped peer review this article.
• And, of course, you for reading it! My hope is, like @strandjs did for me, this article will inspire others to expose vendors for what they are – failures at decades old security best practices.
• UPDATE: 16 Jan 2018: Thanks to Lee Holmes for pointing out a few critical statements in the original release that needed tweaking.

Timeline

• 29 SEP 2017: Research complete, rough draft article written.
• 14 OCT 2017: Peer review of article and changes complete.
• 14 OCT 2017: Sent email to Tanium (security@tanium.com)
• 14 OCT 2017: Sent email to my federal LE contacts, given the high number of federal government and military servers identified.
• 14 OCT 2017: LE responded the same day with an ACK.
• 17 OCT 2017: Sent Tanium another email (new thread) since I had not received an ACK from them.
• 21 OCT 2017: After a full week with no ACK from Tanium, released article.
• 16 JAN 2018: Added a few updates (tagged with “UPDATE”) and made a few minor edits.
• 16 JAN 2018: Still no response from vendor or statements proving any of this wrong.
• 09 MAY 2018: Added DoD IG investigation link.

Featured images courtesy of: Tomasz_Mikolajczyk, congerdesign, and skeeze @ pixabay.com