Читать книгу Tribe of Hackers Red Team - Marcus J. Carey - Страница 13

7 Mark Clayton

Оглавление

“Passion is what drives you to continue to learn and constantly take on challenges because they are more interesting than watching your favorite Netflix show.”


Twitter: @bullz3ye

Mark Clayton (Bullz3ye) is a red teamer, security engineer, and application developer who can’t seem to choose between the three. Professionally he is a red teamer and security engineer but is always developing web and mobile applications at night. As of late, his primary focus has been on DevSecOps, where he is able to blend his security and development experience. Since a young age, Mark has been under the mentorship of a Cult of the Dead Cow (cDc) member, who showed him the ropes and taught him the security ecosystem, and he’s stayed true to those lessons.

How did you get your start on a red team?

I guess you could say my path was a bit unconventional. During college, I was originally cut out to be a software developer. My primary focus was building mobile applications on the Windows Phone…because that was going to take the world by storm. I even had a track laid out for me to potentially join Microsoft after my graduation—that is, until one day during my sophomore year a close friend of mine asked me to join his Collegiate Cyber Defense Competition (CCDC) team, and that’s really when it all changed for me.

About a month into training for the competition, I’m sitting at a CentOS terminal when this tattooed bald guy comes up to me and says, “You like this shit, kid?” I respond with, “Yeah, man, I’m having a blast,” nervously. He then simply says, “Give me a call tonight, man; we’ll chat.” This man was one of the mentors for my CCDC team, but what I didn’t know until later was that he was also CDC (Cult of the Dead Cow). Long story short, during the years I was about 18 to 20 years old he was my mentor. He taught me about the “old school days,” talked philosophy, pushed mandatory Phrack High Council reading material, and preached that FreeBSD is God. Over those years we became good friends, and eventually he said I was ready to join his team as a junior penetration tester, with a specific focus on the web. App sec came naturally for me since I was a natural software developer, so as I grew within the company, I was able to transition into the red team as the “web kid.” Ah, good times. Nowadays I just feel old, and I’m bald at 25.

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

Honestly, I think that passion is everything. Passion is what drives you to continue to learn and constantly take on challenges because they are more interesting than watching your favorite Netflix show. Of course, you have to be technical, and it really helps if you know a little about everything but also a lot about one subject. Too often, people try to be the best l33t hacker and know everything about everything, until they realize exactly how vast the technical landscape is.

Understand that a red team is just that—a team. Every person plays their part and has their specialty. If you want to join a red team, I’d say double down on your specialty, stay passionate, and always be curious. I believe that this energy can be seen from across the room, and a candidate in this position will be a quick hire. You can always teach technical skills, but you can’t teach, much less force passion. Also, get involved in the community and put yourself around others and soon enough you’ll begin to hear about positions.

“If you want to join a red team, I’d say double down on your specialty, stay passionate, and always be curious.”

More practically, I would also say that taking the time to first be a blue teamer, system admin, software dev, or network engineer is key if it’s in your cards. How else will you be able to practically understand environments both culturally and technically if you’ve never been on the other side? I think the best red teamers are previous blue teamers, just like red teamers make fantastic incident response folks!

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

Now I’m young, but I would say that back in the day “teetering” on the lines of the law was a given. You didn’t have these massive amounts of CTF challenges, Hack The Box, vulnerable VMs, and training courses. The world was your lab, so you learned by doing…practicing on prod, baby! Today, things have changed. There is a plethora of training materials, classes, and labs to simulate real-world environments so that you can emulate the attacks all within the confines of the law.

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

Because it sounds sexy to be part of the red team, everybody wants to call themselves that. Red teamers are seen as the grown-up versions of penetration testers. You do penetration testing for a while; then you go to the big leagues, and now you’re red teaming! I’ve spoken to people who claim they are red teamers, and it’s just a team of one within the organization. There is no “I” in team. The allure of wanting to be classified as a red team has muddied the definition to the point where any offensive consultant says they are a red teamer because it is cool to say. You have to get back to the roots of where the term comes from.

What is one thing the rest of information security doesn’t understand about being on a red team? What is the most toxic falsehood you have heard related to red, blue, or purple teams?

As a red teamer, your true goal is to help the blue team and emulate attacks and scenarios, not break everything and start celebrating (in front of the blue team at least). The red team is there to help the blue team, not break the blue team’s spirits and pillage villages. There is no (or shouldn’t be) a red team without a blue team, even if the red team is a drop-in consultant shop. There is always an adversarial stance between the two, and it is reinforced on both ends. The blue team is mad at the red team, or the red team brags about owning the blue team. It isn’t about who wins; it’s about training together to make the organization’s security posture stronger as a whole.

When should you introduce a formal red team into an organization’s security program?

When you can actionably digest the results of the red team’s findings. If your security program is immature and you don’t do any threat modeling, letting a red team loose throughout your environment will tell you what you already know—that your security program needs work. First take the time to understand your environment, your security controls, and your potential pitfalls. Once that happens, you can start to bring in the attackers and see where you stand.

How do you explain the value of red teaming to a reluctant or nontechnical client or organization?

Reinforce the fact that we are here to help, not break everything and walk away. This goes back to the natural adversarial stance between the two. We are here to emulate your worst-case scenarios in a controlled fashion, and afterward we will be here to help every step of the way. Too often people see red teamers as those who create more work or leave a bigger headache once the engagement is done, and are reluctant to perform red teaming.

“Reinforce the fact that we are here to help, not break everything and walk away.”

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

