Incident Response: Methodology and Case Study

We all encounter incidence in our day-to-day life. It can happen in very common places that we might be visiting regularly like road, home, forest etc. The greatest example is the 2017’s California wildfires. It was the biggest example of having an incident and not handled properly, which lead to disaster.

To handle these kinds of incident in our digital life, we follow certain principles, or you can say methodology. To understand the incident response closely I have segmented this topic in multiple posts i.e., in series. I would be discussing about incident response methodology and a case study related to web server attack. Later in this post we would be analysing apache logs. So, let’s get our mind dirty.

Note:- You can download the attachment (report of memory analysis) at the end of the post.

What do you think Incident Response (IR) is? In simple English description, incident means an event or occurrence and, response means, an answer or reply, or something in the nature of an answer or reply. If we consolidate the two then, it implies, an event or occurrence which is answered or replied. This is what we need to do in IR.

During the past decade, working of IR has improvised a lot. As we know, humans learn from their bloopers and seeing that they developed a methodology, that would help to reduce or eliminate the catastrophe that might happen. The methodology is described as below: –

1. Preparation/Prepareness
2. Detection
3. Containment
4. Eradication
5. Recovery
6. After-Math

Preparation

Well everything needs preparation, IR also needs certain preparation to deal with malicious objects and behaviour. For maintaining a standard preparedness, an organization must place adequate & reasonable, defence and controls. Organization should also create some procedure to deal with the incident, that may arise, in an effective manner. For example, the organization can have IDS, IPS, firewall, SOC (Security Operations Centre) etc. These controls would provide instant alerts and would help in shorter response time.

Detection

For removing a threat, we need to identify it first. We can identify threats through the alerts generated by IDS/IPS. We can also check for the following while we are detecting the threat: –

1. Search for the events like:
   • Event log was stopped
   • Windows file protection not active
   • The protected file system <file_name> was not restored to its original
   • Telnet service started successfully
2. Watch the logs of firewall for apprehension. If possible, don’t let the antivirus destroy your evidence.
3. If nothing suspicious is found, it doesn’t mean that you are safe. There can be other programs that might have been installed which doesn’t leave that much trace, like rootkit.
4. If you feel that the system is suspicious, take a bit-by-bit copy, image, of the system, take the entire memory dump (with tools like FTK, Encase, etc.) for further analysis (is discussed in much detail later).

Containment

For containment of any threat, the best option is to isolate the system. Isolation can be done by disconnecting it from the LAN and any other network. Or if permitted:

• Create a VLAN segregating it from others
• Apply a well-versed policy, which won’t let the threat escape
• Start analysing the threat while it is connecting to its Command & Control (C&C) centre

Note: – The latter is only valid if it is a botnet and the current system, doesn’t contain any sensitive files.

Eradication

Now it’s time to rebuild the lost data. In this stage, the lost data is tried to be recovered. All unwanted services should be disabled, and a thorough antivirus scan would help detecting and disinfecting the threats (if any). It’s advised to do the AV scan when the operating system is not booted i.e., boot time scan.

Recovery

In this stage, you may need to install the system from scratch and build it with a good standard configuration. Beware, in this stage, the user may get unconformable as his/her settings are lost and it may take them considerable time to get accustomed with the current setting.

After-Math

As we all know, we would only rectify our self if we look in the past mishap. To view the past, we must have these events documented. So, in this stage reporting of the entire event is done. The report must be written, with the following points in the mind: –

1. Initial alert
2. Initial detection
3. Events and timeline
4. Actions taken
5. Why was it appropriate to take this action?
6. Cost of the entire incident
7. Has the action led to any disciplinary hearing?

And it’s good if we also mention the mitigation steps that should be taken to improvise the whole procedure.

Conclusion

Incident Response methodology can help an organisation to avoid catastrophe and help fight the upcoming threats in an organised manner. It is also advised that, only the technically strong person must take the decisions in the event of an attack else it may lead to a disaster like the deep-water horizon.

I hope it’s now clear what are the precautions that needs to be taken while handling an incident. Well if the incident is handled, still we have not exactly been saved. We need to further analyse the memory dump that was captured during the IR event. Further on we would be learning about memory analysis. We would now be going to the technical aspects of forensics. I hope you love it!!!!

Memory Forensics

Gone are the days of hard disk analysis, because of the importance of the time. For analysing the hard disk, we need much time, much greater than what memory analysis would take. The other benefit of memory forensics is that, if the code is encoded/encrypted/obfuscated, we can find it decoded/decrypted/de-obfuscated in the memory. Because to run in the system, it needs to be understood by the system and system doesn’t understand any of those (encoded/encrypted/obfuscated). So, for learning about how to analysis the memory, we need to have some prerequisites: –

