A Targeted Vendor Risk Assessment Exposes Vulnerabilities

What If an Organization Has Never Had a Pen Test Preformed? Ask a Penetration Tester Live

A security vendor risk assessment identifies critical risks inside your organization. Currently, standard security programs lack the diversity needed to see all possible vulnerabilities.

“One thing a person cannot do, no matter how rigorous his analysis or heroic his imagination, is to draw up a list of things that would never occur to him.”

Thomas Schelling, Nobel Laureate

This is one of our favorite quotes when applied to security. It perfectly explains one of the biggest risks to an organization’s security plan – that you cannot prepare for things you don’t think of. After the hours of thought and consideration that go into any security program – and additionally checking the box for all the compliance requirements, best practices, and controls you must test for – imagine asking yourself, “What gaps exist in our organization that will never occur to me?”. It’s impossible to determine this. That’s why a comprehensive security risk assessment is essential.

Consider a car. While you tightened the bolts, it may have never occurred to you that the belt was cracked. If you did consider the belt, you might very well overlook the seals. If you did account for the seals, you likely failed to notice the exhaust leak. That’s the nature of security. While it is not possible to account for all gaps, it is possible to understand the systems that allow them to exist and build better systems. For this to be possible, another set of eyes are essential.

Even then, it takes more than just new eyes to see what you have been missing – it takes a team of individuals with different experiences, viewpoints, creative mindsets, motivations, and freedom from organizational bias.

An A La Carte Targeted Vendor Risk Assessment Doesn’t Work

An experienced team of hackers with a criminal mindset can raise the bar for your organization’s security which goes far beyond compliance-based security vendor risk assessments and automated scans. Lately, the trend appears to be moving towards in-house testing, paying for “pentest-as-a-service,” and satisfying compliance-based testing requirements with cheap and minimal effort. All of this goes against the mindfulness necessary for optimal security-based decisions that will have drastic consequences in the future for organizational reputation and financial loss..

Yes, penetration testing, a targeted vendor risk assessment, and automation can have a place in a well-structured security program. However, at the end of the day, the real threat actors have something all these other solutions are missing – creativity. These solutions might protect you from threats right now, but how about tomorrow when a new tactic is emerging? Are your organization’s security program and infrastructure agile enough to be ahead of the curve? Does your organization have the holistic view necessary to remain vigilant to tomorrow’s threats? Experience battling real threats with novel attack patterns is the only way to formulate a complete holistic understanding of an organization’s real security gaps.

Re-read the quote, and challenge yourself to write out a list of potential security threats and avenues of attack that will never occur to you, your teams, or your organization.

If you give it careful thought, you should have an empty list. So, how can you fill it out? By getting a penetration test or red team that is performed by a group of real hackers. Not just any hacker, but hackers that cultivate the creative, criminal mindset. Those who want to help your organization put all the other security activities, recommendations, and so-called “best practices” into context and navigate beyond them.

Why You Need a Targeted Vendor Risk Assessment

Security Threats are Not Just Theoretical, They Happened – They’re Happening Now

The purpose of this blog series is to demonstrate examples from actual engagements performed by VerSprite’s offensive security team (also known as OffSec) that proved the real value of contracting criminally-minded hackers. These high-level examples exposed issues that, if having gone unnoticed, would have undermined the security efforts being made by the affected organization. Threat actors can be anyone: insiders engaging in shadow IT, the associate with an ax to grind, a financial or politically motivated outsider, nation-states bent on stealing intellectual property, “script kiddies,” etc.

Who would you rather find and exploit the gaps that haven’t occurred to you – them or us? You must choose because, at some point, the gaps will be discovered, and you should have a choice in who finds them.

Many of the tactics we share can and will be copied, and you are free to consider them in your security program. But, keep in mind that there are hundreds more that go unshared for every tactic we share. Each engagement is unique, and every tactic considers the business interests of the client we are targeting. There should not be a one-size-fits-all model for security testing because every client is different. What we share are the gaps that never occurred to our clients. Because they hired our offensive security team, they became aware of their gaps. Like them, it is in your organization’s interest to consult with a group of real hackers to find your gaps.

The Difference Between Vulnerability Assessments, Penetration Testing, and Red Teaming

An offensive security risk assessment can incorporate all three in some fashion. Still, there can be clear delineations to better understand the spectrum that exists among the assessment types.

Vulnerability Assessment

In its purest form, a vulnerability assessment is merely looking for as many vulnerabilities as possible. This examination is typically done on the surface level and is most often done by running an automated scanning tool. In general, this covers breadth but not depth. While this is great for identifying outdated components with known vulnerabilities, there is no “reading between the lines” on the analysis to identify flaws in logic that a human attacker can identify and abuse.

