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…
My account password for LinkedIn was leaked as part of the 2012 breach. I use the same user name on Pandora and, if my password was the same on both sites, this would have left me exposed to password reuse attacks.
I received an email from Pandora Radio today and I think it is great that companies are taking proactive steps to analyze the leaked data and notify potentially affected customers.
What I think Pandora did poorly is include a link and direct users to click on the link. This looks like a classic phishing email. We spend money and time training our users not to click links in these kinds of emails and then companies like Pandora undo all of that training by sending legitimate emails that teach users that it is OK to click the link.
It is not OK and Pandora Radio should have done better here.
File screens have successfully stopped Locky.
I ran a curious file today that gave me the picture above…but my file server is just fine.
For a test, I created multiple file shares.
One share did not have a screen enabled.
The other share had the screen configured as detailed in my previous two posts.
Use File Screen to Stop Ransomware – Part 1
File Screens Don’t Stop Ransomware – Part 2
After running the email attachment, I observed this netstat and task information.
Here is what what is left of the share without the screen.
This is the share that had the screen enabled. I like this one better!
File screens don’t stop ransomware, but firewalls do.
In my last post, I suggested that disabling shares in response to an unauthorized file extension was a bit extreme. After discussing this with other members of the community, I now believe that blocking access is the only real solution.
If ransomware created an encrypted copy of all files and deleted the original copy, a file screen should prevent it. If the ransomware encrypts the existing file and then renames it, a file screen will prevent the rename but the file will still be encrypted. This clearly does not solve the problem.
In order to make the file screen effective, it must respond to an unauthorized file extension by immediately blocking all file share activity until the event can be investigated.
The best response I can think of is to use netsh.exe to block file sharing on the firewall in order to halt the attack. This is done on the Command tab of the file screen window.
Ransomware has become the hot-topic for 2016. It is bad enough that this crypto malware can encrypt workstations but the risk of one infected user locking down the file server is especially scary.
This article details how you can use Server 2012 file screens to prevent crypto locker from taking over your file server. There are a lot of good articles out there using file screens for this purpose but they all have one flaw; they are blacklisting every known ransomware extension. As long as you are blacklisting, you leave yourself exposed to changed tactics. The steps below detail how to create a file screen whitelist and block everything else that you don’t explicitly allow. Whether the latest extension is .zzz or .xxx or .AYBABTU, this technique will keep you protected.
The Ransomware file screen is created in three steps:
- Add the File Server Resource Manager (FSRM) role
- Create an exception list of the extensions you want to allow on your file server
- Create a screen that blocks everything else
This is a short speech I gave on the topic of phishing using a composite of real customers. I briefly explain what it looks like and the potential consequences.
Have you ever hired someone to work on your house and felt you could have done a better job yourself? Was the handyman unskilled, lazy, or both? Maybe he was just going too fast. Or maybe he just simply didn’t know any better.
This is an all too common scenario in the profession of information technology. Administrators may learn the bare minimum required to implement a system but never reach the level of expertise required to do it properly. What companies are left with is unreliable and unsecured systems that are slapped together quickly by poorly trained administrators.
Training must be a top priority for security in any company. An IT staff of highly trained administrators greatly increases the likelihood that systems will be implemented securely from day-one.
Training from cbtnuggets.com or pluralsight.com is a great start. IT Staff should also attend live classroom training and become certified in each technology they manage. In addition to specific technical training, a general security training course such as CompTIA’s Security+ should be mandatory for all IT staff from help desk to senior engineers.
When implementing a new technology such as a new operating system or a new backups system, consider the steps below in order to maximize reliability, performance, and security.
- Train staff immediately before implementation, not during or after implementation.
- Implement the new system with the assistance of an expert in this technology. No single training event can prepare someone for the challenge of designing and implementing a complex system. Allow in-house staff to learn from the design and implementation process.
- Perform a security assessment on the new system to validate both the technical implementation and the procedures for administration, maintenance, and logging.
- Continue to provide ongoing training on the new system.