The threat landscape is constantly evolving, but often, it’s the same old tricks that pay off. In the past several months, we’ve been seeing a preponderance of webshell attacks. In fact, a good portion of the attacks my research team has seen this year has had some kind of shell component to it.
Why is this important to note? Well, for one thing, it’s that such attacks are getting harder to detect. That takes a savvy defense team to protect their organization from this growing threat.
The rise of webshells
In a webshell attack, a cybercriminal injects a malicious file into a target web server’s directory and then executes that file from their web browser. This isn’t a new type of attack; it’s been around for a while. Consequently, you would think security pros would be good at detecting them by now, but there are just so many different ways of executing webshells. They can be in memory, residing on disk, tunneled within DNS, and encrypted within other protocols. In addition, attackers are now using webshells with new techniques that can execute webshells’ payloads hidden through cloud management applications on AWS, Azure, and other systems. This makes it difficult to detect, since it is coupled with legitimate applications and functions. There are so many ways to hide and manipulate a webshell attack that it’s very difficult for people to detect.
These types of attacks can be pulled off in a few different ways. Phishing attacks are one common tactic. Some are coming through Microsoft Exchange attacks or other vulnerabilities and configurations in Office 365 in Exchange; others originate within on-prem exchange servers that haven’t been fully patched.
One prominent recent example: the Lazarus cybercrime group has been linked to a recent series of such incidents. The nation-state-backed group targets Windows IIS servers to install webshells.
The challenges of detection
These attacks are harder to detect because attackers can easily change the way a webshell looks on the system. It can be done in seconds, and within each connection. No two connections look alike. What happens today is that an attacker is at work, but the system isn’t connecting back to a hacker using one port as in the past. It’s always rotating against the protocols (such as HTTPS, DNS) and different ports. The system itself looks like it’s just browsing different websites. It’s hard for even a SOC or defenders to see that because they just see systems browsing websites.
In reality, though, an attacker is writing that channel on the backend. Attackers are also very good at covering their tracks by manipulating log and DNS traffic, making forensic analysis on these types of attacks very difficult.
More importantly, it’s not just about establishing connections. Once bad actors have a webshell, they can attempt to access the compromised host. The next step is they’ll run additional attack tools such as remote access trojans (RATs), exfiltrate data, and many times run and execute ransomware.
Many times, once they’ve exploited one system, they’ll start looking for other vulnerable systems or systems they can exploit within an organization. Large organizations have difficulty monitoring logs of websites and domains that the users of an organization are connecting to, because a larger enterprise might have thousands, if not tens of thousands, of websites that they go to every year. Attacks that connect back to command-and-control systems can easily blend in and be missed by anyone not carefully verifying these logs.
Taking a proactive approach to patching
As mentioned above, one of the major trends we’re seeing in terms of how webshell attacks are being executed is through Exchange attacks, through vulnerabilities and configurations in Office 365 in Exchange and within on-prem Exchange servers. Some of the most active webshell malicious attacks are taking advantage of unpatched vulnerable Exchange/OWA environments.
This underscores just how important patching is, even though it can be a difficult thing for security teams to truly do efficiently. Nonetheless, it’s one of the most important things that can be done to safeguard your organizations. Regularly patching vulnerabilities is key to shrinking the attack surface.
Attackers understand and know organizations that large organizations fail at patching at scale quickly when vulnerabilities are disclosed and use that to their advantage in attacking organizations. You may be asking yourself is patching a critical vulnerability really that difficult?
If you have five systems, it’s not so difficult to stay updated on patching, but if you have 10,000 systems across different states or in different countries, it’s difficult to support a patching program without testing. So, Microsoft may come out with a patch, but you may not be able to patch it for a month, six months or a year, depending on your organization. Also, a certain percentage of patches fail.
When there are many patches that need attention, it can be hard to prioritize. Looking to the Exploit Prediction Scoring System, or EPSS, can help prioritize patching efforts.
The EPSS draws on a variety of data sources to predict the chances of a vulnerability being exploited in the wild. Vulnerability management teams use it to organize and prioritize their work. However, EPSS can also aid intelligence efforts to monitor the development of vulnerabilities from their original disclosure to the start of a wild exploitation.
Fortinet’s latest Global Threat Landscape Report found that in comparison to other vulnerabilities, the most exploitable vulnerabilities (according to EPSS) are 327 times more likely to be exploited within one week than others on your list. EPSS data can function well as an early warning system if it is included in your threat intelligence process.
Prioritize and persevere
Criminals use whatever works, whether it’s old or new. Webshell attacks are still effective and hard to detect, which helps explain the uptick in this attack type. Patching is still difficult for large enterprises, but prioritizing your patching process will help your organization prevent the major vulnerabilities from becoming a significant issue within your network.
