Contents

Tribe of Hackers: Red Team Edition

Contents

Recently I had the privilege and honor to be asked for my input into the Tribe of Hackers - Red Team Edition book. This book is a compilation of a bunch of opinions from industry professionals on 21 questions. The following blog post is my answers to these questions. If you would like to read all of the other responses and different thoughts, you should buy the book. Here are the links:

1. How did you get your start on a red team?

Craig Balding (@craigbalding) gave me the opportunity to join my first “Red Team,” which turned out to be one of the most rewarding teams and jobs I’ve ever had the pleasure to be a part of. I did this after being many other things, however. I had been a vulnerability scan engineer, a pentest consultant, a tier 1 and 2 incident responder, a forensic analyst, a firewall admin, an IT architect, an on-call help desk tech, and an IT clerk. I believe that having this wide range of experience helped me obtain this opportunity and the ability to interview successfully. Do you have to have the same path? Not at all, I have seen a Mathematician make the leap directly over into pentesting and destroy networks because they understood cryptography better than the network engineers did. I have seen stay at home moms become fantastic SOC analysts out of the blue. Everyone’s path in this industry is different, it’s all about obtaining the experience or expertise to do the job you want to do.

2. What is the best way to get a red team job?

Apply? This is like asking how to get a job period. Red Team jobs don’t follow any particular set of rules. Apply for the jobs that are out there and be qualified to do so. Therein lies the tricky bit though right? First, you have to believe that you are qualified, then you have to convince someone else (the recruiter/hiring manager) that you are qualified. Many hiring managers talk about the “hacker mindset.” This is the headspace where the intended use of something is ignored or expanded upon. The same process needs to be applied to getting a job. Hack it. Think of qualifications as a list of intended uses, RTFM, and go from there.

3. How can someone gain red team skills without getting in trouble with the law?

This question kind of pisses me off because even in 2005 when I started learning about security, there were plenty of avenues to learn without committing felonies. Sure, in the BBS days and those of the “early” Internet, resources were lacking, and many from that era still wear it as a badge of honor. This is fine, they learned the only way they could at the time. That time is long gone. If you think you have to break the law, then someone has misguided you. This does take one minor thing for granted, that you have a computer that you are authorized to use and have Internet connectivity, which is not always the case, especially in third-world countries. If you have neither of these, then those situations may still be out there. I do not condone breaking to law, and no matter how I feel about the law in my own country, breaking laws isn’t the way to fix them.

Let me put away my soapbox real quick so we can talk about the ways you can actually do this in 2019. Red teaming can be made up of a ton of different skill sets from routing, switching, Active Directory, wireless (not just 802.11), physical security, IoT (Internet of Things), web, cloud, cryptography, to databases, etc., etc., etc. You can also come from a vast array of backgrounds and study an even wider variety of topics that it wouldn’t fit in this book without making a Tomb of Hackers. However, VulnHub is where I point most people. On VulnHub you download VMs and attempt to get “root” on them. The great thing about VulnHub is even if you are just beginning you can download a VM, boot it up, have a go, realize you have no idea where to start and read one of the myriads of walk-throughs they have on the site for each VM. There is ZERO harm in reading ALL of the walkthroughs many times over and getting the practice of doing getting root the same way they do and eventually understanding WHY they are doing it.

4. Why can’t we agree on what a red team is?

Because it means different things to everyone and that’s ok. Why does it have to have a precise definition? Can you tell me what a SOC (Security Operations Center) looks like in specific terms? Or what makes up a hospital even? We have a ton of collections of things that are defined by general ideas, and that is fine. Such as the fact that a hospital includes an Emergency room but not all of them include long term cancer wards, or that a SOC must have screens on the wall for NO REASON WHATSOEVER!! and some are 24/7, and some are not. These general ideas are accepted in society, why isn’t it ok for a red team to also be amorphous? The definition of a communicated word is one in which the parties involved understand it, and for the most part, when a customer and a consultant speak of red team engagements, there is an understanding of what that entails through mediums like the Statement of Work (SoW) and Rules of Engagement (RoE).

I have no idea what the rest of the information security community/world/whatever understands or doesn’t understand. One thing I wish was more prevalent is the core value that you are part of the team that’s sole purpose is to make the company better and more secure. This doesn’t happen by pointing and laughing like an outsider. The company has a vulnerability, that’s your company (even if you are a consultant or contractors for them for the week). Get to work.

As for toxic falsehoods? Why does anyone care? Go to work, do good things, or build a company, and do good things. Run your own race to your personal goals. Don’t worry about what the “rest” of information security is doing, or what toxic drama is next up on the Internet. All of that is a waste of your time. You only get so much time on this earth, and you choose who you give that time to, random security fads, or drama is just not worth it.

