Tribe of Hackers Red Team. Marcus J. Carey

Чтение книги онлайн.

Читать онлайн книгу Tribe of Hackers Red Team - Marcus J. Carey страница 28

Tribe of Hackers Red Team - Marcus J. Carey

Скачать книгу

that you see implemented?

      To reverse the question, the most bang-for-your-buck control would be training. It’s easy to buy a product and hope that it works. Vulnerabilities often exist because of a lack of training or hard-to-follow processes. Receiving training and optimizing processes go a tremendous way. As mundane as it may sound, regular security awareness training is effective—and serves as a precursor to red team tests.

       Have you ever recommended not doing a red team engagement?

      My background is working with larger organizations, which I’ve always found needing/requiring a red team engagement. The attack surface/landscape has grown by several orders of magnitude and is proof that security integration is continuous and ongoing. With the rise of applications, APIs, and IoT devices, there are always quite a few red flags identified. Red teams can help flag and assess these vulnerabilities to ensure other attackers are not taking advantage of such issues.

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

      A firewall. There’s very little reason for many ports to be able to communicate outside of your organization. Most modern firewalls can also assist with creating rules that block malformed application requests.

      Additionally, a firewall works great for blocking known bad addresses and other artifacts based on signatures and other techniques. As an organization matures, a firewall is a keystone resource to collect logs from.

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

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

      Fortunately, I’ve never been completely busted. However, I have made several messy mistakes creating logs in sources I did not want to be seen in. More specifically, crashing an application can be an attacker’s worst nightmare. When critical services crash, there are many logs created in several sources. It’s the attacker’s responsibility to clean up after themselves. I’ve had a few engagements where I’ve given an engineer a perfect opportunity to upgrade by crashing a service—which ultimately led to a patched vulnerability. If engineers have verbose logging enabled, there’s a possibility that your payload will be revealed and give away the fact that an attack is underway. In situations like this, I make it my mission to find an alternative route for exploitation to ensure that I can clean up my logs and restart crashed services.

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

      The biggest ethical quandary I face is teaching exploitation. With great exploits come great responsibilities. I spend part of my time teaching educational content on YouTube, with a portion of it being exploitation. While teaching this skill, I put in extra effort to narrow the focus on professionals in the InfoSec field and avoid viewers who are searching How to Hack {Favorite Website Goes Here}.

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

      The red teams that show the most value are the teams that have great documentation practices. Detailed documentation leads to detailed reports and less stress at the end of an engagement. Taking the time to document your work is a team sport in itself. Just one individual not providing detailed documentation could mean missed learning opportunities for the entire team and less understanding of what was completed for the customer. Lastly, if the results are documented well enough, then debriefing blue teams will be a lot more straightforward.

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

      Before an engagement, I work with my customer or organization to set expectations and document each phase of my work. Assuming expectations are set beforehand, it’s easier to collect data/create metrics on what is important. My approach to debriefing is typically sharing details on three pillars: evaluation, scoring/severity, and recommended fixes. My experience with organizations has been ongoing, and I’ve been frequently involved in applying the fix and assisting onboarding new application builds.

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

      I find myself constantly working with teams focused on defense. There is an abundance of applications with open source packages and libraries. When I’m able to find vulnerabilities in source code, I work closely with engineers to patch and with blue teams to search for activity. After finding vulnerabilities, I enjoy hunting for evidence of similar discoveries. My recommendation for defense is to set up perimeters. It’s vital to set up strong perimeters around your critical assets and entire organization.

       What is some practical advice on writing a good report?

      Writing a report can seem like a daunting task if you’ve had negative experiences in the past. For a while, writing was something that I thought I couldn’t get excited about. I learned that it’s all about mind-set. By framing the work as valuable and exciting, I’ve made documentation and reporting the favorite aspects of my job. I’ve also learned it’s the easiest way to show long-term value. I recommend shifting to a positive mind-set, making it fun, and being proud of the work. Documentation and reporting are the trophy case to your hard work.

       How do you ensure your program results are valuable to people who need a full narrative and context?

      Ensuring value can mean many things. It’s important to first know what is the metric for your team’s value. If your team is being measured on a number of engagements per year, then begin collecting that data on that metric and similar metrics. If a red team and blue team are working cohesively as a unit, then each engagement will introduce new results, and the data will reinforce this. If your red team is finding similar or identical findings each engagement, this is a cautionary sign that all teams are not working closely together or the importance is not being highlighted correctly. This is a great opportunity to get involved and provide more contextual information related to findings.

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

      Outside of basic security recommendations, it’s vital to search for the root cause of what introduced a vulnerability. Introduce questions such as these: Is it a software issue? Is it an untrained engineer? Is there an organizational process that’s delaying teams from patching? More insightful questions will establish more trust with the customer and make for more interesting red team engagements in the future.

       What nontechnical skills or attitudes do you look for when recruiting and interviewing

Скачать книгу