Video Screencast Help
Cyber Security Group
Showing posts in English
Jamie Porter | 11 Sep 2014 | 6 comments

The examination of prefetch files is commonly done during live response.  They are easy to grab, quick to analyze and can provide useful information when investigating malicious activity.

Here is what information we can glean from the prefetch:

  • When a malicious file was executed

  • Where it was launched from

  • How many times it has been run

  • What DLLs were used by the malicious code

  • Name and location of the malicious file (even if deleted)

  • Timeline of attack activity

  • General suspicious activity

Let’s start with an overview of prefetch.

Prefetching was first seen in Windows XP and is used to speed up the operating system and application startup.  Here is how Microsoft defines it: “Each time you turn on your computer, Windows keeps track of the way your computer starts and which programs you commonly open. Windows saves this...

Clint M. Sand | 05 Aug 2014 | 1 comment

         program.jpg

The term incident response means a lot of things to a lot of people. Historically, words like “unpleasant” or “chaotic” come to mind when thinking about the last time many organizations responded to the suspicion of a compromise by external attackers. Today, for most organizations incident response is a part of their security program but is still primarily a reactive premise centered on a plan or policy document that describes how they should handle such an event.

How do you ensure your incident response plan is optimized to handle the demands of an escalating threat landscape? Is a plan enough?

I recently spent some time talking with the Incident Response experts on my team, our partners, and about 80 customers in CISO roundtable events over the past few months. A clear answer surfaced.

An incident response plan is...

Matt Sherman | 04 Aug 2014 | 4 comments

layer8.png

I have a calendar alert goes off at 9:30 AM to “Reach out to Layer 8”, which is a little project I devised for myself. When the reminder fires, I open a file called “Friends.txt” that contains several people’s names, departments and phone numbers. I select a name from list and give them a call. This is usually a quick chat. I try to keep the conversation below 15 minutes, and we generally discuss overlap in our roles or projects that we have in common or new projects that the other might not have visibility in to. I end the call by saying something to the effect of “If you see anything weird, let me know”.  This is how I know the status of my Layer 8 sensor array.

I am willing to say that you have these types of contacts in most of the departments in your organization and that you have worked security events with these contacts in the past. I would also say 15 min’s of chat...

Vince Kornacki | 04 Aug 2014 | 0 comments

apache2.png

In the previous installment we examined default Apache logging. Now let's pump up the default Apache combined log format in order to supercharge forensic capability! We'll utilize the "LogFormat" directive in order to define the "enhanced" log format within the /etc/apache2/apache2.conf configuration file:

LogFormat "%{[%a %D @ %I:%M:%S.}t%{msec_frac}t %{%p %Z]}t [%h (%{X-Forwarded-For}i) > %v:%p] [%H %m \"%U\" \"%q\" %I > %>s %D %O %k %L] \"%{Referer}i\" \"%{User-Agent}i\" %{USER}C %{JSESSIONID}C" enhanced

A sample Apache enhanced log format entry looks a little something like this:

[Wed 07/30/14 @ 10:45:59.420 PM CDT] [10.1.1.101 (-) > 192.168.1.1:80] [HTTP/1.1 GET "/example.html" "?foo=bar" 666 > 200 295 999 0 -] "http://192.168.1.1/from.html" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0" jdoe 09162009...
Jamie Porter | 04 Aug 2014 | 6 comments

liveresponse.png

The term live response is being heard more and more frequently but what exactly is it and how does it differ from traditional forensics.

Live response and traditional forensics have a lot in common in that they both are looking for similar artifacts on a system. The differentiator with live response is that the artifacts are being discovered on a live running system against an active adversary. With traditional forensics, images are taken of volatile memory and disks before being analyzed.  Imaging alone can take hours and then the images need to be processed and indexed to allow for keyword searches. Obtaining and processing the image can easily take a day or longer with large capacity discs. With live response there is no imaging or processing that has to occur.  . , everything is real time. This dramatically improves the response time in identifying and...

Trent Healy | 04 Aug 2014 | 7 comments

yara.png

Yara is a tool that Symantec uses on incident response engagements in order to help us respond quickly and triage hosts while our security team is prepping signature updates for our affected clients. Yara is very popular tool among security researchers as it is a flexible tool for classifying and discovering malware through hunting and gathering techniques.

In a live response situation the malware we find is usually only running in memory, with little to no disk artifacts. Yara is perfect for deploying across an enterprise and scanning processes running in memory or files residing on disk. As an incident responder time is of the essence, customers are worried about losing intellectual property, the security team and or the IT team of the customer is walking on eggshells, and the need to find evil fast is of the utmost importance.

The idea is to create a yara rule based on...

Robert Shaker | 04 Aug 2014 | 0 comments

incidentnightmare.jpg

When the kids at the schools where I speak ask me what I do for a living I don't tell them I postulate about quantifying the loss of opportunities when we delay a response to an incident or malicious cyber-attack. I tell them I help the world fight cyber attackers. Just happens that this work gets me thinking about how to make us better at battling back. That's where this blog series started with a really bad couple of weeks of Friday afternoon calls from customers who had run out of options and now needed someone else to come in a help them.

In my last two posts in the series I postulated that there was a quantifiable loss of opportunities when we delay a fast reaction to an incident caused by a malicious attacker. I even came up with an equation for it: TID – TCA = ∆T = LO, Time of Incident Detected – Time to Call for Assistance = Delta Time = Lost...

Bob Burls | 04 Aug 2014 | 0 comments

bug.png

Welcome to the first of a series of blog posts on Malware Evolution. Through the series we’ll be covering modern malware types including bots, denial of service attacks, Ransomware and banking Trojans. We will look at the tactics and trends that have utilised new techniques. In addition, we’ll examine the reuse of existing methodology in new ways, which attempt to thwart detection and increase malicious efficiency. The series will highlight why it is essential for us as Incident Responders to be prepared for what our adversaries are operating with.

As everyone knows, it is essential to defend against and respond readily to the inevitable network attack.  Part of our structured defence regime must be to understand the nature of a threat, its delivery mechanisms and its operational and evasion techniques.

The evolution of malware species has taken a drastically alternative...

Vince Kornacki | 04 Aug 2014 | 0 comments

apache1.png

Like an unsightly beer belly, default Apache logging functionality leaves a little something to be desired, especially with regard to forensic capability. So let's pump up the default Apache logging functionality and carve out a forensic six pack! For this blog post we'll be working with Apache 2.4 running on Debian Linux:

root@debian $ apache2 -v
Server version: Apache/2.4.9 (Debian)
Server built:   Jun  8 2014 10:01:34

The default Apache HTTP log format is defined within the /etc/apache2/sites-available/000-default.conf configuration file (which is symbolically linked from /etc/apache2/sites-enabled/000-default.conf), and the default Apache SSL log format is defined within the /etc/apache2/sites-available/default-ssl.conf configuration file (which is symbolically...

Robert Shaker | 04 Aug 2014 | 0 comments

clock_static.png

In my last post in this series I introduced Time of Incident Detected (TID) – Time to Call for Assistance (TCA) = Delta Time (DT) = Lost Opportunity (LO) and defined what TID and TCA meant in this equation. In today’s post I’d like to explain Delta Time (DT).

Delta time is highly critical is determining success against an adversary. But what is the right amount of delta time? How much time can pass before the loss of opportunity to too great? As I defined, TID is when you determine that a response is needed. That doesn’t mean the same as when you know you need an incident response team; that was TCA. I didn’t feel as though this was something that I solely could opine on. I needed experts in Incident Response that could share with me their point of view on how long DT could be and how that equates to LO. Considering that it takes roughly 24 hours for an external...