Wednesday, April 29, 2015

A thought on security incidents

Wow only one day left in April! No better time than now to crank a blog out. So, I've noticed that despite myself being in the Incident Response (IR) field I don't blog about IR a lot. This blog will change that!

In my day job I work with many different companies, big ones, small ones, public ones, private ones, red ones, blue ones. When I'm not helping companies respond to incidents, I am usually helping them develop their IR plans or testing them through tabletop exercises. Out of all the clients I work with, one of the biggest common difficulties is defining what makes an IT Security Incident.

Let's first talk about why this definition is a critical part of an IR plan. Essentially this definition is the criteria that must be met in order to activate your IR plan. As such, it needs to be broad enough to encompass any IT Security incident, but specific enough that we are not responding to network outages.

The definition I generally start with for any company as a point of discussion is the following:

"An IT Security Incident is any event that is attributable to human root cause and malicious intent."

Let's break down this definition to understand why I wrote it this way. 

Let's start with event. An event is some observable thing that happens. I use thing to keep it broad. In our context, this could anything from an alert in our Intrusion Detection System (IDS) to a user coming up to us in person and explaining a situation through interpretative dance. 

So, now for every event our goal will be to determine if there is a human root cause AND malicious intent. Why those two things?

Human Root Cause: Technologies fail and natural disasters happen. To prevent us from competing with Disaster Recovery plans, we need to rule this out. This is why we add a human root cause. For instance, if a tornado relocates our data center for us, this would definitely fall under the Denial of Service (DoS) incident type. 

Malicious Intent: Malicious intent is specifically added to qualify the human root cause aspect. Specifically, this is what keeps accidents, mis-configurations out of scope. As an example, a drunken sysadmin walking through the data center trips on the power cord to a server. As a result, the server shuts down and the revenue generating website is now offline. While this is attributable to a human root cause, we don't have malicious intent. Therefore it makes no sense to involve the IR team. Additionally, let's say a firewall is not properly configured. This is still not a security incident. In terms of taxonomy, this would an attacker's entry vector and perhaps also the root cause for an incident. In and of itself however, it is not a security incident.

To use this definition, as we analyze events to determine if they are false positives or not, we should assume there is human root cause and malicious intent. In this way, we are disproving this conditions which is safer than trying to prove them, not being able to, and not reacting to an actual incident.

Now, you may ask, what about a user that accidentally emails sensitive data outside the company. You may argue that this is a data breach and we have a security incident, and there this definition is crap! To which I respond nay.

The problem with this is a data breach is not a security incident by itself. Hang tight let me explain! A data breach does not occur by itself. It is usually the result of something else (the actual security incident). For example, malware infects a Point of Sale (PoS) terminal which steals credit card data and sends it to Djibouti. From an IT Security standpoint, your problem is a malware problem. That is the root cause. The breach of credit card data is just a symptom. Therefore, if you rebuild the PoS, and prevent the infection vector used to place the malware, you will solve the problem of credit card being sent to Djibouti.

Let's go back to the example of a user who accidentally emailed out sensitive data. If we use the NIST 800-61 document  and reference Figure 3-1 which I attached below, we'll see the Incident Response Life Cycle. You'll notice to get Post-Incident Activity, first we need to perform the Containment, Eradication & Recovery phase. How do we contain an e-mail that has gone out? Do we eradicate the user? What do we do in the recovery phase?

However, the concern in the example is still real. If it's not a security incident, what is it? Well, it's what you thought it was, it's a data breach. If you went through the NIST document, you'll notice that it never really discusses dealing with a data breach. Instead it points you to OMB Memorandum M-07-16: Safeguarding Against and Responding to the Breach of Personally Identifiable Information. While this document is specifically focused at US government agencies, the commercial sector can implement something similar. What a company would implement is a Data Breach Plan. This plan would complement an existing IR plan. A Data Breach Plan effectively guides the business in responding to a data breach, which requires larger involvement from different business units than an IT Security incident.

In summary, this is a definition I use for companies that don't have an IR Plan are looking to start. It does its job in aligning the purpose of the IR Plan. One reason I don't use the NIST definition from the document referenced is because it requires the incident to have broken a policy. This is great if your organization has very well documented and easy to remember policies. For many of the clients I work with, this is not the case.

