Log4Shell Still Being Exploited to Hack VMWare Servers to Exfiltrate Sensitive Data

 

Description

The U.S. Cybersecurity and Infrastructure Security Agency (CISA), along with the Coast Guard Cyber Command (CGCYBER), on Thursday released a joint advisory warning of continued attempts on the part of threat actors to exploit the Log4Shell flaw in VMware Horizon servers to breach target networks.

“Since December 2021, multiple threat actor groups have exploited Log4Shell on unpatched, public-facing VMware Horizon and [Unified Access Gateway] servers,” the agencies said. “As part of this exploitation, suspected APT actors implanted loader malware on compromised systems with embedded executables enabling remote command-and-control (C2).”

In one instance, the adversary is said to have been able to move laterally inside the victim network, obtain access to a disaster recovery network, and collect and exfiltrate sensitive law enforcement data.

Log4Shell, tracked as CVE-2021-44228 (CVSS score: 10.0), is a remote code execution vulnerability affecting the Apache Log4j logging library that’s used by a wide range of consumers and enterprise services, websites, applications, and other products.

Successful exploitation of the flaw could enable an attacker to send a specially-crafted command to an affected system, enabling the actors to execute malicious code and seize control of the target.

Based on information gathered as part of two incident response engagements, the agencies said that the attackers weaponized the exploit to drop rogue payloads, including PowerShell scripts and a remote access tool dubbed “hmsvc.exe” that’s equipped with capabilities to log keystrokes and deploy additional malware.

“The malware can function as a C2 tunneling proxy, allowing a remote operator to pivot to other systems and move further into a network,” the agencies noted, adding it also offers a “graphical user interface (GUI) access over a target Windows system’s desktop.”

The PowerShell scripts, observed in the production environment of a second organization, facilitated lateral movement, enabling the APT actors to implant loader malware containing executables that include the ability to remotely monitor a system’s desktop, gain reverse shell access, exfiltrate data, and upload and execute next-stage binaries.

Furthermore, the adversarial collective leveraged CVE-2022-22954, a remote code execution vulnerability in VMware Workspace ONE Access and Identity Manager that came to light in April 2022, to deliver the Dingo J-spy web shell.

Ongoing Log4Shell-related activity even after more than six months suggests that the flaw is of high interest to attackers, including state-sponsored advanced persistent threat (APT) actors, who have opportunistically targeted unpatched servers to gain an initial foothold for follow-on activity.

According to cybersecurity company ExtraHop, Log4j vulnerabilities have been subjected to relentless scanning attempts, with financial and healthcare sectors emerging as an outsized market for potential attacks.

“Log4j is here to stay, we will see attackers leveraging it again and again,” IBM-owned Randori said in an April 2022 report. “Log4j buried deep into layers and layers of shared third-party code, leading us to the conclusion that we’ll see instances of the Log4j vulnerability being exploited in services used by organizations that use a lot of open source.”

Read More

Malicious Cyber Actors Continue to Exploit Log4Shell in VMware Horizon Systems

 

Description

CISA and the United States Coast Guard Cyber Command (CGCYBER) have released a joint Cybersecurity Advisory (CSA) to warn network defenders that cyber threat actors, including state-sponsored advanced persistent threat (APT) actors, have continued to exploit CVE-2021-44228 (Log4Shell) in VMware Horizon® and Unified Access Gateway (UAG) servers to obtain initial access to organizations that did not apply available patches. The CSA provides information—including tactics, techniques, and procedures and indicators of compromise—derived from two related incident response engagements and malware analysis of samples discovered on the victims’ networks.

CISA and CGCYBER encourage users and administrators to update all affected VMware Horizon and UAG systems to the latest versions. If updates or workarounds were not promptly applied following VMware’s release of updates for Log4Shell, treat all affected VMware systems as compromised. See joint CSA Malicious Cyber Actors Continue to Exploit Log4Shell in VMware Horizon Systems for more information and additional recommendations.

This product is provided subject to this Notification and this Privacy & Use policy.

