Motivations of a Red Team TesterHow does a red team tester create simulated attacks to mimic real-world online threats that test your system's defenses?
As a simulated criminal – someone who is hired by your organization to try and penetrate your cyber defenses – let's talk about motivations and fears people in my position have about breaching your network. You have something I want. I would like to steal it but don't want to get caught. I don't want to go to jail. When I try to break in to take what I want, I prefer using methods that offer me the greatest chance of reward for an acceptable amount of risk. If I am successful, great! Mission accomplished. If my attack is unsuccessful but I've not been caught, I can either give up or I can reassess the amount of risk I'm willing to accept. If the reward is big enough, I might try an attack that has a greater chance of success but also an increased risk of detection. I can repeat this escalation until I have what I want or I stop trying for fear of getting caught. Or something gets in the way, forcing me to stop.
Revving up Risk for Reward
How might these motivations play out for a red team tester? Let's assume we are starting by looking to move from outside to inside the network. We'll likely start by probing externally facing systems. This is something that happens all the time; we can do it from anywhere in the world and it's pretty low risk. If we can find a way in from the outside or move towards our goal, then we've been able to accomplish a lot with minimal chance of exposure. If it doesn't work, it's time to start ramping up our efforts.
We may then move to remote social engineering – a phishing campaign. There's an increased risk that the phishing emails are going to be identified and reported, but this is still a pretty low risk attack. Even if the emails are reported, it isn't likely we'll get caught. We might be able to compromise an internal workstation or capture some credentials that can be used to access an externally facing system. If none of our phishing targets bite, then we look to take on more risk.
If our previous attacks failed, we might attack the Wi-Fi networks. Unfortunately, we do have to be in relative proximity to the target, creating greater risk, but a successful attack might get us both access to the internal network and user credentials.
Finally, if all else fails, we can escalate to on-site, in-person attacks. We really don't want it to come to this, but physically entering a target facility and connecting to the network is very effective. This most certainly has the greatest risk to the attacker. If caught, there's a good chance you're going to jail. But depending on the location, it can be very easy to simply walk into a building, find an unoccupied office or conference room and get to work.
Once on the internal network, this risk assessment continues. There are plenty of effective (though noisy) attacks but getting caught and kicked off the network doesn't move us towards our goal. And in the end, it is the goal of a red team tester to simulate a real attack as best as possible.
Syncing the Timeline to the Motivation
The common problem that we run into with red team tests is time. Red team tests are more involved engagements, often scheduled to run for a few weeks with three or four testers. This might seem like compressed realistic window to execute these attacks, but in fact, it's a compressed version of the real things, and the short timeline interferes with the assessment. Instead of escalating attacks as a legitimate criminal likely would, all of the attacks are run concurrently. As a result, we might see a physical attack quickly provide results even though it was an unnecessary risk. The external testing might trigger defensive systems that could have been avoided by a slower, stealthier tactic.
Unfortunately, the simulation starts to move away from what an authentic attack might look like.
Reworking the Red Team Test
What can we do to combat this? One option is to extend the testing window. Execute the engagement over a course of months rather than days or weeks. Instead of nonstop testing, slow down the process to a more realistic pace. Engage testers work to stealthily probe external defenses, then progressively escalate to more risky tactics, ramping up efforts in pursuit of the testing goal.
This was the idea that we took into a recent SecureWorks Red Team engagement. Working with the client, we laid out testing goals and built a plan outlining how each phase of testing would progress. We decided that, if, for example, external or phishing attacks were successful, then we wouldn't escalate to physically breaking into the target location.
Testing started with open source intelligence gathering, and we found some good information about the externally facing hosts and services. We found some source code with hard coded credentials that had been uploaded to a public code repository by a contractor. Interesting information. Useful.
When we started the external testing, things were spread out, built off of the open source intelligence; we began probing select systems at different times from different parts of the world, looking for weaknesses that would grant us access to the internal network.
One of the first things we found was a system running a default installation of the Jenkins web application. This application can easily provide remote code execution so finding one in the default state – not requiring any credentials – was a good bit of luck for us. In fact, it was too lucky. Immediately after compromising the system, we discovered a malicious script in a temp directory. It was not part of our test which meant this system had already been compromised.
Here is where we deviate from the criminal mindset – we contacted the client to inform them of the compromise so that they could begin incident response procedures.
Shifting Tactics to Reach the Targets
That system had been burnt but testing continued. We decided to try something simple. A number of target systems were listening on port 22 SSH so we used the common user root and the password we had discovered during the open source intelligence gather, and we slowly attempted to log in to more than 200 systems. We successfully logged into three of them. We had breached the external network.
Immediately, we looked to secure our point of entry. We identified additional systems which did not face the internet that use the same root password and set up back door access should our original compromise be discovered and remediated.
At that point we ramped up efforts, bringing in additional testers. We discovered some domain credentials and found that we had routing to some internal subnet but not our target environment. We were able to gain some elevated domain privileges using the discovered credentials and found an accessible system with routing to the target subnet. By pivoting our connection through multiple compromised systems, we were able to reach our target and begin the search for the target data.
This entire attack, executed from the internet, flew under the defenders radar. We were prepared to escalate our attacks and conduct physical break-ins, but it wasn't necessary. In the end, we were able to provide the client with a test that demonstrated some critical, issues that could be easily resolved.