Last but not least, only four of you put your names in the comments of my March post entering the raffle for the EFF hat. With a 25% chance of winning, I'd like to say congrats to mrlanrat who won the hat and stickers. I'll be contacting you to arrange shipping! Thanks again to everyone who reads this blog!

Sunday, March 29, 2015

Why CSI: Cyber is a good thing

Welcome to the blog post for March. This happens to be very late. If you missed last month's post, don't worry you didn't miss anything since I didn't do a blog post. I paid for my laziness by donating $100 to the EFF. I'm also giving away the hat they sent as a gift. Check out the last post for more details!

WARNING: This blog post is pretty much a giant spoiler. While I don't believe in spoilers, I do respect them, so you've been warned. Go watch the show (Episode 1) and come back. 

Without any further ado, March marked the start of the new CSI spin off CSI: Cyber

Just as I expected, this ruffled SO many InfoSec jimmies. The halls of Twitter filled with echoes of DERP. It was horrible. I heard rants about Green Code, and Malworms, and Dawson's Creek, oh my! So, as curious as a cat, I decided to watch it as well. This way I can see what the hullabaloo was about.  

In case you don't have time to read this blog, I'll jump to the point right now:

TL;DR This show is a good thing for the InfoSec community. 
Because it gives us a common ground for speaking to the laymen while using examples from the show which are very real. Read on to see me break out the realism in the show.

I probably just lost half of my 7 readers with the above statement, but for those that have stuck around, please hear me out. 

We have one of the more difficult jobs when it comes translating our work into laymen's terms. As an example, many of us have an excruciating time explaining to our family members why this is not normal:

Even more difficult is trying to explain why some attachments just shouldn't be opened. The core of the problem is pretty simple. People do not understand the risk. Businesses are just starting to realize risk as major companies continue to headline the news. However, everyday people are still in the dark as to how real of a threat this is. 

At this point of the blog, I'd like to press pause and level set with everyone. I believe that the only way to build support for our security efforts is to bolster awareness of the threats so that we have buy in from end users. I've walked into too many companies as a security consultant and have been told that things from the SANS Top 20 would negatively impact culture. We need end user's to realize they need these controls. 

I hate using FUD ("Fear, Uncertainty, and Doubt"), but in some cases it is the only way to get people to pay attention. This is where CSI:Cyber comes in.

Let's pretend for a second that you are sitting down with your extended family watching CSI:Cyber. The show concludes and everyone is sitting around talking, when little Bobby Tables asks: "Mom, Dad, could someone really spy on us from the baby cam?"  

This is where mom will usually give that line about, "Of course not Bobby, it's just a movie and movies aren't real" ... but not this time! This is your chance!

You have the chance to not only give Little Bobby nightmares of cyber abduction, but to actually have a real conversation with someone about the capabilities of the bad guys. You may ask yourself, why couldn't we do that before? Well, simply put, our audience didn't have interest in the subject matter. CSI:Cyber gives us a common ground that is both engaging and entertaining. 

From here we can draw parallels to real life, real attacks. Explain that these are the reasons WHY we patch, this is WHY you don't need admin rights, this is why you shouldn't use default credentials etc. etc.

In order to do that, we need to sift through this show piece by piece and actually identify how plausible these events are. That’s coming next, but first, let’s addresses the DERP factor with a quick tangent. 

Sure this show, has its level of derp, but what show doesn't? Do you really think doctors all nod their head and say, "I concur" as they watch House. Hell, I bet real detectives will hang their head every time SVU mentions semen. However, at the same time if we were to actually depict the day in the life of a forensic investigator, the show would suck and no one would care or want to watch it. 

Let's take a day out of my life for example:

Hour 0: XYZ Company calls says they were breached
Hour 4: I join a meeting to talk to a representative from XYZ
Hour 5: Rep from XYZ has no clue what he's talking about, schedules another meeting with 'tech guy'
Hour 7: I get travel booked to goto client site:
Hour 19: I am on a plane to client site
Hour 24: I am at the client site, they stick me in an old office ... it smells, only 1 light works.
Hour 48: Still waiting for access to go take acquisitions of evidence.
Hour 72: Evidence is acquiring.
Hour 96: I'm reviewing logs ....
Hour 120: .... still reviewing logs
Hour 144: .... wtf is this system? client says oh thats our windows 2000 box we have to have
Hour 150: we finally found the guy that knows where this box is, its in an old telco room
Hour 168: Windows 2000 box acquired

