You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: vipa00 blog - Documenting the mechanics of system failure through red team tactics, CTF writeups, malware analysis, and the path into deeper systems hacking.
8
-
author: m4ze-v0
6
+
title: ScytheVipa0z
7
+
description: vipa0z Blog - Documenting the mechanics of system failure through red team tactics, CTF writeups, malware analysis, and the path into deeper systems hacking.
Copy file name to clipboardExpand all lines: source/_posts/SSRF-exploitation-cheathseet.md
+7-11Lines changed: 7 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,16 +11,18 @@ tags:
11
11
- web-security
12
12
- application-security
13
13
---
14
+
14
15
# \_OVERVIEW
15
16
16
-
Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making requests on their behalf. This deceptively simple flaw can have devastating consequences, potentially allowing attackers to:
17
+
Server-Side Request Forgery (SSRF) is a vulnerability where an attacker tricks a server into making requests to internal resources on their behalf. This deceptively simple flaw can have devastating consequences, potentially allowing attackers to:
17
18
19
+
- Bypass firewall rules blocking externel access to resources
18
20
- Access internal services hidden from the public internet
references to articles, cheatsheets, payloads, tools, and bypasses
87
-
88
+
88
89
#### Port Scanning
89
90
90
-
SSRFs exploitation provide a way to map internal resources such as live machines/local ports.
91
+
SSRFs exploitation provide a way to map internal resources such as live machines/local ports.
91
92
92
93
First, We have identify error messages by inspecting discrepancies between server responses. Comparing how the application responds to open vs. closed ports can reveal valuable information.
93
94
@@ -283,8 +284,3 @@ Many developers focus exclusively on blocking IPv4 addresses and completely over
283
284
Explores recent SSRF vulnerability reports and identifies common coding patterns and testing techniques. Highly recommend her entire SSRF series, including [Bypassing SSRF Protections](https://vickieli.dev/ssrf/bypassing-ssrf-protection/)!
description: "A practical walkthrough of abusing Groovy script consoles in DevOps environments to write persistent JSP bind shells, with techniques for transferring tools (base64), persistence, and post-exploitation tailored for tight scenarios where outgoing network access is blocked by firewalls."
6
+
- bind shell
7
+
- groovy
8
+
- liferay
9
+
- jenkins
10
+
- RCE
11
+
description: "A practical walkthrough of abusing Groovy script consoles in DevOps environments to write persistent java bind shells, with techniques for transferring tools (base64), persistence, and post-exploitation tailored for tight scenarios where outgoing network access is blocked by firewalls."
Have you ever been in an engagement or CTF where you finally find a Groovy script console… and then discover that outbound connections are blocked? Or you have a basic shell but you just can't get tools to the target using built-in upload methods?
17
19
18
-
Over the next few minutes I'll show a practical, repeatable approach for turning a Groovy console into a persistent, multithreaded JSP bind shell that lives in the webroot and how to transfer binary tools via base64 encoding (small and large size). This guide serves as a proof of concept; the shell in here is not secure enough for opsec, but it's a starting point for you to build upon.
19
-
<!-- more -->
20
-
---
20
+
Over the next few minutes I'll show a practical, repeatable approach for turning a Groovy console into a persistent, multithreaded java bind shell that lives in the webroot and how to transfer binary tools via base64 encoding (small and large size). This guide serves as a proof of concept; the shell in here is not secure enough for opsec, but it's a starting point for you to build upon.
21
+
22
+
## <!-- more -->
23
+
21
24
### Quick Refresher on Bind Shells:
25
+
22
26
23
27
The top side shows a bind shell: the victim host runs a listener (a shell bound to a TCP port) and the attacker connects into that listener to gain interactive access. The bottom side shows a reverse shell: the attacker runs the listener and the victim initiates an outbound connection back to the attacker, delivering a shell to the attacker's listener.
24
28
25
29
Reverse shells are the go-to for many red-teamers because they slip out through egress and work around NAT. But when outgoing traffic is tightly restricted (egress-blocked/proxied), you need a plan B. That's when bind shells become essential. In short: a bind shell makes the target listen and waits for an inbound connection. It trades the egress dependency of a reverse shell for a requirement that you can reach the host inbound (or via a pivot you control). That trade can be exactly what you need when defenders have locked down outbound channels.
When your RCE is limited to a Groovy-style script console (in tools such as Jenkins, Liferay, etc.) and the target cannot reach back to you, the console itself becomes your primary file system and transfer channel. This post focuses on turning that console access into a stable way to read/write files and drop tools. Treat the console like a tiny development environment on the target: you can list folders, create files, and write binary blobs (via base64) into disk locations the web server will execute or serve.
33
37
@@ -39,7 +43,7 @@ When your RCE is limited to a Groovy-style script console (in tools such as Jenk
39
43
40
44
1. Initial reconnaissance: Run simple OS commands to identify the environment and locate the webroot.
41
45
2. Discover writable paths: Find locations where you can save files that persist and potentially get executed or served.
42
-
3. Deploy the bind shell: Write a persistent JSP bind shell to the webroot.
46
+
3. Deploy the bind shell: Write a persistent java bind shell to the webroot.
43
47
4. Transfer tools: Use base64 encoding to transfer binary tools (if needed).
44
48
5. Verify and connect: Test the bind shell and establish a connection.
45
49
6. Clean up: Document detection artifacts and remove traces when done.
@@ -61,6 +65,7 @@ pwd, ls -la, id, whoami, env
61
65
For Windows:
62
66
dir, whoami, echo %USERPROFILE%
63
67
```
68
+
64
69
The full groovy script would look like this:
65
70
66
71
```groovy
@@ -94,17 +99,16 @@ Tips:
94
99
In this step, you use a Groovy script that embeds a Java-based bind shell.
1. Saves a JSP bind shell to the specified location.
101
-
2. Activates the listener once you access the JSP through a URL.
102
-
103
-
Update the output path in the script to match your Tomcat webroot and modify the port the shell should listen on, then paste the script into your console and run it.
104
105
106
+
1. Saves a java bind shell to the specified location.
107
+
2. Activates the listener once you access the java through a URL.
105
108
109
+
Update the output path in the script to match your Tomcat webroot and modify the port the shell should listen on, then paste the script into your console and run it.
106
110
107
-
Hit save, then to enable the listener, browse to your web shell at: `http://site/bindshell.jsp`
111
+
Hit save, then to enable the listener, browse to your web shell at: `http://site/bindshell.java`
**Note on why multithreading was used:** With many bind shells, it’s easy to accidentally kill the session (for example, by hitting `Ctrl+C`). In early versions of this shell, once the client disconnected, reconnecting with netcat wasn’t reliable. To fix that, the JSP handler accepts new connections in separate threads so a disconnect doesn’t permanently “break” the listener.
119
-
120
-
---
121
122
122
-
## Tool Transfers Using the Groovy Script Console
123
-
We can use the script console to transfer tools to the file system by first base64-encoding them and then running a script to decode that data into a local file on the target.
124
-
Depending on the target environment, some Groovy script console versions only support string variables that are around 6000 characters in length, which requires a bit of improvisation on our side.
123
+
**Note on why multithreading was used:** With many bind shells, it’s easy to accidentally kill the session (for example, by hitting `Ctrl+C`). In early versions of this shell, once the client disconnected, reconnecting with netcat wasn’t reliable. To fix that, the java handler accepts new connections in separate threads so a disconnect doesn’t permanently “break” the listener.
**Note:** This will not work if your base64 string is more than 6000 characters in length; you can use Method 2 below instead.
127
+
## Script Console as a dropper
129
128
129
+
We can use the script console for dropping tools on the file system by first base64-encoding them and then running a script to decode that data into a local file on the target.
130
+
Depending on the target environment, some console versions only support string variables that are around 6000 characters in length, which requires a bit of improvisation on our side.
**Note:** This will not work if your base64 string is more than 6000 characters in length; you can use Method 2 below instead.
132
135
133
136
Base64 encode the tool and copy to clipboard:
134
137
@@ -151,28 +154,34 @@ Files.write(dest, bytes)
151
154
println "Wrote ${bytes.length} bytes to ${dest}"
152
155
```
153
156
154
-
### For Larger Binaries
157
+
### Dropping Larger Binaries
155
158
156
-
I put together a script that chunks your tools into smaller base64 files (6000 chars per chunk by default), so you can paste them into the console and reassemble them with Groovy.
159
+
update: i wrote a dropper generator that generates the groovy script to drop the tool for you, you can use either the dropper here: https://github.com/vipa0z/B64Dropper or continue with the semi-manual method below.
the following is a script that chunks your tools into smaller base64 files, each containing a base64 String variable that is 6000 characters in length, so you can paste them into the console and reassemble them with Groovy.
|**[Ligolo-NG](https://github.com/nicocha30/ligolo-ng)** (4.1k+ ⭐) | I contributed a usability improvement to ligolo-ng’s autoroute feature. The tool previously didn’t reflect the last-selected interface when rebinding pivot routes, which caused friction during multi-interface pivots. I added state persistence so operators can clearly see which interface was previously selected before binding tunnel addresses. |
|[Vulnserver Exploit](https://github.com/vipa0z/vulnserver-Reverse-shell)| A custom Buffer Overflow exploit for a vulnerable server application |
50
-
|[Cheatsheet & Cookbook](https://vipa0z.github.io/cheatsheets)| Active Directory, Web, API, Internal Network exploitation cheatsheets, notes, and methodologies |
|[Vulnserver Exploit](https://github.com/vipa0z/vulnserver-Reverse-shell)| A custom Buffer Overflow exploit for a vulnerable server application |
46
+
|[Cheatsheet & Cookbook](https://vipa0z.github.io/cheatsheets)| Active Directory, Web, API, Internal Network exploitation cheatsheets, notes, and methodologies |
0 commit comments