Mitigating Pass the Hash attacks

Pass the hash is not a new attack but a really old lateral movement kind of attack that has been exploited by attackers during the last 15 years. However, still today is really effective in Windows networks.

The purpose of this post is to give you an overview of how this attack works and what are the main security controls that you could put in place to prevent or mitigate it.

The attack consist on getting the password hashes from a compromised system and reuse it to get access into other systems of the network. This attack is possible in Windows due to how the NTLM protocol works; attackers can use the hash of a password to authenticate to remote services without needing the plaintext password or without having to undertake dictionary or brute-force attacks on the hash itself.

It’s not possible to prevent completely attackers using this technique in our Windows infrastructure, but there are some mitigation controls that we can put in place. These are the security controls recommended by Microsoft for that purpose:

• Restrict and protect high privileged domain accounts
• Restrict and protect local accounts with administrative privileges
• Restrict inbound traffic using host-based firewall

Let’s review each of them.

Mitigation 1: Restrict and protect high-privileged domain accounts

This mitigation reduces the risk of administrators inadvertently exposing privileged credentials to higher risk computers.

The idea is to restrict high-privileged accounts like domain and enterprise admin accounts from being used to authenticating to less trusted computers. So the admins should use less privileged admin accounts to perform their regular tasks instead of using high-privileged accounts. It’s important as well not schedule tasks or configure services with privileged accounts on lower trust computers.

The rationale behind this control is that an attacker cannot steal credentials for an account if the credentials are never used on the compromised computer.

This mitigation can only be technically enforced from Windows Server 2012 R2. Prior to this version, could only be enforced by policy or procedures.

Mitigacion 2: Restrict local accounts with administrative privileges

This mitigation restricts the ability of attackers to use local administrator accounts for lateral movement PtH attacks.

The idea is to enforce the restrictions available to prevent local accounts from being used for remote administration by explicitly deny network and Remote Desktop logon rights for all administrative local accounts.

On the other hand, as Windows is not using Salt for calculating the hashes or the passwords, local accounts with administrative privileges should have a unique password for each system.

With this control in place, an attacker who successfully obtains local account credential from a compromised computer will not be able to reuse those credentials in other computers on the organization’s network.

Mitigation 3: Restrict inbound traffic using a host Firewall

This mitigation restricts the ability of attackers to initiate lateral movement from a compromised workstation by blocking inbound connections.

The idea is to restrict all inbound connections to all workstation except for those with expected traffic originating from trusted sources. Using a ‘whitelisting’ approach in terms of sources and protocols will prevent an attacker who successfully obtains any type of account credentials to be able to connect to other workstations.

Other windows features that can help

Other windows features that could be useful to prevent an attacker from stealing or using stolen credentials are:

• Enforce credential removal after logoff
• Remove LAN Manager hashes from LSASS
• Remove plaintext credentials from LSASS for domain accounts
• Protected Users security group
• Authentication Policies and Silos
• LSA protection-theft
• Disable Automatic Restart Sign-on (ARSO) Routine

More info and conclusion

In that link: https://technet.microsoft.com/en-us/security/dn785092, you can find extensive information and more details about those MS features as well as deeper information about how and why the PtH attack works and how to prevent or mitigate it.

It’s important to keep in mind that there is no silver bullet for the PtH attacks. Technology alone cannot solve that problem, so people and processes become critical elements in any corporate defense program. The proposed security controls must be enforced and integrated into a comprehensive security approach that should include security awareness, security monitoring and incident response readiness.

Secure DevOps without dying in the attempt

As the Product

I’d like to be secure

To avoid hackers exploiting me and having fun at my expense

One of the things that I’ve been working on during the last time is about how to ensure that the security of the product is correctly managed through the agile lifecycle. And it’s not an easy topic since we don’t have a big up-front planning were we can expend the needed time to analyze the risks and set up the security requirements. In fact is the opposite, we are not sure of what we will be building some weeks after so planning security can be a really painful activity or even worst, we can decide to forget about security in our product or do it as “best effort”. But after consider it carefully, I really think it’s a good opportunity to increase security efficiency since we can also be agile on security; reassessing the risks with a higher frequency and being able to better adapt the countermeasures to the dynamic context where the product will be leaving.






But to be able to exploit this opportunity we will need a “security champion” collaborating with the DevOps team to guarantee the security risks are detected and managed on time. I don’t mean having a dedicated security architect by team but he should have some dedication at least once per sprint to ensure that no new risks are being introduced while the team develop the new stories.
This security specialist must work closely with the Product manager and the Product owner to understand what is the long and mid-term vision and roadmap for the product, so he can forecast what will be the risks and define the security requirements that would be taken in consideration by the scrum teams in the implementation.

He also need to have close interaction with the scrum members to understand how they will implement each story in order to be able to detect security risks coming from the implementation strategy selected in each case.
He’s also the one that should maintain up to date the risk register agreeing with the risk board the strategy to manage the identified risks and work with the Product owner to translate these risks management strategies into user stories to inject in the teams backlog.

On the other hand, as part of the continuous integration process,  the static code should be checked with a tool to detect any security vulnerability being introduced on the product, as well as vulnerability scans for the infrastructure and application vulnerability scan before to consider a release prepared to be deployed in production. Beside of that, periodically and always for each major release, it must be done a complete security audit before deploying the code into production, as well as a Pentest exercise over the infrastructure hosting the product.

Sometime I've heard also people afraid by the fact of the same team developing and operating the solution. Since it can be a risk on some cases, there is plenty of ways to mitigate it: peer programming, peer reviews, external audits, role segregation, etc...

Lastly but not least it will be fundamental to deliver proper training to the scrum team about secure code techniques since as in all the cases, the human factor is always the weakest link of the chain.

In conclusion, contrary to what is commonly believed, agility does not have to mean lack of security. In fact, as we have seen, it could become an opportunity to improve better security processes being smarter and more effective on the efforts that we dedicate to protect our product.