............... I'm going to stop here, my life sucks ... this is why I drink.
So obviously, to keep people from developing stress, depression, high blood pressure and drinking habits like we have all developed. CSI:Cyber adds some zest ... you know kind of like these Air Force commercials. Anyhow, I'll just refer to these acts as "Good TV".

NOW Let's get into the show!

Part 1: Webcam 

The show begins with a baby getting snatched from a crib while a bunch of foreign voices are arguing through the webcam/baby monitor. This is the BEST FUD Factor EVER! We have cyber-peepers and a kidnapping. This is every parent's nightmare! I guarantee you will have the ear of anyone with a child. So let's break it down:

Later in the show we learn that the attackers could view the webcam via a Remote Access Trojan ("RAT") installed on mommy's computer which was put there by the baby daddy (remember, this is a drama!). This leads us to it definitely being a targeted attack, but I'll explain first how it could have also been un-targeted. 

First, let's tackle some of the tech. Some people didn't think that a webcam could transmit audio.
You bet'cha it can! Meet the Neewer V100!

It's less than $40, Prime Available and fully loaded, with pan and tilt (you can remotely move it, think about that for a minute), Night Vision ... and most importantly TWO WAY AUDIO! 

Now for our next trick, and why I mentioned the possibility of it being un-targeted. Let me introduce you to ShodanHQ. Shodan is the work of the brilliant John Matherly. This is an awesome project and I'm not going to do it any justice with a quick overview, but imagine it as the Google of banner grabs. This bad boy crawls the internet like Google, but it indexes what is running on all the ports. Then we can search those banner grabs for things we are interested in. Today it will be webcams.

Below are the results just from the term "netcam". At first glance we can see almost 6,000 in the US alone. This is also just from one webcam dork. There are many others.

Using the paid API and Python I was able to sift through hundreds of results in under 30 minutes and found this little girl from [Redacted, not really important to the story], USA, sound asleep. This is what I meant by un-targeted. I have no clue who this little girl is, yet here she is. As a parent this is where my stomach starts to turn, as did many of my friends who had kids who I let preview this blog. 

Now if that is not sickening, let's get kinetic. Many of these webcams are connected to the WiFi. In these administrative pages are the connection details for the WiFi such as the ESSID (WiFi name) and in some cases the BSSID (MAC address). Now ... if only there was a database that mapped ESSID and BSSIDs to a geographical map ... kind of like ...

Anyhow, remember, I digressed from my point. As we learned later in the episode, the criminals used a RAT. RAT is a real term. Short for Remote Access Trojan, or Remote Access Tool. There are plenty of these to choose. You have Dark Comet, Cybergate, Blackshades, Poison Ivy, jRAT, etc. All of them do essentially the same thing, and they do it very well. They give an attack remote access to your computer.

Feel free to read more about RATs if you're new to term: However, I am going to steal the Wikipedia list of capabilities:
  • Block mouses and keyboards
  • Change the desktop wallpapers
  • Downloads, uploads, deletes, and rename files
  • Destroys hardware by overclocking
  • Drop viruses and worms
  • Edit Registry
  • Use your internet to perform denial of service attacks (DoS)
  • Format drives
  • Steal passwords, credit card numbers
  • Alter your web browsers homepage
  • Hide desktop icons, task bar and files
  • Silently install applications
  • Log keystrokes, keystroke capture software
  • Open CD-ROM tray
  • Overload the RAM/ROM drive
  • Send message boxes
  • Play sounds
  • Control mouse or keyboard
  • Record sound with a connected microphone
  • Record video with a connected webcam
  • Show fake errors
  • Shutdown, restart, log-off, shut down monitor
  • Record and control victim's screen remotely
  • View, kill, and start tasks in task manager
