Monday 12 November 2018

Redline Analysis : Part2

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’.

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.

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. 

Scenario

Network X is an isolated, highly secured and monitored part of the network where Nation’s Secrets are stored. Team responsible for monitoring the infrastructure reports suspicious activity on one of the servers WIN-UC6FN0KAUGQ (10.10.100.100) including failed authentication attempts, originating from a host within the same geographic location as network X. The suspected machine’s is WIN-569IC7NK834 (10.10.100.50). IR team was called to investigate. Reported time of the suspicious activity: 2015-01-28T19:30:24Z.

Data Collection and Analysis

Every investigation is all about getting as much context as possible. This gives handlers better understanding of what happened and in turn it influences decision what to do next. At this point the only available information are few suspicious authentication attempts. Data collected by Redline’s Comprehensive Collector would be the best option to start our initial investigation.

Collection steps include

1. Incident Handler creates and sends collector to Administrator responsible for
     executing it on suspicious machine.
2. Administrator logs to box with temporary created account, and executes collector.
3. Archived results are sent to Incident Handler in a secure, predefined way (e.g. SFTP server).
4. Incident Handler downloads the file and start the analysis in a preconfigured Virtual Machine.

Analysis

Where do we start? Each investigation is different and each handler has its own style. For most of the investigation one of the following strategies should yield satisfactory results:

* Timeline analysis (based on the time of suspicious activity)
* Data analysis (based on information about suspicious activity)

Timeline analysis

This one is fairly simple the only requirement is to have approximate time of suspicious activity.

1. Build a timeline based on all collected data.
2. Set up a timeframe e.g. 30 minutes.
3. Review events that occurred within defined timeframe before and after the suspicious activity.
4. Look for anything that is out of ordinary.
5. Follow up on all suspicious events with additional investigation.
6. If nothing suspicious was found start again at step 2 and extend the timeframe.

Let’s test this approach in on our scenario.

Collected data can be loaded in Redline by double clicking the .mans file and selecting the type of investigation:
                                                     

On the Analysis data panel select Timeline:



Redline will build the timeline based on all collected events. Next step is to define a TimeWrinkle which is a basic filter that will show only entries within defined time frame.


One of the Windows Event Log entries close to the time of suspicious activity correlates with the usage of explicit logon credentials by user PMac against the target machine.


Let’s see what happened before user PMac tried to authenticate.



Processes cmd.exe and conhost.exe were spawned by the user PMac two minutes before the explicit logon event. It might be worth checking memory ranges for conhost.exe as this process usually 
holds history of user’s activity in a Windows command line (this is true for Windows 7/2008R2 or higher, for earlier versions you should focus on csrss.exe memory ranges). 
Dumping memory for given process with Redline can be easily achieved. Double clicking on conhost.exe displays the process information page. Select MRI Report and hit 
Acquire Process Address Space (assuming collector acquired memory). All memory ranges for given process will be extracted in the background. Let’s not waste time and continue with the timeline analysis.


There was nothing interesting in the timeline until we stumbled across the following entry: suspicious m64.exe file in a root directory.


Next step would be to get the file and perform initial analysis. Unfortunately Redline collects information about the metadata of the files within filesystem. 
File would have to be extracted manually, for instance by the same administrator that run the collector (sometimes it is possible to extract files from the memory image using e.g Volatility).

Now it is time to take a closer look at what happened in our timeline after the explicit logon attempt occurred.

Initial report mentioned few suspicious logon attempts. Using search feature we can look for other explicit credentials events:


Apparently user PMac tried to use Rob’s account


Mike’s account


and Bob’s account against the target server:


Interestingly enough the time differences between the logons were very short and suggest more of an enumeration activity.

Let’s get rid of the filter and examine closely all related entries for each explicit credentials event log entry. Nothing interesting for the first two logons, however entries surrounding third explicit logon give us more details. Registry changes suggest some sort of network activity, which might be related to accessing a network share on our protected target server by user Bob-ADC. This doesn’t look good at all!



Let’s summarize the findings of our analysis so far:

* The file m64.exe was present in the root directory on WIN-569IC7NK834 (10.10.100.50) 
    before suspicious logon started.
* Followed by authentication attempts using four different sets of credentials against 
    protected target server WIN-UC6FN0KAUGQ (10.10.100.100).
* Evidence suggesting mounting a remote network share (root directory) on the 
   protected server WIN-UC6FN0KAUGQ (10.10.100.100) was recorded in the 
   Windows registry on WIN-569IC7NK834 (10.10.100.50).

There is still plenty of stuff to investigate further. What about the conhost.exe memory ranges? Redline finished dumping the files to disk after few minutes so it’s time to review memory ranges with good old strings.exe from Sysinternals.

After endless scrolling through strange hex, numbers and letters eventually a needle in a haystack was found! Strings inside the conhost.exe process memory revealed commands executed on the host WIN-569IC7NK834 (10.10.100.50) by user PMac (everyone loves memory forensics!):


