Tribe of Hackers Red Team. Marcus J. Carey. Читать онлайн. Newlib. NEWLIB.NET

Автор: Marcus J. Carey
Издательство: John Wiley & Sons Limited
Серия:
Жанр произведения: Зарубежная компьютерная литература
Год издания: 0
isbn: 9781119643333
Скачать книгу
the most important or easiest-to-implement control that can prevent you from compromising a system or network?

      Something that I have mentioned a few times in conference talks is a creative practice that legitimately caught us on an engagement. The organization used log review as a punishment of sorts for almost anything in the office. If you were late to a meeting, lost a wager on last night’s game, or failed to contribute to a swear jar, you earned log review time. The manager handed out logs from a different team for review every week, and they would produce a write-up on the most serious thing they found for the teams afterward. This had a few benefits. All teams knew that their logs would be reviewed and likely were more thorough as a result, and there was an obvious focus on security in all departments. Fresh and curious eyes were able to find anomalies that would have otherwise been lost in the noise, which led to the discovery of compromise without the use of any expensive security appliances. Finally, skills and knowledge were passed between the teams, which kept people engaged and, I believe, more satisfied in their work.

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

      The rules of engagement (ROE) are absolutely critical and need to be ironclad. Trust and professionalism are paramount to the ultimate success of a red team. If you violate the ROE, you have broken the trust the organization has put in the entire team. The time to question and adjust the ROE for everyone’s benefit is before the engagement begins. The level of access a typical team achieves during an assessment is likely greater than that of any individual admin or IT section in the organization. That trust should never be violated.

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

      I have been busted many times during assessments and could probably write an entire book on those interactions alone. One of my favorite incidents involved signing up for a conference room through social engineering, tailgating into the building, and then joining several members of the red team while we plugged into the target’s internal network. After using traditional methods of acquiring credentials, I attempted to utilize those credentials on the first interesting hostname I saw in Active Directory. We underestimated our audience, and the use of credentials over the network directly to a workstation from another workstation IP address caused an alert to prompt from their host-based security product. The warning contained my IP address, the account that I was using, and what file I was attempting to access. Unfortunately, the machine I targeted was the machine being used to project slides for a meeting that the entire IA section was attending. They jumped into action and were able to figure out where we were before I realized that I had tripped anything. We were busted, and it was all my fault. They ran into the room where we were quietly working and demanded to know who we were. Feeling responsible for the situation, I firmly told them to go get their boss so we could discuss their disturbing our work. This confused the group, but they declared that they would be right back. Afterwards, they returned to an empty conference room, and we endured a super-awkward out-brief a few days later.

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

      A situation that I have encountered several times is being asked to leave out specific critical findings from a report. I imagine this is common, based on discussions with other testers. Sometimes assessments come with far greater ramifications than a tester realizes. As tests have become more normal and more organizations have publicly reported being breached, it has ideally reduced the stigma that comes with poor performance on an assessment. An experienced and properly scoped red team engagement will almost always result in a successful compromise. No one should lose their job because of it unless they are found to have violated company policies or acted unethically. The point is to train and improve the security posture of the organization and not poke people in the eye. For that reason, I am against withholding confirmed findings from a report.

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

      The “team” element of red teaming is critical. No one can be an expert in everything. Having people with diverse technology backgrounds allows you to work together to accomplish the mission. Communication is important, and each member of the team should have an understanding of what the others are working on. Additionally, leadership of the team is extremely important. Each action on the network and the risk it presents of being caught or reacted to needs to be understood and analyzed. Rogue actions can be detrimental and lead to internal conflict as well as poor results. Documentation during the assessment should be everyone’s responsibility, but it is my experience that rotating one person to combine the results into the report leads to better results.

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

      Every engagement is going to have required written or oral deliverables, but I have always been partial to the informal out-brief. This brief is free of managers and egos and is just a frank discussion of the things that were done with all who were involved. When it is done correctly, both sides benefit. Additionally, this is a great time to glean things that the organization did well or things the defenders would like you to emphasize for their bosses in order to secure support or funding.

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

      I believe that the first step in defending any environment is to map it. There is almost always a discrepancy between the number of machines an organization believes they have and how many they actually have. It seems so simple, yet there are often surprises that have been either forgotten over the years or never documented. You have to figure out what is there before you can ever hope to defend it.

       What is some practical advice on writing a good report?

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

      The narrative is what differentiates a red team report from a pentest report, and for many it is where much of the value of a red team engagement comes from. What techniques did you use? What adversary were you emulating? Why did you choose that group over other groups? All of those questions should be answered in a red team report. The reader should learn not just what you did to them but how their environment could be realistically attacked in the future.

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

      It is important to understand that you don’t know why decisions were made in an environment. It is so easy to recommend specific improvements without having any knowledge of business needs, which makes your recommendations potentially worthless and may actually serve to discount your findings entirely. Presenting findings with generic recommendations for how to improve their security posture is likely the best a true red team will be able to do. You need to have a better understanding of an organization’s needs to make specific recommendations in a lot of cases. You just don’t get that from the adversarial perspective.

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

      Empathy and passion are what I look for. Passion keeps you learning new technologies and not becoming complacent with the same techniques you