It’s Monday morning, and as you slide in to your desk chair preparing for your first Zoom call of the day, you get the worst news known to IT departments everywhere – you’ve been the victim of a cyber-attack. Once you’ve stopped the active incident, one of the next vital considerations is the motivations of the attackers. To non-IT folks, this might seem beside the point, but as most security professionals know, getting to the bottom of why and how you were targeted is essential to fix the problem.
A Targeted Attack
Targeted attacks are rightly considered to be one of the largest threats facing any organization. Such attacks can cost billions of dollars and cause sufficient damage to a company’s reputation. The reason that these attacks are so damaging is that they are not “smash-and-grab” operations, conducted for immediate gain. Truly targeted campaigns are carefully thought out, take place on a variety of fronts and are almost always after some form of closely held data whether its customer/patient data or intellectual property. Examples of these sophisticated attacks include a hack of Twitter in July, which was attributed to a concerted spear phishing attack and a data breach at Marriot in which hackers using employee’s credentials got away with 5.2 million hotel guest records. As a sign of the times, Zoom became victim of a breach in April, with over half a million Zoom user credentials offered for sale including those of financial institutions, banks, and colleges.
These targeted attacks are the result of a carefully and patiently coordinated plan. Methods might include highly concentrated phishing campaigns, social engineering, malware, or any combination of methodology. Even though these hacks make the news and do huge damage, because of the sophistication and effort required to pull targeted attacks such as these, they are not actually all that common.
A Target of Opportunity
While every cyber-attack feels targeted, particularly to those who must handle the problem, the fact is that most incursions are targets of opportunity rather than intent. Hackers are not willing to spend the level of money or time required to break into an organization if they can find an easier entrance to exploit. Luckily enough (for the bad guys), such a simple method exists in the form of bot-driven reconnaissance. These bots perform site scanning and probing to gather information about web apps and underlying infrastructure that can later be used to launch a focused attack. Bot recon is like an old hacking method called war-driving that was popular back when wireless networking was first becoming a valid method for connectivity. Hackers would drive around looking for an unsecured Wi-Fi signal that could be used to capture data entered. Bot recon is even easier – plus you don’t need to put miles on your car.
Bots are used to scan a site and determine variables that include the type of server operating system in use, details on the infrastructure and information about the applications being used, including server types and content management systems. That information can then be matched to known vulnerabilities, which can then be exploited. This is a particularly rich hunting ground, given the growing complexity of today’s applications. As apps have evolved from monolithic, linear services to microservices which can be housed in many locations including containers or sidecars, attack surfaces have grown to include application programming interfaces (APIs) that connect different elements and content management systems (CMSs) that enable them. And to make hacking even easier, many of these vital tools are based on open source code.
Now all these elements are protected in a perfect world in which every vulnerability is patched as soon as it is announced. Collection of vulnerability information is handled by Cybersecurity Vulnerabilities and Exposure (CVE), sponsored by the U.S. Department of Homeland Security (DHS) and the Cybersecurity and Infrastructure Security Agency (CISA). Information gathered in CVEs is designed to function like a dictionary to share data across different categories, including tools, databases and services that can be used to identify and fix issues as they are reported. Each CVE entry has an ID number, a description, and a public reference. Sounds easy enough…until you consider that there have been over 10,000 vulnerabilities announced in the first half of 2020 alone. Hackers can probe for unpatched vulnerabilities, then plan exploits (which can also be automated) based upon what they find because they have access to the CVEs as well. While this does pose some risk, Mitre, the corporate that manages and maintains the CVE list, notes that the vulnerabilities that are published are already public1. That said, it bears observing that Web applications were involved in 43% of breaches seen in Verizon’s 2020 Data Breach Investigations Report (DBIR)2.
A Cascading Target
Another type of attack can be thought of as a vertical cascade. This type of attack often starts opportunistically when a particular vulnerability is discovered during recon. Further analysis can show the hacker that this vulnerability also exists in other organizations within the same vertical industry as the target company. This has been an especially fruitful endeavor in 2020, a year that has seen many companies forced to jump into the digital world to stay afloat. Many firms, particularly those in the mid-market, have had to create or grow their e-commerce capabilities quickly and have done so using things like content management systems to make their website more dynamic. It is not uncommon to find that as one company uses a tool successfully it is adopted by competitors, resulting in vertical dominance by specific vendors. While there are many positives to this use case, including saving time and money while increasing competitiveness, there are downsides, too. Keeping up with vulnerability patching is an arduous and growing process for large enterprise; for smaller players, it can be overwhelming. And for the opportunistic hacker, finding that a lucrative industry segment is likely to have utilized a particular element with a probably unpatched vulnerability can be a bonanza.
How to Keep the Bullseye Off Your Back
As we’ve noted, most attacks are opportunistic in one way or another. As infrastructure becomes increasingly complex, now involving internet of things technologies, as well as, elements that could reside in the public or private cloud – not to mention microservices with containers and sidecars – keeping track of assets is a huge issue. How, then, can companies keep themselves competitive and safe?
One of the first things that any organization should try to do is to ensure that there is an awareness of what is being used to power applications. It is vital to ensure that you know the details of the APIs and CMSs that are in use. The proliferation of these elements may greatly increase your productivity, but they do the same thing for your attack surface.
A way to keep track of the pieces and parts that comprise your applications today is to ensure that you have a modern, API-capable Web Application Firewall (WAF) in front of them. In addition to providing app basics, including protections against things like the OWASP Top Ten, it is essential that your WAF have some way to “learn.” These newly emerging environments develop and change constantly, and WAF must have a way to roll with the punches.
And speaking of punches, let’s talk about patches. One of the most overwhelming parts of a comprehensive API/CMS inventory is considering the difficulty of keeping all the patches up to date. Luckily, a WAF can help you there too. Many WAFs include the ability to do virtual patching, described on OWASP’s site as a “security enforcement layer analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the web application3. ” Virtual patching does not imply that the underlying code itself has been changed; rather an addition layer of security is placed over the vulnerable application to keep attacks on it from being successful. You could think of it as an application “band aid.” Naturally in a world where we all had unlimited time and budget, the “right” way to handle a vulnerability would be to fix it at the source, but as we all know, that’s not where we work. The fact is that there are times where patches may not be available or changing code might just be too expensive. The code may be old or outsourced, and the original source may simply not be available. Regardless of the reasons, we know that this happens, and virtual patching is an excellent way around the immediate issue.
Finally, try to keep up with exploits in your industry. As we noted earlier, hackers are opportunistic. If they discover that a particular piece of exploitable code has been widely adopted throughout an industry, a logical next move is to see if it has been picked up by others in the same field. In this case, the sooner you can deploy a virtual patch, the sooner that hackers will look elsewhere. Keep your WAF running, your ear to the ground, and your eyes open. This strategy will enable you to use rapidly evolving code, improve your bottom line, and ensure security at the same time.
1. Source
2. Verizon’s 2020 Data Breach Investigations Report (DBIR)
3. Source
