Web Shell & Application Persistence

You have achieved code execution on a web server during an authorized penetration test. Evaluate persistence through the web application layer.

**Web Shell Types**
- What is the difference between a simple command web shell, a feature-rich shell (like b374k), and a callback shell?
- What file extensions are interpreted by common web servers? (.php, .aspx, .jsp, .cfm)
- How do you obfuscate a PHP web shell to avoid signature detection?

**Placement Strategy**
- Where should a web shell be placed to maximize persistence and minimize detection?
- How do you mimic legitimate file names, timestamps, and permissions?
- What is the risk of placing a shell in a version-controlled directory vs outside the web root?

**Callback & C2 From Web Shells**
- How do you upgrade from a web shell to a reverse shell?
- What firewall bypass techniques work for outbound connections from a web server?
- How do you use a web shell to stage additional tools without writing to disk?

**Application-Layer Backdoors**
- How can you backdoor a PHP application's authentication function to accept a master password?
- How do you add a route to a web framework (Laravel, Django, Express) that provides backdoor access?
- How can a cron job at the application level maintain persistence if the web shell is removed?

**Detection & Removal**
- What tools do defenders use to find web shells?
- How do content integrity checks work and how do you survive them?
- What artifacts does a web shell leave in access and error logs?

Output:
- Web shell placement decision matrix
- Simple obfuscated PHP shell template
- Persistence survival checklist