Patch Remediation With PowerShell – Part 1

There are a lot of security topics that are absolutely fascinating but patch management is not one of them.  Even more horrific is patch management remediation.  Deploying patches isn’t so bad but getting that last 10% out of your compliance efforts is just a never ending brutal slog through the mud.


I wrote a quick script to take a list of non-compliant computers and give some basic information about their health and status so action can be taken.  Unfortunately, this script can’t make phone calls to find out why a computer is off or unplugged but it can at least get you started.

Computer List – To start, export a list of computers that need to be evaluated to ComputerList.txt and place in the same directory as the script.

Ping – The script will ping a computer and return a response.  This tells you whether or not the computer is on and responding.

DNS – Next, the script will query DNS for the computer.  This tells you if the computer is off temporarily or if it has been off long enough that the DNS record has been scavenged.  Check your local DNS aging and scavenging settings to learn what this means in your environment.  The default setting are around 2 weeks I think.

Active Directory – Finally, the script checks to see if the computer exists in Active Directory or if it has been deleted.

Output – All the results are written to a new line in ComputerTestResult.CSV file for easy use and filtering in Excel.

Here’s the script…

Continue reading


Password Spray with PowerShell

Find user accounts with weak passwords without getting ntds.dit, admin rights, account lockouts, or logging any events.


With basic domain access and PowerShell, this script uses a password spray technique to test one password at a time against all active user accounts in the domain.

More traditional brute force password guessing might try as many password combinations as possible against a single target user account.  Password spraying takes a reverse approach by casting a net to catch as many accounts as possible.

Unfortunately, passwords can be pretty simple even with complexity requirements enabled.  With complexity enabled, passwords are required to use of a mix or character types.  Specifically, 3 of the 4 types of characters are required to meet complexity requirements.  The 4 types of possible characters are UPPER CASE, lower case, numbers 0123456789, and special characters such as $%&#.  Unfortunately, there is nothing stopping a user from using weak passwords that meet the complexity requirements such as Password1 or Summer2016.

With Azure AD, Microsoft is banning common or known-exposed passwords in its cloud deployments.  I would really like to see the complexity policies in group policy updated to include this same functionality.  Some people have customized their own password filter to prohibit certain passwords while others use 3rd party products to add this additional functionality.   Here is an example of a 3rd party product from nFront Security that has solved this problem.  I haven’t used it so I can’t make a recommendation but it certainly seems like a product that is worth exploring.

Weak passwords are such a massive exposure that this really needs to be built-in functionality.  Until Microsoft’s password policies are improved, scripts like this can help administrators or penetration testers identify and notify users about their risky password choices.

On to the script…

Continue reading