Red Team Penetration Testing – Fallout (Part 3 of 3)

In the first and second parts of this red team penetration testing blog, I described how armed with minimal knowledge of a company, I was able to root the entire domain. Anything goes in red team penetration testing, and I went all the way.

After a few days of hacking, I got domain administrator credentials and unlimited remote access. However, just as I was cleaning up, the client stopped the test.

Our client had monitored my progress and was shocked at how adeptly I bypassed controls. I was simultaneously honored to hear this, but also felt bad for the system administrators. They were confident with their configurations. This client had invested extensively in some of the best security technologies, however, technology alone cannot protect a business.

It took me 13 hours to go from nothing, to root access. What can we learn from this?

External Analysis

The following chart illustrates the actions I took during the external testing portion of the attack. Green boxes indicate steps that provided valuable information that allowed me to progress. Yellow boxes were steps that I took that did not allow me to progress. The red boxes indicate the actions that got me credentials.

On the left side, red text indicates things that directly contributed to the successful attack against Victim Corp. Black text indicates other things that did not have a direct impact on the attack

From the outside, Victim Corp’s environment was quite secure. I located many web services and a few web applications, but there were no exploitable weaknesses. Any attempts I made were shut down quickly. From a purely technical perspective, Victim Corp was secure. They patched systems regularly and had excellent perimeter defenses.

Unfortunately, like many companies, their weakest link was the people and processes they follow (or do not follow.) All it took was one phone call to obtain working domain credentials to the network. This proves something we say regularly at Anitian: it is not the technology, but how it is used and managed. In this case, it did not matter that Victim’ corp had great technology, their people were not following good procedures. Victim Corp’s IT help desk made no attempt to verify my identity when I called to have my password reset over the phone. This is a classic weakness that impacts all companies, especially those with a lot of remote workers.

External Improvements

There are some basic procedural and technical ways that Victim Corp could have thwarted this attack:

1. Require employees to identify themselves with secret questions before resetting passwords. You see these on a lot of bank websites: “what is your favorite sports team?” This is not always practical and can be hacked, but it would have stopped me.
2. Use call-back verification. Rather than just reset the password, inform the employee that you will call them back at an approved number. Again, not the most practical, but it still would have stopped my attack.
3. Require multi-factor authentication for all remote access. This is perhaps the simplest and the most reliable solution. It would have stopped me before I even started.

Some other practices that would have helped thwart this kind of social engineering attack:

• Discourage the use of email autoresponders.
• Do not verify to remote users that a username exists.
• Do not tell the remote user when their account is locked out.
• Do not allow direct dialing of your internal help desk from outside phone numbers. Alternatively, differentiate between internal and external calls, and require any external call to use stronger verification procedures.

On a side note, when Victim Corp reset John Doe’s password to “Password1” the system did not force me to change my password. This tells me something as an attacker: Victim Corp does not use random passwords. They likely always reset employee passwords to the same thing. Out of those 325 employees, I identified, how many of them do you think had their password reset in the last 90 days and then left it as “Password1”? How many of them had their password reset sometime in the past and have just been changing it to “Password2”, “Password3”, etc. as they are forced to change their password every so often?

While I did not pursue this tactic, I am reasonably confident it would have been successful. It was another layer to attack.

Internal Analysis

Getting into the organization was only one part of this attack. Once inside I quickly hacked the entire domain.

The next chart shows the steps taken to get from a regular domain user to domain administrator. Yellow boxes indicate steps that did not move me forward. Green boxes are actions that were normal for my current level of access but could have been prevented if I never had that level of access in the first place. Red boxes indicate serious, preventable weaknesses.

Victim Corp kept their virtual workstations up to date, so there were no obvious vulnerabilities there. Also, network scanning did not reveal any obvious weaknesses or misconfigured services. Victim Corp had decent internal network controls to prevent me from executing any broad network-level attacks.

Unfortunately, I could identify several critical misconfigurations that gave me crucial access.

Internal Improvements

There were five main things that Victim Corp could have done on their internal network to prevent me from completely compromising their domain. Most of these findings relate to password security, but some are related to configurations.

1. Do not use group policy preferences to configure passwords. These files are accessible to all users on the domain and are easily decrypted using free tools. All it would take is one tech-savvy employee to go snooping around to lose accountability on their network.
2. Restrict user access to only what is necessary to perform a job function. There is no reason the John Doe account needed remote desktop access to IT workstations.
3. Never store passwords in cleartext documents. John, Victim Corp’s risk manager, had all kinds of personal passwords saved in a Word document. This showed a profound lack of security awareness, among a risk manager nonetheless. I could have severely disrupted his life, and even injected ransomware into the environment.
4. Do not reuse passwords, especially service accounts. This attack clearly shows why re-using passwords between accounts and domains is extremely dangerous. If Victim Corp had different, complex passwords for their development environment, I would never have made it as far as I did.
5. Finally, use strong passwords. The “admin” account on the development domain used a password that is highly likely to be in common password lists. It is a safe bet that other accounts on this domain use equally weak passwords, if not the same password altogether. Victim Corp should train employees to use complex passwords or passphrases that are less likely to be easily guessed.