This matches the capabilities of the RAT in the show. Furthermore, do you remember how the RAT got installed? The husband installed it to monitor the life of his kid by spying on his wife's computer. It is not uncommon for attackers to put a link to their RAT on YouTube advertising it as spy software to remotely monitor a spouse. Kinda like this: Something tells me this probably isn't legit. 

For the most part, once these attackers get access to your computer, they most likely aren't going to come steal your baby. Instead, what they will do is turn on your webcam and start taking pictures of you. Kind of like this one I found which was posted in a forum. This is a bot owner showing off one of their 'slaves'. This is the term the use for a botted computer.

This guy has absolutely no idea someone is taking a picture of him. Now he's obviously in his bedroom. Imagine what images our attacker could take pictures of in there and use to demand a ransom. Now, what if this was your son, daughter, wife or husband? 

If that made you angry, wait until you find out that these are mostly teenagers doing this, and on top of that, they also sell and trade access to your camera like Pokemon cards. 

One of the offers I found was 10 slaves for $1 USD. Yeah, that's 10 Cents for access to your mug. I'm not sure what I would be more offended by.

So to recap:
Technical capability of a webcam playing audio? Check!
Ability to find unsecured webcams on the internet? Check!
Getting a RAT on a spouse's computer? Check!

Congratulations. You've made it past Part 1. The rest are quick points addressing some of the dialog in the show. 

Part 2: DFIR Shenanigans 

As part of my profession (Digital Forensics, Incident Response "DFIR"), I conduct a lot of engagements helping companies establish incident response ("IR") policies and procedures. A lot of the issues companies have when trying to establishing these plans are captured in this show. Let's break them down:

"Any crime involving electronic devices is by definition cyber": Oh man! Twitter had fun with this one. At the end of the day, cyber is the term. Someone used it, it caught on, and just like APT, we are stuck with it, so let's grow up and get over it. The next trick, how does a company define a cybersecurity incident versus perhaps a physical security incident, or better yet, a general IT incident? At the end of the day, you need to define what activates your cyber incident response team actually responds to.

"The baby cam was unplugged and secured": If I had a dollar for every time I arrived onsite to a company who was nice enough to turn the server off to contain the incident .... "Please treat all hardware, including the baby cam like a dead body, don't touch it, don't move it" This line was excellent and underscored the need for first responders to be properly trained in acquiring evidence. Many companies will sometimes assign their help desk team members to this job with little training.

Here comes something fun we don't talk a lot about in the DFIR field. Testing! Our cyber sleuths start tossing evidence into these cool high speed Faraday bags which should be blocking the communication to the mobile devices. These are great to prevent the device owner from issuing a remote wipe command. That is provided they work. Make sure you take the time to test things like Faraday bags and write blockers. Nothing is more embarrassing than sticking a phone in a Faraday bag and then it rings.

"All I got is green code here" Okay, look. I don't even know what to make of this. The best I can do is guess that this is cooler than what most companies will come back and say: "Well, our AV scan didn't show anything" 

Part 3: Natal-Cam HQ

In this scene we find our analyst hero Krumitz walking the data center of Natal-Cam HQ. I really don't have to go too far into analysis here. This is a great allegory of our current state of cyber security. Krumitz asks "How long has your source code been like this?" referring a vulnerability in the company's camera software. The uneasy company rep states he was instructed to not talk to Krumitz. 

He then goes on to explain how he took [the vulnerability] upstairs but nobody listened. 

This is a huge theme in many companies. As I go around to different companies and conferences I get to talk to a lot of analysts who have the same issue. The business has difficulty in understanding the risk of vulnerabilities. This usually equates to them being disregarded in lieu of operations.  

Part 4: Password Tattoos

I'll cave here, the password thing was funny. I have seen multi-person passwords in the field before. Usually the idea is around two groups of people, each group knows a half of the password and together they can unlock a joint system. I assume this is what the criminals were doing. No honor among thieves and what not, so they used this. Each person would put in their portion and then bam, unlocked. How they all didn't know each other's secret dates is beyond me. What's really going to bake your noodle though is remember it was a 20 character password? I'll let you add up the numbers.

I'm just kidding, I won't bake your noodle ... I told you, spoilers.

Part 5: Conclusion

