Dangers of Local Windows Administrator Rights

One of the questions that has come up, and it always does, is the question – how bad is it if users have local administrator rights?


Obviously the easiest answer is BAD, REALLY BAD! It’s like you buy a house or a car and then decide that you don’t need locks on any of the doors. The reason we have file permissions, registry permissions, user right assignments, and the like in Windows is to limit ourselves to only having the rights we need on a system that are necessary in order for us to do our jobs. We shouldn’t have any more or any less rights than are necessary. But when we give our end users administrator rights, it is like we’ve just taken all the locks off the doors and given those users the ability to go into any room of the house without our permission.


Ok, so beyond the simple answer, what else could happen on a machine if we allow users to be local administrators of their machines? Here are just a few of the things that could happen:
System files can be accessed or changed.
Program files or program configurations could be modified.
Software that is not approved could be installed, and won’t be maintained.
Malicious code can be installed with unlimited rights.
New, unapproved user accounts could be added to the system.
Password policies could be subverted.
Security controls such as anti-malware, firewalls, removable media controls, could be disabled.


And as you can imagine, the list goes on and on…


One other fun issue to consider is the issue of passwords. Many people have heard of the pass the hash attack where an attacker steals the local password hash from a machine and then replays it into the system’s memory whenever they want to authenticate as that user. This attack is certainly possible when users have local administrator rights. But wouldn’t it be easier if the user could just steal passwords out of memory in clear text instead? Well it turns out that’s possible too. Enter Mimikatz.


For a nice long, technical explanation of how Mimikatz works, there are plenty of nice tutorials (although to be fair many of them are in French). But here’s the bottom line, if your users are local administrators on their Windows machine, then they will by default have the user right assignment of “Debug Programs” (or they can assign themselves this right if it is taken away by a security policy). Once they have this right they have the ability to interact with sensitive portions of memory, such as those where authentication credentials are stored. With that information they are able to read authentication credentials out of memory.


Not only are we able to read the NTLM password hash out of memory – which could be taken offline and cracked or used in a pass the hash attach, but we are given the passwords for every logged in user in plain text. Even in the above example where the user is utilizing upper case, lower case, numbers, and special characters and a long password, there is no need for the time or computing resources to crack the password because it is there in clear text.


Many people might wonder at this point, is this only in older versions of Windows? Unfortunately the answer is no. Version 1.0 of Mimikatz works all the way through Windows 8 systems (although Windows 8.1 does appear to be safe). Version 2.0 of Mimikatz works even with Windows 8.1 systems to manipulate this type of information. And if you were wondering, yes, there is integration between Mimikatz and the Metasploit framework to make your penetration testing efforts easier. And, just because, there is also a plugin for Mimikatz for Volatility if you’d like to play with this tool with offline forensic memory dumps.


So once again, let’s restate the issue. How bad is it if end users have local administrator rights on their Windows machines?  It’s BAD, REALLY BAD!! Both the Australians DSD in their Top 35 Mitigation Strategies document and the Council on CyberSecurity in their Critical Security Controls document list this issue as a serious concern. Hopefully we can all make sure to keep this issue in mind as we defend our systems.

Vulnerability Assessments vs Penetration Testing

There are many instances where I have had discussions with an organization asking about the difference between a Vulnerability Assessment and a Penetration Test. So I thought I would take a shot at identifying the differences between the two types of testing.

Vulnerability Assessment is the process of identifying vulnerabilities on a network using a series of automated tools that scan the network for known weaknesses. A penetration test is focused on actually exploiting those weaknesses to gain unauthorized access to the tested systems or data (as directed by the client). A vulnerability assessment provides an overview of the flaws that exist on the system while a penetration test goes on to provide an impact analysis of the flaws, and identifies the possible impact of those flaws on the underlying network, operating systems, databases etc.

Vulnerability Assessments use scanners to identify vulnerabilities that are known to report a great amount of false positives. In Penetration testing, there is human intervention to exploit vulnerabilities, thus eliminating false positives. Vulnerability Assessments are more of a passive process. In vulnerability assessment you use software tools that analyze both network traffic and systems to identify any exposures that increase vulnerability to attacks. Penetration testing is an active practice wherein ethical hackers are employed to simulate an attack and test the network and systems’ resistance.

Vulnerability assessments deal with potential risks, whereas penetration testing is actual proof of concept. Vulnerability assessments are just a process of identifying and quantifying the security vulnerabilities in a system. Vulnerability assessments do not provide validation of security vulnerabilities. Validation can be only done by conducting a penetration test.

The scope of a Penetration Testing can vary from a Vulnerability Analysis, to fully exploiting the targets, to destructive testing. Penetration Testing consists of a Vulnerability Analysis, but it goes one step ahead where in you will be evaluating the security of the system by simulating an attack usually done by a malicious hacker. For instances, a Vulnerability Assessment exercise might identify absence of anti-virus software on a system or open ports as a vulnerability. However, a penetration test will determine the level to which existing vulnerabilities can be exploited, and the damage that can be inflicted due to this.

A vulnerability assessment answers the question: “What are the present vulnerabilities and how do we fix them?” Penetration testing simply answers the questions: “Can any external attacker or internal intruder break-in, and what can they attain?”

 

Top tips for educating employees about Cybersecurity

1. Educate your employees and regularly talk to them, explaining the potential impact a cyber-incident may have on your operations. Employees need to know their obligations, especially when it comes to mobile data. It's not enough to require an annual review and signing of an "I have read and understand company IT policies" statement.
    
2. Remember top management and IT staff. Top managers are often the target of cyber criminals because of their higher level of access to critical corporate and customer data. This increased access has a much bigger damage/financial payoff for the hackers. IT staff are also more vulnerable, given their administrative access over the network.
    
3. The weakest link - Any network is only as strong as its weakest link. Explain to employees that while your organization is making its best effort to secure the company's infrastructure, it's critical that employees fully engage and do their part in following company policies. Policies should be sophisticated enough to cover all possible attack vectors.
    
4. Social engineering - Warn employees to pay special attention to social engineering ploys they will find in social media, blogs and emails. It's also important to point out that many cyber incidents begin with a phone call from someone posing as a co-worker asking seemingly innocuous questions. Meanwhile, they are actually gathering information about the company and its operations.
    
5. Recognizing an attack - Train employees to recognize an attack. It's critical that organizations have policies in place that assume they'll be infiltrated. Don't wait to react. Have a documented remediation plan in place and update or review it frequently. Communicate step-by-step instructions about what employees should do if they believe they've witnessed a cyber-incident.
    
   Training should include specific rules for email, web browsing, mobile devices and social networks. Don't forget the basics, such as physically unplugging the machine from the network and notifying the admin of any suspicious emails, activity or lost devices. Kaspersky suggests that employees should be able to locate their emergency IT contact number in 20 seconds or less.
    
6. Notifications - If an incident happens, give employees a heads-up as soon as possible. A lack of transparency or improper handling of a cyber-incident may significantly increase the impact of the event. Issue instructions to employees about how to speak to the public and the press about the incident. Have an internal communications plan and PR strategy in place before anything happens. Consider insurance for cyber incidents.
    
7. Regularly test employees - Organizations should regularly test their employees' cybersecurity knowledge and tie the results back into the training curriculum. It's important to make it fun and/or rewarding, with incentives for prompt responses