Top 20 CIS Critical Security Controls (CSC) Through the Eyes of a Hacker – CSC 16

In this blog series, members of Optiv’s attack and penetration team are covering the top 20 Center for Internet Security (CIS) Critical Security Controls (CSC), showing an attack example and explaining how the control could have prevented the attack from being successful. Please read previous posts covering:

• CSC 1: Inventory of Authorized and Unauthorized Devices
• CSC 2: Inventory of Authorized and Unauthorized Software
• CSC 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
• CSC 4: Continuous Vulnerability Assessment and Remediation
• CSC 5: Controlled Use of Administrative Privileges
• CSC 6: Maintenance, Monitoring, and Analysis of Audit Logs
• CSC 7: Email and Web Browser Protections
• CSC 8: Malware Defenses
• CSC 9: Limitation and Control of Network Ports, Protocols and Services
• CSC 10: Data Recovery Capability
• CSC 11: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
• CSC 12: Boundary Defense
• CSC 13: Data Protection
• CSC 14: Controlled Access Based on the Need to Know
• CSC 15: Wireless Access Control

CSC 16: Account Monitoring and Control

The Control

Actively manage the lifecycle of system and application accounts – their creation, use, dormancy, deletion – in order to minimize opportunities for attackers to leverage them.

The Attack

All too often companies and organizations are breached – not by a sophisticated attack or unknown exploit – but rather a compromised account with a not-so-strong password. An attacker is not going to waste time constructing a sophisticated attack if the same can be accomplished via impersonating a valid user account. How many large scale breaches have occurred due to an inactive account? What happens when a disgruntled employee is terminated from an organization? Is the employee’s account immediately disabled? Who within the organization is responsible for monitoring successful and failed login attempts within an environment? Why were hundreds of employees trying to login to our systems and applications at 3 a.m.? Why is Alice in the marketing department trying to access the finance department’s network share? These are questions that organizations should have answers for, or at least have the tools and processes in place to properly investigate and develop a solution.

As one can imagine, CSC 16 might seem to fit like a puzzle piece with CSC 5 and 14, but in all reality this control, if in place, has pieces and parts that overlap with many other CSC controls.

We begin our attack by gathering potential employee accounts either via metadata, old password dumps or other OSINT related activities. Many organizations allow employees to access company resources from an external presence, in addition to the internal network via a VPN connection. One such goldmine that attackers tend to abuse is Microsoft’s Outlook Web Access (OWA). As shown below, an attacker can perform password spraying of the candidate user accounts in order to identify valid user credentials. 

Figure 1 - Password Spraying Against Microsoft OWA

Based on HTTP status codes and the length of the data returned, an attacker is able to visually distinguish a valid set of credentials. Once these credentials are attained, an attacker is able to login and pillage through the user’s emails (among other attacks) for any information that could lead to additional access of company resources. In this particular case information regarding VPN access and client software is gathered. 

Using this information, the attacker is now able to login via VPN and access the internal network.

Figure 2 - Logged into the Internal Network

At this point, the attacker is sitting on the internal network with a set of working credentials. After a little passive internal network reconnaissance, the credentials could then be used across the network to test whether or not a user has access to a particular system – specifically identifying systems where the user might have administrator type permissions.  The credentials could also be used to attempt access to network shares, query the domain controller for information regarding other users and systems, etc.

Figure 3 - Verbose Output of Identifying Internal Hosts the User May Have Access To

At this point it’s really just a matter of time before privileges are escalated and confidential information is attained. As we have already performed multiple activities in this scenario that could be identified with account monitoring and control, let us address the solution. 

The Solution

As we are nearing the end of this blog post series, I want to stress that CSC controls need to be implemented in a defense-in-depth approach. CSC 16 – as you’re probably thinking to yourself – covers many different areas within an environment. However, with a combination of enforcing policy, proactive data/user analysis (many of which can be automated) and some general “house-keeping,” account monitoring and control doesn’t seem like such a daunting task.

In the attack above, proper account monitoring could have minimized the success of the attack. First, multiple user accounts were utilized in a password spraying attack. These accounts were authenticating against the domain. Therefore, there would be success/failure event codes within the security event logs. Additionally, more in-depth proactive analysis could have detected the attack against the OWA application (i.e. 1000’s of user accounts attempting to login during a short timespan). Correlating a user’s normal activity to what was identified could have helped minimize this attack scenario. For example, did these OWA login attempts all occur at 4 a.m.? Would this particular user ever access the VPN during business hours if the employee is at their desk plugged into the network? 

Takeaways:

• Make sure all accounts are associated with an active user or service account.
• Immediately disable an employee’s access upon termination.
• Monitor user activity, both their typical daily usage, as well as audit success and failed login attempts for systems they don’t normally access.
• Implement multi-factor authentication wherever possible.
• Enforce strong and complex password policies.

Additionally, consider implementing a privileged access management solution. Many of these solutions can help with a lot of the items that fall within CSC 16. Much of this can also be accomplished with in-house built tools.

Remember user accounts are a “key” into an organization. And last but not least, ensure your pentesters are removing any “accounts” that may have been introduced into your environment.

The next post will cover CSC 17: Security Skills Assessment and Appropriate Training to Fill Gaps.