Vulnerability assessments are usually very quick to turn around a report, often around a week’s timeframe. A vulnerability assessment often does not include an exploitation and post-exploitation phase to demonstrate the findings’ real impact. Instead, results are typically validated to discard false positives.

Penetration Test

A penetration test is a human-directed and goal-oriented security vendor risk assessment of a target application or organization’s infrastructure. Goals are achieved by going below the surface level understanding the target’s business objectives and exposing weaknesses in critical infrastructure. These assessments are often very limited in scope. The timeframe is defined so those goals can be achieved, given the complexity of the target. Two to three weeks is a typical turnaround time for testing but can often go four weeks or longer for large and complex assessments.

The goals of a penetration test go beyond merely finding vulnerabilities. A penetration test is not designed to find every vulnerability but instead, identify systemic and critical issues that derail an application or organization from achieving its intended goals. This security risk assessment generally focuses on the depth of coverage but can incorporate some breadth.

Red Team Exercise

Red team exercise is a long-term, team-based, and goal-oriented security risk assessment intended to challenge an organization’s security program’s effectiveness. In most cases, the scope is unlimited, allowing for uncountable attack vectors, certainly more than you can possibly imagine. A red team starts with defined goals, such as gaining access to business-critical data and deriving objectives to achieve those goals. The goals are typically defined by the target organization that hires the red team, such as gaining access to customer data, proprietary source code, or physical access to the data center. The red team then begins defining a series of objectives to achieve those goals, which often occurs after a threat modeling session.

Consider the following example: One of the goals an organization sets may be to gain physical access to the corporate headquarters. The team will then set objectives such as tailgating, cloning a badge, or planting a rogue device. The organization might also set a goal of gaining access to customer data through external attacks. In this case, the red team may define objectives like locating servers with legacy Java applications, performing source code analysis on these applications, achieving remote code execution on a server, and pivoting to internal databases that contain business-critical data.

This type of assessment focuses almost exclusively on the depth of coverage since its breadth would distract from the goals.

A Deeper Dive into the Different Targeted Security Vendor Risk Assessments

While both penetration tests and red teams are goal-oriented, red team goals are typically more broadly defined. Hence, the post-exploitation phase is significant in the red team methodology to accomplish the organization’s agreed-upon goals. With post-exploitation, the red team’s real impact on discovering and highlighting the missing gaps in a security program is recognized.

Lines often get blurred among the three types of security vendor risk assessment types. For example:

• A vulnerability assessment can incorporate aspects of penetration testing to validate findings and assess risk through exploitation.
• A penetration test can include elements of a vulnerability assessment to complement testing efforts and be used for a breadth of coverage.
• A red team can have the scope limited to a degree or restrictions placed upon specific tactics like stating that social engineering and physical attacks are out of scope.

Regardless of where a security assessment lies on the spectrum, it is essential to clarify what value is desired. It is also important to realize that the value gained from any security assessment will be limited by the scope and rules of engagement. For example, by not assessing the internal network or restricting social engineering to a shortlist of targets, your organization will have blind spots that only a malicious attacker will discover.

We argue in favor of full-scope red teams with clear goals aligned with the business objectives that are important to each enterprise. There is value in any security risk assessment. However, only red teams will simulate real-life attackers’ motivations and attack patterns and push the boundaries beyond what is thought to be possible. Several security blind spots can exist that are likely to go unnoticed until they are discovered, either by us or the determined and unequivocal threat actor.

Next, we’ll detail a high-level set of vulnerabilities and exploits that we have uncovered in our quest to be one step ahead of criminals. These were organizational security blind spots that our clients were previously completely unaware of despite working diligently to be “on top of things.”

Network Attacks – Password Spraying and Failed MFA

This is one of the most commonly attacked areas that are under-secured and a great reason for a security risk assessment. Password spraying refers to the attack method that takes several usernames and loops them with a single password. Typically, users choose passwords that are easy to remember. Some of these will fit into patterns that are easy to rotate when password-aging rules apply. Many of these patterns that users choose are well-known. Below are some of these common patterns that we have found over and over again:

• $Season$Year[!] (e.g. Summer20, Fall2020, or Winter20!)
• $Month$Year[!] (e.g. July20, August2020, or September20!)
• $Company$Year[!] (e.g. VerSprite20, VerSprite2020, or VerSprite20!)

We have a script that generates all of the most probable patterns. In most cases, we find at least one employee using a password that follows predictable patterns. Once we find them, we can authenticate as an employee to external services like Office 365, a corporate VPN, or Salesforce. The attack is relatively straightforward: generate a list of valid accounts and attempt to login to each using the same password.We have a script that generates all of the most probable patterns. In most cases, we find at least one employee using a password that follows predictable patterns. Once we find them, we can authenticate as an employee to external services like Office 365, a corporate VPN, or Salesforce.

