Querier was an ‘medium’-rated machine on Hack the Box that required attackers to harvest files from unsecured SMB shells, and capture database credentials off the wire to get a toehold on the system, and then carefully enumerate the box to find admin credentials to finally pwn the system.
On the target network at 10.10.10.125, the system description noted that it was a Windows box, and from the name, it was likely that a database server was likely to play some role.
Initial Enumeration
Running nmap against the box, I find that there’s quite a few open ports, incuding SMB, MS-SQL, and some Windows remote management services (wsman and winrm):
root@kali:~/htb/querier# nmap -v -Pn -R 10.10.10.125 -p1-65000 -oG querier_nmap_all.txt Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-07 19:41 EDT Initiating Parallel DNS resolution of 1 host. at 19:41 Completed Parallel DNS resolution of 1 host. at 19:41, 0.00s elapsed Initiating SYN Stealth Scan at 19:41 Scanning 10.10.10.125 [65000 ports] Discovered open port 139/tcp on 10.10.10.125 Discovered open port 135/tcp on 10.10.10.125 Discovered open port 445/tcp on 10.10.10.125 Discovered open port 49669/tcp on 10.10.10.125 Discovered open port 49667/tcp on 10.10.10.125 Discovered open port 49664/tcp on 10.10.10.125 Discovered open port 49671/tcp on 10.10.10.125 Discovered open port 49665/tcp on 10.10.10.125 Discovered open port 49668/tcp on 10.10.10.125 Discovered open port 5985/tcp on 10.10.10.125 Discovered open port 47001/tcp on 10.10.10.125 Discovered open port 1433/tcp on 10.10.10.125 Discovered open port 49670/tcp on 10.10.10.125 Discovered open port 49666/tcp on 10.10.10.125 Completed SYN Stealth Scan at 19:42, 31.53s elapsed (65000 total ports) Nmap scan report for 10.10.10.125 Host is up (0.032s latency). Not shown: 64986 closed ports PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 1433/tcp open ms-sql-s 5985/tcp open wsman 47001/tcp open winrm 49664/tcp open unknown 49665/tcp open unknown 49666/tcp open unknown 49667/tcp open unknown 49668/tcp open unknown 49669/tcp open unknown 49670/tcp open unknown 49671/tcp open unknown 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds? 1433/tcp open ms-sql-s Microsoft SQL Server 14.00.1000.00 | ms-sql-ntlm-info: | Target_Name: HTB | NetBIOS_Domain_Name: HTB | NetBIOS_Computer_Name: QUERIER | DNS_Domain_Name: HTB.LOCAL | DNS_Computer_Name: QUERIER.HTB.LOCAL | DNS_Tree_Name: HTB.LOCAL |_ Product_Version: 10.0.17763 | ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback | Issuer: commonName=SSL_Self_Signed_Fallback | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2019-06-07T19:36:42 | Not valid after: 2049-06-07T19:36:42 | MD5: f232 b7fc 7f41 4dbc 8453 479f 8950 f343 |_SHA-1: c986 b6ee c2b7 cea6 c0fd cc62 a32d 64da fe20 2b7b |_ssl-date: 2019-06-07T22:35:03+00:00; -1h06m12s from scanner time. No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=7.70%E=4%D=6/7%OT=135%CT=1%CU=43704%PV=Y%DS=2%DC=T%G=Y%TM=5CFAF62 OS:3%P=x86_64-pc-linux-gnu)SEQ(SP=106%GCD=1%ISR=108%TI=I%CI=I%II=I%SS=S%TS= OS:U)OPS(O1=M54DNW8NNS%O2=M54DNW8NNS%O3=M54DNW8%O4=M54DNW8NNS%O5=M54DNW8NNS OS:%O6=M54DNNS)WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FF70)ECN(R=Y% OS:DF=Y%T=80%W=FFFF%O=M54DNW8NNS%CC=Y%Q=)T1(R=Y%DF=Y%T=80%S=O%A=S+%F=AS%RD= OS:0%Q=)T2(R=Y%DF=Y%T=80%W=0%S=Z%A=S%F=AR%O=%RD=0%Q=)T3(R=Y%DF=Y%T=80%W=0%S OS:=Z%A=O%F=AR%O=%RD=0%Q=)T4(R=Y%DF=Y%T=80%W=0%S=A%A=O%F=R%O=%RD=0%Q=)T5(R= OS:Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=80%W=0%S=A%A=O%F= OS:R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=80%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T OS:=80%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=80%CD= OS:Z) Network Distance: 2 hops TCP Sequence Prediction: Difficulty=262 (Good luck!) IP ID Sequence Generation: Incremental Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: |_clock-skew: mean: -1h06m12s, deviation: 0s, median: -1h06m12s | ms-sql-info: | 10.10.10.125:1433: | Version: | name: Microsoft SQL Server | number: 14.00.1000.00 | Product: Microsoft SQL Server |_ TCP port: 1433 | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2019-06-07 18:35:06 |_ start_date: N/A
After doing a little research and a little poking, it looks like the Windows remote management services need credentials. The SMB share, on the other hand, is open to guest sessions.
There are some default shares, and then a “Reports” share. What’s in that?
In \\10.10.10.125\Reports, I find the macro-enabled Excel spreadsheet “Currency Volume Report.xlsm”. I don’t have anything on my Kali box that can open xlsm files, but I can unzip it and run ‘strings’ against the pieces. Lo, and behold, in xl/vbaProject.bin, we find…
A MS-SQL connection string with username ‘reporting’ and password ‘PcwTWTHRwryjc$c6’. We also get the database name of ‘volume’.
Initial compromise
Impacket has a nice little MSSQL client Python script, and after monkeying around with it for a bit, I was able to connect to the previously-identified MSSQL server, using the ‘-windows-auth’ flag for authentication.
./mssqlclient.py -db volume QUERIER/reporting:@10.10.10.125 -windows-auth
So, xp_cmdshell is not enabled, and “reporting” doesn’t have sufficient privileges to enable it. Additionally, poking around the database didn’t reveal anything of interest in the tables.
At this point, I hit something of a wall and ended up turning to the forums for a hint. They suggested looking at some previous Ippsec walkthroughs, where I eventually found instructions on using the MSSQL built-in xp_dirtree function and Impacket’s smbserver.py to harvest credentials.
Mark Mo has a good tutorial on how to do this on Medium.
So, I start up a SMB server with Impacket’s smbserver.py script in one shell and talk to the MSSQL server in another.
The result? The database server calls our SMB server to get a directory listing, very helpfully packaging its NTLM credentials in the request, which our SMB server catches and spits out.
mssql-svc::QUERIER:4141414141414141:9bdec9baeb18bf5da5a96feab645bd9a:01010000000000008020b765b420d5018fdcee522db462ba00000000010010004b0072005700790064006c004c00560002001000750055006f0043004900470041005600030010004b0072005700790064006c004c00560004001000750055006f0043004900470041005600070008008020b765b420d50106000400020000000800300030000000000000000000000000300000b1edba0b8013bae6a2412505596deabb3d9456a0fcf9f4df7f0feeff708139a40a0010000000000000000000000000000000000009001e0063006900660073002f00310030002e00310030002e00310034002e003400000000000000000000000000
Save that hash to a file (in this case mssql-svc.hash), and run it through John with the rockyou password list.
14 seconds later, I have new credentials:
Mssql-svc::corporate568
Using these creds back in the database, I’m now running as the service account, and can enable Xp_cmdshell and start running commands on the host:
After some poking around in the file system, I get…
Upgrading our shell, and escalating privilege
So, that’s user, but I still need an admin shell to fully pwn the box. Messing around on the system via xp_cmdshell is tedious, so the next thing to do is to upgrade my connection.
I go back to my SMB server, and put ncat in the share directory, then pull it over to the target box.
Or… not.
So, there’s probably an easier way of doing this, but a small part of me wanted to see how antivirus on the box was detecting ncat. Black Hills Information Security did a post a while back about just editing the code of a Meterpreter shell binary to evade antivirus by removing certain overtly malicious keywords. Unfortunately, I can’t find a link to it at the moment. Regardless, I was curious to see if something similar would work here, so I broke out hexeditor and turned ‘ncat’ into ‘mcat’ one character at a time.
A few minutes of find-and-replace later, and I have a perfectly innocent-looking binary.
With a firm beachhead on the machine, I turned to enumerating the box. I pulled out Just Another Windows (Enum) Script , went through Fuzzysecurity’s Windows enumeration tutorial, used Pentestmonkey’s windows-privesc-check2.exe… Nothing. I went back and tried using the credentials I had with winrm and wsman… Zip. Zilch. Nada.
Finally, after much searching, and banging of my head against the wall, I went back and looked at something I’d skipped before because it looked like it was only relevant to domain machines, and this was (I thought) a standalone box. But in
ProgramData\Microsoft\Group Policy\History\{31B2F340-016D-11D2-945F-00c04FB984F9}\Machine\Preferences\Groups\Groups.xml
I find:
The cpassword is what I’m looking for. Per fuzzysecurity, Microsoft published the static AES key used to encrypt all the cpasswords a few years ago. PowerSploit has a tool Get-GPPPassword, for retrieving those passwords, but since I already had the ciphertext, I just pulled out the Get-DecryptedCpassword function, made it a module and ran that:
MyUnclesAreMarioAndLuigi!!1!
One psexec later…
-30-