Any files created by WebShells will be owned by the application server and have accurate creation/modification times. The access to the webshell will appear in the application server logs. Also child processes will be owned by the application server process. To test this, you can place new files on your webservers and see how long it take to detect them. You can also search for suspicious strings that may indicate the presence of a webshell, such as exec() or shell_exec().
Some webshells may also store data or hidden code in new databases or unexpected tables. A new URI may indicate the presence of a Webshell. pay close attentions to URIs that only have single or a handful of requests from a VPN, Tor, or International IP address. Also a 400 error may indicate that the webshell was called incorrectly. A 500 error indicates that there was an issue with the server. Some Webservers may connect to an unexpected external or internal site.
The behavior of a web shell is dependent on the configuration of the compromised web service. Most webshells ues the HTTP 80/TCP service already hosted on most systems. Webshells can be very difficult to detect if they use the HTTP as they are hidden by the noise of usual web traffic. Webshells may ues string rotations, array segmentaiton, hex encodng, base64 encoding, compression, and whitespace removal to obfuscate their commands. They also encrypt the command input and output using hard-coded pre-shared keys. most web shells are passive and don’t have keep-alives with the C2 infrastructure. Detecting web shells require an updates accurate hardware and software inventory, network logs, and web server logs.
Backlinks
[[Array Segmentation]]
[[Base64 Encodings]]
[[Encryption]]
[[HTTP]]
IP Addresses
[[PHP]]
[[String Rotation]]
Tor
VPN
[[Web Shell]]