Laika BOSS

Last summer Lockheed Martin open-sourced one of their tools for intrusion detection, Laika BOSS. The whitepaper can be found here.

The tool approaches detection of malicious activity differently from say Snort or Suricata.  Instead of looking at the entire traffic stream, it looks at elements within the traffic, individual files and programs. For instance if an email is received, it will look at the body of the email, then the attachment, break out the sub-components of the attachment and analyze them separately.

Laika BOSS has been internally tested at Lockheed for several years now and most of the bugs should be worked out. They have open sourced it in the same spirit that they released the now famous kill chain paper, hoping to promote more advances in network defense.

A copy can be found at their github: https://github.com/lmco/laikaboss.

The install instructions are pretty straight forward, there are a fair bit of dependencies to be installed first:

apt-get install yara python-yara python-progressbar
pip install interruptingcow

apt-get install libzmq3 python-zmq python-gevent python-pexpect

apt-get install python-ipy python-m2crypto python-pyclamd liblzma5 libimage-exiftool-perl python-msgpack libfuzzy-dev python-cffi python-dev unrar
pip install fluent-logger olefile ssdeep py-unrar2 pylzma
wget https://github.com/smarnach/pyexiftool/archive/master.zip
unzip master.zip
cd pyexiftool-master
python setup.py build
python setup.py install
wget http://pefile.googlecode.com/files/pefile-1.2.10-139.tar.gz
tar vxzf pefile-1.2.10-139.tar.gz
cd pefile-1.2.10-139
python setup.py build
python setup.py install

I had no trouble installing any of this on a fully updated debian box, on an older CentOS machine (5.7) I had to manually search google for a lot of things and install from source.

Next, grab a copy of the laika source from github:

wget https://github.com/lmco/laikaboss/archive/master.zip
unzip master.zip
cd laikaboss-master

Laika has several parts, a standalone scanner, a distributed client-server framework, and an integration with MTA's.  Usage of the standalone instance is fairly simple:

Just point it at a file and go. It returns a wealth of information in JSON format, so it can easily be parsed by other applications or sent to a SIEM. 

I haven't played around with the networked instances yet, but I probably will in the near future. Someone also pointed me to REbus, which looks like a similar application I'm going to have to take a look at in the future. 

f3n3s7ra

ICS Challenge part 3

Apologies for the long delay between posts, between getting my wisdom teeth taken out and classes starting up again I was busier than I expected.

The third part of the challenge starts out by giving us this hash:  392afaed9e68dd857d15072d8646c51a

• What type of file is this, what campaign was using this malware, what 0-day was used in this campaign, what is another hash associated with this campaign, what are at least C2 addresses observed as part of this campaign. 

The obvious place to start researching is virus total. Putting the hash in we get that it's a Windows executable, specifically WINCC_SCADA file for  Siemens AG. The files name is CCProjectMgr. Is this starting to sound familiar? Siemens, SCADA, CCmgr....it should. It's part of Stuxnet. Stuxnet used multiple 0-days to spread, but one of the more famous ones was the .lnk vulnerability which it used to spread through USB drives. One of the hashes also associated with stuxnet is 0x758240613C362BB1FD13E07D19F357B7F8A6DA from the malicious driver. Some of the IP's used in the Stuxnet campaign are 69.195.129.72 and 211.24.237.226.

Next we are asked to conduct another analysis of the pcap.

• There is an obvious ICS protocol being used, what are the status codes it is using. At one point this protocol communicates about tags set on the system, what are these tags? There is an indication of an ICS protocol in use on another segment of this network. what is this protocol?

Opening up the pcap in wireshark immediately we can see that Modbus is being used.

Then looking farther down at the actual content of one of the packets we can see one of the status codes the question asks about.

So now we can go and look for the rest of these status codes, there are in total: Read Holding Registers (3), Read Input Registers (4), Read Coils (1), Unknown Function (103), Unknown Function (104), Unknown Function (105), Unknown Function (120), Unknown Function (121), and Unknown Function (122). 

Now we need to find the tags. Most of the modbus packets are either Read Holding Function or Read Input Registers, neither of which carry much in the way of data that we'd be interested in. However the Unknown Function packets have a large blob of data, let's start looking through those. And bingo!

We see the status codes GREEN and RED. Upon more digging we see the codes OPEN and CLOSE as well. 

As I was going through the packet capture, some NBNS requests stood out to me. 

These are NetBIOS Name Service lookups for sites like Netflix and Amazon. Leaving aside the issue of employees trying to visit those sites, this points to another interesting fact. NBNS is used to try to resolve a domain, AFTER a DNS lookup fails. Now I didn't see any DNS packets in the capture, meaning it's probably not running in the environment. However this provides an opportunity for malicious attackers on the network to employ NBNS spoofing, without even having to go through the trouble of exhausting the UDP ports to block DNS first. 

I do not know enough about ICS protocols to try to discern what the other protocol being used on a different network segment is. 

The next set of questions is about internet connected ICS. 

• How many modbus devices are currently connected to the internet in North America. How many BACNet clients are currently connected to the internet in the US. How many IEC-104 devices are online currently. Document a feature of Shodan that you find interesting. 

Now the premier search engine for ICS devices is Shodan. I am already familiar with this service, so it's a simple matter to head to the site and query for modbus devices. It shows 2,152 modbus internet connected devices in the US.

Now we do the same thing for BACNet:

And we see that there are 4,663 BACNet devices connected to the internet. And then we do this once more for IEC-104:

Which returns 109 currently connected devices. Lastly we are to document a feature of Shodan that we  find interesting. To me, that would be the Shodan API, which let's you utilize the power of Shodan in your own applications. 

That was the final 300 level question. 

f3n3s7ra