A Red Team Challenge: A Very Successful Defense

Back Story Part 2 – Victory!

Part 1 took the accepted view that, “the Red Team always wins!” and considered some circumstances when the the Red Team may not win, which appears to be a rare occurrence.

I also posed the question that if an constrained, limited Red Team always wins, won’t unconstrained adversaries always win also?

By extension, how many times does the Red Team or a pentesting team have to win, with remediation, before the bar begins to be raised for attackers? Who would really know, since every environment is different and most are dynamic and evolving continually? Is the underlying assumption that this activity, which is supposed to detect and plug, vulnerabilities and defensive gaps before the bad guys do, sound enough, or the only game in town?

Perhaps only when Red Teams start losing, will the adversaries start to lose as well?

The Defender Advantage series posts on this blog here, here and here for example, takes a different view. Trustifier promotes trustworthy systems in order to tilt the advantage to defenders, using innovative KSE technology to reduce complexity, overhead and facilitate security management. To illustrate, part 1 also provided some backdrop to an event where Trustifier defensive technology successfully held off a very capable Red Team, on multiple levels. This post further discusses some of the unique aspects of this Trustifier win.

Blue Team Scanning

Continuing with the back story from the CWID event, recall that Trustifier was the first vendor cleared to hook up to the network. With the Trustifier target demo network added to the the JITC network, the Blue Team attempted to scan the systems. Imagine when they couldn’t find them on the network? Querying the network admin regarding whether our systems were actually on the network, the admin laughed and said, “Oh yeah. That happened to us too, we couldn’t find them either.” In both cases Team Trustifier had to open up the rules of our systems so the Blue Team could scan them. When tightened up, KSE protected nodes won’t reply to scanner pings.

Protection Without Patching

Not all of the vulns found from the network admin’s scan were patched by Team Trustifier. KSE is designed specifically to protect vulnerable systems, without patching. (That is what trusted computing is supposed to do, after all.) How would one demonstrate this? Perhaps the only way is to leave exploitable vulnerabilities unpatched, on the defending systems in a challenge.. intentionally. When Trustifier accepts such a challenge for KSE, it’s not unusual for exploitable vulnerabilities to be purposely left unpatched. This goes counter to most defensive positions, that would try and patch at least the riskiest vulnerabilities beforehand. (If you explore our Web site, you may notice that we don’t talk much about vulnerabilities or their management at Trustifier. Rather, we talk about the need for infosec to escape the vuln-centric model!)

The non-by-passable controls provided by KSE escapes the vulnerability-centric model; threats are disconnected from exploitable vulns. From this post:

“KSE is able to envelop all processes in a “need-to-access” environment, which limits the access of all processes, users, files and data to exactly what is needed for a specific service to operate safely and securely. The algebra backed security mechanisms of KSE can enable a pre-emptive lockdown of the system so that the possibility of external intrusion intending to tamper with system privileges or rules for access becomes an extremely difficult exercise.”

“One ends up with just-in-time control over privilege elevation, so the chances of intrusion are reduced by exceptional factors. This is a mechanism that prevents threats from exploiting vulnerabilities, and unauthorized privilege elevation is prevented.”

To clarify this all a little, not all vulnerabilities were patched as I mentioned, but the systems were closed down so that scans would no longer pick them up, so the demo systems could be cleared to join the network. The plan was to make them visible again during the challenge. Team Trustifier didn’t patch all of the vulns from the initial vuln scan.

Red Team Experience, Track Record

We were informed that the challenging Red Team was a combined DISA/NSA Red Team. Trustifier was introduced to NSA reps with the Blue Team. Apparently the Red Team operated from a remote location for this event, not on site. According to their representatives, in over 8k challenges they had never failed to breach the target.

In fact their average time to breach was about 15 minutes. This Red Team had never required more than 25 minutes to successfully reach their goal.

I can’t add much about the make up of this team, or whether they use a rotating roster, or outsource, but the numbers indicates that they do a large number of challenges. When the event got going, it was quite intense according to accounts from those who were there. It seems to me that this Red Team knew what they were doing. Anyone think otherwise?

Conditions, Limitations on Tools? 

Unlike the limitations that are usually place on Red Teams targeting actual corporate networks, for this event, no conditions  were placed on the Red Team in terms or weapons they could use in the attack. This is one of the benefits of a demo event, because one probably wouldn’t want to risk taking down production systems/networks down.

Full-bore insider threat testing

Since KSE is designed as insider threat protection, Trustifier welcomes challenges that include defending against the insider threat, including evil admins. Do you perform no-holds-barred insider threat testing? Hey, no worries, your employees are probably doing that for you, right now.

