Basic Web Application Attacks
Please provide the information below to view the online Verizon Data Breach Investigations Report.
Thank you.
You will soon receive an email with a link to confirm your access, or follow the link below.
Thank you.
You may now close this message and continue to your article.
- 2024
- Summary of Findings
- Introduction
- Helpful Guidance
- Results and Analysis - Introduction
- Incident Classification - Introduction
- Incident Classification - System Intrusion
- Incident Classification - Social Engineering
- Incident Classification - Basic Web Application Attacks
- Incident Classification - Miscellaneous Errors
- Incident Classification - Denial of Service
- Incident Classification - Lost and Stolen Assets
- Incident Classification - Privilege Misuse
- Industries - Introduction
- Introduction to Regions
- Wrap Up
- Appendix
- Corrections
- Download the full report (PDF)
Summary
Threat actors continue to take advantage of assets with default, simplistic and easily guessable credentials via brute forcing them, buying them or reusing them from previous breaches.
What is the same?
Financially motivated external actors continue to target credentials and personal information.
Frequency |
1,997 incidents, 881 with confirmed data disclosure |
|
Threat actors |
External (100%), Internal (1%), Multiple (1%) (breaches) |
|
Actor motives |
Financial (85%), Espionage (15%) (breaches) |
|
Data compromised |
Credentials (71%), Personal (58%), Other (29%), Internal (17%) (breaches) |
What if we were to tell you there is perhaps no pattern that is as complex, multifaceted and, quite frankly, riveting to read about as the Basic Web Application Attacks pattern? We’d be pulling your leg, that’s what. This pattern is basically just like it sounds: typically uncomplicated attacks against either unprotected or (more often) poorly protected web applications that grant the criminal a foothold into an organization’s environment. If the System Intrusion pattern can be thought of as a sophisticated bank71 heist,72 this pattern presents us with a good visualization of Occam’s razor in action. It has fewer steps and is possibly the simplest and shortest path from point A to point B. Like many things that are not overly complicated, it works extremely well.
Last year, this type of attack accounted for one-quarter of all breaches. This year, however, our dataset shows just over 8% of breaches in the Basic Web Application Attacks pattern. As is always the case in this pattern, the attacker gains access via hacking by the Use of stolen credentials (77%), Brute force (usually easily guessable passwords) (21%) or the Exploit vuln action (13%) (Figure 41).
Beware devs bearing crypto.
Interestingly, approximately 20% of the malware in this pattern consists of cryptocurrency mining Malware. Upon further inspection, we found a small cluster of Nation-state actors that were leveraging known vulnerabilities and cryptocurrency mining malware (and Ransomware) to make a few extra dollars for their country. Not something particularly revolutionary but always interesting to see tactics that are more than a decade old still hold up.
Like a one-size-fits-all gas station baseball cap (“Keep on Truckin’”), any organization can fit into the Basic Web Application Attacks pattern, but it won’t look too good on you. The Financial and Insurance (18%); Information (14%); and Professional, Scientific and Technical Services (13%) industries make up the top three verticals affected by Basic Web Application Attacks, but we see these attacks in most other industries as well. There is also no substantial difference between large organizations (55%) and small organizations (47%) in the Basic Web Application Attacks pattern.
Attack of the stolen credentials
If you’re a regular reader,73 you may have realized by now that there are a great many incidents in our dataset that leverage stolen credentials. Over the past 10 years, stolen credentials have appeared in almost one-third (31%) of breaches (Figure 42). Ergo, credentials are a core component of compromising organizations. However, while we know this to be a fact, there are a lot of things we don’t know about these credentials: Where do they come from, how did they get here and will we ever know the full story?74
If we are to understand where stolen credentials come from, we must consider the different types of credential attacks that exist. Unsurprisingly, Phishing is the most common credential-related attack that we see in our dataset and accounts for 14% of breaches involving Credentials. Social Engineering is extremely common and remarkably effective because it targets individuals versus systems. It’s much easier to harden a system than it is to harden an individual,75 as our Social Engineering section illustrated. Another basic type of credential attack is Brute force (guessing all the passwords), and while it is an effective tool in the attacker’s arsenal, it appears in only 2% of breaches this year. This technique is most successful when individuals or applications use weak or, even worse, default credentials. A silver lining here is that Brute force attacks have existed as long as there has been a login option, so a multitude of mitigations are commonly available, such as enforcing password complexity (ick) and length (slightly less ick) as well as limiting how quickly and how often logins can be attempted.
No country for old credentials
Credential stuffing is Brute force’s more hip cousin.76 While these attacks have a lot in common, credential stuffing affords the attacker a greater chance of success. That’s because rather than guessing all possible combinations, credential stuffing leverages combinations of usernames/emails and passwords that are already known to exist because they were harvested from previous breaches. Recent high-profile cases have occurred in which attackers leveraged this technique to gain access to highly personal user data.
These types of attacks are more insidious because they spread the attack across various accounts and IP addresses, thus making them more difficult to prevent. If your organization has a high number of customers, especially consumer-facing web applications and application programming interfaces (APIs), you should consider instituting robust protections before attackers use a tool and a free list of proxies to attempt combinations they found in a chat site.
Speaking of APIs, we can examine the prevalence of those types of attacks in sampled detection data from our API firewall data partners in Figure 43. As expected, credential stuffing is the most commonly identified attack, but it is often commingled with Brute force. Another interesting result from this dataset was that the prevalence of credential abuse-like attacks amounted to only 15% of attacks, less than half of what we see in Use of stolen credentials in the incident dataset. This makes sense because there is much more to try to exploit on APIs than just credentials.
But what if you don’t have consumer facing web applications or APIs? What if you already enforce strict password policies, such as a monthly rotation of 24-character passwords? Surely such a fate could not befall you, right? Unfortunately, password stealers can still snatch your data. While we admittedly do not see password dumpers too often in our dataset (2% of breaches), it is important to keep in mind that we can only report on those things into which we have visibility, and this type of Malware likes to reside in places where there’s limited visibility77 (such as personal computers, not work-related ones).
To get an idea of how pervasive this issue might be, we took a look at the marketplaces dedicated to selling and reselling credentials and cookies collected from these password stealers. Our sample was only two days from one market; nevertheless, we found more than a thousand credentials per day being posted for sale with an average price of $10.
After examining these postings, we found that 65% of these credentials were posted for sale less than one day from when they were collected.78 They are often purchased by attackers who leverage them as a beachhead for other attacks, against either individuals or their employers. Oftentimes these product offerings not only list what credentials or cookies are available but also give information regarding the associated region. We wanted to determine whether these credentials are coming from organizationally managed assets or personal computers. On average, more than 30% of postings had no social media credentials listed, which could be an indication that many of the systems aren’t for personal use. Figure 44 shows the percentage of postings by stealer family name without social media accounts listed.
Another source of password stealers are libraries posted on public repositories. For the non-developers of the world, writing code is incredibly tedious, and our “if it’s not easy, I’m not doing it” society has led to people creating libraries that other developers can import simply by saying “pip install library-of-my-choice” or “install.packages (‘library-of-my-choice’)”79 and download the library they find posted. Needless to say, a very real risk with this approach is that you’re taking it on faith that the libraries you’re downloading are free from malware. Human nature being what it is, that is often not the case, and the libraries act as a means of distributing malware. Fortunately, there are numerous companies that actively scan the uploaded libraries to identify possible malware. When malicious packages are found, they often consist of information stealers (shocker).
Of course, simply uploading a package is not enough, it still requires someone to download it.80 Figure 45 captures some of the more popular approaches found in an npm repository.81 The most common type we found in the JavaScript ecosystems were malicious packages that would advertise themselves as free video game currency generators. These target the folks who are clever enough to know how to install and download the code but not sufficiently clever to realize that if it sounds too good to be true, it usually is.82
In addition, there were malicious packages that leveraged typosquatting. This is when the developer of the malware posts the package with a similar name as a popular package in the hopes that someone would accidentally mistype the package name when attempting to install the legitimate package. As a group of authors who collectively would be unemployed if it were not for the existence of spell-check, we can see this being a relatively effective tactic.
Lastly, there were also packages that targeted what we (and a few people smarter than we are) believe are dependency confusion attacks. In these types of attacks, the attackers take advantage of how some tooling checks for packages on public repositories before it checks for private ones. If the attackers know that organizations are using the library “super-cool-internal-library,” which is stored in their internal repository, the attackers can create a library on a public repository called “super-cool-internal-library” and the tooling may check the public repo first before looking at the internal ones. Fortunately, there are various programming best practices that can help mitigate this, alongside all the great companies that are out there helping protect us from these threats.
Take a breather after reading this section; there seem to be a lot of landmines that you have to avoid to help keep your organization safe from credential attacks. This is not new. We (and many others) have said it before: Multifactor authentication (MFA) goes a long way toward mitigating these types of attacks. For that matter, so does not letting your kids use your corporate computer to find ways of making free V-Bucks.83 As with anything else security related, the most effective controls are typically the ones that leverage the human element along with technical resources.
CIS Controls for consideration
Mitigating against stolen credentials Account Management [5] |
Mitigating against vulnerability exploitation Continuous Vulnerability Management [7] |
71 For more bank heist content, please review the Financial vertical in the “Industries” section.
72 We probably shouldn’t mention movies such as “Ocean’s Eleven” or “The Great Train Robbery” or we may need to pay royalties.
73 And we hope you are.
74 Or will it just continue to spice up our daily lives with mystery?
75 The former becomes more secure, while the latter simply becomes jaded.
76 Aviator sunglasses are involved.
77 Not unlike Bigfoot (No DBIR would be complete without at least one Sasquatch reference.)
78 If these creds were doughnuts, the “hot and fresh” sign would still be on.
79 Bet you can’t guess what coding environments the DBIR team uses :p
80 Same as this report: If you got this PDF or printed issue from a friend, please go to verizon.com/dbir and download a copy for yourself. Download early, download often!
81 https://www.npmjs.com/about
82 We’re afraid there are no cheat codes to get money. Microtransactions for live-service games function the other way around.
83 Be sure to read all sections of the report to unlock custom cover skins from our DBIR Battle Pass.