One tool that bad guys use to go after your web servers is a web shell. A web shell is a malicious script that masquerades as a legitimate file and provides a backdoor into your server. Recent guidance from the US National Security Agency (NSA) and the Australian Signals Directorate (ASD) offers techniques to detect and prevent web shell malware from affecting web servers. The NSA document describes web shell malware as a long-standing, pervasive threat that continues to evade many security tools.
Detection may be difficult. Web shells target existing applications and files. Because they mimic proper files on your system, it’s often difficult to determine that an attack has occurred. Here’s how to best detect and prevent web shell attacks on a Windows network.
1. Compare files
Begin by comparing the files on the machine to known good files. Compare date and time stamps and especially SHA-2 hash values. You can also use Windiff to compare to files to determine if the attacker has replaced them with similar ones.
2. Review web traffic
Review web traffic for unusual traffic patterns. Make sure that you have enabled logging on your Internet Information Services (IIS) web server. You might want to enable both IIS logging and Event Tracing for Windows (ETW). Decide if you plan to export these log files to an external location and how long you plan to keep these logs.
3. Match time stamps
Match the time stamps on the systems to be appropriate for your needs. At one time, the recommendation was to set the time zone of the web servers to match the time zone of the physical location of the server. This would allow you to match up events given that physical servers and firewalls were typically in the same datacenter.
Now with the 24/7 world we live in, many people are moving to Coordinated Universal Time (UTC) so they can match up with network logging world-wide. Given that technology likely runs through various cloud properties, having your entire network on the same time zone may allow you to better investigate events and determine relationships.
4. Review for anomalies
Use a PowerShell script to review for anomalies. Signature-based detection can be done as well with tools like Snort, but this is often difficult as determined attackers will change how they process network traffic to make their activities harder to detect.
5. Patch web applications
Attackers often target web applications because of the tendency to delay patching highly trafficked servers. SharePoint, Exchange, Citrix and even WordPress deployments on Windows servers are often targeted as entries into the network. Ensure those responsible for patching are fully aware of all software installed on your servers and especially note any management software or remote access software that could introduce attack points. Review external databases of public exploits and prioritize patching accordingly.
6. Use a zero-trust model
Network segregation is recommended but may be complex to do. If you can, try to implement a zero trust model, which focuses on the following concepts:
- An identity provider keeps track of users and user-related information.
- A device directory maintains a list of devices that have access to corporate resources, along with their corresponding device information (e.g., type of device, integrity).
- A policy evaluation service determines if a user or device conforms to the policy set forth by security admins.
- An access proxy uses the above signals to grant or deny access to an organizational resource.
Zero trust ensures that employees still have access to all needed resources but is more reliant on tracking identity than the traditional security and permissions model typically used for on-premises networks. As you transition to this model, don’t allow web applications to write to a web accessible directory. If you are unable to do this, then implement file integrity monitoring.
7. Use an IPS and WAF
Intrusion prevention is also key to preventing web shell attacks. Intrusion prevention systems (IPSs) and web application firewalls (WAFs) each add a layer of defense for web applications by blocking some known attacks. SQL injections for example, are often one way that attackers use techniques that present specific patterns to gain access to the web server.
8. Adhere to a least privilege, least access policy
When setting up web servers, always think in terms of least privilege and least access. Restrict port access to the least amount of ports needed for activity as possible. It’s no more acceptable to leave the standard SQL port open to the internal network. Now, think in terms of how the attacker can access and attack from both inside and outside the network.
9. Use Sysmon
Finally, if you haven’t already done so, install Microsoft’s Sysmon. Sysmon logs information about how each process is created. This information is valuable for identifying the kind of anomalous behavior a malicious web shell generates. Install the tool and then port the resulting logs to a security information and event management (SIEM) tool. You might consider using Microsoft Sentinel to be a repository for your Sysmon logs.
Finally, don’t forget to view this and other security-themed videos on the IDG Techtalk page.