Trustifier suggested the following format for for the CWID challenge. If after an elapsed time of greater than 30 minutes, (longer than they had ever taken previously) the RT had not breached from an external vantage point, they would be signed in as a regular user. After a period of time they were unable to elevate privileges, the Red Team would be granted admin passwords.

But this challenge had another interesting little twist. In such challenge events Trustifier even goes so far as to direct the RT to particular target directories, and request that the Red Team reveal their contents. This format tests two situations, the first being a rogue users or evil system administrator. The second is a simulation of where an external attacker has breached the network and obtained admin credentials, but with a condensed time frame to expedite the process.

Results: The Red Team always wins? Well, not always.

You might guess that the DISA Red Team was unable to breach from external vantage point, against unpatched systems. This team failed to breach for the first time in over 8k challenges. After 30 minutes or so – longer than they have ever taken to breach before, they were assigned regular user privileges, but were unable elevate those privileges further. They were unable to access the target directories. Later they were signed in as admins on systems of our cross-domain network. The point to keep in mind is, that at every stage, they were unable to exploit the vulnerabilities that were left open for the purposes of advancing to the target goal. They could find the vulnerabilities; they just couldn’t take advantage of them. They even thought they had the binaries at one point, but still no go.

Even when holding admin/root credentials, the DISA Red Team was unable to access the target directory. By the way, KSE protection does this without the use of encryption. KSE is able to separate mission-critical data from system administrators using digital separation for all users with rules set by KSE reference monitor capability, and enforced at the kernel level by mandatory access controls.

Interestingly, to close the event and with the Blue Team observers watching, Team Trustifier implemented a few rules and the Red Team was locked out of the target directory system.

I can assure you that there was plenty of congratulations and back-slapping after the win. Defense was indeed looking very sexy  at that moment, and Team Trustifier enjoyed the dopamine hits after an intense but victorious session.


When I point folks to this, the usual response is a bit of the “roaring silence”. Perhaps they suspect some gimmick or trickery involved, or severe good luck that this happened. Some said they outsource Red Teaming to contractors and we didn’t get their “A” team. Apparently the attack was extremely intense, from about 5 remote locations simultaneously.

Others say that this can be done with SELinux etc.. Maybe it can, but go right ahead and do that for hundreds, or thousands of boxes. Let’s not forget they may different types and versions of Linux boxes, or multiple platforms. Is SELinux practical to use for cross-domain solutions? What one can do with KSE ‘s simple one command, might take a couple of pages of programming-type commands for SELinux. Plus, how does that translate into non-linux boxes or windows administrators without Linux skills?

Some who have read the DISA report have been quick to note that vulnerabilities were found, implying that it was only a matter of time. So I’ll emphasize again that they were left unpatched purposely to demonstrate that KSE would prevent their exploitation, which it did. The whole point is to demonstrate the ability to protect vulnerable systems (without patching).

The bottom line is, they were unable to exploit the vulns, any of them. They couldn’t do anything with them. Some of those vulnerabilities weren’t visible until they were given root, and but before that, they couldn’t get root. When they could see them, they were still unable to exploit them.

It was also the point of the math series I wrote, starting here, to explain why it would not be a matter of time, as one assumes in the typical vuln-centric infosec world view. KSE does not work the same as other technologies.

Why is this important? If you can protect systems that are not yet patched, you can protect systems for which there is no patch, and systems with unknown vulnerabilities.

Could you expect this result with your current defences? Can you replicate this on your environment?

Current Evolution

There it is. Exploitable vulns left unpatched, no conditions on tools, full bore insider threat testing and the Red Team failed to breach. We could repeat this defense tomorrow, or next week or month. How about you? It would be even easier for us to defend today, with the use of TUX AI automation.  Even more important, TUX AI will provide even #SMBs without stellar security expertise trustworthy Defender Advantage

A current theme here at the Trustifier blog, is using trustworthy computing to turn the advantage from attackers, to defenders. A recent example of this was the GOV2COM hackathon in which Trustifier defended against about a dozen or so Red Teams at once for almost 3 months. (See here, and here.) We had interns role playing and deliberately clicking on probable bad links, which was kind of fun. A very interesting thing for us was that the defense was more than just protecting individual systems with trustworthy systems and langsec based detection. Trustifier is a leader in all aspects of defensive capability and we were also looking at deception techniques as well. We’ll discuss that even more in future.

By the way, none of those Red Teams were successful either.


Related Reading

Five Attributes of an Effective Corporate Red Team

Trustifier Inc.’s comments on,
Joint Interoperability Test Command’s Information Assurance Assessment Report dated January 2010 on CWID2009 Trustifier Multi-level Security Solution Trial

By |September 26th, 2016|Insider threat, KSE, TUX GUI|

About the Author:

Leave A Comment