Security on a Budget
Following the completion of all our penetration tests and assessments we take time to review the findings and the deliverable with our customers. During this review, we almost always get asked the following:
Of all the vulnerabilities you identified, which ones would you mitigate first? We're a small team and need to know where our time is best spent.
This is the reality of security... While all organizations want to achieve "perfect" security, the truth is that (for most companies) limiting factors such as budget, human resources, and business needs decrease the likelihood of ever achieving that goal.
So, we did an exercise. We held a working session with all the STACKTITAN security consultants to determine three recommendations we'd make to all customers. These recommendations, subjectively identified from our experience performing thousands of assessments over a 15 year timespan, meet the following requirements:
- Requires no additional (or very minimal) spend on product
- Can be implemented by most organizations using current, internal staff
- Requires minimal time and effort to perform
- Achieves a remarkable improvement on security posture
- Addresses an issue or bad practice that is very common
So, with those requirements in mind, here's what we came up with over a pot of coffee and some heated brainstorming. By the way, we aren't discounting the importance of a comprehensive security program. We believe the most effective operating environment is one that relies on defense-in-depth. We simply tried to identify a few impactful actions that aren't extraordinarily expensive.
1. Perimeter Attack Surface Reduction
TLDR: Reducing the attack surface with stringent access controls is a cost-effective method of protecting against external, Internet-based threat actors.
The What:
Reduce the publicly accessible services, systems, and applications. That is, update access controls (e.g., firewall, web server) to limit the available attack surface to only the minimal resources necessary for the business.
The Why:
Look, we can pick a handful of vulnerabilities we commonly identify on our customer's Internet-facing systems. Oftentimes, these issues are identified in superfluous services or application functionality. Further, some of these services are attractive targets for attackers (e.g., web management portals, Windows services such as RDP and SMB, etc.). While we will always advocate for patching and hardening your systems and software, it can be a difficult and costly practice that requires continual management, updated inventory, etc. Restricting access to or decommissioning these services can be a cheaper alternative that reduces the likelihood of a breach. It's not the perfect solution and may just kick the can down the road, but it's an effective method to controlling your risk exposure from the hostile Internet.
The How:
We recommend, amongst other practices, the following:
- Implement a Default-Deny firewall access control policy
- Review firewall rulesets to identify overly promiscuous or unnecessary rules. After identifying any that are too broad, fix 'em.
- Review your perimeter web applications. Use tools like nmap, aquatone, and gobuster to quickly survey the landscape. Whatchu got out there and is there a reason for it to be there? If not, 86 it!
- Hunt for common management portals (e.g., devices, Java Web Application such as Tomcat, etc.). They're common targets. Restrict access to them. This will be dependent on the product in question but could be as simple as adding rules to an Apache
.htaccess
file. - Pay particular attention to auth. portals that use Active Directory as their identity provider. You'll want to be especially vigilant with these. They're high value targets that commonly lead to network breaches, business email compromise, etc. Oh, and don't just look at web forms. Find those pesky NTLM web authentication endpoints!
2. Legacy and/or Unnecessary Broadcast Traffic
TLDR: Internal networks are very chatty. A lot of this traffic is for legacy support, is unnecessary, and/or can be easily abused to compromise user accounts or workstations. Disabling this traffic will have significant impact on an attacker's ability to compromise the Active Directory environment (users and/or workstations) from within the network.
The What:
Protocols such as LLMNR and NBNS are used as a fallback method to resolve domain names, in the event that DNS fails. Additionally, protocols such as IPv6 and mDNS are generally unnecessary for internal, enterprise networks. These protocols are widely targeted during internal penetration tests due to their susceptibility to poisoning. Disabling these protocols is relatively easy and has a profound positive impact.
The Why:
In our experience, we abuse these legacy protocols on about 80% of our internal penetration tests. It's the most common method through which we gain initial domain credentials and almost always leads to domain escalation and lateral network movement. Fixing these issues will have a significant impact against insider threats and unauthorized internal threat actors.
The How:
We recommend, amongst other practices, the following:
- Update computer policy to
Turn OFF Multicast Name Resolution
- Update Network Connections properties to
Disable NetBIOS over TCP/IP
- Disable IPv6 via GPO
- Set a static proxy value for all browsers in the network
- Disable mDNS, if possible
- Added Bonus: Require SMB signing to prevent relaying
3. Active Directory Password Blacklisting
TLDR: Passwords remain a highly sought after target; credential acquisition is often the first and most important stage in an attack chain. Password length and complexity alone may not be sufficient to protect accounts from compromise. Instead, blacklist common base words and patterns to prevent trivial recovery via online and offline attacks.
The What:
Most organizations enforce a password policy consisting of uppercase, lowercase, numeric, and special characters with a minimum length of 10. A forced password change cadence of 90-days is typical. Guess what? Spring2022!
meets all those requirements. Users like patterns - they're easy to remember - so, they choose Summer2022!
when required to change their password. Easy for them; easy for an attacker. Passwords selected using a simple baseword or a password that was publicly disclosed in a breach greatly increases the likelihood of an attacker guessing a user's password or, in the event that a hash is acquired, cracking it offline. We need better alternatives than length and complexity...
The Why:
One of the first things we try on a pentest is to guess a set of user credentials. One of the first passwords we'll try is of the format SeasonYYYY!
or MonthYYYY!
. We see all sorts of patterns based off company name, sports teams, cities, first names, etc. Restricting users from setting passwords based off certain basewords or words disclosed in password breaches greatly reduces the likelihood of account compromise, and it's fairly cheap!
The How:
We recommend, amongst other practices, the following:
- Implement it using Azure AD Password Protection
- Implement it with bubble gum and duct tape
So, we genuinely had a difficult time narrowing the list to three, given there are so many "what ifs" and business-specific requirements. Here are a few additional on-a-budget wins we highly recommend.
Multi-Factor Auth.
Ok, this might not be cheap or easy, but it needs to be included because of its importance. Protect, at the least, business email portals, VPN portals, and sensitive management portals with MFA.
Increase Password Length
Increasing password length exponentially increases the keyspace and recovery times. Increase the length to further fortify accounts against compromise.
Printer Credentials
Printers are attractive targets. They commonly run with default or guessable passwords. Countless times we've exploited this to retrieve Active Directory credentials and get a foothold on the domain. Just change the administrative password. Problem solved.
Local Admin Controls
Too often, we still encounter local administrator accounts with shared passwords across several hosts. That's bad. It turns it into a pseudo-domain-admin. Implement Microsoft's Local Account Password Solution and disable remote logon for local administrators.
While you're at it, you should review the users with local admin rights in your organization. While it might be a fight, removing these rights and enforcing a "least privilege" policy will limit the opportunity of abuse should their account get compromised.
Active Directory Certificate Services ("ADCS")
Microsoft's PKI is a complex beast. Recently disclosed vulnerabilities make ADCS a prime target for abuse. Harden it. It's a common target that leads to privilege escalation, user impersonation, and persistence.
Enable Conditional Access
Whether you have MFA or not and whether you have strong passwords in place, enabling Conditional Access allows you to provide fine-grained controls over the user access based on a variety of factors. It can reduce the likelihood or impact of account compromise.