It’s been a couple of months since we first announced that Red Team Journal, redteams.net, and OODA Loop would be compiling the latest “Red Teamer’s Bookshelf” jointly. For those of you who’ve been waiting, the list is finally here. It’s larger than previous years, so we’ve organized the titles by category (and yes, some of these titles would fit in more than one category). The titles address a range of red teaming activities and skills, with a noticeable increase in special operations books this year. Thank you to everyone who submitted titles.
A must watch video from one of my heroes of climbing, Will Gadd. Risk management simplified.
Lessons learned from US agents who operate in enemy territory have been captured for years and transformed into a code of conduct popularly known as “Moscow Rules.” Those old rules existed for a reason. Real-world experience proved their effectiveness when agents had to operate in the presence of adversaries.
Since modern cyber defenders are also frequently required to operate in the presence of adversaries there are lessons from these old Moscow Rules relevant to cyber defense.
With that as an introduction, the following is a modified list of the old Moscow Rules designed to help the cyber defender under fire.
Consider these as “Moscow Rules for Cyber Operations”
I like this one:
I've experienced plans going wrong many times during the several years I've been Red Teaming. Sometimes because of poor planning, some others because the real world always has the last word, especially when Mr. Murphy is along for the ride - and he always is.
Over the years both experience and mental resilience had taught me to assess the situation and adapt the original plan, go to a plan B or just work without a plan. While on the field, ideally you’d be looping through 4 steps constantly:
- Understand the problem (in this case what caused the plan to not work)
- See the solution (how do I solve this in a simple, fast and reliable way)
- Communicate the new plan (to your team or to you, mentally saying the plan helps red team the issues)
- Execute it
However, while doing this you have to keep in mind the goal of the mission, assessment or engagement. It is very easy to lose focus of the goal. An instructor at one of the schools I attended while on the military, always told us to focus on the end goal, no matter how bad it was. Mission came first and if the mission was to recon a target and gather intel then that should be the focus. All our planning was geared towards achieving that mission. Once we had that, then the rest (kit, transport, alternative exfil points, etc) would cascade from there. Remember: Rule 16: Target dictates the weapon and the weapon dictates the movement. The goal comes first. The what you are planning for.
It is very easy to lose focus of this when the conditions on the field are chaotic, or not as expected. We tend to focus on the things on front of you, and while these are often pressing and more important (sometimes life or death), once we solve the immediate problem, we need to go back to the original mission.
The best way I found to do this is adding the following to the steps described above:
0: What is the goal.
So, identify the goal, identify the problems preventing you from achieving the mission, find a solution (don’t forget: the solution is in the problem), communicate that solution and execute it. If it didn’t work, or a new problem arises, start again, but always keeping the question what is the goal as the first step. This will keep you focused on your mission.
"It's not what you do, it's when and how you do it. It's all about the conditions. Make it asymmetrical."
"Security is nigh near impossible. It’s extremely difficult to stop a determined adversary. Often the best you can do is discourage him, and maybe minimize the consequences when he does attack, and/or maximize your organization’s ability to bounce back (resiliency)."
"1st rule of Red Teaming - The purpose of a Red Team is to become the adversary, to be the worse case scenario."
-- "On Red Teaming". Soon to be finished book.
On 02 APR 2016, 37 people showed up in Boston, MA for the GORUCK Challenge Red Teams Edition. It was brutal, it was cold, it was wet and it was a lot of fun. 33 finished. 33 got the one patch that will never be up again. 33 people got together, as a team, got after it and came out the other side stronger. Smiling all the way.
A full AAR will follow, but for now here are a few pictures. Keep an eye on this post as I will update it soon.
To all that came, respect!Read More
"Assess the situation: Solutions naturally evolve when you know what you are dealing with."
Some people don’t see the benefits of Red Teaming until you show them. Offensive security is not something organization are often willing to undertake, but sometimes is the only way to really find who is after them.
This was the case for one of our customers. We run a Red Team engagement for 3 months, we showed them what their competition and other adversaries can do to get to their IP (Intellectual Property) and, while doing so, we uncover signs of an ongoing exfil of data.
Once we presented the findings, including the possibility of the bad guys already inside and extracting information, their CTO asked us if we could help their security department find out what/when/how/who. After some discussions with the CTO and the CSO, we mentioned the need for offensive security, or as they put it, to hack back. Well, I hate that term hack back. Offensive security is not that, but good luck trying to explain this to execs that don’t really understand security on the field. We tried to walk them through the many possibilities of offensive security, we tried to explain that there’s nothing wrong with trying to go after the people already inside their network in a more pro-active way. They brought the legal department… Things got more complex..
After about a week of discussions, where all the while, the attackers might have still managed to exfil information, even when we told them what to block (if these were good attackers,they would have contingency routes and access, so I was still convinced they were active), we went nowhere. On the out, their CSO grabbed me and told me that he would arrange for us to come on-site, covertly as he called it, and do our thing from within. The idea was that he would bring us is as a group of contractors working on a network issue, and while we were there we should investigate and attack back (again, his words). We were happy to oblige.
It took 10 days, but we figured out a pattern. The bad guys were good and were covering their tracks (we discovered some IP addresses, but they were just not their real ones), but they were after a specific kind of data. So, we set a trap. We set a bunch of weaponized Office documents, along with some fake developer environment systems that had some extra monitoring in place. These systems also had a particularly vulnerable version of Apache and PHP, making it an attractive target for lateral movement for the attackers.
Meanwhile, in our office, we had a bunch of listeners to see if any of the weaponized documents managed to drop our attack code and get us a way in.
While we discussed the findings with the CSO and his VP of security, we agreed to temporarily pull the real data the adversaries were going after and slowly replace it with fake data and some watermarks. This way we could also track that data if it would appear on some competitor’s site, or news site, etc.
Anyway, 3 days later, we had a ping. One of our listeners emailed us. We had a shell. A day later 2 more. At the end of the week we had all of them pinging home.
Now we needed to move fast. While I did the recon on where we were and possibly who they were, JD try to get some redundancy (extra ways in, just in case) and uploaded some really nasty code to bring the buys down if we needed it. I uploaded our digital drone and set it up to discovery mode. In this mode, the drone only maps the network and reports back any targets of interest, such as DBs, web servers, domain controllers, network devices, email servers, etc. It’s really fast and surprisingly nimble and quiet. Hard to detect unless you know what you look for.
Within the hour we already had an idea that this was a simple setup, it seemed like a bunch of laptops (based on their MAC addresses) connected by a wireless router. We had also a possible real IP and geolocation of the bad guys. Z run a bunch of searches on this IP and locale and we compiled a brief of all we knew for the CSO.
In the meantime, some of the fake information we dispersed began to appear in a forum in Asia and on some download sites. While these are hard to crack to get who the users uploading the info were, it was an indication that these people were after just money, not really the damaging of our customers. So, we added that to the brief.
With all this information, the CSO briefed the legal department and they decided to get the law enforcement involved. However, they asked us to bring this guys down and help reconstruct what happened to help the forensics team sent by the LE.
So, we did.