6. What is the appropriate point in the maturation of a security program to introduce a formal red team into an organization?

As soon as they can afford it. Red Teams are like human security unit tests. Everyone knows they need unit testing in their code, and they put them in as soon as it starts becoming needed or things start breaking. Same goes for Red teams, the moment you begin to need a Blue team is about the same time you need a Red team.

7. What has been effective at explaining the value of red teaming to a reluctant or non-technical client, or even to your own organization?

Listening. If you are there to help an organization genuinely, they will feel that and not be reluctant anymore. If they continue to be hesitant, then they don’t want your services, you should let them make that decision and move on.

8. What is the least bang-for-your-buck security control that you see implemented?

Logs. But what is the most bang-for-your-buck? Also logs. The problem with logs is that if you don’t have a skilled team to look at said logs, they are useless and moreover they cost more money the more you have just sitting around. So unlike AV or a SEIM or several other things that can be considered unnecessary under different contexts they usually don’t cost you exponentially more money as logs do.

Plenty of times. I did a talk called Open Source Pentesting where I talked about the myriad of different offerings that I have offered and think other firms should offer because they fit better than a standard pentest or red team assessment, or source code review. Ultimately though, the customer is the one making a business decision to purchase your services, counseling them to do something different may fall on deaf ears, or they may have a perfectly good reason for doing so that you have no purview to. You have to be ok with that.

10. What’s the most important or easiest-to-implement control that can prevent you from compromising a system or network? For example, how can we help small and medium businesses who have a smaller budget and staff?