Please share your thoughts.

Read More

Atlassian Confluence Flaw Being Used to Deploy Ransomware and Crypto Miners

 

Description

A recently patched critical security flaw in Atlassian Confluence Server and Data Center products is being actively weaponized in real-world attacks to drop cryptocurrency miners and ransomware payloads.

In at least two of the Windows-related incidents observed by cybersecurity vendor Sophos, adversaries exploited the vulnerability to deliver Cerber ransomware and a crypto miner called z0miner on victim networks.

The bug (CVE-2022-26134, CVSS score: 9.8), which was patched by Atlassian on June 3, 2022, enables an unauthenticated actor to inject malicious code that paves the way of remote code execution (RCE) on affected installations of the collaboration suite. All supported versions of Confluence Server and Data Center are affected.

Other notable malware pushed as part of disparate instances of attack activity include Mirai and Kinsing bot variants, a rogue package called pwnkit, and Cobalt Strike by way of a web shell deployed after gaining an initial foothold into the compromised system.

“The vulnerability, CVE-2022-26134, allows an attacker to spawn a remotely-accessible shell, in-memory, without writing anything to the server’s local storage,” Andrew Brandt, principal security researcher at Sophos, said.

The disclosure overlaps with similar warnings from Microsoft, which revealed last week that “multiple adversaries and nation-state actors, including DEV-0401 and DEV-0234, are taking advantage of the Atlassian Confluence RCE vulnerability CVE-2022-26134.”

DEV-0401, described by Microsoft as a “China-based lone wolf turned LockBit 2.0 affiliate,” has also been previously linked to ransomware deployments targeting internet-facing systems running VMWare Horizon (Log4Shell), Confluence (CVE-2021-26084), and on-premises Exchange servers (ProxyShell).

The development is emblematic of an ongoing trend where threat actors are increasingly capitalizing on newly disclosed critical vulnerabilities rather than exploiting publicly known, dated software flaws across a broad spectrum of targets.

Read More

CVE-2022-33915

 

Description

Versions of the Amazon AWS Apache Log4j hotpatch package before log4j-cve-2021-44228-hotpatch-1.3.5 are affected by a race condition that could lead to a local privilege escalation. This Hotpatch package is not a replacement for updating to a log4j version that mitigates CVE-2021-44228 or CVE-2021-45046; it provides a temporary mitigation to CVE-2021-44228 by hotpatching the local Java virtual machines. To do so, it iterates through all running Java processes, performs several checks, and executes the Java virtual machine with the same permissions and capabilities as the running process to load the hotpatch. A local user could cause the hotpatch script to execute a binary with elevated privileges by running a custom java process that performs exec() of an SUID binary after the hotpatch has observed the process path and before it has observed its effective user ID.

Read More

Difference Between Agent-Based and Network-Based Internal Vulnerability Scanning

 

Description

For years, the two most popular methods for internal scanning: agent-based and network-based were considered to be about equal in value, each bringing its own strengths to bear. However, with remote working now the norm in most if not all workplaces, it feels a lot more like agent-based scanning is a must, while network-based scanning is an optional extra.

This article will go in-depth on the strengths and weaknesses of each approach, but let’s wind it back a second for those who aren’t sure why they should even do internal scanning in the first place.

Why should you perform internal vulnerability scanning?

While external vulnerability scanning can give a great overview of what you look like to a hacker, the information that can be gleaned without access to your systems can be limited. Some serious vulnerabilities can be discovered at this stage, so it’s a must for many organizations, but that’s not where hackers stop.

Techniques like phishing, targeted malware, and watering-hole attacks all contribute to the risk that even if your externally facing systems are secure, you may still be compromised by a cyber-criminal. Furthermore, an externally facing system that looks secure from a black-box perspective may have severe vulnerabilities that would be revealed by a deeper inspection of the system and software being run.

This is the gap that internal vulnerability scanning fills. Protecting the inside like you protect the outside provides a second layer of defence, making your organization significantly more resilient to a breach. For this reason, it’s also seen as a must for many organizations.