After breaking down the show, I want to go back and bring up the point of this blog again. This show is a good thing for the infosec community. We as infosec professionals should know what is possible and what is good TV and then to use these things this as a common ground for communicating risk and realism to the layman. Doing so will help us bridge the educational gap the laymen has in information security. Hopefully, this results in them becoming more security conscious which is all we can really ask for.

Saturday, March 7, 2015

Missing the mark -- Win a free EFF hat.

In my last blog post, I committed to posting a blog at LEAST once a month. Not even a month in I failed at that and February got no love from me. To top it off, one of my 7 readers actually called me out on it in IRC (I hangout in #blackterminal on Freenode).

The whole point of this blog is to give a little something back to the community. Since I gave nothing in February, I literally JUST donated $100 USD to the Electronic Frontier Foundation (EFF).


At the bottom of this is the proof. As further proof of my donation and to continue giving back directly to my seven reader, I opted for the hat gift from the EFF as seen below. I will be doing a drawing for the hat and mailing it to a winner at the end of March. 

To enter the drawing, simple leave a comment in THIS post. I will hand write your handle and toss it into a big furry hat and have my son pull a name. I will do the drawing on a live Google hangout on April 4th (exact time will be adjusted here and tweeted). This is open to anyone and I will ship internationally for FREE. I may even toss in some random things from my office too like stickers and such.

If you feel inclined to donate to the EFF visit them here:

I promise the March blog post is in the works now and as a sneak peak its about the new TV show CSI: Cyber. Make sure to comment below to enter.

Monday, January 12, 2015

Happy New Year and a CTF Challenge Write-Up

Happy New Year!!!

I'd like to start the first blog post of 2015 by wishing the 7 people who read this blog a Happy New Year! As a new year's resolution, I am challenging myself to write at LEAST one (1) blog post per month. We'll see how well it goes. Without further ado, here is January's.

In December, two people (@akiym and @xrekkusu) put together an Advent Calendar Capture The Flag competition (ADCTF). This was an awesome and unique CTF where every day in December, a small challenge was released. I was able to complete a couple of these challenges, but wanted to take some time to do a write up on my favorite one.

Before we get into it, a quick disclaimer: I will be posting a solution. According to the rules of the CTF this is not allowed. Therefore, I waited awhile (over two weeks after the challenge ended) to post this solution. I don't agree with the rule of NEVER releasing a write up. Therefore, as someone who personally identifies as a pirate, I scoff at rules. ARRRGGGGGHHHHHH. 

A lot of people, including myself learn the most from the trying and failing process, but eventually we all need a hand. So in the spirit of that, I will try and keep the write up linear in the sense that, if you need a hint, just keep reading until you get to the part where you are stuck, get a hint or two and then stop reading and continue trying. 

If it wasn't clear enough .... 




Okay, fair warnings aside let's get into the challenge. This was the Day 9 PPC Challenge dubed "qrgarden".

Apart from the lacking hint of "read a lot" there is a png file:

It is hard to see, since it is compressed down, but what you are looking at is 10,000 QR codes. 100 x 100. I know it is 10k QR codes for two reasons:

    1) I measured the size of 1 QR code in a graphics program
    2) I saw this tweet:

So based on the clues, the challenge consists of reading every, single, last, QR code and finding the one that starts with "ADCTF_"

If for some reason, you can get the png file from the CTF website, I've mirrored it on my GitHub here:

So, how do we read 10k QR codes? The way I thought of doing it was pretty simple. I will leverage Python, the Python Imaging Library (PIL) to slice the image into individual QR codes and then use the python qrtools library to read each one. 

Step 1: Slice and Dice

In order to read each QR code, we need to slice and dice this big png into individual QR codes. The first thing I did was to determine how big each code was.

While in my Kali Linux VM, I used the file program on the image and got 8700 x 8700 pixels as the size in pixels which means each QR code is 87x87 pixels.

The process I took was to slice the large png HORIZONTALLY into 100 new images each being 1 qr code high by 100 qr codes wide. Then for each of the horizontal strips, to dice each of those new 100 images VERTICALLY into single QR codes.

