# About Me
Nathaniel Fernandes
This is my personal blog, which is not associated with any company, and are my personal views
### A Little About Me
* A Tech Geek with business prowess
* Gone from Developer to Architecture to Operations to Management to Cyber Security
* My Hobbies
* Fashion
* Automating my life (With my Homelab)
* Geeking out in things which pique my interest
## Certifications
### CISSP
CISSP
* Passed CISSP at the age of 23
* [Verify with credly link](https://www.credly.com/badges/660f96e7-9751-4f67-b163-637f9608b47d)
* Want to know how I got CISSP at the age of 23
* [The Journey of how I passed CISSP](/blog/the-journey-of-how-i-passed-cissp)
### Other Certification
#### Certified in Cyber Security
* Link to [Badge](https://www.credly.com/badges/98cb1c0e-0827-46ad-add7-ecd275b0c130)
Certified in Cyber Security
#### ISO/IEC 27001 Information Security Associate
* Link to [Badge](https://www.skillfront.com/Badges/86910310894979)
#### Google Cyber Security
*
## Public Interviews
### John Hammond
{% embed url="" %}
### Grant Collins
#### Build Practical Experience in Cybersecurity Today (Cybersecurity Homelabs)
{% embed url="" %}
## Public Talks
* Breachforce
* Diving into nmap How exactly does OS detection work
*
* [How Nmap gets what OS is running by using different probes](/blog/how-nmap-gets-what-os-is-running-by-using-different-probes)
* Vidyalankar School of Information Technology (2024)
* breaking into cybersecurity
*
* keynote speaker at Responsible Netism (2017)
* Social engineering high value targets
*
## Fun Facts about me
* started working at the age of 16 doing web development
* And things just scaled up from there
* I have given multiple speeches but my most notable one is at the age of 17
*
* After being awarded a grant by honourable Minister [Ashwini Vaishnaw](https://www.linkedin.com/in/ashwini-vaishnaw-349b40226/) \*
* 
* Trained over 1500+ people in cybersecurity
### About this Site
* This is a public documentation site of the tools and configs to build applications faster
* The Focus of my home lab is Cybersecurity
* building an entire enterprise environment
## Resume
{% file src="/files/BQADqxGQmpIbHichkdeT" %}
## Links
* [Github](https://github.com/nathaniel-security/Docs)
* [linkedin](https://www.linkedin.com/in/nathaniel-fernandes/)
# Homelab
* a place where I upload scripts I have used in my homelab for public documentation
* just added a high level architecture diagram below
{% embed url="" %}
Current Diagram
{% endembed %}
# Change SSH Port
Change SSH Port
```bash
sudo nano /etc/ssh/sshd_config
```
* Change Port Number
#### Restart SSH
For the configuration changes to take effect, restart the SSH service. Run the following command:
```
sudo service ssh restart
```
## Reference
*
# Install Docker Ubuntu
Install Docker Ubuntu
## Install docker on ubuntu
```bash
sudo apt-get update && sudo apt upgrade -y
```
```bash
sudo apt-get install \
ca-certificates \
curl \
gnupg \
lsb-release
```
```bash
sudo apt install apt-transport-https ca-certificates curl software-properties-common -y
```
```bash
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
```
```bash
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
```
```bash
sudo apt install docker-ce -y
```
```bash
sudo systemctl status docker
```
# Portainer
docker management tool
* Good Docker Management tool
* is opensource
## Update
```bash
sudo apt update && sudo apt upgrade -y
```
## Install Portainer Community Edition
```bash
mkdir portainer_data
current_path=$(pwd)
sudo docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v $current_path/portainer_data:/data portainer/portainer-ce:latest
```
# Install Active Directory
* Config
* 4 GBram
* 4 cores
* windows server 2019
### Install Windows server
* remove the floppy disk before starting it
* else it keep asking for product key
### Install Active Directory
#### Rename Server
### Install Active Directory Services
* click on add roles and features
### Promote to domain controller
* then Install
### Add user to Domain
* click on Active directory Users and computers
# Setting up Wireguard
just a place to documenting my homelab
* update and upgrade
```
sudo apt-get update && sudo apt-get upgrade -y
```
* install wireguard
```
sudo apt-get install wireguard
```
* edit the sysctl.conf
```
sudo nano /etc/sysctl.conf
```
* uncomment \`net.ipv4.ip\_forward=1\`
```
net.ipv4.ip_forward=1
```
```
sudo sysctl -p
```
* wireguard conf
```
cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
sudo nano /etc/wireguard/wg0.conf
```
* Server conf (technically its a peer)
```
[Interface]
PrivateKey =
Address = 10.0.0.1/24
# PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE
# PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens33 -j MASQUERADE
PostUp = iptables -A FORWARD -i wg0 -o ens33 -j ACCEPT; iptables -A FORWARD -i ens33 -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -o ens33 -j ACCEPT; iptables -D FORWARD -i ens33 -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens33 -j MASQUERADE
ListenPort = 51820
Table = off
[Peer]
PublicKey =
AllowedIPs = 10.0.0.2/32 , 192.168.0.0/24 , 192.168.0.146/32
```
* clinet conf
```
wg genkey | tee privatekey | wg pubkey > publickey
```
```
[Interface]
Address = 10.0.0.2/32
PrivateKey =
# DNS = 1.1.1.1
[Peer]
PublicKey =
Endpoint = 110.110.110.110:51820
# Endpoint = :51820
AllowedIPs = 192.168.0.0/24
PersistentKeepalive = 25
```
## References
*
# Managing WireGuard Logs with Systemd and Logrotate 🔥
When managing a **VPN like WireGuard**, logging is crucial for **monitoring activity, debugging issues, and ensuring security**. But if left unchecked, logs can **grow rapidly** and become unmanageable.
In this guide, we’ll **set up Systemd** to capture WireGuard logs dynamically and use **Logrotate** to keep them under control automatically.
### Setup a Systemd file to store logs
**Step 1: Create a Systemd Service to Store Logs**
First, we need to create a Systemd service that continuously logs WireGuard activity.
🔹 Open a new Systemd service file:
```
nano /etc/systemd/system/wireguard-log.service
```
🔹 Add the following configuration:
```
[Unit]
Description=WireGuard Dynamic Debug Logging
After=network.target
[Service]
ExecStart=/bin/bash -c 'dmesg -wT | grep wireguard >> /var/log/wireguard-dyndbg.log'
Restart=always
RestartSec=5
StandardOutput=null
StandardError=null
[Install]
WantedBy=multi-user.target
```
🔹 Reload and restart Systemd to apply changes:
```
sudo systemctl daemon-reload
sudo systemctl restart wireguard-log.service
sudo systemctl enable wireguard-log.service
```
🔹 Verify that the service is running:
```
sudo systemctl status wireguard-log.service
```
### **Set Up Logrotate for Automatic Log Management**
Now, let’s ensure our logs don’t grow indefinitely by setting up **Logrotate**.
🔹 Install Logrotate (if not already installed):
```
sudo apt update && sudo apt install logrotate -y
```
🔹 Create a Logrotate configuration file:
```
nano /etc/logrotate.d/wireguard
```
🔹 Add the following configuration to manage log rotation:
```
/var/log/wireguard-dyndbg.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 0640 root root
postrotate
systemctl restart wireguard-log.service > /dev/null 2>&1 || true
endscript
}
```
Test Your Log Rotation Setup
```
sudo logrotate -v /etc/logrotate.d/wireguard
```
To **force** log rotation manually:
```
sudo rm -f /var/lib/logrotate/status
sudo logrotate -f /etc/logrotate.d/wireguard
```
```
ls -lh /var/log/wireguard-dyndbg.log*
```
# Cloudflare Tunnels: The Cybersecurity Pro's Secret Weapon for Secure Cloud Access
### 🔥 Backstory: Why I Set This Up
* One of my internal apps was **exposed on the internet** despite being **proxied through Cloudflare**.
* Anyone scanning the internet (like Shodan or Censys) could hit it directly, even though Cloudflare was enabled
* Enter: **Cloudflare Tunnel** no exposed ports, no firewall nightmares, no BS.
***
Would you like me to add a little `shodan.io` search reference or a quote from your internal logs to give it that gritty realness?
### ✨ TL;DR
Use **Cloudflare Tunnel** to securely expose multiple web apps (on different ports) to the internet using **just one tunnel**, without opening a single port on your firewall. This blog walks through:
* Creating the tunnel
* Mapping subdomains to services
* Auto-starting with systemd
***
### 🧠 Why Use Cloudflare Tunnel?
* 🔐 No port forwarding
* 💸 Free for personal and dev use
* 🌍 Expose multiple apps via subdomains
* 📦 Works great with local HTTPS and Docker
***
### ⚙️ My Setup
* OS: Ubuntu 22.04 (but any Linux works)
* Cloudflare domain: `wehost.co.in`
* Goal: Expose multiple local apps like:
* `test.wehost.co.in` → `localhost:8002`
***
### 🚀 Step 1: Install `cloudflared`
```
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb
```
### 🔐 Step 2: Authenticate with Cloudflare
```
cloudflared tunnel login
```
* This opens a browser window. Select your domain, and Cloudflare will generate a credentials file.
### 🌪️ Step 3: Create the Tunnel
```
cloudflared tunnel create test
```
This creates a tunnel and saves a `.json` credentials file under `~/.cloudflared/`.
You can confirm with:
```
cloudflared tunnel list
```
### 🛠️ Step 4: Create Config File
Create a `config.yml` in `~/.cloudflared/`:
```
nano ~/.cloudflared/config.yml
```
```
tunnel:
credentials-file: /home/groot/.cloudflared/.json
ingress:
- hostname: test.wehost.co.in
service: https://localhost:8002
originRequest:
noTLSVerify: true
- service: http_status:404
```
Replace `` with the one from `cloudflared tunnel list`.
### 🌐 Step 5: Route the Subdomain
```
cloudflared tunnel route dns test test.wehost.co.in
```
This links your tunnel to the subdomain in Cloudflare DNS.
### ✅ Step 6: Run the Tunnel
```
cloudflared tunnel --config ~/.cloudflared/config.yml run test
```
You should see output like:
```
Starting tunnel tunnelID=...
Using CurveP256...
```
### 🔁 Step 7: Auto-Start on Boot with systemd
Create the service file:
```
sudo nano /etc/systemd/system/cloudflared-test.service
```
```
[Unit]
Description=Cloudflare Tunnel - test
After=network.target
[Service]
TimeoutStartSec=0
Restart=always
ExecStart=/usr/local/bin/cloudflared tunnel --config /home/groot/.cloudflared/config.yml run test
User=groot
Environment=HOME=/home/groot
[Install]
WantedBy=multi-user.target
```
```
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl enable cloudflared-test
sudo systemctl start cloudflared-test
```
### 🔮 What’s Next: Auto-Magic with CI/CD
Now that the tunnel’s solid, I’m planning to take it a step further:
> **The next iteration of this setup will integrate with a CI/CD pipeline** so every time I deploy a new app or update port mappings, the pipeline will:
>
> * Automatically update the `config.yml`
> * Push it to the server
> * Restart the Cloudflare tunnel service
> * Route any new subdomains on the fly
Think: zero-touch deployments with automatic subdomain provisioning. No more manual edits, no more downtime just ship and forget.
Stay tuned — that one’s gonna be fun. 🔧🚀
# 🧠💥 How I Routed My Entire Lab's HTB Traffic Through a Single VPN Box
### 😤 The Problem
If you’re working in a lab environment and doing serious work with Hack The Box (HTB), chances are you've got automation running scanners, exploit frameworks, recon tools, and maybe even a full orchestration setup.
The catch? HTB traffic only routes through their VPN tunnel. So unless *every single* box in your lab connects to the VPN (spoiler: bad idea), you’re stuck.
### 🎯 The Goal
Instead of duct-taping VPN clients on every box, here’s what we want:
* **Single system connected to HTB VPN**
* **All LAN devices route HTB-bound traffic through that system**
* **Clean iptables rules that don’t wreck your firewall**
* **Scriptable and reversible setup that “just works”**
### 🧠 The Setup
Here’s the architecture:
* **LAN Interface:** Your main interface (e.g., `ens33`)
* **VPN Interface:** Where your HTB VPN is connected (`tun0`)
* **LAN Subnet:** `192.168.0.0/24`
* **HTB Subnet:** `10.10.0.0/16`
We’re going to build a gateway that transparently routes traffic from your LAN to HTB over the VPN.
### 🛠️ The Script
```
# Define variables
LAN_IFACE="ens33"
# LAN_IFACE: The interface connected to your local network (home lab or automation server).
VPN_IFACE="tun0"
# VPN_IFACE: The interface created by HTB's OpenVPN connection.
LAN_SUBNET="192.168.0.0/24"
# LAN_SUBNET: The subnet used by your internal LAN devices.
HTB_SUBNET="10.10.0.0/16"
# HTB_SUBNET: The IP range used by HTB target machines. This is what we want to reach via VPN.
echo "1" | sudo tee /proc/sys/net/ipv4/ip_forward
# 🚀 Enable IP forwarding
# Required so it can forward traffic from LAN to VPN
sudo iptables -F
sudo iptables -t nat -F
# Flushes all filter and NAT rules.
# ⚠️ Warning: This will wipe existing firewall rules. Fine for a lab, dangerous in production.
# NAT outgoing traffic to VPN
sudo iptables -t nat -A POSTROUTING -s $LAN_SUBNET -d $HTB_SUBNET -o $VPN_IFACE -j MASQUERADE
# Changes the source IP of packets from your LAN going to HTB, so they appear to come from your VPN interface IP.
# Allow traffic from LAN to VPN and back
sudo iptables -A FORWARD -s $LAN_SUBNET -d $HTB_SUBNET -i $LAN_IFACE -o $VPN_IFACE -j ACCEPT
# Allows packets going from LAN to HTB (via VPN)
sudo iptables -A FORWARD -d $LAN_SUBNET -s $HTB_SUBNET -i $VPN_IFACE -o $LAN_IFACE -j ACCEPT
# Allows return packets coming from HTB back to LAN
```
👽 Link to updated [code](https://gist.github.com/nathaniel-security/0b63812f96c7dfca8c66b7e6a4176d2f#file-connect_htb-sh)
### 💥Connect my client
```
sudo ip route add 10.10.11.165 via 192.168.0.251 dev wlp0s20f3
```
* `10.10.11.165` is an HTB IP address of the box
* `192.168.0.251` my proxy\_box IP address
* to delete the ip route
```
sudo ip route del 10.10.11.165 via 192.168.0.251 dev wlp0s20f3
```
### ⚡ Real-World Use Case
Now every system on my network even my toaster (I always knew it was destined for great things) can reach any HTB target, without needing its own VPN setup. 🤖🔗💣
### 💬 Final Thoughts
This isn’t about fancy scripts or over-engineering (I tend to do it a lot but don't we all). It’s about having a reliable, controlled setup that routes HTB traffic through your VPN **without reinventing the wheel or smashing your firewall with a sledgehammer**.\
You now have a surgical routing setup. There are no hacks, no weird side effects, and just a clean flow from your lab to HTB.
# Opening SSH with Root Access to the World: A Controlled Honeypot Experiment
> *"If you're going to set a trap, make sure it looks like a jackpot."*
***
### 🐱 It Started with a One-Way Conversation
Before any real hackers showed up, I decided to have a little fun.\
I shared the open SSH port with a friend and told him to "explore freely."
What followed was pure comedy.
He logged in, typed commands like `clear`, `ls`, `cat`, `man`, and even tried chatting with the server:
> `"what the f*** is the server"`\
> `"why have you even exposed this on internet to waste our time"`\
> `"please get a life bro"`
Meanwhile, I sat back, silently watching him yell at a machine that logged everything without a response.
Here’s a live snapshot from that session
***
### 🎯 The Goal
After laughing way too hard, I got serious.\
This wasn’t about trolling, it was about building a **controlled honeypot** designed to capture real-world attacker behaviour.
The mission:
* **Expose a fake SSH service** offering **root access**.
* **Isolate** the honeypot completely from the real internet.
* **Control** entry points with tight firewalling and routing.
* **Observe** and log attacker behaviour safely.
In short:\
✅ Full control.\
✅ Full visibility.\
✅ Zero risk.
***
### 🛠️ The Architecture
The setup involved two servers:
| Machine | Role | IP / Interface | Notes |
| ---------------------- | ------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `shaddykrupa` | Cowrie SSH Honeypot | `192.168.237.128` (host-only network) | No internet access |
| `shaddy-reverse-proxy` | Reverse Proxy | LAN Interface: `ens33`, Host-Only Interface: `ens37` | Port `2000` exposed to the Internet (exposed on port 22 publically so technically 3 layers of network translation 2 NAT and 1 PAT ) |
**Traffic flow:**
```plaintext
[ Attacker ]
⬇️
Public IP (Port 22 externally)
⬇️
shaddy-reverse-proxy:2000 (LAN-facing)
⬇️
iptables DNAT
⬇️
shaddykrupa:2222 (Cowrie Honeypot)
```
### 🔥 The Firewall (iptables) Rules
Here’s the exact firewall script I used on `shaddy-reverse-proxy`:
```sh
# Flush old NAT rules if needed
sudo iptables -t nat -F
# Forward all TCP traffic hitting port 2000 on the LAN-facing interface to Cowrie
sudo iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 2000 -j DNAT --to-destination 192.168.237.128:2222
# Allow forwarding
sudo iptables -A FORWARD -p tcp -d 192.168.237.128 --dport 2222 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# Masquerade the packets so they appear to come from the proxy
sudo iptables -t nat -A POSTROUTING -o ens37 -p tcp -d 192.168.237.128 --dport 2222 -j MASQUERADE
sudo iptables -A INPUT -m state --state INVALID -j DROP
sudo iptables -A FORWARD -m state --state INVALID -j DROP
```
This setup ensures:
* Only traffic on port `2000` is accepted and redirected.
* Packets are rewritten so Cowrie sees them correctly.
* Invalid traffic is dropped to harden the proxy itself.
***
### 🧪 Watching the World Come In
Once the trap was live, it didn’t take long.
Bots, opportunistic attackers, and noisy scanners started pouring in each believing they had **found an open root-access SSH server**.
They spammed password attempts, tried `wget` malware downloads, dropped crypto-miners,\
and some immediately fired off `rm -rf /*` like it was Christmas morning.
Meanwhile, Cowrie quietly logged everything.
***
### 📈 Key Observations (So Far)
* **Attackers behave differently** when they think they have root: bold, reckless, and noisy.
* **Speed is insane**: The first bot hit within minutes of exposure.
* **Defence in depth is non-negotiable**: Even honeypots need strong isolation.
***
### 🛡️ What's Next?
This is just the beginning.
I'm **continuing to log** and **analyse** all incoming activity.\
The real fun starts now: studying **what the bots do**, how they behave, and what tools and malware they attempt to deploy when they believe they've found root access.
Will try and put updates soon with:
* Full analysis of attacker behaviour over time
* Common attack patterns spotted in the wild
* Tricks attackers use once they believe they "own" a system
***
### 🧠 Final Thoughts
This wasn’t just about catching hackers / Bots — it was about **understanding them**.\
Learning how fast they move, how they think, and how to outwit them.
By exposing fake root access in a controlled, isolated, and fortified environment,\
I got a front-row seat to the chaos without ever risking a real system.
And honestly? Watching my friend get mad at a fake server was just a bonus.
***
## 🎯 TL;DR
I opened SSH with root access to the world, but the only ones who got pwned were the bots.
And a little bit... my friend too.
## Reference
* [cowrie docker compose](https://gist.github.com/nathaniel-security/c7d662d0460af15f73e0c70c938b80f6)
* [iptables](https://gist.github.com/nathaniel-security/dc6165ae26b301f858a749e6a5db8df7)
# CyberSecurity
* Just a place I dump my cyber security notes
# Insecure Direct Object References (IDOR)
* IDOR vulnerabilities occur when a web application exposes a direct reference to an object, like a file or a database resource, which the end-user can directly control to obtain access to other similar objects
* download.php?file\_id=123
## Identifying IDORs
### URL Parameters & APIs
* `?uid=1` or `?filename=file_1.pdf`
### AJAX Calls
```javascript
function changeUserPassword() {
$.ajax({
url:"change_password.php",
type: "post",
dataType: "json",
data: {uid: user.uid, password: user.password, is_admin: is_admin},
success:function(result){
//
}
});
}
```
### Understand Hashing/Encoding
* download.php?filename=c81e728d9d4c2f636f067f89cc14862c
* At a first glance, we may think that this is a secure object reference, as it is not using any clear text or easy encoding.
* However, if we look at the source code, we may see what is being hashed before the API call is made
```javascript
$.ajax({
url:"download.php",
type: "post",
dataType: "json",
data: {filename: CryptoJS.MD5('file_1.pdf').toString()},
success:function(result){
//
}
});
```
### Compare User Roles
* If we want to perform more advanced IDOR attacks, we may need to register multiple users and compare their HTTP requests and object reference
* if we had access to two different users, one of which can view their salary after making the following API call:
```json
{
"attributes" :
{
"type" : "salary",
"url" : "/services/data/salaries/users/1"
},
"Id" : "1",
"Name" : "User1"
}
```
# HTTP Verb Tampering
* can be exploited by sending malicious requests using unexpected methods, which may lead to bypassing the web application's authorization mechanism or even bypassing its security controls against other web attacks
### Insecure Coding
```php
$pattern = "/^[A-Za-z\s]+$/";
if(preg_match($pattern, $_GET["code"])) {
$query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
...SNIP...
}
```
### Insecure Configurations
```
Require valid-user
```
### Attack
* Crafting custom HTTP requests
```
[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]
```
```
OPTIONS /index.html HTTP/1.1
host: www.example.com
```
```
GET /index.html HTTP/1.1
host: www.example.com
```
```
HEAD /index.html HTTP/1.1
host: www.example.com
```
```
POST /index.html HTTP/1.1
host: www.example.com
```
```
PUT /index.html HTTP/1.1
host: www.example.com
```
```
DELETE /index.html HTTP/1.1
host: www.example.com
```
```
TRACE /index.html HTTP/1.1
host: www.example.com
```
```
CONNECT /index.html HTTP/1.1
host: www.example.com
```
### Automated HTTP Verb Tampering Testing
```
#!/bin/bash
for webservmethod in GET POST PUT TRACE CONNECT OPTIONS PROPFIND;
do
printf "$webservmethod " ;
printf "$webservmethod / HTTP/1.1\nHost: $1\n\n" | nc -q 1 $1 80 | grep "HTTP/1.1"
done
```
## Reference
*
# SSH Attack
### SSH-Audit
```shell-session
git clone https://github.com/jtesta/ssh-audit.git && cd ssh-audit
```
```shell-session
./ssh-audit.py 10.129.14.132
```
```shell-session
# general
(gen) banner: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
(gen) software: OpenSSH 8.2p1
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)
# key exchange algorithms
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256 -- [fail] using weak elliptic curves
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384 -- [fail] using weak elliptic curves
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521 -- [fail] using weak elliptic curves
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 (2048-bit) -- [info] available since OpenSSH 4.4
(kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group14-sha256 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
# host-key algorithms
(key) rsa-sha2-512 (3072-bit) -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (3072-bit) -- [info] available since OpenSSH 7.2
(key) ssh-rsa (3072-bit) -- [fail] using weak hashing algorithm
`- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
`- [info] a future deprecation notice has been issued in OpenSSH 8.2: https://www.openssh.com/txt/release-8.2
(key) ecdsa-sha2-nistp256 -- [fail] using weak elliptic curves
`- [warn] using weak random number generator could reveal the key
`- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5
...SNIP...
```
# Basic Bash
basic bash commands used in cybersecurity
## SET TERM
```bash
export TERM=xterm
```
```bash
python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm
```
## Local Python Server
```bash
python3 -m http.server #python3 -m http.server 80
```
## NETCAT
### Netcat Listener
```bash
nc -lvp #nc -lvp 8080
```
# Nmap
### Notes
* Passing an ip is better than using domain name
* else nmap will spend time doing a reverse domain lookup
* but an ip can also have multiple domain under it
* which could be used to attack it
* if you know target is online pass the flag for telling it not to do a ping
* Pass the `-Pn` flag
* Nmap used the response of port scan as well as the network header to determine the OS
* this is a probability
* this can be increased by various NSE scripts
* Suggestion
* Always save it to a file
* the order of the flags are also important if you do a -sv and the a -p- it will do a banner grab on every port
* instead if you do a -p- first then a first check if the port is open and then does a banner grab
*
## Nmap Commands
### Basic
```
nmap -Pn -n -A -vvv -oN nmap/00-basic.txt -iL target.txt
```
### TCP port scan Full
```bash
nmap -n -p- -vvv -oN nmap/01-full-port-scan.txt -iL target.txt
```
### UDP port scan Full
```bash
sudo nmap -vvv -sU -n -p- -oN nmap/02-udp-full-port-scan.txt -iL target.txt
```
### Top 1000 UDP port scan Full
```bash
sudo nmap -vvv -sU -n -p- -oN nmap/02.5-udp-top-1000-port-scan.txt -iL target.txt
```
### Detail scan
```bash
sudo nmap -vvv -sC -A -O -osscan-guess -sV -version-all -oN nmap/03-detail-scan.txt -iL target.txt -p
```
### Convert nmap xml to html
```shell-session
xsltproc target.xml -o target.html
```
### Type of Scans
#### -sT
* most stealthy where the whole connection is made
* most stealthy since many firewalls are tuned to look for half open connections
* SYN > SYN/ ACK > ACK
* also the most accurate
* but takes the most time
#### -sA
* only sends a `ACK` packet
* done to understand the firewall rule set
* works if firewall is stateless
*
#### -sS
* default scan of nmap
* Sends only a `SYN` packet
* can be detected by firewalls after potential 2 packet , 3 to prove a trend
* also the fastest scan
#### -sU
* performs UDP scan
* still does a ping first
* Don't know why Nmap tries to connect on port 80 with TCP in a UDP scan
#### -Pn
* nmap always does a icmp request to check if the port is up
* this tell nmap not to do a ping request
#### -sV
* discovers service version by banner grabbing
#### -O
* discovers OS details from ports and TTL
#### -A
* does os discovers (-O) and service discovery along with their versions
## Cheat sheet
| **Nmap Option** | **Description** |
| -------------------- | ---------------------------------------------------------------------- |
| `10.10.10.0/24` | Target network range. |
| `-sn` | Disables port scanning. |
| `-Pn` | Disables ICMP Echo Requests |
| `-n` | Disables DNS Resolution. |
| `-PE` | Performs the ping scan by using ICMP Echo Requests against the target. |
| `--packet-trace` | Shows all packets sent and received. |
| `--reason` | Displays the reason for a specific result. |
| `--disable-arp-ping` | Disables ARP Ping Requests. |
| `--top-ports=` | Scans the specified top ports that have been defined as most frequent. |
| `-p-` | Scan all ports. |
| `-p22-110` | Scan all ports between 22 and 110. |
| `-p22,25` | Scans only the specified ports 22 and 25. |
| `-F` | Scans top 100 ports. |
| `-sS` | Performs an TCP SYN-Scan. |
| `-sA` | Performs an TCP ACK-Scan. |
| `-sU` | Performs an UDP Scan. |
| `-sV` | Scans the discovered services for their versions. |
| `-sC` | Perform a Script Scan with scripts that are categorized as "default". |
| `--script