Yeah. Definitely antivirus.

Have you ever recommended not doing a red team engagement?

Absolutely. I’ve gotten requests to have a red team engagement on X environment to demonstrate impact or “see how secure it is.” There have been several times when doing an “offensive” architecture review or a review of the security controls in place may be more effective. This allows the customer to understand the theoretical attacks and how we would approach it, assume successful attacks, and approach implementing security controls accordingly.

What’s the most important or easiest-to-implement control that can prevent you from compromising a system or network?

Implement the principle of least privilege wherever possible. This is cost effective and can prevent some major splash damage upon compromise. Also, keep everything up to date. Lack of patches will be your downfall.

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

Not staying within the rules of the engagement is a breach of trust and also does not provide the exercise its due diligence. I think that breaking the rules results from a selfish desire to prove yourself as 133t or placing the priority of a breach over how it will affect the environment. If you breach the environment but topple over production systems, doesn’t that make you the true bad guy? Your job is to provide business value to the organization, not obstruct it. Stick to the rules; they are there for a reason. If you disagree with the rules, kindly start a conversation as to why and promote a revision.

If you were ever busted on a penetration test or other engagement, how did you handle it?

I’ve always had pretty bad anxiety. I was on a physical penetration test, and after I got onto the floor, I selfishly sat at this lady’s cubicle for two hours just casually performing the assessment. No big deal, just a new employee here. I even asked my “new co-worker” what the password to the Wi-Fi was. It wasn’t long before people started to walk past me several times and whisper to each other before they asked for my badge and eventually called security on me. When they caught me, I shakily pulled out my “get-out-of-jail-free” paper and explained myself. They were pissed, and I just kept sweating and trying to laugh it off, hoping it would lighten the situation.

As I was getting escorted off the floor, employees were looking at me like I was a serious criminal, which didn’t help my anxiety either. I shouldn’t have stayed at the lady’s desk. I had the LAN Turtle beaconing out as soon as I had gained access to the floor, so there literally was no need. To be fair, the mistake they made was escorting me to the elevator and not escorting me outside of the building, so I just went two floors down and sat at another cubicle. I was young and dumb, but looking back on it I still laugh.

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

I think sometimes the methods used to social-engineer people can get really dicey. I personally wasn’t involved in this, but I heard about someone actually getting the client served a falsified court document instructing them to go to a website and schedule their court date. The website snatched their credentials, and they were successful. I don’t have the gumption to do that. The emotional toil put on the client must have been pretty heavy.

How does the red team work together to get the job done?

Red teaming consists of a team of offensive consultants who bring a variety of specialties to the table working cohesively to accomplish the objective. You must rely on each other. For example, if you are a web guy and you pop shell on a web server, pass the shell off to the person with the most experience doing privilege escalation or lateral movement. Once again, you rely on your teammates and work selflessly. All the members of the team should keep good documentation and track everything they do, as it will be critical in the reporting phase. Each person should contribute to the report and, if possible, have a technical editor make sure everything is smoothed together and the language reads well. Delivery to the blue team should also be performed as a team. Either you can take turns walking through the break and explain which role applies to you, or you provide the attack narrative and have each member on standby to explain specifics if requested.

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

I’m a big fan of helping blue teams, so I try to provide as much remediation support as possible. I take the time to understand their security controls and how things look from the blue team side. From there, I can try to truly explain what the failing control is. Lastly, I give them actionable remediation recommendations that are specific to their environment. You can just say “fix all input sanitization” and leave it to them to provide the solution. Help them out, understand their environment or predicament, and try to come up with the solutions together.

If you were to switch to the blue team, what would be your first step to better defend against attacks?

My first step is to provide education into offensive capabilities, attack scenarios, and true objectives and motivators of attackers. For example, I still do a ton of application development. Throughout my entire development lifecycle, I’m adjusting how I’m architecting solutions or how I’m developing stuff simply because I know how I would attack it. As you develop, or defend, you must keep the adversarial mind-set at the forefront.

What is some practical advice on writing a good report?

It sounds generic, but really know your audience. Your objective isn’t to show off; understand that everything you provide should be actionable in some way. Also, your engagement isn’t known for how sweet your hacks are, but for your deliverable. The report is the primary thing they are left with when you move on to your next gig, so make it count. It’s like dropping off your résumé after you introduce yourself.

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

Typically, I try to discuss security best practices as opposed to failed controls. Like, “Hey, client, it’s standard to implement X because it prevents Y.” It is the opposite of saying “Hey, client, you should implement X because your current X sucks.” I realize that may have been overly casual, but you get the point.

What nontechnical skills or attitudes do you look for when recruiting and interviewing red team members?

The ability to communicate effectively and to understand the bigger picture. If you can’t explain the l33t hacker hacks you performed, how can you expect the client to understand what their pain points are and effectively implement mitigating controls? Also, exercise sympathy. I get that you are excited about your l33t hacker hacks, but you’re not here to brag. Sometimes you have to be able to step out of the terminal and understand the true objective.

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

I think it all boils down to the ability to adapt. You see a lot of red teamers fold when the tricks they already know fail or the tutorials they read aren’t giving them shell. I’ve seen several cases where the big break is right on the other side of banging your head against the wall because you are at the point of giving up. Being able to go that next step and leave the realm of comfort makes all the difference. Lastly, I think it goes without saying that a good teamer “thinks outside of the box.” In this case, the box would be the comfort zone and the tricks you know so well. ■

Tribe of Hackers Red Team

Подняться наверх