How many of the vulnerabilities from your last penetration test report did you risk accept? Everything with a Medium severity or lower? This article is intended to help you reconsider that mindset.
Be careful about disregarding penetration testing findings just because they are not High or Critical severities by themselves. Companies are breached every day when an attacker strings together Informational, Low, and Medium level vulnerabilities.
Here is an example attack using Info to Medium level vulnerabilities we find in many of our clients’ environments while testing:
- None: Collect a list of employee names from LinkedIn
- If you’re a law firm or educational institution, you have probably posted all of these on your website – which likely even includes email addresses.
- Info: Determine domain username convention in document metadata you have posted on your website
- As a bonus, that same metadata will likely provide versions of the software you are running, hardware in your environment, location information (ex. in picture EXIF data), etc.
- Info: Realize your domain username format is easily determined by knowing (or guessing) your employees’ names
- You may have made it even easier by using the same as the local part of the email (before the “@”).
- Assuming the username contains a person’s name, then the attacker could just use a list of common names.
- None: Generate a list of possible usernames and/or email addresses
- Med: Exploit user enumeration vulnerabilities in your external services to curate the username list
- ~95% of your external services are vulnerable, in our experience.
- If you use Microsoft O365/Azure services, then your external services are near guaranteed to be vulnerable to the attack – Microsoft has risk-accepted this attack on your behalf.
- Med: Your users are likely being forced to change their password periodically/arbitrarily
- Your users’ passwords will be VERY predictable because of this.
- It won’t stop the account takeover.
- Your 90-day rotation policy is worse than useless, it’s going to be your downfall.
- Low: Find an external service where Multi-Factor Authentication (MFA) fails to kick in until after the password is confirmed
- 99.9% of services are vulnerable to this attack.
- If you don’t see how dangerous this is, keep reading.
- Med: Lockout a few accounts over time to narrow in on your lockout policy
- HTTP response time is almost always different for locked accounts, but most of your services are going to be friendly enough to literally tell when it happens.
- The attacker could go ahead and lock out all of your accounts (from external) and continue to do so until your users are impacted so badly that you have to shut down all of your external services – but (s)he will do that later if they need to retaliate.
- Your MFA fails to protect against this, even though it should.
- Med: Password spray against an external service just slow enough to prevent lockout
- The attacker could rotate their IP per request, if needed, but most of your systems won’t identify this attack anyway.
- Your MFA fails to protect against this, even though it should.
- Med: Bypass MFA
- For new accounts or otherwise a partial adoption rate, the attacker could potentially just add their own MFA, or…
- Send a push – about 20% of users will accept out of habit/muscle memory.
- Find a service not forcing MFA – there’s always at least one.
- [a dozen more ways here]
- None: Gain remote access to a workstation as a standard user
- Then again, the attacker may pop an IT admin with a weak password – these always make for awkward debrief calls.
- Med: Privilege escalate to at least local admin
- Keylogger to catch IT admin creds, creds in local or net share files (ex. SYSVOL scripts), LLMNR, internal phish, [thousand more ways here]
- Note: Your penetration tester is going to try to convince you this is at least a High severity finding, but you’re going to counter with the fact you need inside access first and list other mitigating controls/reasons why it’s not that serious of a threat.
- Med: Laterally move to sensitive systems
- Use privileged account(s) from the previous step, or a number of other ways.
- No doubt your internal firewalls are going to allow a random workstation to reach other workstations and all of your servers.
- Worst case, the attacker will pivot to another system first that has the needed access – modern printers have a lot of capability, often have default creds, and can be reached by any endpoint.
- Low: Export your most sensitive data and stage it on an internal system
- Often enough, this could be found by just crawling open network shares – no admin creds needed.
- Low: If needed, zip the payload, change the first 2 bytes to “$$”
- That will fool most of those pricy DLP solutions.
- Low: Exfil it for the win
- You’re not going to notice the huge outbound data transfer.
- And, even if you do notice, the data is gone by that point.
- None: Change the first two bytes back from “$$” to “PK”
- Extract, screenshot, demand millions
As can be seen, none of these would typically rise to the level of high or critical by themselves. However, when an attacker strings them together and uses them in conjunction with one another, a breach is very likely. If you were to mitigate any one of these, you have the potential to stop the breach of your systems.
If you are only concerned about script kiddies, then only worry about Highs and Criticals (i.e. isolated vulns, single-shot exploits). If you want to stop an attacker, do not ignore anything in the penetration test report – not even the info-level findings. If a reputable firm listed something in a penetration test report, it means it was valuable to them in their attacks. If it is in your control, do not risk-accept what is valuable to an attacker.
If you are curious how your network would perform against this and other attacks, but do not have the expertise or resources to do so, contact PEN Consultants today!
Featured image is a derivative work from the following images: GDJ @ https://pixabay.com/vectors/see-no-evil-hear-no-evil-7717203/