If you’re reading this article, though, you are probably already aware of the value internal scanning can bring but you’re not sure which type is right for your business. This guide will help you in your search.

The different types of internal scanner

Generally, when it comes to identifying and fixing vulnerabilities on your internal network, there are two competing (but not mutually exclusive) approaches: network-based internal vulnerability scanning and agent-based internal vulnerability scanning. Let’s go through each one.

Network-based scanning explained

Network-based internal vulnerability scanning is the more traditional approach, running internal network scans on a box known as a scanning ‘appliance’ that sits on your infrastructure (or, more recently, on a Virtual Machine in your internal cloud).

Agent-based scanning explained

Agent-based internal vulnerability scanning is considered the more modern approach, running ‘agents’ on your devices that report back to a central server.

While “authenticated scanning” allows network-based scans to gather similar levels of information to an agent-based scan, there are still benefits and drawbacks to each approach.

Implementing this badly can cause headaches for years to come. So for organizations looking to implement internal vulnerability scans for the first time, here’s some helpful insight.

Which internal scanner is better for your business?

Coverage

It almost goes without saying, but agents can’t be installed on everything.

Devices like printers; routers and switches; and any other specialized hardware you may have on your network, such as HP Integrated Lights-Out, which is common to many large organizations who manage their own servers, may not have an operating system that’s supported by an agent. However, they will have an IP address, which means you can scan them via a network-based scanner.

This is a double-edged sword in disguise, though. Yes, you are scanning everything, which immediately sounds better. But how much value do those extra results to your breach prevention efforts bring? Those printers and HP iLO devices may infrequently have vulnerabilities, and only some of these may be serious. They may assist an attacker who is already inside your network, but will they help one break into your network to begin with? Probably not.

Meanwhile, will the noise that gets added to your results in the way of additional SSL cipher warnings, self-signed certificates, and the extra management overheads of including them to the whole process be worthwhile?

Clearly, the desirable answer over time is yes, you would want to scan these assets; defence in depth is a core concept in cyber security. But security is equally never about the perfect scenario. Some organizations don’t have the same resources that others do, and have to make effective decisions based on their team size and budgets available. Trying to go from scanning nothing to scanning everything could easily overwhelm a security team trying to implement internal scanning for the first time, not to mention the engineering departments responsible for the remediation effort.

Overall, it makes sense to consider the benefits of scanning everything vs. the workload it might entail deciding whether it’s right for your organization or, more importantly, right for your organization at this point in time.

Looking at it from a different angle, yes, network-based scans can scan everything on your network, but what about what’s not on your network?

Some company laptops get handed out and then rarely make it back into the office, especially in organizations with heavy field sales or consultancy operations. Or what about companies for whom remote working is the norm rather than the exception? Network-based scans won’t see it if it’s not on the network, but with agent-based vulnerability scanning, you can include assets in monitoring even when they are offsite.

So if you’re not using agent-based scanning, you might well be gifting the attacker the one weak link they need to get inside your corporate network: an un-patched laptop that might browse a malicious website or open a malicious attachment. Certainly more useful to an attacker than a printer running a service with a weak SSL cipher.

The winner: Agent-based scanning, because it will allow you broader coverage and include assets not on your network – key while the world adjusts to a hybrid of office and remote working.

If you’re looking for an agent-based scanner to try, Intruder uses an industry-leading scanning engine that’s used by banks and governments all over the world. With over 67,000 local checks available for historic vulnerabilities, and new ones being added on a regular basis, you can be confident of its coverage. You can try Intruder’s internal vulnerability scanner for free by visiting their website.

Attribution

On fixed-IP networks such as an internal server or external-facing environments, identifying where to apply fixes for vulnerabilities on a particular IP address is relatively straightforward.

In environments where IP addresses are assigned dynamically, though (usually, end-user environments are configured like this to support laptops, desktops, and other devices), this can become a problem. This also leads to inconsistencies between monthly reports and makes it difficult to track metrics in the remediation process.

