Neo-reGeorg: an HTTP tunnel that hides inside a webshell

What Neo-reGeorg actually does

Neo-reGeorg is a rewrite of reGeorg, the older tunnelling tool that used an uploaded web script as a relay. The README states the goals directly: improve usability, avoid signature detection, improve tunnel connection security, improve the confidentiality of transmitted content, and work in more network scenarios. The problem it addresses is narrow and specific. You have code execution or file upload on a web server, and you want a TCP path into the network behind that server without opening a listening port on it. The server-side script answers ordinary HTTP requests; the Python client on your machine turns those request and response pairs into a SOCKS5 proxy bound to 127.0.0.1:1080 by default.

The audience is security researchers and penetration testers, and the README says so in a warning that places all legal responsibility on the user. That framing matters: this is a tool for authorised testing, and the repository does not pretend otherwise. What makes it more than a reGeorg clone is the transport design. Content is transformed and base64-encoded so it resembles ordinary base64 data, and the payload uses a BLV (Byte-Length-Offset-Value) format. The response to a direct request can be a decoy page, for example a 404, so a browser or a scanner hitting the URL sees something unremarkable.

The client-server data flow, and why the server files differ by language

The architecture is a loop. The client holds the SOCKS5 listener, accepts a connection from a local tool, reads bytes, wraps them in the BLV format, encodes them, and POSTs them to the tunnel URL. The server script decodes the request, opens or reuses a TCP connection to the target, writes the bytes, reads the reply, encodes it, and returns it as the HTTP response body. The client unwraps the response and writes it back to the local socket. Everything rides on request and response bodies, which is why the project can claim header customisation, custom HTTP response codes, and request templates.

The language-specific server files are not cosmetic. The README notes that aspx, ashx, jsp and jspx no longer depend on Session and work without cookies, while the PHP server file follows pivotnacci in creating multiple TCP connections from a single session to cope with load balancers. Non-PHP Node.js supports intranet forwarding for the same reason. There is also a Go server file that can be started as a process with `go run neoreg_servers/tunnel.go 8000`, for environments where a plain script is not enough. If you are choosing a language, that list is the real decision surface: pick the one whose runtime is already present on the target and whose session behaviour matches the deployment.

Installing the client and running a first tunnel

The repository ships `neoreg.py` at the top level and a `templates/` directory. There is no packaging step described in the README; you install the Python dependency and run the script. The only required dependency is `requests`.

python -m pip install requests

The README lists three optional extras: `requests[socks]` for SOCKS5 proxy support when the client itself must reach the server through a proxy, `curl-cffi` to switch the HTTP library for performance and stability, and `requests_ntlm` for NTLM authentication.

python -m pip install requests[socks]
python -m pip install curl-cffi
python -m pip install requests_ntlm

Step one is generating the server files with a key. The key is the shared secret between client and server, so it must match on both sides.

python neoreg.py generate -k password

The README shows the output listing `neoreg_servers/tunnel.jsp`, `tunnel.jspx`, `tunnel.ashx`, `tunnel.aspx`, `tunnel.php` and `tunnel.go`. Upload the one matching the target and then connect.

python3 neoreg.py -k password -u http://xx/tunnel.php

According to the README, the client prints the log level, the SOCKS server address (`127.0.0.1:1080`), and the tunnel URL. Point your tooling at that SOCKS5 endpoint. If the server needs a proxy to reach it, add `--proxy socks5://10.1.1.1:8080`; if it needs headers or cookies, use `-H 'Authorization: ...'` and `--cookie "key=value"`.

Camouflage, templates and the -T flag

The camouflage features are the part most likely to be misunderstood. Generating with `--file 404.html --httpcode 404` makes the server respond to a direct request with that page and status code, and the README pairs this with `--skip` on the client side to skip the usability test. That is a decoy for casual inspection, not a guarantee of stealth. The request template flag is more interesting: `-T 'img=data:image/png;base64,NEOREGBODY&save=ok'` replaces the `NEOREGBODY` placeholder with the encoded payload, so the POST body looks like a form field carrying an image. The README notes that the template can also be read from a file by passing a path to `-T`.

