Daily Blog #309 Sunday Funday 4/27/14 Winner!

Hello Reader,
   Another Sunday Challenge completed as we now only have 56 days left in the year of blogging. This week we have a returning champion with Andrew Case being the only soul brave enough to attempt the challenge. This is a good answer and for those of you doing response in the real world or in defense competitions I would suggest reading it.

The Challenge:

You have a Windows 2008 server that you are reviewing logs for and notice that an attacker is currently logged in. What would you do to:
A. Remotely interact with the system without exposing credentials to the attacker to steal
B. Determine the attackers actions
C. Determine where the attacker is coming from
D. Determine which processes may be providing some kind of persistence for the attacker

The Winning Answer:
Andrew Case

 A. Remotely interact with the system without exposing credentials to the attacker to steal

 I would create an account that only had access to the compromised system. This way even if the attacker steals the credentials he does not get any further access than he already has. This account would be disabled after the analysis phase.

To perform remote investigation of the machine, the previously created account would be used to remotely load a F-Response agent. This agent securely exposes RAM and disks of the running system as read-only iSCSI devices. These can then be mounted on the analysis machine across the network, and tools such as Volatility, Sleuthkit, etc. can be run against the iSCSI nodes.

This process, generally called sampling, has the great advantage of only having to process the part’ of memory and the disk needed by the tools. For example, in our initial tests of F-response and Volatility we discovered that plugins such as pslist and modules only need to transfer about 500KB of data from the RAM of the analyzed system back to the analyst’s workstation. Another nice use of F-response is that if full imaging is determined to be required after analysis, the i-SCSI nodes can be imaged using tools like dd.

B. Determine the attackers actions

To determine the attacker’s actions I would use Volatility to recover information such as running processes, active network connections, loaded kernel drivers, and so on. I would also use the cmdscan and consoles plugins as they recover both input and output of cmd.exe. These could potentially uncover every action performed by the attacker (and have in the past). I would also run the Windows malware analysis plugins, such as apihooks, malfind, and callbacks in order to see if the attacker has loaded malware. While memory was being analyzed, I would run a script that gathered select files from the remote hard drive including event logs, registry hives, prefetch files, and the scheduled tasks directory. These all hold a wealth of information about activity that occurred on the system including program execution, user account activity, and network share access. The registry also contains many places that are utilized by malware for persistence.

C. Determine where the attacker is coming from
When analyzing memory of a Server 2008 system, the netscan plugin can be used to list active network connections. This would reveal the IP address of the attacker.

D. Determine which processes may be providing some kind of persistence for the attacker

Since this question lists processes as a persistence mechanism I assume it is referring to code being injected into long running processes (explorer.exe, svchost.exe, etc.) and not something like the attacker installing a rouge FTP or VNC server or enabling Terminal Services when it is normally disabled. If this was what the question was referring to then this activity can be trivially detected by looking for processes that do not normally run on the system. This can be determined through baseline analysis or by looking for programs installed during the timeframe the attacker was active. Volatility’s svcscan plugin can be used to enumerate running services and check for ones related to RDP, VNC, etc.

To detect code injection as a persistence mechanism, the Volatility plugins malfind, apihooks, and ldrmodules can be used. malfind will find regions of code that were injected into processes, apihooks will find hooks that malware places to control running applications, and ldrmodules will find libraries that delete themselves from the list of the host process’s DLLs in order to avoid detection on a live system. Combined, these plugins find the three main code injection techniques --- shellcode injection, remote library injection, and reflective DLL loading.

Another indirect artifact that can often be used to find malware is by looking at the active network connections of a system and determining which process initiated each connection. The Window’s networking data structures maintain a reference to the process that started them and these can be used to trivially map a network connection to a process. This will immediately flag
suspicious behavior such as when explorer.exe is connected to a remote IP address somewhere in China.

Also Read: Daily Blog #308