Cybersecurity Blog
Thought leadership. Threat analysis. Cybersecurity news and alerts.
Web Shell Malware Facilitates Cybercriminals' Access to Victims’ Networks, New Report ShowsA recent report from the national security agencies in Australia and the US showed that cybercriminals are increasingly using web shell malware to access victims’ networks. In a joint advisory, Australia’s national security agency, the Australian Signals Directorate (ASD), and its counterpart in the US, the National Security Agency (NSA) said that cybercriminals have increased the use of web shell malware for computer network exploitation. "Web shell malware can facilitate cyber attackers' access to a network where they are able to execute arbitrary system commands, enumerate system information, steal data, install additional malicious software or use the infected server to pivot further into the network," the ASD said in a separate statement. The NSA, meanwhile, said in a separate statement, “Malicious cyber actors have increasingly leveraged web shells to gain or maintain access on victim networks.” What Is Web Shell Malware?Web shell malware is a type of malicious software that’s deployed by an attacker on a compromised web server – referring to a software to which web browsers connect to run web applications. A web application, meanwhile, refers to a set of code written to perform certain action or actions on a web server and display the result to a web browser. An example of a web shell malware is China Chopper, a malware that allows attackers to execute various commands on the server, including dropping other malware. First found in the wild in 2012, this web shell malware uses a simple and short code that can be deployed on the target web server by simply typing it with no file transfer needed. Due to the malware’s simple code and ease of use, security researchers have difficulty in connecting this malware to any particular threat actor or group. Preventive and Mitigating Measures Against Web Shell Malware?The national security agencies in Australia and the US recommend the following preventive and mitigating measures against web shell malware: 1. Web Application UpdateWeb shell malware is often created by making changes to a file in a legitimate web application. Attackers are able to make malicious changes to legitimate web applications due to the failure of the users’ to apply in timely manner patches to known security vulnerabilities in web applications. According to the national security agencies in Australia and the US, web application updates need to be prioritized as attackers sometimes target vulnerabilities in internet-facing and internal web applications within 24 hours of a patch release. 2. Early Detection MethodsWeb shell malware is hard to detect using typical detection methods as malware creators hide their creation using encryption and obfuscation. “Known-Good” comparison and monitoring anomalous network traffic are some of the suggested measures. In known-good comparison, a verified version of a web application is compared to your organization’s on-hand version of the web application. Discrepancies between the verified version and the on-hand version need to be manually reviewed. Depending on the attacker, any of the following could be indicators of anomalous network traffic resulting from web shell malware: unusually large responses (an indicator of data exfiltration), recurring off-peak access times typically during non-working hours, and request from unlikely geographical location (an indicator of a foreign threat actor). 3. Harden Web Application PermissionsAccording to the national security agencies in Australia and the US, web applications shouldn’t have permission to write directly to a web accessible directory or modify web accessible code. The national security agencies said that malicious actors are unable to upload a web shell to a vulnerable web application if the web server blocks access to the web accessible directory. In February of this year, Microsoft reported that attackers uploaded a web shell in multiple folders on the web server owned by an organization in the public sector. "DART’s [Microsoft’s Detection and Response Team] investigation showed that the attackers uploaded a web shell in multiple folders on the web server, leading to the subsequent compromise of service accounts and domain admin accounts,” Microsoft said. “This allowed the attackers to perform reconnaissance using net.exe, scan for additional target systems using nbtstat.exe, and eventually move laterally using PsExec.” 4. Use Intrusion PreventionThe use of Web Application Firewall (WAF) adds an extra layer of defence for web applications by blocking some known attacks. Attackers, however, have been known to evade this signature-based blocking, as such, this approach should only be part of the whole cybersecurity measures. WAF has also been known to block the initial compromise but is unlikely to detect web shell traffic. 5. Network SegmentationNetwork segmentation refers to the practice of dividing a network into sub-networks. This practice ensures that in case a particular sub-network is compromised by attackers, the other sub-networks won’t be affected. For instance, it’s important to put in place in one sub-network internet-facing servers. The practice of network segmentation blocks web shell propagation by preventing connections to other sub-networks. “While web shells could still affect a targeted server, network segmentation prevents attackers from chaining web shells to reach deeper into an organization’s network,” the national security agencies in Australia and the US said. 6. Harden Web ServersSecuring the configuration of your organization’s web servers can prevent the deployment of web shell malware. As additional measures to harden web servers, the national security agencies in Australia and the US recommend that access to unused ports or services should be blocked, and routine vulnerability scanning should be conducted to identify unknown weaknesses in an environment. Your comment will be posted after it is approved.
Leave a Reply. |
AuthorSteve E. Driz, I.S.P., ITCP Archives
November 2024
Categories
All
|
4/28/2020
0 Comments