Reporting is a key component of most vulnerability management programs, and senior stakeholders will want you to demonstrate that vulnerabilities are being managed effectively.

Imagine taking a report to your CISO, or IT Director, showing that you have an asset intermittently appearing on your network with a critical weakness. One month it’s there, the next it’s gone, then it’s back again…

In dynamic environments like this, using agents that are each uniquely tied to a single asset makes it simpler to measure, track and report on effective remediation activity without the ground shifting beneath your feet.

The winner: Agent-based scanning, because it will allow for more effective measurement and reporting of your remediation efforts.

Discovery

Depending on how archaic or extensive your environments are or what gets brought to the table by a new acquisition, your visibility of what’s actually in your network in the first place may be very good or very poor.

One key advantage to network-based vulnerability scanning is that you can discover assets you didn’t know you had. Not to be overlooked, asset management is a precursor to effective vulnerability management. You can’t secure it if you don’t know you have it!

Similar to the discussion around coverage, though, if you’re willing to discover assets on your network, you must also be willing to commit resources to investigate what they are, and tracking down their owners. This can lead to ownership tennis where nobody is willing to take responsibility for the asset, and require a lot of follow-up activity from the security team. Again it simply comes down to priorities. Yes, it needs to be done, but the scanning is the easy bit; you need to ask yourself if you’re also ready for the follow-up.

The winner: Network-based scanning, but only if you have the time and resources to manage what is uncovered!

Deployment

Depending on your environment, the effort of implementation and ongoing management for properly authenticated network-based scans will be greater than that of an agent-based scan. However, this heavily depends on how many operating systems you have vs. how complex your network architecture is.

Simple Windows networks allow for the easy rollout of agents through Group Policy installs. Similarly, a well-managed server environment shouldn’t pose too much of a challenge.

The difficulties of installing agents occur where there’s a great variety of operating systems under management, as this will require a heavily tailored rollout process. Modifications to provisioning procedures will also need to be taken into account to ensure that new assets are deployed with the agents already installed or quickly get installed after being brought online. Modern server orchestration technologies like Puppet, Chef, and Ansible can really help here.

Deploying network-based appliances on the other hand requires analysis of network visibility, i.e. from “this” position in the network, can we “see” everything else in the network, so the scanner can scan everything?

It sounds simple enough, but as with many things in technology, it’s often harder in practice than it is on paper, especially when dealing with legacy networks or those resulting from merger activity. For example, high numbers of VLANs will equate to high amounts of configuration work on the scanner.

For this reason, designing a network-based scanning architecture relies on accurate network documentation and understanding, which is often a challenge, even for well-resourced organizations. Sometimes, errors in understanding up-front can lead to an implementation that doesn’t match up to reality and requires subsequent “patches” and the addition of further appliances. The end result can often be that it’s just as difficult to maintain patchwork despite original estimations seeming simple and cost-effective.

The winner: It depends on your environment and the infrastructure team’s availability.

Maintenance

Due to the situation explained in the previous section, practical considerations often mean you end up with multiple scanners on the network in a variety of physical or logical positions. This means that when new assets are provisioned or changes are made to the network, you have to make decisions on which scanner will be responsible and make changes to that scanner. This can place an extra burden on an otherwise busy security team. As a rule of thumb, complexity, wherever not necessary, should be avoided.

Sometimes, for these same reasons, appliances need to be located in places where physical maintenance is troublesome. This could be either a data center or a local office or branch. Scanner not responding today? Suddenly the SecOps team is picking straws for who has to roll up their sleeves and visit the datacenter.

Also, as any new VLANs are rolled out, or firewall and routing changes alter the layout of the network, scanning appliances need to be kept in sync with any changes made.

The winner: Agent-based scanners are much easier to maintain once installed.

Concurrency and scalability

While the concept of sticking a box on your network and running everything from a central point can sound alluringly simple, if you are so lucky to have such a simple network (many aren’t), there are still some very real practicalities to consider around how that scales.