• Knowledge of operating system processes (Windows in this case)
• Knowledge of operating system files
• Knowledge of browsers
• Knowledge of networking
• Knowledge of Hibernation file
• Knowledge of page file
• Think like an investigator
• Have patience

In this section we would be using the Volatility framework to analysis this memory dump, which was shared by Tek Defense for educational purpose.

Volatility framework is an open-source tool, which is very useful for memory dump analysis. Github best defines it as:

The Volatility Framework is a completely open collection of tools, implemented in Python under the GNU General Public License, for the extraction of digital artifacts from volatile memory (RAM) samples. The extraction techniques are performed completely independent of the system being investigated but offer visibility into the runtime state of the system.

It is very true that RAM tells you a lot more than your HDD. It is a boon if you know about memory forensics. So now, let’s dive into the ocean of memory forensics.

Note: – In this explanation of memory forensics, I would be using Kali Linux, because it is open-source and has the required tools (like volatility, strings, etc.) for the current practice.

I hope you all have downloaded the memdump (memory dump) from the link provided to you and you have Kali Linux installed in your Virtual Machine software (for me it’s Oracle VirtualBox). Provide at least 2 GB of RAM and 2 processors to the Kali VM. Make sure you have a shared folder (which is shared with the host machine), which would help you to copy the memdump in your virtual machine. Now let’s get our hands dirty.

If you execute the following command, you will get the help option of volatility. It would tell you what you can instruct this tool to do for you.

volatility -h

Now we know what the options/plugins in volatility are. We need to use the relevant plugins for getting our results.

For the information regarding the file, which we are going to analyse, we would need to run the imageinfo plugin. Before that you may need to unzip the Darkcomet.zip file and run the following command on the WIN-TTUMF6EI3O3-20140203-123134.raw file :-

volatility -f WIN-TTUMF6EI3O3-20140203-123134.raw imageinfo

From the result we know that, it’s a Windows 7 Service Pack 1 32-bit system (exact profile is Win7SP1x86_23418).

Note: – You may find all the output of the commands (as a zip) at the bottom the post.

Now using this profile, we would like to know the processes that were running at that time. So, for checking that, we would be using the pslist command.

volatility -f WIN-TTUMF6EI3O3-20140203-123134.raw --profile=Win7SP1x86_23418 pslist

That’s a weird process runddl32.exe

Let’s check the psxview what it says

volatility -f WIN-TTUMF6EI3O3-20140203-123134.raw --profile=Win7SP1x86_23418 psxview

Not much help with psxview. Let’s get the DLLs related to the process 1524. Let’s check what we get: –

volatility -f WIN-TTUMF6EI3O3-20140203-123134.raw --profile=Win7SP1x86_23418 dlllist -p 1524

Oh!! we found something, something good, something that we can bit on. The file runddl32.exe has a different path which is in temp.

That’s not good, because a windows system file never runs from a temp location. It must start from System32 folder which is under C:\Windows\ path.

Let’s extract the file and do a further analyse.

When we start dumping the files, we see that MSDCSD is common directory that is created by the malware. If we do a google search, we would find that it’s common for darkcomet to create that directory, it’s the signature of it.

When I tried to move the dumped files, of process 1524, to my windows 10 machine it gave me the following message.

Windows Defender caught a backdoor named “Fynloski.A”, in one of the dump files. That’s good for Windows 10 users, by the way. At least safer than Windows 7 or 8 users.

In the next post we would dive much deeper into the analysis phase like try to simulate the code execution and find out it’s network connections. The draw back in volatility was that we couldn’t check the connections made by the system. In my next post I would try to simulate the entire process with faknet and then do my further investigation on the malicious code. If possible, we would extract the code itself and do a API checks and all.

The main advantage in this would be that, we could see what the chain of events are, when the darkcomet is executed in a windows machine.

Conclusion

So, we can conclude, till now, that this system was infected with Darkcomet and the analysis goes as follows: –

• A suspicious process, named “runddl32.exe” was found
• When we checked for the path, it wasn’t in the System32 folder. It was getting executed from the temp folder (MSDCSD, created by the malware).
• There were other processes like cmd.exe and notepad.exe accompanying the runddl32.exe (we would analyse the chain of events also)
• We also found that, it was calling many Windows APIs (which we would analyse in the next post)
• Windows defender says it as a backdoor named “Fynloski.A”

Download the reports here.

Note: Download file may contain malicious code. Open at your own risk.