Pizza, Pasta and Red Teaming: insights and ideas for an Italian-style report

Foreword

After more than 2 years from the inauguration of Labs, made with my friend Paolo Stagno aka VoidSec, it was perhaps time for me to write something .

But $whoami? Make yourself comfortable and go to the “Author” section at the end of the article.

The challenge

In these years, my mission, my purpose, has been to give my all for this type of project (Red Teaming, it’s written in the title), understanding its underlying importance.

The customer who has the desire and the possibility to rely on a Red Team for a real attack simulation, places enormous trust in you: in technical qualities, in organizational qualities especially in case of borderline situations, respecting their data and their operational continuity. The confidence that in asking you for an activity of this type you are actually going to answer the fateful question

“But if instead of attacking my neighbor, they had done the same thing with me, how far would they have gone?”

If on the one hand it is therefore essential to have an EXTREMELY qualified and CONSTANTLY updated team (but really, constantly), the real big challenge is to present the results of an activity that could have lasted months, involving 2-3-4-5 figures depending on the moment.

Suffering in part from imposter syndrome, in recent years I have taken some advanced courses such as SEC564 and SEC565 to understand a little in the rest of the world what they were advising to do. But we are in Italy, we are Italians, and this always involves a bit of customization.

How I structured your Red Teaming report

And here we are, to the point.

On how to make a Red Teaming report it is difficult to find information. Or rather, given the confidentiality of this type of work, it is very difficult – fortunately – to find concrete examples.

The result of the various courses, the directives issued and above all the experiences in the field, we have now landed to a rather consolidated structure.

I will therefore try to summarize in points some rationales on which in the last 3 years we have hit our heads, having no fear that this may or may not consist of a competitive disadvantage // perhaps, here, in Italy we have a bit of the vice, among us in the Cyber Security sector, to see ourselves as adversaries, so let’s try to do a good deed.

1| Deliverables

It seems a trivial thing but already here there is to sweat.

The formula that makes me feel at peace with myself today includes:

• A main, all-encompassing document, which will be the main source of discussion within the article; recipients = trusted agents, i.e. that small group of people on the customer side who knew about the activity and who remained aligned throughout the course of events.
• One or more Excel files attached, because filling the main document with pages with endless tables is ugly, and then copy-paste from pdf is hell
• A presentation of the Attack Timeline in a few simple slides, because the report is fantastic but it is also very long to read (in Italy we would say una mattonata) without a minimum of guidance; the purpose of the Attack Timeline, is to reproduce the salient events (positive and negative) according to a chronological order; recipients = trusted agents and any close or Management figures, depending on the context

2| The Structure

This is inevitably constantly evolving and dynamically dressed around the project, BUT some absolutely fundamental sections can be highlighted.

2.1| Executive Report

This part must answer the question “So how did it go? Did you hack us? Did the SOC notice anything? And what should I do? And how urgent is it? Huh? Huh?”

To do this, we have hypothesized the following sub-sections:

• Document Structure: First of all, a quick summary of how the “small” report that the reader is coming across is structured
• Test Plan, which goes through the main steps that led to the birth of the project, the construction of the objectives, the definition of the Rules of Engagement, the Communication Plan, the Threat Intelligence phase and then the structure of the project as hypothesized – first – and actually happened – then
• Objective & Goals, which resumes the purpose of the activity according to the customer summarized in some simple points that will be the mantra of the Red Team throughout the activity. Where possible, it is useful to separate into process objectives (what the Company wants to verify in terms of the quality of its maturity) and strategic objectives (that is, what the profile of the attacker that has been outlined would point to)
• Test Results, where each objective is associated with the result according to a qualitative scale

Now, depending on how many scenarios the activity is composed of, for each of them we are going to treat:

• Unified Kill Chain, which is a graphical representation of the phases of the Kill Chain by Paul Pols (https://www.unifiedkillchain.com/) adapted to the context of the scenario
• Attack Path, i.e. a graphical representation of the attack flow followed in the simulation (Infographic), which must be simple and easy to read, combined with the list of Vulnerabilities identified along the way, whether they have been exploited or not

It is the moment of the section that I consider to have the greatest added value, the Future Works & Lessons Learned.

Let us stop wanting to appear invincible, infallible, perfect, omniscient.

In conducting these activities it is human to come across mistakes, on both sides. In this section we want to tell:

• What we would have done another way if we could rewind time
• What we would do in an ideal context, with an infinite budget and time (a bit like in Physics problems at school)
• What we would recommend then as evolutionary

We then proceed with a roundup of Insights, then a summary of the most interesting things that emerged, which we are going to divide in this way:

• Strengths //yes, we Red Teamers do not always have to celebrate ourselves, but we must give the right credit to the Companies and any competitors “faced” when it is right
• Defensive Processes, so a focus on all those points where the Red Team said “wow, but here I would have expected a block”.

It is essential that these entries are perfectly mapped with the Mitre Att&ck, so as to facilitate remediation and considerations

• Security Governance & Best Practices, where we want to open a debate on some situations that do not comply with industry best practices (eg “But how is it possible that a critical application with a lot of SQLi was exposed? Had it never been subject to a penetration test before? Did the developer ignored any guidelines for secure development?”)

And finally Remediation & Follow Up, or a guide in rereading the previous points, so as to contextualize an action plan.

2.2| Technical Report

And someone here might say, “But after all the flood of things you wrote above, do we still need to dig deeper?” Oh yes. Because the above points are a great summary. But in the Technical Report we go to dissect the whole history, including technical detail, tools used, screenshots to support and so on and so forth.

We have therefore hypothesized these sub-sections:

• Attack Narrative, quite eloquent
• Findings, i.e. the detail for each of the identified technical vulnerabilities
• Focus, where it is necessary to concentrate certain details such as IoCs or Artifacts, or considerations on the robustness of credentials
• Appendix, where we go to explain the whole reference methodology

Conclusion

A Red Teaming report is something fundamental, which a company could use for months if not years.

The super-skilled-nerd-hacker-technician is therefore required to put himself in the shoes of the customer and his suppliers, trying to be as clear as possible but above all trying to highlight the really really important things.

And that’s all, folks!

Author

“Roberto Chiodi, born in 1990, in Yarix since 2017 and Head of Red Team since 2020”

A bit sad summed up like this.

Let’s add some curiosities.

I became passionate about the world of computer security by chance: I was in Cortona, at a University Orientation Course organized by the Normale di Pisa (https://www.sns.it/sites/default/files/2021-04/2008cortona.pdf) // yes, it is still not clear to me, after 15 years, how I ended up in it, but let’s move on

The luck lies in attending a speech by Fabrizio Luccio, professor at the University of Pisa, entitled “La crittografia”. ZACCHETE. Something happened.

There I decided that I wanted to pursue that path, going to Verona (https://www.univr.it/it/home) and studying – incredible but not so much – Cryptography with a pupil of Luccio, Roberto Segala.

The cool thing is that I had no idea that the work I’m doing today even existed.

Then happened incredible strokes of luck, which will be a bit the leitmotiv of my life.

Thanks to Yarix (Mirko, Diego, Nicola), to the first hard core of the Red Team (Marco – always be praised, Andrea, Alessandro, Lorenzo) I get the confidence to lead a group of crazy wonderful guys, with a huge heart and a desire to break the world and get rid of the label of “nerds who do beep boop beep beep boop” and maybe,  a little, of eternally underrated.