Take, for example, the recent vulnerability Log4shell, which impacted Log4j - a logging tool used by millions of computers worldwide. With such wide exposure, it’s safe to say almost every security team faced a scramble to determine whether they were affected or not.

Even with the ideal scenario of having one centralized scanning appliance, the reality is this box cannot concurrently scan a huge number of machines. It may run a number of threads, but realistically processing power and network-level limitations means you could be waiting a number of hours before it comes back with the full picture (or, in some cases, a lot longer).

Agent-based vulnerability scanning, on the other hand, spreads the load to individual machines, meaning there’s less of a bottleneck on the network, and results can be gained much more quickly.

There’s also the reality that your network infrastructure may be ground to a halt by concurrently scanning all of your assets across the network. For this reason, some network engineering teams limit scanning windows to after-hours when laptops are at home and desktops are turned off. Test environments may even be powered down to save resources.

Intruder automatically scans your internal systems as soon as new vulnerabilities are released, allowing you to discover and eliminate security holes in your most exposed systems promptly and effectively.

The winner: Agent-based scanning can overcome common problems that are not always obvious in advance, while relying on network scanning alone can lead to major gaps in coverage.

Summary

With the adoption of any new system or approach, it pays to do things incrementally and get the basics right before moving on to the next challenge. This is a view that the NCSC, the UK’s leading authority on cyber security, shares as it frequently publishes guidance around getting the basics right.

This is because, broadly speaking, having the basic 20% of defences implemented effectively will stop 80% of the attackers out there. In contrast, advancing into 80% of the available defences but implementing them badly will likely mean you struggle to keep out the classic kid-in-bedroom scenario we’ve seen too much of in recent years.

For those organizations on an information security journey, looking to roll out vulnerability scanning solutions, here are some further recommendations:

Step 1 — Ensure you have your perimeter scanning sorted with a continuous and proactive approach. Your perimeter is exposed to the internet 24/7, and so there’s no excuse for organizations who fail to respond quickly to critical vulnerabilities here.

Step 2 — Next, focus on your user environment. The second most trivial route into your network will be a phishing email or drive-by download that infects a user workstation, as this requires no physical access to any of your locations. With remote work being the new norm, you need to be able to have a watch over all laptops and devices, wherever they may be. From the discussion above, it’s fairly clear that agents have the upper hand in this department.

Step 3 — Your internal servers, switches and other infrastructure will be the third line of defence, and this is where internal network appliance-based scans can make a difference. Internal vulnerabilities like this can help attackers elevate their privileges and move around inside your network, but it won’t be how they get in, so it makes sense to focus here last.

Hopefully, this article casts some light on what is never a trivial decision and can cause lasting pain points for organizations with ill-fitting implementations. There are pros and cons, as always, no one-size-fits-all, and plenty of rabbit holes to avoid. But, by considering the above scenarios, you should be able to get a feel for what is right for your organization.

Read More

Potent Emotet Variant Spreads Via Stolen Email Credentials

 

Description

Emotet’s resurgence in April seems to be the signal of a full comeback for what was once dubbed “the most dangerous malware in the world,” with researchers spotting various new malicious phishing campaigns using hijacked emails to spread new variants of the malware.

The “new and improved” version of Emotet is exhibiting a “troubling” behavior of effectively collecting and using stolen credentials, “which are then being weaponized to further distribute the Emotet binaries,” Charles Everette from Deep Instinct revealed in a blog post this week, citing research from HP Wolf Security’s latest threat insights blog.

“[Emotet] still utilizes many of the same attack vectors it has exploited in the past,” he wrote. “The issue is that these attacks are getting more sophisticated and are bypassing today’s standard security tools for detecting and filtering out these types of attacks.”

In April, Emotet malware attacks returned after a 10-month “spring break” with targeted phishing attacks linked to the threat actor known as TA542, which since 2014 has leveraged the Emotet malware with great success, according to a report by Proofpoint.

