This post was originally published on this site is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to

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

This article is about Tanium:

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 open-minded readers that are willing to admit that vendors (as a general rule) fail us. For the nay-sayers, there is no hope for you or your company; you are doomed. Do yourself a favor and just go back to worshiping your vendor gods and prepare (the best you can) for the cyber apocalypse.

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; I initially obtained all information through Tanium’s website. I have also gained access to a little more than just “information”, but it is minimal.

The entire article will be speculative, based on logical reasoning imposed on information from their website. As such, there will be “challenges” to complete for those of you who currently have Tanium installed. Your mission will be to prove (or disprove) my speculations.

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, probably even more trivial to pull off.

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

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” 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:

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 lame, traditional “IOCs” (IPs, hashes, domains/URLs, etc). But, that’s another topic! For more info on traditional IOCs vs TTP, read here:

On that note, see for yourself how out of touch Tanium is with modern detection capabilities; Google this: “ 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:

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

Image description


What about the parameters? Here’s one area that those with Tanium can do a little exploring on their own if you have a inquisitive mind. We can be certain, the parameters are run against the scripts.

Challenge #1


  • Find the scripts/sensors
  • Find the parameters

Tools needed: including, but not limited to…


  • Run questions continually while doing this assignment
  • 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?


  • 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 even telling you do things that dumb? Is Tanium demonstrating best practice for specifying the password for use in psexec on this page?

Image description


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 “all too 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


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

Tools needed: including, but not limited to…

  • Tools from Challenge #1


  • 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 the easily discoverable?
  • Are there ways to see the results being sent? On the wire and/or temp files and/or slave processes?


  • 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:

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. (

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


  • 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…


  • Use logical reasoning


  • 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. Do you know how to tell a vendor is lying? The answer is simple: if their lips are moving. What makes the best lie? One that has some truth embedded in it.

“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: 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. What’s a logical person to think about whether or not the sensitive data from your 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 ‘’…would instead pass back as…’389956048’” ( 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?


  • 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


  • How about theorizing that the hash-2-string mappings are global and prove/disprove that 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 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.


  • 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,, the log verbosity level is typically 0 or 1. By setting it to 91+, you “enable the most detailed log levels”.

According to, the logs will be named log0.txt, log1.txt, log2.txt, etc.

Challenge – #5


  • 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.


  • 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.


  • When you’ve 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…

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, 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.

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 had 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.

IP Name
13.x.y.133 Amazon Corporate Services Pty Ltd
209.x.y.5 MetLife
208.x.y.206 MCI Communications Services, Inc. d/b/a Verizon Business
70.x.y.254 MCI Communications Services, Inc. d/b/a Verizon Business
71.x.y.24 MCI Communications Services, Inc. d/b/a Verizon Business
71.x.y.151 MCI Communications Services, Inc. d/b/a Verizon Business
96.x.y.105 MCI Communications Services, Inc. d/b/a Verizon Business
74.x.y.147 InComm
161.x.y.60 Target Corporation
159.x.y.140 Cerner Corporation
159.x.y.141 Cerner Corporation
104.x.y.193, LLC
184.x.y.163, LLC
184.x.y.17, LLC
192.x.y.136, LLC
198.x.y.2, LLC
162.x.y.220 Toyota Motor Sales, U.S.A., Inc.
143.x.y.77 McKesson Corp.
143.x.y.248 McKesson Corp.
204.x.y.37 Splunk
216.x.y.130 eBay, Inc
208.x.y.9 Autonation, Inc
144.x.y.203 Metropolitan Water District of California
130.x.y.96 Georgia Institute of Technology

Again, I’m not going to release the full list, just the recon code and the heavily filtered/redacted list above. 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.

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!

Based on, install with… SetupClient.exe /S /ServerAddress=[server IP] /17472 /KeyPath=c:[path to file]

Specify the IP address of a known Tanium server or testing server. Based on 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!

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 smarter 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”: Wow! My interpretation of this is that 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:

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:

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?”

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.

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.
  • 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 (
  • 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.

At L Technology Group, we know technology alone will not protect us from the risks associated with in cyberspace. Hackers, Nation States like Russia and China along with “Bob” in HR opening that email, are all real threats to your organization. Defending against these threats requires a new strategy that incorporates not only technology, but also intelligent personnel who, eats and breaths cybersecurity. Together with proven processes and techniques combines for an advanced next-generation security solution. Since 2008 L Technology Group has develop people, processes and technology to combat the ever changing threat landscape that businesses face day to day.

Call Toll Free (855) 999-6425 for a FREE Consultation from L Technology Group,