Poor passwords used by employees are a great risk to organizations. A security risk assessment can recognize this.

In this particular case, we found working credentials that did not require multi-factor authentication (MFA), which permitted us access to the corporate VPN.

However, things aren’t always this simple. If MFA is enabled, the login attempt might be blocked at first.

If we try to log in to their Office 365 account, we run into messages like this:

This is just a minor inconvenience to an attacker. For any given login approval prompt on their phone, employees may tap “Approve” regardless if they did not try to log in themselves. Often this is because they believe it was just their Outlook client logging back in. This thinking is especially true of non-technical employees that simply want to get through the day and get their job done with as few headaches as possible.

However, if this notification is missed, a much bolder tactic for an attacker exists: click “Sign in another way” and request Microsoft to call the phone on file.

This is often very effective. We have yet to have employees report this as suspicious behavior. The good news is that we raised awareness for the company and the employees about this trick, and they will do much better in the future.

In one case on a separate red team, we found that MFA was enabled, but we were permitted to enter our own phone number.

And sure enough, we were then able to authenticate to the employee’s account and go from there.

Mitigating and defending against password spraying attacks require a combination of multiple defense strategies:

• Reduction in overall attack surface
• A strong password policy
• Compensating controls such as multi-factor authentication, anti-automation protections, and monitoring

A reasonable password policy can be derived from the following general rules:

• Passwords must have a minimum length of 12 characters with no maximum length
• Passwords can contain any characters (including spaces and Unicode)
• Passwords are not within a database of known leaked or common passwords
• Users can supplement their passwords with 2-factor authentication methods such as Google Authentication or Universal Second Factor

These are general guidelines, and they would block the common culprits like “Winter2020” or “October20!”. Still, some users will likely always make new patterns like Winter2020!! or October20!!! To satisfy the password requirements. That is why it is essential to implement multi-factor authentication and assess gaps in its implementation. Detection tools should be implanted to identify password-spraying attacks as they occur and to alert defenders before an attacker can get far. Where possible, anti-automation tools should be used to obstruct automated attacks. Above all, a targeted vendor risk assessment is crucial.

Security Risks of Forgotten Web Servers and Enterprise Admin

During one security vendor risk assessment, we found a massive external network footprint on a full-scope network penetration test for a Fortune 1,000 company. They were in the process of taking an inventory of their external attack surface. They asked if we could assist them by finding critical assets from a security perspective by simulating motivated threat actors. We spent a grueling 3-week period on intelligence gathering, asset discovery, and attacking every domain, IP address, and server they owned. We could not find a straightforward way in. We did uncover several vulnerabilities, but none of them could get us far, including several SQL injections that turned up nothing.

It was when we thought we ran out of options that a particular web application caught our attention. It appeared to be a broken application that once supported document upload functionalities, but it no longer worked. When we probed further, attempts to use the upload functionality were met with errors that indicated that someone deleted a file necessary to make uploads work.

We worked with manual efforts and found the original upload script was not deleted but moved to another folder. This folder could only be discovered by fuzzing the server directories with a custom dictionary. It was not clear what parameters were expected of this upload script. Still, after some more fuzzing, we were able to determine some of the required parameters. A quick Google search for these parameters, followed by the terms “PHP upload script,” yielded what we were looking for. We uploaded a php info page followed by a p0wny web shell to gain access to the server:

From here, we were able to scan the internal network. We expected to be placed within a DMZ that had no access to the internal corporate network. But we were wrong. We found that someone had made a mistake with VLAN segregation rules, and this server had access to the entire corporate network! For example, we could enumerate and connect to RDP servers in other networks:

After that, we were able to gain root access to the web server, scrape SSH keys and login credentials, and pivot to enterprise admin:

From here, we were able to complete all the goals and objectives, including locating and gaining access to business-critical data. Suffice it to say, that we helped save this client from massive headaches and financial loss that could have resulted from a breach that mimicked this attack.

The lessons here are clear – inventory all assets, take legacy and “forgotten” systems offline, and regularly audit network firewall rules and VLAN segmentation policies. Even if this is done, it is essential to have another set of eyes to audit and test those assumptions.

Check out our other articles in this series:

Blind Spots in Security Awareness Training Programs
Preventing Physical Security Attacks Against Your Business
Risk-Based Security Assessments Expose Vulnerabilities

Get a Personalized VerSprite Targeted Vendor Risk Assessment

VerSprite’s Offensive Security team focuses on emulating cybercrime and simulating test scenarios that not only reflect current attack patterns, but also threat motives. Our team can perform vendor risk assessments such as penetration testing, vulnerability assessments, red teaming exercises, and custom organizational threat models. 

Contact Our Security Advisors To Learn More About Risk-Based Defense→