Good password management. Passwords are the bane of information security right now. 2FA/MFA is a solution, but they are still cumbersome or impossible to incorporate into the authentication platform a company uses. Most pentests and red team assessments that I perform these days start with some kind of initial toe hold into the organization, and then the hunt for credentials begins. API keys, SSH keys, passwords, anything that can get me to a higher level or more access than that toe hold. This is why I think a company should require the use of password managers for all work-based authentication, this includes API keys (vaulting products help make this a reality). A way to force this is to change your internal password minimum to something like 40 characters. Initial login (in order to get to the password manager can be done via a smart card, FIDO or another token-based product. Even mobile devices these days can act as FIDO devices which would remove the need to deploy and manage a fleet of devices for authentication.

11. Why do you feel it is critical to stay within the rules of engagement?

Because it’s a felony in the US if you don’t (breaking into a system without authorization) and liability insurance only goes so far. It’s also an agreed-upon document (Rules of Engagement). This is like asking, “why should you honor a contract?”.

12. Tell about a time you were busted on a penetration test (physical, network, social engineering, etc.). How did you handle it?

This happens a lot and while I do get pissed (mostly at myself for being stupid in some way), it quickly becomes admiration for what the defense team put in place. I did a talk called Attacker Ghost Stories about several different occasions when I was caught. One of my favorite stories was the result of a honey pot (an intentionally vulnerable looking software).

Once upon a time in a red team far far away my team had harvested a few sets of credentials from a phishing exercise, and I wanted to test them out on a web application page I found which showed a number of indicators that Active Directory authentication was in play on this page (such as a DOMAIN\jdoe) example. I proceeded to use each of the credentials the team had obtained, testing to see if the credentials were good and if they provided any higher-level access to the web application. Unbeknownst to our team, this was a page that did not actually have connectivity to any backend much less Active Directory. It did, however, alert the administrators to every single user and password that we tried against that page so that they could disable them and have their passwords changed. This page was set up by a system administrator, not even the blue team (defense team) as a way to catch leaked credentials. Needless to say, our team was very displeased with me that I had burned all of their work.

13. What is the biggest ethical quandary you experienced while on an assigned objective?

There was a law firm I was testing. It was an internal test, and responder was pretty new to the industry, so it was a pretty quick assessment. I was sitting there cracking passwords from the domain so I could access the target data for this assessment ( dummy case records in their case data storage system) when I saw a credential crack for one of the top partners at this firm. The password was “poisonedher.” This freaked me out. What should I do? Should I call the police? What would I tell the police if I called them? I had no proof of any wrongdoing. Did this person confess (as they secretly typed in their password every day) that they were or had poisoned some woman somewhere? Or did they just really like murder mystery books? I expressed my concerns to the engagement point of contact at the law firm, but I was agonizing over if to tell anyone else or not the whole week allotted for the test. A few months later the partner no longer worked at the firm and that’s the last information I got on the subject. The story still gives me the chills to this day.

14. Describe the “team” aspect of red teaming. How do you work together to get the job done, including documentation, reporting, and working with the blue team afterward?

It’s a team, much like any other. Teams combine strengths and compensate for weaknesses, and every team is different. What works for my team might not work for yours. Good leadership, and using a fast-fail approach when trying new things to find out what works best for your team has been highly effective for me in the past. What platform works for most of the team when documenting findings? Is it MS Word, OneNote, Google Docs, Etherpad. This is all about styles, personal preferences, and effectiveness. Communication about what works, what doesn’t work, and what to try next is vital.

15. What is your approach to debriefing and supporting blue teams after an operation is completed?

That’s easy, you give them as much as you can. Everyone has a schedule to keep, but if I had infinite time, I would go on-site with every single customer and fix every single one of the findings I found during an engagement. Every company is understaffed right now when it comes to security talent. Being that extra body, with intimate familiarity with the findings (since you found them) and showing the effort to find the right person and right fix would do leaps and bounds more help in this industry than shoveling reports over a table.

16. If you were to switch to blue team, what would be your first step to better defend against attacks, and if it isn’t commonly done already, why do you suppose that’s the case?

This really depends on what is considered the “blue” team. If that means incident response, then what I would do is forward Windows event logs, deploy Sysmon and OSQuery across my fleet of systems to talk to a central logging server and set up alerts. I don’t think this is done very much because it’s a free solution and takes expertise (which is in high demand) to deploy. Blinky boxes are still the highlight of InfoSec because they come with experts to implement and fix if things go wrong.

If by “blue” team, we mean security teams in general, then I would focus on making security policies like minimum password lengths that force password managers and 2FA. I don’t think this is done as much because it takes a lot of work to get approved and is usually a highly political process.

17. A lot of people complain about writing testing reports, and a lot of customers complain about the quality of reports. What is some practical advice on writing a good report?

Work with your customers to identify the most beneficial medium of reporting. While the industry standard is a 40 some-odd page report, it doesn’t have to be this way. Many companies would rather reports be just imported into a ticketing system. Other companies prefer having their reports in the form of a slide deck with commentary on a conference bridge. If you never discuss the most efficient method, you’ll never do anything different, and probably just give them another PDF or DOCX to be ignored.

18. How do you ensure your program results are valuable to people who need a full narrative and context, instead of a showcase of their weaknesses vs. your skillset?

Objection! Leading the witness! In all seriousness, we in the industry are a lazy bunch. We spend a ton of time on things we find interesting and valuable, and the drudgery of writing reports, findings and explaining our discoveries to others is tedious. We want to discover and be left alone. We have to overcome this. It’s like working at McDonald’s and sitting there, making only the things we want to eat instead of the food being ordered. Part of maturity is learning that work is work because it involves things that are beneficial to persons other than yourself. Put in the work to figure out the weaknesses, document how they were found, then spend the time to research fixes, multiple if possible, and test out those fixes. I’ve tested various “industry-accepted” fixes for common vulnerabilities that just don’t work, or only work partially. Do the work, spend the time. You’re getting paid to make the customer better, not show how cool you can be.

19. How do you recommend security improvements other than pointing out where it’s insufficient?

General Electric has one of the most well-known leadership tracks in the industry, companies worldwide send their managers to Crotonville. While I personally didn’t attend any of the Crotonville training sessions, I had the fantastic opportunity to interact with a large number of peers and leaders who had. One of the main themes I heard most repeated from that training program centers around motivation. Motivating others to do as you want them to. But, getting back to the question, “Insufficient” it a purely subjective, especially in the Information Security space. Chris Nickerson said it best in his TED talk where he said that security is a feeling, so you have to treat it that way. Identifying with how someone feels when you report a vulnerability to them and locating the right motivation to have them fix it can make a huge difference. If you go into a room huffing and puffing that you know better and that this change or that change will secure the company better, you are going to get ignored. We all have better things to do than listen to someone ranting and raving about the next ‘worst’ thing.

20. What non-technical skills or attitudes do you look for when recruiting and interviewing red team members? Or, what is one of the most beneficial non-technical skills you use for red team activities?

I would say extreme curiosity is probably the primary non-technical skill I look for in candidates. If you aren’t curious, you aren’t going to go digging through a pile of manuals to find the one URL that isn’t protected by authentication or that one share out of ten thousand that happens to have a PASSWORDS.XLS in it. I use my insatiable curiosity regularly during red team assessments to poke at everything and anything (within the RoE).

21. What differentiates good red teamers from the pack as far as approaching a problem differently?

In my opinion, the most significant differentiator from people that I have seen as successful versus not is the ability to ask for help. The ability to ask for help is not as natural as it sounds. When you are knee-deep in a network or security vulnerability, it’s hard to ask for help or let people into your “secret sauce.” Letting go of that pride allows red teamers to go further, learn more, and be more successful overall.