So what exactly happened here?

Someone tried to view the available network resources with the net view command and then failed to mount a remote share using different accounts (PMac, Rob-ADC, Mike-ADC). 
The last attempt using Bob-ADC credentials successfully mounted network share. After that the attacker copied suspicious file m64.exe to remote location. 
If the file was not suspicious enough when we’ve looked at it for the first time, now it would be really good to speed up our malware analysts to get as much information as possible regarding the file.

Creating an IOC

Building IOCs is based on the Boolean logic and keywords. For instance we can use Event Log ID 4648 to look for any existence of explicit credentials in Event log:


Let’s assume that malware analyst came back with the results: m64.exe is recompiled version of Mimikatz - a well known password dumping tool. For instance an IOC can be built based on the name for both 32 and 64 bit platforms, extension and MD5.


Hunting with IOCs

In real case scenario this would be a good time to gather all the findings from the initial investigation and sweep across estate for more machines that indicate similar suspicious activity. 
It would be a good starting point to extract all activity of compromised accounts from the Domain Controller and run IOC collectors on all machines where any of those accounts were recorded. 
It might be worth considering to add collection of all event logs and/or memory to your collector.

When analyzing the data collected by the IOC Collector open the analysis file and select:




The report will be generated in the background. When it is ready click the IOC Report on the bottom left side and review your IOC report.


You found more indicators of compromise on other machines? Cool now you can iterate through our process with the new findings. 
Repeat the same process over and over again in order to understand what exactly happened. Eventually this will allow you to get rid of the bad guys, sharpen your tools and be more 
prepared for another round!


































Friday 9 November 2018

RedLine Analysis : File Download / Execution

We’ll just re-image the box then” is the phrase I often used early in my IT career. That was standing operating procedure for a compromised machine. We would receive a SOC alert. We would go kick the user off the box and have it re-imaged.

It’s a free tool that allows me to do an investigation on potentially compromised boxes. With the tool, we started getting a better understanding of why compromises occurred. That information allowed us to make better decisions about defenses in place.

Download and install Redline. Download the user guide as well. The user guide is how I got started using the tool. It will explain the ins and the outs in much more depth.

Launch Redline and, click on the “Create a Comprehensive Collector” link. This will create the collection package. Check the box for “Acquire Memory Image.” A lot of malicious activities happen in memory. Collecting what’s in memory is vital.* Next, decide where the collection package will reside on the computer. Click OK to create the package.

*When responding to an incident, disconnect the computer from the network or contain it in a separate VLAN. Avoid rebooting or shutting down. A reboot or shutdown will wipe whatever is in memory.



Once the data is collected open the .mans file. Redline will now load the session. After the session opens, click on the option to investigate based on an external source. There are other options for starting an investigation. Refer to the user guide for explanations on these. A Timeline will appear with all events from registry changes, browsing history, event logs. A Timeline Configuration pane is available for refining the timeline. Computers create a ton of events, so it can take some time to load everything. Which is why it's a good idea to define a time period. Go to the Time Wrinkle tab and set a number of minutes before and after a certain time period. If the information available on the incident is vague, a wider time period may be needed. For more accurate time a smaller time period can be used.

For the most part, when I received a SOC alert the information I received was exact down to the second. I would use only two minutes before and after a specific time. When I didn’t have an exact time, I would go as high as 15 mins before and after. One thing to note is that the time on events is in GMT time. A conversion to GMT is needed to match the time from the incident to the computer (+4 or +5 hours).For the most part, when I received a SOC alert the information I received was exact down to the second. I would use only two minutes before and after a specific time. When I didn’t have an exact time, I would go as high as 15 mins before and after. One thing to note is that the time on events is in GMT time. A conversion to GMT is needed to match the time from the incident to the computer (+4 or +5 hours).


Now go through the timeline and look for anything associated with the incident. Use Google to research any suspicious events. Say several users had clicked a phishing email. A block box had popped up on their machine and then went away. We ran Redline on the machines and found that an .exe had been dropped in the Windows temp folder. In other instances I would see the anti-virus or EMET step in and block the attack. Look for anything suspicious. If unsure Google it.Now go through the timeline and look for anything associated with the incident. Use Google to research any suspicious events. One incident I responded to, several users had clicked a phishing email. A block box had popped up on their machine and then went away. We ran Redline on the machines and found that an .exe had been dropped in the Windows temp folder. In other instances I would see the anti-virus or EMET step in and block the attack. Look for anything suspicious. If unsure Google it.

Using the timeline function from Redline is very easy and powerful. It lines up any artifacts collected using several timestamps that are selectable.
















Conclusion :-

Mandiant's Redline software is free to download and use. I find it amazing how much details can be found by analyzing a host with Redline and how easy it is to create a timeline for analysis.

Redline can combine disk and memory artifacts in a timeline, showing processes created and ports opened in time relation to files and registry keys created.