Red Teams: When you can’t find the bad guys, make some up

Red Teams: When you can’t find the bad guys, make some up

You’ve spent money on security products that escalate nothing. You have a 24/7 SOC that hardly pays attention to their tools, or knows how to use them. You have intelligence feeds but have no idea what consumes them. Logs are inaccessible, slow to query, or non-existent. Defenders have stopped hunting and lost a sense of purpose.

That means it’s time for a Red Team to come in and fuck shit up.


Observability vs. Inspectability

I ran across this post, Putting observability first, on HackerNews.

It’s an interesting discussion, but unfortunately the term observability is overloaded. It is used in control theory as “a measure for how well internal states of a system can be inferred by knowledge of its external outputs” [1].

For several years I’ve been using the term “inspectability” to refer to the kind of observation of code execution to which the author refers. Inspectability is an important concept, especially for computer security, and is not often discussed.

It’s interesting to note that malware written in a language like OCaml would often be harder to reverse engineer than malware written in C, precisely because of the points the author makes.

[1] http://en.wikipedia.org/wiki/Observability


Introducing the WeaselBoard!

Introducing the WeaselBoard!

I’ve also put up a link to that whitepaper and a slide deck at weaselboard.com


Cyberattack on German steel factory causes ‘massive damage’

From IT World:

A German steel factory suffered massive damage after hackers managed to access production networks, allowing them to tamper with the controls of a blast furnace, the government said in its annual IT security report.

The attackers got in through spear phishing, then were able to access the ICS directly.

I’m expecting 2015 to be an interesting year for ICS security.


South Korean Nuclear Plant Hack

From Reuters:

The Korea Hydro and Nuclear Power Co Ltd (KHNP) and the government said only “non-critical” data was stolen by the hackers, and that there was no risk to nuclear installations, including the country’s 23 atomic reactors.

South Korea’s energy ministry said it was confident that its nuclear plants could block any infiltration by cyber attackers that could compromise the safety of the reactors.

“It’s our judgment that the control system itself is designed in such a way and there is no risk whatsoever,” Chung Yang-ho, deputy energy minister, told Reuters by phone.

“It is 100 percent impossible that a hacker can stop nuclear power plants by attacking them because the control monitoring system is totally independent and closed,” the official said.

100% percent impossible? That sounds like a challenge.

I’m willing to wager that “non-critical” data could be a good starting point for crafting a more sophisticated attack. But of course, nothing has ever jumped an air gap…


Very realistic

I’ve been reading through Kim Zetter’s excellent new book, Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon and saw this reference to Sandia (and indirectly, to my colleague John Mulder):

“In a 2009 report on 60 Minutes , researchers at Sandia National Lab showed how they could cause components at an oil refinery to overheat by simply changing the settings of a heating element and disabling the recirculation pumps that helped regulate the temperature.”

I found the article at CBSNews.com, but haven’t been able to track down the actual video.

“The first thing we had to do was actually gain access to the network and that’s, we just got that as launch attack. And then we turn up the BTUs, and then we’re turning off the re-circulator pump. There we go,” Mulder said.

Mulder said this type is simulation is “very” realistic.


U.S. Blames China’s Military Directly for Cyberattacks

New York Times – U.S. Blames China’s Military Directly for Cyberattacks:

The Obama administration on Monday explicitly accused China’s military of mounting attacks on American government computer systems and defense contractors, saying one motive could be to map “military capabilities that could be exploited during a crisis.”

From the report itself:

In 2012, numerous computer systems around the world, including those owned by the U.S. government, continued to be targeted for intrusions, some of which appear to be attributable directly to the Chinese government and military. These intrusions were focused on exfiltrating information. China is using its computer network exploitation (CNE) capability to support intelligence collection against the U.S. diplomatic, economic, and defense industrial base sectors that support U.S. national defense programs.


Python Number Conversion Chart

I ran across this Python number conversion chart a while ago on HackerNews. It looks pretty helpful – I always forget which way hexlify and unhexlify work!

Python Number Conversion Chart


Getting clever with list comprehensions

Suppose you have a list of TCP connections:

packets = [
    { 'src': ('192.168.1.1', 22045), 'dst': ('192.168.1.3', 31037) },
    { 'src': ('192.168.1.1', 11567), 'dst': ('192.168.1.2', 28432) },
    { 'src': ('192.168.1.1', 22045), 'dst': ('192.168.1.3', 31037) },
    { 'src': ('192.168.1.7', 1), 'dst': ('192.168.1.8', 2) }
]

If we just want to get a quick idea of who is talking to who (most data of this sort would be much larger than the example above), a quick count of how many packets are in each conversation is a good start. Here’s the simple code to parse that out:

packet_count = {}
for p in packets:
    if (p['src'], p['dst']) in packet_count:
        packet_count[(p['src'], p['dst'])] += 1
    else:
        packet_count[(p['src'], p['dst'])] = 1
print packet_count

--- output ---
{(('192.168.1.1', 11567), ('192.168.1.2', 28432)): 1,
 (('192.168.1.1', 22045), ('192.168.1.3', 31037)): 2,
 (('192.168.1.7', 1), ('192.168.1.8', 2)): 1}

But we can simplify this code a lot just by using defaultdict:

from collections import defaultdict
packet_count = defaultdict(int)
for p in packets:
        packet_count[(p['src'], p['dst'])] += 1
print packet_count

--- output ---
defaultdict(<type 'int'>, 
    {(('192.168.1.7', 1), ('192.168.1.8', 2)): 1, 
    (('192.168.1.1', 22045), ('192.168.1.3', 31037)): 2, 
    (('192.168.1.1', 11567), ('192.168.1.2', 28432)): 1})

I’ve got a while until this plane lands, so how about a clever one-liner?

packet_count = dict([((p['src'],p['dst']), packets.count(p)) 
                    for p in packets])
print packet_count

--- output ---
{(('192.168.1.1', 11567), ('192.168.1.2', 28432)): 1,
 (('192.168.1.1', 22045), ('192.168.1.3', 31037)): 2,
 (('192.168.1.7', 1), ('192.168.1.8', 2)): 1}

But wait, there’s more! Python 2.7 supports dictionary comprehensions, allowing us to do…

packet_count = {(p['src'],p['dst']) : packets.count(p) 
                    for p in packets}
print packet_count

--- output ---
{(('192.168.1.1', 11567), ('192.168.1.2', 28432)): 1,
 (('192.168.1.1', 22045), ('192.168.1.3', 31037)): 2,
 (('192.168.1.7', 1), ('192.168.1.8', 2)): 1}

Reverse Engineering the Saturn V’s F-1 Rocket Engine

How NASA brought the monstrous F-1 “moon rocket” engine back to life

A typical design document for something like the F-1, though, was produced under intense deadline pressure and lacked even the barest forms of computerized design aids. Such a document simply cannot tell the entire story of the hardware. Each F-1 engine was uniquely built by hand, and each has its own undocumented quirks. In addition, the design process used in the 1960s was necessarily iterative: engineers would design a component, fabricate it, test it, and see how it performed. Then they would modify the design, build the new version, and test it again. This would continue until the design was “good enough.”

Lots of parallels with software development and reverse engineering.