# Homework 3: Cracking WiFI!

For this homework assignment, I will demostrate cracking the `NetSec` WiFi network, and performing some reconissance. I will do this via the `mallory` machine, running kali

## Crack the NetSec WiFi network password with bettercap

After connecting to mallory, I start by running `bettercap` on the `wlan0` interface. I then try to turn on wifi reconnaissance.
![start-bettercap](./start-bettercap.png)

As issue is returned that bettercap cannot put wlan0 into monitor mode. This is strange, but I work around it by running `sudo iwconfig wlan0 mode Monitor` to do this manually
![manual-monitor](./manual-monitor.png)

### Find the BSSID and connected client of the NetSec Network

Running `wifi.show` with bettercap, we see the BSSID of NetSec. That being 28:87:ba:75:7e:93
![bettercap-wifi-show](./bettercap-wifi-show.png)

with `wifi.recon 28:87:ba:75:7e:93` I can see the clients of the NetSec network. Here, we see the client with BSSID 70:f7:54:ff:1c:59
![bettercap-wifi-recon](./bettercap-wifi-recon.png)
### Perform a deauth attack on the network with bettercap and capture the 4-way handshake

With `wifi.deauth 70:f7:54:ff:1c:59` I can send a deauth message to the above client. We can see this worked, and the handshake was automatically captured
![bettercap-deauth](./bettercap-deauth.png)
### Use the hcx toolsuite to convert the captured handshake to a format that hashcat can understand

Using hcxpcapngtool of the hcx toolsuite, I can convent this pcap file to a format hashcat will understand (after copying the file from /root to /home/kai)
![hcxpcapngtool](./hcxpcapngtool.png)
### Crack the password using hashcat and rockyou.txt

Finally, I run `hashcat -m 22000 -a 0 -w 3 -o bettercap-cracked.txt handshake.hc22000 rockyou.txt` on the above converted handshake file, to crack the password and write it to `bettercap-cracked.txt`.
![hashcat-running](./hashcat-running.png)

After ~7 minutes, we have cracked the password. That being `crackme1`
![cracked](./cracked.png)

### Connect workstation to the wifi network and show using nmtui
Now that I have found the password, I can initiate a wifi connection from `mallory` to the NetSec network

The first issue encountered was the the network manager was inactive. This is confirmed by running `systemctl status NetworkManager`

![network-manager](./network-manager-status.png)

This was fixed by running `sudo systemctl start NetworkManager`

Now with `sudo nmtui` I can finally attempt connect to NetSec with the password, `crackme1`.

![nmtui-connect](./nmtui-connect.png)

The connection was successfull

![nmtui-connected](./nmtui-connected.png)

## Scan the network with nmap
I now want to scan the network to identify the router, and devices connected to the router. A quick check with `iwconfig` and looking at the `wlan0` interface shows that as a client of this router, we are in the subnet `192.168.0.0/24`

![subnet](./subnet.png)

Now running `sudo nmap -sn 192.168.0.0/24` (a simple ping scan) we have some interesting results. I've run this a few times on different days to see which hosts are persistant, and less likely to be other students

![nmap](./nmap.png)
![nmap-1](./nmap-1.png)
![nmap-2](./nmap-2.png)
![nmap-3](./nmap-3.png)

To summerize this, the interesting devices, excluding ourselves (mallory) are
```
Nmap scan report for Archer (192.168.0.1)
MAC Address: 28:87:BA:75:7E:98 (TP-Link Limited)

Nmap scan report for bookworm (192.168.0.139)
MAC Address: D8:3A:DD:7E:3C:31 (Unknown)

Nmap scan report for 192.168.0.240
MAC Address: E4:5F:01:91:0C:52 (Raspberry Pi Trading)
```
We have one router/gateway (archer/28:87:BA:75:7E:98), one persistant client device (bookworm/D8:3A:DD:7E:3C:31). The other devices shown in some of these scans do not seem to persist and are not shown in my last scan which is at the time of writing. I will now scan for open ports on these available devices.

### Open ports and services on archer
As the router/gateway, I do not expect any interesting servcies to be running here. But let us make sure
![archer-scan](./archer-scan.png)

As probably expected, our gateway is responding to DNS requests, and has web interfaces open on http/s.

Using ssh tunneling from 192.168.0.1:80 to localhost:8080, I can take a look at the web page on http. As shown, it prompts for a password, but is otherwise unremkable. When looking at the page on https, it is also un-remarkable, and just says that https is not supported (not shown)
![tp-link-page](./tp-link-page.png)

I decided not to try any attacks against the router and will be moving on.

### Open ports and services on bookworm

### Access the RTSP stream

#### Screenshot

#### Camera make, model, brand, capacity, and manufacture date