These attacks—which were being leveraged to deliver ransomware—came on the back of attacks in February and March hitting victims in Japan using hijacked email threads and then “using those accounts as a launch point to trick victims into enabling macros of attached malicious office documents,” Deep Instinct’s Everette wrote.

“Looking at the new threats coming from Emotet in 2022 we can see that there has been an almost 900 percent increase in the use of Microsoft Excel macros compared to what we observed in Q4 2021,” he wrote.

Emotet Rides Again

The attacks that followed in April targeted new regions beyond Japan and also demonstrated other characteristics signaling a ramp-up in activity and rise in sophistication of Emotet, Deep Instinct noted.

Emotet, like other threat groups, continues to leverage a more than 20-year-old Office bug that was patched in 2017, CVE-2017-11882, with nearly 20 percent of the samples that researchers observed exploiting this flaw. The Microsoft Office Memory corruption vulnerability allows an attacker to perform arbitrary code execution.

Nine percent of the new Emotet threats observed were never seen before, and 14 percent of the recent emails spreading the malware bypassed at least one email gateway security scanner before it was captured, according to Deep Instinct.

Emotet still primarily uses phishing campaigns with malicious attachments as its transportation of choice, with 45 percent of the malware detect using some type of Office attachment, according to Deep Instinct. Of these attachments, 33 percent were spreadsheets, 29 percent were executables and scripts, 22 percent were archives and 11 percent were documents.

Other notable changes to Emotet’s latest incarnation is its use of 64-bit shell code, as well as more advanced PowerShell and active scripts in attacks, according to Deep Instinct.

History of a Pervasive Threat

Emotet started its nefarious activity as a banking trojan in 2014, with its operators having the dubious honor of being one of the first criminal groups to provide malware-as-a-service (MaaS), Deep Instinct noted.

The trojan evolved over time to become a full-service threat-delivery mechanism, with the ability to install a collection of malware on victim machines, including information stealers, email harvesters, self-propagation mechanisms and ransomware. Indeed, Trickbot and the Ryuk and Conti ransomware groups have been habitual partners of Emotet, with the latter using the malware to gain initial entry onto targeted systems.

Emotet appeared to be put out of commission by an international law-enforcement collaborative takedown of a network of hundreds of botnet servers supporting the system in January 2021. But as often happens with cybercriminal groups, its operators have since regrouped and seem to be working once again at full power, researchers said.

In fact, in November 2021 when Emotet emerged again nearly a year after it went dark, it was on the back of its collaborator Trickbot. A team of researchers from Cryptolaemus, G DATA and AdvIntel separately observed the trojan launching a new loader for Emotet, signaling its return to the threat landscape.

Read More

3 Takeaways From the 2022 Verizon Data Breach Investigations Report

 

Description

Sometimes, data surprises you. When it does, it can force you to rethink your assumptions and second-guess the way you look at the world. But other times, data can reaffirm your assumptions, giving you hard proof they’re the right ones — and providing increased motivation to act decisively based on that outlook.

The 2022 edition of Verizon’s Data Breach Investigations Report (DBIR), which looks at data from cybersecurity incidents that occurred in 2021, is a perfect example of this latter scenario. This year’s DBIR rings many of the same bells that have been resounding in the ears of security pros worldwide for the past 12 to 18 months — particularly, the threat of ransomware and the increasing relevance of complex supply chain attacks.

Here are our three big takeaways from the 2022 DBIR, and why we think they should have defenders doubling down on the big cybersecurity priorities of the current moment.

1. Ransomware’s rise is reaffirmed

In 2021, it was hard to find a cybersecurity headline that didn’t somehow pertain to ransomware. It impacted some 80% of businesses last year and threatened some of the institutions most critical to our society, from primary and secondary schools to hospitals.

This year’s DBIR confirms that ransomware is the critical threat that security pros and laypeople alike believe it to be. Ransomware-related breaches increased by 13% in 2021, the study found — that’s a greater increase than we saw in the past 5 years combined. In fact, nearly 50% of all system intrusion incidents — i.e., those involving a series of steps by which attackers infiltrate a company’s network or other systems — involved ransomware last year.

