Analyzing Windows EVTX Logs
This is a sneak peak of Audit Explorer analyzing Windows EVTX logs (Windows' audit trail). For this preview we focus on the attacks that traditional network IDS/firewalls and AntiVirus software have troubles with — use of multiple layers of encryption on the network, moving laterally within an organization, and the use of standard (non-malware) tools.
Audit Explorer was originally designed to analyze Mac OS X's BSM audit trail; now we have added Windows EVTX logs to the files it can analyze. Audit Explorer lets you explorer the valuable information locked up in your audit trail.
We got the initial version of the Windows analysis code integrated this weekend. It is still rough around the edges, and we will be doing lots of polishing over the next few weeks. We hope this preview will get people thinking about turning on the auditing in their Windows systems. A good audit trail is one of your most powerful tools for protecting your network.
1 The Scenario
To generate the data used in the screenshots below, we carried out the following attack on our systems. (1) On another system (not shown), an attacker initially penetrates the organization (e.g., with a PDF exploit for Acrobat Reader). (2) The attacker then moves laterally in the organization into the machine we are auditing. The attacker used PsExec to start a command prompt (cmd) on the new machine. (3) On this new machine, the attacker performs a secure copy command to pull down some tools from another server to help carry out his attack. In particular, he pulls down the rar archiver and sdelete secure delete tool. (4) Upon finding some documents of interest in the PACOM directory, the attacker bundles the directory up in stuff2.rar, which is also encrypted. (5) Next the attacker exfiltrates these documents by running the secure copy command to transfer the stuff2.rar file to a remote server. Note that the there are two levels of encryption — the connection is encrypted and the file carried over the network is encrypted. (6) Finally the attacker uses sdelete to remove evidence of the attack.
2 Find the Thread
The general way we use Audit Explorer is by finding an interesting thread and following the thread. "Finding the thread" can be thought of as "detection", but that word is loaded with lots of meaning and expectation so we prefer to avoid it when possible. "Following the thread" can be thought of as a form of forensics. The first two screenshots show how you might find a thread to follow.
2.1 Cyber Espionage Indicator
Much of computer security is focused on looking for attacks — certain types of connections, certain data in connections, or AntiVirus software looking for signatures in executables. Since much of cyber espionage is about going after your documents, we just wrote a filter rule that basically says, "these are the programs that should access your Microsoft Word documents and no other." The types of programs that should access it include Word itself, Microsoft's search indexer, backup software, and so on. Any other program accessing your Word documents is flagged. Essentially we have white listed the programs that can access particular document types.
Figure 1 shows that two filter rules were triggered for suspicious access to Word and PowerPoint documents. We've selected the first filter rule, and the second list shows the actual program that triggered the alert. It is an instance of the RAR archiver running from an unusual location. We double clicked on that incident to bring up the "Process Details" window on the right.
At the bottom of the Process Details window we see numerous standard files the program accessed, but the interesting items are the last three lines. RAR read the files Fleet1.docx and Ships.pptx in the PACOM directory and bundled them up the in the file called stuff2.rar.
Is this an attack? Maybe or maybe not, but it is a good place to start investigating. You have found a thread.
2.2 Being Cued
Today no sensor stands alone. In this second scenario we assume that a network monitor detected suspicious connections to a remote server. Unfortunately, those connections were encrypted, so the the network monitor's ability to analyze the activity is limited. So we use this suspicious network activity to start exploring what the audit trail has to say about it.
Figure 2 shows that in the Network tab we entered the suspicious server's IP address and get a list of connections to that server. We also see the program that initiated each connection; in this case each connection was started by PuTTY's secure copy program.
By double clicking on one of the connections we again bring up details about the connection. In particular, in the "File accesses" section we see that it wrote to the file sdelete.exe in the Documents directory. So now we know the person (attacker?) downloaded the sdelete program and installed it in an usual location.
Again, this is not a smoking gun, but it is a great thread to start following.
3 Following a Thread
Now that you have found an interesting thread, you can follow it in several ways. Below we focus on the process tree.
3.1 Process Tree
An important way to follow a thread is to find out how a process fits into the bigger picture of activity on your computer. Figure 3 shows part of the process tree leading to one of the PuTTY Secure Copy connections identified by the network monitor.
On the left we see some unknown process created an instance of PSEXESVC.EXE which created the command-line process cmd.exe (third column). This is what happened when the person (attacker?) on the initial machine ran the PsExec command to create a presence on this machine. He is moving laterally in the network from his initial beachhead. He now has a command prompt on this machine.
In the fourth column we see eight children processes created by the command prompt. These are essentially the commands the user carried out. By double clicking on each of those commands to view them in detail, we can largely reconstruct the attack. Again, in this case we see the second instance of PuTTY's secure copy downloading the RAR executable. Two commands later we see the user is running the RAR command.
In Figure 4 we have double clicked on the PuTTY Secure Copy instance following the RAR archiving command. Here we see the file stuff2.rar is being uploaded to the remote server (because RAR is reading the file). From Figure 1 we know exactly what went into this file, namely the files Fleet1.docx and Ships.pptx from the PACOM directory.
Again, this is an encrypted RAR file going across an encrypted SSH connection (secure copy uses SSH). The network monitor has no chance of understanding what is in it, but the audit trail can tell you (1) the files that were in it, (2) how the RAR file was created, and (3) that the user was not logged in at the console but had moved laterally across the network to this machine via PsExec.
4 What's Next
We literally just got the Windows analysis code integrated into Audit Explorer, so we have lots of polishing to do. We are hoping to ship in about two months (the end of May). If you have particular scenarios you would like to see analyzed in the audit trail, we would love to hear from you. Microsoft Windows has an excellent auditing system, and we want to know how far we can push it for detection and forensics.
If you want to see Audit Explorer analyzing Mac' BSM audit trail, check out the following video tutorials:
Doorknob Rattling 1.1 — This video shows someone trying to guess passwords on multiple services (doorknob rattling).
Planting Malware 1.1 — This video shows a user logging into Eve's account, planting a Trojan horse, and installing some other suspicious files.
Advanced Persistent Threat 1.1 — This video shows the analysis of an Advanced Persistent Threat (APT) running when Bob logs in.
If you have a question: contact us