Well it happened.

You are working as a full time Incident Responder or it might be that you are working as a consultant and use your knowledge and expertise only whenever security incident hits your organization. Never mind the details, incident is declared! Someone is inside your network, it all started with information about strange behavior - suspicious logon attempts from different admin accounts to your highly secured part of a network. One of the servers used for unsuccessful logon attempts contained suspicious executable which after short initial analysis seems to be well known password dumping tool. Insider? APT? Management is highly interested, pressure is growing. Someone may think: ‘Yep just another day of an Incident Handler’

In a perfect world, you would be working for an organization that has all the tools and processes in place. You grab your jump bag, take your corporate credit card and go directly on site to investigate. No? So your company only does it remotely? Fair enough. No time to be wasted - you need to verify information and start to analyze artifacts in order to recreate what happened. You are able to remotely collect valuable data from the endpoints, perform initial assessment, review monitoring platforms, sweep estate for initial indicators, perform basic memory and file system forensics, analyze netflows, logs and finally build timelines. At the end of the day, when you have more knowledge about what happened, you can update management and plan your next steps.

Say Whaaaat? You don’t have any tools because there was no budget? You do not have a full coverage of the environment with your monitoring platforms? Management decided to use endpoint security only for the most protected part of the infrastructure and you do not have access and visibility? Your organization decided to offshore infrastructure to managed services provider and you need to collaborate with technical teams from different organization?

Pick your reason. If it makes you feel better even add your own. We live in a Murphy’s Universe. You will probably never have everything you need and yes, you can blame management and complain or you can have fun and investigate potential incident and do some cool stuff. You just need to build alternative toolset and processes as a plan B (or build it as your primary toolset if you are really screwed up and your organization finance your Incident Response capabilities with ‘Great Job!’ approach.)

IR activities can be divided into following steps:

Analysis:

• collect data (locally or remotely, manually or automatically)
• analyze data
• build timelines and recreate what happened

Scoping:

• create indicators of compromise (IOC) based on TTP (tools, tactics, procedures)
• deploy IOC (create rules across monitoring platforms, sweep estate)
• monitor estate for new suspicious activity

Keep in mind that it is highly likely that you might not be the person that will execute the tools, and you will need to rely on someone (administrators, local support, janitor?) to perform one of the most crucial part of every investigation - collection of evidence - for you. Thus it would be really good to have this process automated and easy to use.

Standard disclaimer. Before we start playing with Redline it’s definitely a good idea to first test it in a safe environment! Feel free to check official documentation to be sure that you know what you are doing. This series will leverage capabilities of Redline in some example scenario and build a basic process around it. Keep in mind that if you have any other ideas, doubts or experience please feel free to share it so we could all learn from it!

Redline allows analyst to build endpoint collectors. In our scenario we will use Comprehensive and IOC Collectors. Official manual states that:

• “Comprehensive Collector configures scripts to gather most of the data that Redline collects and analyzes. Use this type of Redline Collector if you intend to do a full analysis or if you have only one opportunity to collect data from a computer.”

• “IOC Search Collector. The IOC Search Collector collects data that matches selected Indicators of Compromise (IOCs). Use this Redline Collector type when you are looking only for IOC hits and not any other potential compromises. By default, it filters out any data that does not match an IOC, but you can opt to collect additional data.”

Creating a Comprehensive Collector

Select the type of collector:

Click on Edit your script to review what data will be collected. Tick a box if you want to acquire memory. General recommendation - acquire memory whenever it is possible (legal, bandwidth, HR approvals etc.). Memory forensics is an invaluable source of information and essential part of every investigation.

At the bottom of the window select the name of the folder where collector will be stored and then press OK.

Creating an IOC Collector

Select IOC Search Collector:

Select a folder containing indicators of compromise (see how to create IOC):

Redline will parse content of the folder and display names of all IOCs:

Select IOCs that should be included in the collector and than follow the same steps for creating a Comprehensive Collector. With know-how about building collectors, scenario in place and basic process, incident handlers are ready to collect data and investigate suspicious activity. In part 2 we will start the analysis with Redline.

If you are wondering at this point why not just pull a plug, or separate suspected machine from a network, create a forensic image and perform full blown forensics? Bear with me until the end of the series. However if you are really impatient, using collectors allows you to act faster and start investigation and basic containment while your forensic images are still uploading or waiting for segregation in Fedex storage room. Oh, by the way it is far more easier to get approval for ‘acquiring metadata’ rather than full image straight away, especially when user traffic and data is involved.