On a positive note, Victim Corp’s administrators did detect my activities and shut down my domain administrator accounts. It took about 12 hours to notice any malicious activity, but considering a bulk of these activities happened overnight during the weekend, it is understandable.

However, there are a lot of things I could have done, that I did not. Once I had domain admin rights, I could have injected malware or ransomware into the environment. I could have set up botnets and listeners. I could have stolen additional credentials or intellectual property. I had unlimited access to an entire corporate network for at least 12 hours. The amount of damage I could have done is staggering.

General Recommendations

This entire exercise also demonstrates a number of important lessons about information security in 2017.

• You cannot rely exclusively on human response. While Victim Corp’s administrators responded rather quickly, they still took 12 hours. I could have done a lot of damage in those 12 hours. It is vital to automate detection and response wherever possible.
• Technology is only as good as the people using it. Victim Corp had invested heavily in “best of breed” NGFWs and “threat intelligence.” Yet, they failed to implement an inexpensive, proven technology of multi-factor authentication.
• It is pointless to send people to security awareness training if they are following procedures that do not reinforce the message.
• Focus on fundamentals. This hack was executing using tried and true techniques. I did not use any advanced zero-day attacks. I did not download anything from the Dark Web. No Russian criminal organizations were involved. All this focus on obscure attacks and attribution at RSA and elsewhere is distracting. Focus on the fundamentals, and never lose sight of them regardless what the “cybergurus” tell you.

Why Red Teaming?

Penetration testing provides valuable information but is not representative of what a dedicated attacker can do to your organization. Many organizations conduct pentests, pass those tests and assume they are safe. The complexities of an environment compounded with the diminishing role of perimeter security make the value of classic penetration testing increasingly less meaningful.

Furthermore, a dedicated attacker is not constrained with time, ethics, or project scope. They can and will execute anything they want. They do not care about every little vulnerability you have. They only need one, and that vulnerability may have nothing to do with your next-generation firewall or advanced endpoint solution, and everything to do with the people working in your organization.

Red team tests are an ideal way to test an entire security program and find those missing links in the armor. You may have performed a network penetration test recently and foiled the penetration testers, but what would happen if you widened the scope of the test to everything on your network perimeter? Or what if you allowed them to social engineer your employees? Are your WiFi networks secured? How about the door your employees use for their smoke breaks? What about that third-party vendor you use for recruiting? Are they secure?

This red team engagement was a thorough test of our client’s program. Honestly, this client did better than most. Throughout the course of this engagement, Anitian executed the following tests:

• Internet footprint
• External defenses
• Security procedures
• Employee training
• Configuration weaknesses
• Web application weaknesses
• Password weaknesses
• Intrusion detection and prevention
• Internal network security
• Incident response

While red team tests are an ideal way to test your security program, they are not necessarily suitable for every organization. There are two ideal scenarios for red team tests:

The ideal red team scenario is if you believe your organizational security is strong and are serious about testing it. However, you cannot constrain the test. There are some obvious restrictions you can make, such as no denial of service attacks. Red team tests only work if the tester can try anything. If you constrain the test too much, then it invalidates the value of the test.

Another way red team tests can be useful is when you believe your organizational security is poor, and need to definitively prove this to management. Lack of support for security improvements from leadership is a common source of frustration for security practitioners. Many people view security as a hindrance, and will not accept the reality of their situation until presented with hard evidence. A red team exercise is an excellent way to produce some strong evidence.

Watch Out for Blowback and Gotcha Testing

If you go down the path of performing red test tests, be prepared for these pitfalls.

Poor performance on a red team test may lead to blowback from leadership. Bad leaders are fond of “blaming the messenger” rather than solving problems. They may fire you (and the security firm) if the report is negative. Moreover, our industry still has plenty of checkbox assessors. Bad leaders will seek out these firms to get a report that tells them what they want to hear, and not the truth.

Also, be on guard against security firms that practice “gotcha testing.” That is, they focus on the process and sensationalism of the test, and not the outcome and what it means. This red team test provided our client with a detailed report regarding the specific issues they faced, and recommendations to fix them. While this blog was about the process, the process is not the deliverable. The purpose of any penetration test is not to test the analyst’s skills and cleverness; it is to test the business and their security. Skill and cleverness are expected of any penetration tester. But the measure of success is not skill, it is results.

When you scope a red team test with a provider, pay close attention to how they position the test. Do they use scientifically valid testing methods? Are conclusions drawn from the data or opinion? Do they focus on their cleverness, or the results and how they can help?

Conclusion

Red team testing is a lot of fun. I thoroughly enjoyed hacking this client’s systems. However, the truly rewarding part was helping them fix these issues and get better. It is important to remember that our jobs are to make businesses work better. Hacking systems is fun, but the end goal is to get better.

Let us know your red team stories in the comments below.