Tips for an Information Security Analyst/Pentester career - Episode 62: Forensic Challenge (pt 2)

This post resumes from my previous one Tips for an Information Security Analyst/Pentester career - Ep. 57: Forensic challenge (pt. 1), where I analyzed interesting artifacts and event IDs from Event Viewer with reference to a clean system configuration.

This time, I'll analyze a hacked Windows 7 Professional system and I'll show you what those artifacts and event IDs look like in that specific context.

Also, I'll show you how to use a PowerShell script to save the most relevant event IDs to a csv file, that you can then filter by using Excel or parse through PowerShell or other programming languages.

With that being done, I'll show you how certain event IDs may be reflected in AlienVault Cloud Central alarms, even though the online demo looks quite different from the configuration I use at work.

My work configuration reflects much more closely the same hex codes you find in Event Viewer.

For this reason, after showing some examples in the online demo, I'll display a real-world example taken from my job, of course duly redacted in order to protect corporate data.

Stage 1: System Exploitation

I used an msfvenom custom payload to hack a Windows 7 Professional VM configured for use with Georgia Weidman's pentesting class and attached a reverse meterpreter shell payload to it.

Then I moved the malicious file to the web root directory and started Apache, so it could be accessed from the victim machine through the web browser.

Before exploiting our victim VM, I enabled some specific auditing policies, in order to have an audit trail for our attack.

From Group Management Policies, I enabled Audit logon events (for failure only), Audit account management (success and failure), Audit privilege use (success and failure) and Audit system events (success and failure), in order to detect failed logons, user creation, privilege escalation and other critical events.

Then I launched my attack, and I could easily get in.

As a sidenote, I used port 666 to perform a devilish hack (LOL).

I used windows/local/bypass_uac exploit to achieve a privilege escalation.

I then migrated to a more stable process and killed the executable I used to hack in.

After dropping a Windows shell, I had a look at existing users through net user command and then added a new user, called blackhat, to the system (check the embedded video for more details).

We can have a look at the Administrators local group. Our new user doesn't belong to it but, as we're system administrators, we can do whatever we want and we can easily remedy to that.

Stage 2: How it looks like on the victim machine: forensics and detection.

a) A deep look at running processes

Let's have a look at all running processes through the netstat -abno command, which I redirected to a text file.

In the output file, I searched for all entries matching the IP address of our attacking Kali VM and I found several ones.

The executable I used to attack the system (videoplayer.exe) was still running in memory even though I had killed it (darn it!).

You can also notice some system processes for which our Kali machine is listening on port 666.

That's because I migrated to a system process, still listening on that port (devil calling??).

Let's first have a look at Event Viewer.

Our actions have generated a bunch of noise and a corresponding audit trail on the victim machine.

We could have used timestomp to mess with the MACE attributes and also cleared the logs.

We'll find, in fact, a corresponding event ID, because I had cleared the logs before starting the exploitation, in order to get rid of the entries generated over a previous exploitation attempt.

Each actions we performed over our exploitation stage have generated a corresponding event.

Let's now run wmic process list full, redirecting its output to a file.

We notice an interesting entry related to the same malicious executable.

b) A deep look at Event Viewer's critical event IDs

Let's now retrieve the most critical event IDs from Security and System log files under Event Viewer.

Those event IDs will help us audit and track the artifacts and tracks of our attack, such as those related to the creation of a new user, to changes to a user account, etc.

Looking at event IDs this way is very cumbersome, lengthy and impractical.

In fact, there's a much better way to do so.

You can use a PowerShell script, created by Eric Conrad and referred to by John Strand, to gather the most significant event IDs in an orderly way.

I perfected the script (just published on GitHub) by redirecting the output to a .csv file, so it can be neatly viewed through Excel.

 

After running the script, I obtained a very neat Excel spreadsheet, which can be filtered the way you want or parsed through several programming languages (PowerShell, Python, etc.). 

You can notice below some critical events, all caused by our previous exploitation:

• 4674: privilege escalation
• 4732: member added to a security-enabled local group
• 4720: new user account created
• 4738: user account changed
• 1102: audit log cleared

Stage 3: What it looks like in AlienVault

Let's now mean business and talk about an analyst's main work tool.

I'm not a sysadmin for a company, I'm an analyst monitoring their server and network logs on their behalf.

Therefore, I don't have the luxury of being able to use the above script, I need to rely on my SIEM logs, in my case AlienVault.

Let's have a look at some examples taken from the online demo. 

I'll then show you a duly redacted example taken from my daily job.

I noticed my real-world platform reflects very closely the same logs you find in Event Viewer, with the same hex codes you find in the raw log.

This below is an example taken from Cloud Central online demo.

Here you'll notice how the example is referred to Office365 users.

I don't see that kind of situation in my daily job.

Below is a redacted work example. You'll notice how the structure closely reflects Event Viewer entries for the same ID.

You'll notice the log contains a series of hex codes, apparently meaningless at first sight.

Those codes are very important, instead, and help an analyst understand in detail what happened.

I search through those codes every day by using several references.

Check external resources below for some links.

I mostly deal with event ID 4625. I recently happened to spot a 4674 event ID, which was really something.

Another thing I keep an eye on is the Security ID.

I get concerned when I notice S-1-5-18 (i.e. a system administrator account) is involved (that's why I highlighted it in my report to the client).

I pay attention more to these details than to the priority per se.

An event can be low priority but be more important than a high priority one clearly being a false positive.

Wrap up

Detecting an attack is not always easy.

Often times you really need to dig into the rabbit hole and that's the real analyst's job.

It takes patience, dedication, will to learn, love for coding and automation and drive to keep up with the latest threats and detection rules updates.

People fill their mouths with AI and machine learning and they can surely help but so far no one can replace human analysis capabilities and intuition, that sorta sixth sense guiding you when things start getting confused and blurry and you're unsure about what you're really looking at but your internal nose somehow smells a rat.

I often find out my guts are right, but experience is paramount, too, for you to make the right decisions.

I need to grow a lot and fast, and I'm working hard to do it as soon as possible.

Thank you for your time.

External resources:  

Analyst's reference