by Nicolas Oberli | Nov 11, 2021 | Penetration Testing
It seems like everyone is talking about red teaming these days, and for good reason. Red teaming can be an incredibly useful exercise for organizations looking to test their threat detection and response capabilities as well as their maturity as whole. It’s an evolution of the traditional network pentest, but there are key differences in when they should be used, how they’re executed and what type of information they provide. If you’re considering a red team engagement, consider this your guide to getting started.
What is red teaming?
In essence, red teaming is a vertical attack that demonstrates the feasibility of real-world scenarios by identifying and chaining together vulnerabilities in a client’s network to reach a specific objective. The objective of the red teaming exercise could be exfiltrating sensitive data from the internal infrastructure or establishing domain admin access in Active Directory or anything else the client desires.
Red teaming vs. pentesting
Both red teaming and pentesting fall under the category of Offensive Security. However, where red teaming is considered a vertical attack, pentesting is a more horizontal attack. The goal of a pentest is to identify as many network vulnerabilities as possible and flaws in assessing existing security controls.
A red team exercise, on the other hand focuses on identifying the weakest vulnerabilities in an organization’s processes, technologies and staff. This is done in order to form a fully functional attack path with the primary goal of reaching a specific asset or completing a specific action. In other words, it simulates what a motivated attacker would be capable of without having any information about the infrastructure.
Despite their differences, it’s important to note that red teaming and pentesting are not opposites, but complementary. They can work together to show the entire company’s exposure as well as the feasibility and impact of a full attack path against it.
| Pentest |
Red Team |
| Horizontal attack that identifies as many vulnerabilities as possible |
Demonstration of the feasibility of a real advanced attack (vertical path) |
| Goal is to uncover total attack surface |
Goal is to reach a specific objective undetected |
| Testing for flaws in network infrastructure and security controls |
Testing for vulnerabilities in processes, staff, and technologies |
| Automated scanning and manual testing and manipulation |
Advanced techniques and custom tools |
| Focused on exposure of digital assets |
Transcends digital boundaries |
| Periodic |
Situational or periodic |
| Can be known to employees |
Unknown to employees |
How red teaming works
Because red teaming is limited in time and has a range of potential attack vectors, it’s important to have a repeatable methodology in order to ensure you’re able to reach the objective set by the client. At Kudelski Security, we use the following five-phase methodology.
Phase 1 – Passive reconnaissance
The first step is to conduct manual research using open-source intelligence, or OSINT. The goal is to gain context about the company — number of employees, email addresses, leaked passwords, company-owned domains, web applications, etc.
Phase 2 – Active reconnaissance
Based on the information gathered from Phase 1 — for example, which IP address is exposed on the internet — we can use automated tools to scan the network for vulnerabilities that could be exploited later. The scan is carried out silently so as not to be detected by security equipment or the SOC.
Phase 3 – Exploitation
After phases 1 and 2 are complete, we have enough information to build out different scenarios to exploit. During exploitation, we can use all the vulnerabilities we’ve identified and chain them together to reach the client objective. Exploits can be very targeted. For example, a broad phishing test done during a pentesting exercise may not be very successful. But a red team phishing test will be very targeted based on specific roles and the information those roles would have access to. Those types of phishing campaigns tend to be much more successful.
When we achieve a successful exploitation, we can move to either phase 4 or phase 5. It all depends on what part of the IT infrastructure we’re facing.
Phase 4 – Lateral movement
When we succeed in infiltrating the infrastructure, the next objective is to expand access through lateral movement in order to reach our targets. The first thing to do is to figure out what we can reach with our current level of access. Then, once we reach it, identify what’s reachable from that place in the network. We do that until we’re able to reach the target data or assets. Once there, we can go to phase 5.
Phase 5 – Stabilize footprint and exfiltrate data
Even once they’re able to connect to the internal infrastructures, attackers still want to establish a stable connection in order to exfiltrate data. Typically, this means installing a backdoor on the server in order to ease exploitation, gain and elevate privilege, install other tools and eventually exfiltrate the target data — all while evading detection.
When to Use a Red Team Exercise
When you want to move beyond theory into practice. A pentest, unlike a red team exercise, does not show feasibility of an attack, only all the points where you are vulnerable. It would be impossible to fix all those vulnerabilities without knowing how they could be used to reach an asset. Because a red team exercise exploits everything in order to form a full attack path. It’s concrete proof that an attack is possible with clear steps for remediation.
When you want to put vulnerabilities into a business context. With red teaming, you are able to demonstrate the consequences of a successful attack scenario. This is important when talking to management about a vulnerability, because most of the time they will not have the technical background necessary to make the connection between a vulnerability and the business impact. After a red teaming exercise, you will be able to clearly show how an attacker would be able to gain control of the infrastructure and block operations because of a chain of vulnerabilities.
When you want to understand your blind spots. After a successful red team, you will have a report that shows all the tools and techniques that were used during the exercise. Many times, red teamers are able to evade detection because the techniques they’re using are unknown to the client. With the report, the client can learn about these new methods and use that information to harden their defenses.
When you need to get buy-in from the C-suite. If you are a CISO tasked with presenting risk to the C-suite or board, it’s important to parlay that risk with facts about the consequences of not acting. If it’s not a clearly demonstrated fact, you’re going to have trouble building the trust you need to get buy-in. With a red teaming exercise, you have a proof of concept that can help you gain support of management to develop your cybersecurity defenses.
The content in this blog was originally presented in the webinar “Continuous Improvement to Your Application Security.” To learn more about Kudelski Security’s pentesting and red teaming services, visit https://kudelskisecurity.com/solutions/by-capability/penetration-testing/.
by Zach Luze | Oct 27, 2021 | Penetration Testing
In this two-minute read, Zach outlines three simple things that CISOs and security leaders can do to reduce the modern enterprise attack surface: discovery, contextualization, response.
You can’t secure what you don’t know exists; you can’t hide what you don’t know is exposed.
John Binns, the self-professed perpetrator of this summer’s T-Mobile breach, reminded us of this when he shared the striking image of his entry point: a publicly exposed router. It was the first domino in a kill chain yielding millions of exfiltrated customer records.
Source: WSJ
The Problem: A Story of the Old and the New
The problem is not new, and many organizations believe it addressed by existing vulnerability management and red teaming efforts. However, our old methods have not kept pace with the growth and transformation of what constitutes an organization’s attack surface. Propelling this new challenge are two drivers: first, legacy/forgotten assets; and second, novel/unknown assets.
- On the legacy front, organizations host heaps of debt from decades-old domains and M&A activity. This means that vulnerability management activity may not include all exposed assets. The assets included produce overwhelming volumes of results, usually prioritized by CVS scores and existing organizational knowledge (e.g., that’s our ERP system, we need to fix that vulnerability) versus granular analysis. This leads to many assets – like overexposed routers – being overlooked.
- The problem of the new may be even more pressing. SaaS makes shadow IT easy, which expands the perimeter to user identities and data movement across thousands of platforms. If we enumerate only our datacenter and known cloud locations, we miss every “as-a-service” entity our users have made their own.
The Solution: Dedicated Attack Surface Reduction and Data Leak Assessment
More than likely, the router at the root of T-Mobile’s breach was captured by at least one external vulnerability scan and in-scope for multiple red team assessments. But in the face of competing priorities and limited scopes, no-one made their way down the list to discover it. To address this challenge, organizations must dedicate time and resources to comprehensively discovering, contextualizing, and responding to their attack surface.
- Discovery can no longer be limited to a set of known IP addresses and domains. This means non-intrusively querying external environments and augmenting vulnerability-centric with data-centric analysis to find your data outside of your known environment. Additionally, organizations must enrich discovery with business knowledge, like past M&A activity, to uncover forgotten assets and repositories.
- Additionally, current methods of contextualization based on CVSS scores and known understanding of criticality need to become more comprehensive. Automation always helps, but at the end of the day, some manual analysis will be needed to vet newly discovered assets and potential data leaks.
- Finally, organizations should design boundary-spanning response processes to address problems uncovered outside of their known perimeter. For instance, if security discovers a potential source code leak to a personal GitHub account or accidental data exposure from a partner, privacy or legal needs to be engaged for resolution.
In summary, a transformation of the technology landscape requires an equal transformation to secure it. Vulnerability management of known assets, the security industry’s current approach to attack surface management, is an important starting point, but is just incomplete.
To address decades of technical debt and the SaaS-powered reframing of “perimeter” to identity and data, organizations must augment current practices with non-intrusive, comprehensive, and often data-centric discovery approaches.
To truly understand and protect their digital footprints, organizations must reconsider – and discover – what comprises it.
by Ricardo El-Darwish | Jul 4, 2018 | Penetration Testing
In August 2008, the DEFCON security conference held its 16th session in the Riviera hotel in Las Vegas, Nevada. Among the litany of brilliant talks on computer security was a 30-minute presentation by Renderman on the topic of attacking client computers rather than servers. It was dubbed “How shall I pwn thee, let me count the ways” and it covered attacking an employee through his network connection, software, and Bluetooth. It was very well received.
I was in the audience for that talk. It was eye-opening; at the time, in my experience, the industry was emphasizing hardening infrastructure against attacks coming from outside companies’ walls. The point Renderman made clear, at least to me, was the ease with which one could compromise employee devices while they are in transit and the ease with which, once back in the office, these compromised devices could be used to access resources that are difficult (if not impossible) to attack from the outside. That same year, I began providing security awareness coaching to my clients, both individuals, and groups. These mostly-informal, 15-minute sessions with employees attempted to convey the fact that one needs to be mindful of the risks inherent to using technology while not being paralyzed by the fear of compromise. When we started offering security awareness training sessions at Kudelski Security, I was delighted to be given the opportunity to contribute to what I think is a cornerstone of corporate security. If our people don’t know how they can be attacked, how can we expect them to defend themselves?
Security awareness coaching is an art rather than a science: you are trying to convey the notion of good security hygiene to people that may not be intimately acquainted with technology, let alone security. As well, more often than not, the people who you are trying to coach are busy and stressed, on top of being confused by the topic of information security. One approach that I think helps in these sessions is to share my experiences as a pentester, to provide concrete examples of what constitutes risky behavior before discussing best security practices for employees to follow.
For example: if during a security engagement, we find an insecure guest Wi-Fi access point, we may try to capture employee password hashes by injecting malicious HTML tags in web traffic. Though one could make a point that the infrastructure, in this case, would greatly benefit from some hardening, what could an employee do to avoid risk? There are several good practices here: the employee could, for instance, choose to use the encrypted corporate access point rather than the guest access point. Using the guest access point with the corporate VPN could also be a viable alternative. If the employee knows how to differentiate between an encrypted and an unencrypted WiFi network, then this could make the difference between an attacker gaining access to the employee’s sensitive e-mails or not.
One challenge that security awareness trainers face is that of producing updated, relevant content. For example: in 2017, ransomware was a dangerous – and rather endemic – family of malware that affected hospitals[1], police stations[2], home users and companies alike[3]. Then, in 2018, ransomware infections took a sudden dive[4]. Is this due to the invention of a miraculous counter-measure that drastically improved computer’s defenses against ransomware? Sadly, no. Attackers realized that it was much simpler and more lucrative to run cryptominers and moved away from ransomware. Trainings should, therefore, focus on how to help users identify cryptominers. If your employees fail to see the relevance of their training, they are unlikely to pay heed to it.
A venerable figure in the infosec community once said that security is a process, not a product. We cannot buy a turn-key solution that magically transforms our infrastructure into an impenetrable fortress. We must make do with a judicious mix of hiring the right people to secure our networked services, acquiring (and tuning!) products that help us eliminate threats, and educating our staff to be sensitive to computer-related threats. This is by no means an easy task; however, it is a vitally important one and success depends on following best practices in all three areas instead of devoting energy to only one.
Interested? Follow the links to more info on security training or penetration testing.
[1] https://www.zdnet.com/article/us-hospital-pays-55000-to-ransomware-operators/
[2] https://www.nbcnews.com/news/us-news/ransomware-hackers-blackmail-u-s-police-departments-n561746
[3] https://www.tripwire.com/state-of-security/security-data-protection/cyber-security/10-significant-ransomware-attacks-2017/
[4] https://www.tripwire.com/state-of-security/security-data-protection/3-malware-trends-watch-2018/
by Ricardo El-Darwish | May 30, 2018 | Penetration Testing
Last year, my colleague Fabrice wrote about the benefits and challenges of penetration testing to businesses’ security. I decided to revisit the subject and provide more insight as a practicing security engineer.
An opportunity to compile a security checklist
Something I hear a lot when talking shop with colleagues and friends is that the companies they work with aren’t ready to undertake a penetration test (‘pentest’ for short). I find this notion puzzling. Why do they think they’re not ready for a pentest?
“Because you’d get in too easily” is a frequent response. I find this amusing because that is an excellent reason to conduct a security assessment. A pentest is not a validation check that one undertakes when one is sure that the attacker can’t get in; it is an exercise that helps a company identify and prioritize security issues that need to be fixed. It helps defenders understand how an attacker would get in, why it is easy to get in, what impact one can expect from an intrusion, and, hopefully, what countermeasures can be put in place to detect and prevent attacks.
I once had the opportunity to run an internal security assessment for a company that had never had one done before. The first day of the engagement, the client apologized for not having a wired connection ready for us and asked us to make ourselves comfortable while we waited. In the meantime, A guest Wi-Fi connection was available for our use, should we wish to check our mail and prep for the engagement. By the time our contact came back to say the wired connection would soon be ready, we had remote access to several internal systems.
It was easy to gain access to this particular client’s infrastructure; does this invalidate the pentest? Not necessarily. During our assessment, we were able to confirm that an attacker could compromise sensitive business information and cause long-term damage to the client’s systems; it’s one thing to suspect your systems are vulnerable, but to have those suspicions confirmed along with identification of an attack path and a realistic timeframe for an attack is an entirely different kettle of fish. More importantly, our assessment provided a prioritized list of what should be fixed along with suggestions on how to remediate. This ‘security checklist’ is in many ways the best thing a pentest can do for you; it provides you with a starting point for building your defenses so that you can make your security investments count.
A chance to test your defenses before they are tested for you
In addition to providing you with a prioritized list of security issues to fix, pentesting can provide valuable insight into how good your defenses are. Let’s say you’ve invested significant resources into building up your security operations center (SOC). How good are you at detecting intrusion attempts? How fast does it take your team to respond? Are you able to determine how many systems were affected by the latest attack? What is the impact of a successful phishing campaign within your organization? These are questions that are practically impossible to answer unless your SOC has had the chance to test its mettle during an attack.
On one occasion, we conducted a two-part security engagement of a client infrastructure: an external pentest followed by an internal assessment. When I came in for the internal part, the client gave me a tour of their security center, which featured several large screens with the latest security alerts. With a grin, he pointed out a series of alerts tagged with a familiar IP address: their systems had correctly detected not only our automated scans but much of our manual probing as well. They’d also had the chance to use our tests to tune their systems so that alerts would flag an attack without uselessly flooding their monitoring tools with redundant information.
The most productive pentests are those that involve communication between the blue team and the red team; by getting your defenders to talk to the attackers, you can see if your defense has any blind spots. It also gives your SOC the chance to test out some of their response processes or tools that they would not have the opportunity to cut their teeth on otherwise.
A way of seeing how prepared your staff is to attacks
Pentesting is not only a good training opportunity for your team; it is also a good means to evaluate the readiness of your most important asset against attacks: your employees. By that, I do not mean your SOC team: I mean non-technical staff and technical staff alike, throughout your organization. When we organize simulations of phishing campaigns, we request the authorization to send email to a representative population of our client’s staff, so as to realistically gauge the chances of a successful attack and estimate its impact. If the risk is significant, we’ll recommend security awareness training and then a follow-up simulation. You would not believe how a mere two hours of security awareness can benefit your company’s security!
The big picture
Penetration testing is a discipline that businesses often approach with a sense of apprehension, feeling that it is a better investment of time and resources to buy security solutions before mandating a pentest. While it makes a certain amount of sense to be prepared before one is conducted, I would contend that a pentest is a great way to evaluate how your assets, infrastructure, and staff can best benefit from strategic investments in security tools and training.
by Fabrice Guye | Oct 31, 2017 | Penetration Testing
Usually a pentest is considered to belong to the realm of technical, geeky activities and is supposed to answer the question: “can my company be breached?” Unless you’ve been living under a rock during the last 10 years, you’ll know the answer is a simple “yes.” It’s just a question of the attacker’s time spent and ability.
There are a lot of pentests available on the market and now is a good time to book one, either to end the year with your security vulnerabilities identified and remediated, or to start next year on the right footing. To ensure you book the right type of pentest, you need to be clear what a good pentest can do for your organization.
Almost all security companies have a “pentest” services in their portfolio; those that don’t usually employ a third party to do a pentesting engagement for them. Note that I have received many strange requests, including for a pain-test. This requires an altogether different skill set… Anyway, I digress. Over the last years I’ve seen so many pentest reports, embedding thousands of lines of scripts and logs, highlighting tons of vulnerabilities in huge tables with red flags, some of which are described as potentially critical for the company.
But now here is the interesting question: does the report really present a relevant reality? What can the company do with such report? Are the findings actionable? At first glance, as most of the report focuses on prioritized key elements, you might say “yes, it is.” And that’s true, having priorities listed in a pentest report is good practice. But dig a little deeper and you’ll see that most of the time, unfortunately, the priorities reflect the severity of the vulnerability. Herein lies the real pain point. Relying just on severity level does not translate into real relevance to the company.
Much more needs to be taken into account when defining a priority. Here’s a simple example that illustrates why: is a critical vulnerability on a test server that is disconnected from the rest of the network really critical? Although a vulnerability is critical, the level of priority should not be defined as high, as the impact on the business will be low or zero. Another example: would it be worthwhile for the client to read a top-1 priority remediation related to a critical vulnerability that indicates that thousands of machines should be upgraded to the latest OS version? Again, although vulnerability is critical, the business context should be considered to present the best remediation actions and the related effort, because – as anyone knows – it is far from simple to upgrade the whole company’s IT.
The risk-based approach to pentesting is something different altogether. Its different approach can be summarized in a few words: to present concrete, actionable and realistic information, it is essential to gather a good understanding of the Client. And when we say “Client”, we mean a point of contact who does not focus on the technical elements of an organization’s security, but rather someone with a broader understanding of the company, its business, its activities and its risk position and appetite. This also means that the most important part of such pentest engagement is the preparation phase during which several discussions with the Client take place in order to understand the business of the company, the company’s risk posture, its concerns, and its assets. In summary, the context.
With such information to hand, the pentest engagement can be performed differently. It is no longer a geeky activity for a geeky Client. It demands that the pentester has a Client-oriented vision, able to understand what a risk is, how they should invest their time during engagement, and even more importantly, how to report a vulnerability and how to classify it in the order of priority.
This approach to pentesting delivers a radically different result. The report of a risk-based approach to pentesting will be different to that delivered by a regular pentesting approach.
No more tons of logs or scripts, no more lists of thousands of vulnerabilities; all this content will appear in the appendices and used as a support to create the actual report where the added value is present. It is not that all this content is unnecessary, these activities need to be executed but they should not to be exposed as such. They should be deeply analyzed and contextualized to provide valuable content.
This is the difference between a vulnerability assessment (which is almost exclusively raw data and mostly performed by automated tools) and a genuine pentest engagement. I’m not saying vulnerability assessments are never appropriate. They have their time, place, and benefits, including the fact that they are (or should be) very inexpensive and that they can provide a gap analysis if done on a weekly or monthly basis. But they will not provide the Client with information on the relevant risks as they affect the business.
The final deliverable in a risk-based approach will consider the context and will contain text, a many humanly-readable text that will not come from an automated report generator. The content will be based on risk analysis, business context, and will present realistic and prioritized vulnerabilities and remediation. It could also show how several vulnerabilities, which in and of themselves are not critical, could be chained together in a real-world attack to have a critical impact.
Finally, a pentest built on a risk-based approach is not much more expensive than a vulnerability assessment-type pentest. It is just the time investment that is different. A significant portion of the time will be invested in the preparation of the engagement, in discussion with the Client and in reporting activities. Then, the execution part will be optimized and will focus on the most important elements and areas. This will also reduce the potential impact on the Client’s operation as the engagement is more controlled, targeted and its duration is reduced.
It is therefore important to keep in mind that if a Client wants to have an actionable output, time will have to be invested in discussion with the pentest provider. If your pentest provider does not ask for it, you will receive a less actionable vulnerability assessment rather than a realistic pentest.
Make your choice.
With the end of year looming, Kudelski Security believes that it’s a good moment for security professionals to take stock of their programs and reflect openly about what works and what could be improved upon. If you are interested in understanding more about how a risk-based pentest can help improve your security posture, we can talk.