While the threat has massively increased, the top methods of ransomware delivery remain the ones we’re all familiar with: desktop sharing software, which accounted for 40% of incidents, and email at 35%, according to Verizon’s data. The growing ransomware threat may seem overwhelming, but the most important steps organizations can take to prevent these attacks remain the fundamentals: educating end users on how to spot phishing attempts and maintain security best practices, and equipping infosec teams with the tools needed to detect and respond to suspicious activity.

2. Attackers are eyeing the supply chain

In 2021 and 2022, we’ve been using the term “supply chain” more than we ever thought we would. COVID-induced disruptions in the flow of commodities and goods caused lumber to skyrocket and automakers to run short on microchips.

But security pros have had a slightly different sense of the term on their minds: the software supply chain. Breaches from Kaseya to SolarWinds — not to mention the Log4j vulnerability — reminded us all that vendors’ systems are just as likely a vector of attack as our own.

Unfortunately, Verizon’s Data Breach Investigations Report indicates these incidents are not isolated events — the software supply chain is, in fact, a major avenue of exploitation by attackers. In fact, 62% of cyberattacks that follow the system intrusion pattern began with the threat actors exploiting vulnerabilities in a partner’s systems, the study found.

Put another way: If you were targeted with a system intrusion attack last year, it was almost twice as likely that it began on a partner’s network than on your own.

While supply chain attacks still account for just under 10% of overall cybersecurity incidents, according to the Verizon data, the study authors point out that this vector continues to account for a considerable slice of all incidents each year. That means it’s critical for companies to keep an eye on both their own and their vendors’ security posture. This could include:

• Demanding visibility into the components behind software vendors’ applications
• Staying consistent with regular patching updates
• Acting quickly to remediate and emergency-patch when the next major vulnerability that could affect high numbers of web applications rears its head

3. Mind the app

Between Log4Shell and Spring4Shell, the past 6 months have jolted developers and security pros alike to the realization that their web apps might contain vulnerable code. This proliferation of new avenues of exploitation is particularly concerning given just how commonly attackers target web apps.

Compromising a web application was far and away the top cyberattack vector in 2021, accounting for roughly 70% of security incidents, according to Verizon’s latest DBIR. Meanwhile, web servers themselves were the most commonly exploited asset type — they were involved in nearly 60% of documented breaches.

More than 80% of attacks targeting web apps involved the use of stolen credentials, emphasizing the importance of user awareness and strong authentication protocols at the endpoint level. That said, 30% of basic web application attacks did involve some form of exploited vulnerability — a percentage that should be cause for concern.

“While this 30% may not seem like an extremely high number, the targeting of mail servers using exploits has increased dramatically since last year, when it accounted for only 3% of the breaches,” the authors of the Verizon DBIR wrote.

That means vulnerability exploits accounted for a 10 times greater proportion of web application attacks in 2021 than they did in 2022, reinforcing the importance of being able to quickly and efficiently test your applications for the most common types of vulnerabilities that hackers take advantage of.

Stay the course

For those who’ve been tuned into the current cybersecurity landscape, the key themes of the 2022 Verizon DBIR will likely feel familiar — and with so many major breaches and vulnerabilities that claimed the industry’s attention in 2021, it would be surprising if there were any major curveballs we missed. But the key takeaways from the DBIR remain as critical as ever: Ransomware is a top-priority threat, software supply chains need greater security controls, and web applications remain a key attack vector.

If your go-forward cybersecurity plan reflects these trends, that means you’re on the right track. Now is the time to stick to that plan and ensure you have tools and tactics in place that let you focus on the alerts and vulnerabilities that matter most.

Additional reading:

• A Year on from the Ransomware Task Force Report
• Are You in the 2.5% Who Meet This Cybersecurity Job Requirement?
• What’s Changed for Cybersecurity in Banking and Finance: New Study
• How to Strategically Scale Vendor Management and Supply Chain Security

NEVER MISS A BLOG

Read More