I wrote the below function called slice_and_dice() to do just that. I assume you could use this any time you needed to slice and dice something into squares. This tool will save each single qr code to a directory of your choice.

I have also posted this in GitHub:

1:  from PIL import Image  
2:  import math  
3:  import os  
5:  def slice_and_dice(img_path, output_dir, horizontal_size, vertical_size):  
6:   #set statistics  
7:   total_h_slices = 0  
8:   total_v_slices = 0  
9:   total_s_slices = 0  
11:   filename = os.path.split(img_path)[1]  
12:   img =   
14:   #get image size, and the starting points  
15:   h_width, h_height = img.size   
16:   h_upper = 0   
17:   h_left = 0  
19:   # get how many horiztonal slices to make  
20:   h_slices = int(math.ceil(h_height/horizontal_size))   
22:   #make the horizonal slice  
23:   for row_count in range(1,h_slices+1):  
24:    h_lower = int(row_count * horizontal_size)   
25:    h_bounding = (h_left, h_upper, h_width, h_lower)  
26:    horizontal_slice = img.crop(h_bounding)  
27:    # increment the upper boundry     
28:    h_upper += horizontal_size   
29:    print "Made horizontal slice #"+str(row_count)  
30:    total_h_slices += 1  
32:    # slice the horizontal slice vertically into singles  
33:    v_width, v_height = horizontal_slice.size  
34:    v_upper = 0  
35:    v_left = 0  
36:    v_lower = v_height  
37:    v_slices = int(math.ceil(v_width/vertical_size))  
39:    for column_count in range(1, v_slices+1):  
40:     v_width = int(column_count * vertical_size)     
41:     v_bounding = (v_left, v_upper, v_width, v_lower)  
42:     single_slice = horizontal_slice.crop(v_bounding)  
43:     v_left += vertical_size  
44:     print "Made vertical slice #" + str(column_count)  
45:     total_v_slices += 1  
47:     #save the single slice  
48:, filename +"_row" + str(row_count) +"_column" + str(column_count)+".png"))  
49:     print "Saved slice: " + filename +"_row" + str(row_count) +"_column" + str(column_count)+".png"+ str(column_count)  
50:     total_s_slices += 1  
52:   #print the stats  
53:   print "Total Horizontal Slices Made:", str(total_h_slices)  
54:   print "Total Vertical Slices Made:", str(total_v_slices)  
55:   print "Total Slices Saved:", str(total_s_slices)  
57:  slice_and_dice("qrgarden.png", 'output/', 87, 87)  

So this worked out very well and provided me with 10,000 individual QR codes ...

Step 2: Read all the QR codes

Suddenly, reading all the QR codes doesn't seem so daunting. To make life easier I used a python library called qrtools. The script I wrote will take a directory and a search term and decode all the QR codes in that directory while searching for the search term provided. This code is also on my GitHub at:

1:  import os  
2:  import qrtools  
4:  def read_qr_codes(directory, search_term, verbose=True):  
5:    # initalize a list for holding our hits  
6:    matches = []  
8:    # for each qr image in the directory ....  
9:    for f in os.listdir(directory):  
10:      img_path = os.path.join(directory, f)  
11:      code = qrtools.QR(filename=img_path)  
12:      # check if we can decode the image  
13:      if code.decode():  
14:        # convert the code to a string  
15:        code_value = code.data_to_string()  
16:        # if verbose is toggled, output the qr code values  
17:        if verbose: print img_path + ", " + code_value  
19:        #if we find the search term add it to the matches list  
20:        if search_term in code_value:  
21:          matches.append({img_path: str(code_value)})  
22:      else:  
23:        print "Could not decode:", img_path  
25:    #print all the matches  
26:    print len(matches), "match(es) were found:"  
27:    for finding in matches:  
28:      for key in finding:  
29:        print key + ', ' + finding[key]  
31:  read_qr_codes('/root/Desktop/day9/output','ADCTF_', False)  

After running this, I had my flag and this challenge was completed:

Step 3: PROFIT!

I blurred the answer out so at a minimum you at LEAST had to copy and paste the code to complete the challenge.

I hope you enjoyed this small write up and code. Please leave a comment if you found this helpful or were able to use it to solve a different CTF or challenge!