There is a real constraint here. The template must be set at generate time and match at connect time, so a mismatch between the two sides produces a tunnel that simply does not work. The README does not document a diagnostic for template mismatches, which makes this a place to test carefully rather than guess. Similarly, `--cut-left`, `--cut-right` and `--extract` exist for responses wrapped in extra content, and the README's help output is the only description of them; it does not explain what a typical wrapping looks like.

Where Neo-reGeorg is the wrong tool

Throughput is the first limitation. Every byte crosses the wire as an HTTP request and response, encoded and wrapped in BLV. The client exposes `--read-buff` (default 7 KB, max 50), `--read-interval` (default 300 ms) and `--write-interval` (default 200 ms), and those defaults are tuned for reliability on unfriendly links, not for moving data quickly. If your goal is to transfer a large file or run an interactive session that feels local, this is not the right instrument. The intervals alone mean the tunnel is pacing itself.

Stability under load balancing is the second. The README is candid that the server may be deployed on only some machines behind a balancer, and the mitigations (multiple URLs via repeated `-u`, the PHP multi-connection behaviour, `-r` redirect for java/.net, Node.js intranet forwarding) are partial answers to a problem the tool cannot fully solve. If requests land on a machine without the server file, the tunnel degrades.

Finally, the legal boundary. The README states the tool is for security research and teaching only and that the user bears all legal responsibility. Any use outside an authorised engagement is outside what the project supports, and the repository offers no mechanism to make that safe.

Neo-reGeorg against the original reGeorg and against a plain reverse shell

The original reGeorg is the direct comparison, and the README frames Neo-reGeorg as an aggressive refactor of it rather than a fork with patches. The practical differences documented here are the transport encoding (transformed base64 plus BLV instead of the older format), the removal of Session dependence in aspx, ashx, jsp and jspx, the PHP multi-connection behaviour borrowed from pivotnacci, the Go server file that can run as a process, and the request template mechanism. If you used reGeorg and hit cookie or session problems in a .NET or Java environment, those are exactly the cases the rewrite targets.

The other alternative is not a tool but an approach: a reverse shell or a direct bind shell. A reverse shell gives you a command channel, not a network proxy, so it cannot be used by arbitrary local tools that speak SOCKS5. Neo-reGeorg's value is that it exposes a standard proxy interface, which means your existing tooling works without modification. If you only need to run a handful of commands on the host, a reverse shell is simpler and faster. If you need to reach other hosts from that position, the proxy is the point.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-08-14, so it is close to current. The release history is uneven rather than fast: v5.2.0 in January 2024, v5.2.1 in February 2025, and v5.3.0 in January 2026. That cadence suggests a project that ships when something meaningful changes, not one that churns. Upgrading means replacing both sides: the client script and the uploaded server file are generated from the same version, and the README does not document compatibility between a v5.2 client and a v5.3 server file. Regenerate and re-upload rather than assuming they interoperate.

The licence is GPL-3.0, which is a copyleft licence. If you redistribute Neo-reGeorg or a modified version, the GPL's obligations attach to that distribution. Internal use during an engagement is a different question, and the repository does not discuss it. This is not legal advice; if redistribution is part of your plan, read the LICENSE file at the repository root and get proper advice.

Editorial conclusion

Neo-reGeorg is for security researchers and penetration testers working in authorised engagements who need a SOCKS5 foothold through a web server and want the traffic shaped so it does not look like a raw tunnel. It is not for anyone who needs a stable, high-throughput proxy, and it is not for use on infrastructure you have no written permission to test. Before adopting it, verify three things: that your target language is one of the generated server files (aspx, ashx, jsp, jspx, php, go), that the Python client's dependencies install cleanly (requests is required, curl-cffi and requests_ntlm are optional), and that the defaults for --read-buff and --max-threads suit the link you are tunnelling over.

Frequently asked questions

Official sources

1. Issues
2. L-codes/Neo-reGeorg on GitHub
3. License: GPL-3.0
4. README
5. Releases