Getting breached is the surest way to learn your organization’s cybersecurity vulnerabilities. And that’s why you need to hack yourself before threat actors do. A cyber breach and attack simulation, also called red teaming, is best to understand vulnerabilities in practice, rather than just theory. What can you do before, during and after a simulated attack to boost your defenses?

Types of Simulations

Some methods for finding vulnerabilities are easily confused with each other. Here are three basic approaches:

Vulnerability assessment: This is a routine semi- or fully-automated scan for publicly known vulnerabilities. The system harvests data from the network and connected devices and compares this to a database of known vulnerabilities. This is not a simulation exercise.

Penetration testing: An example of how security systems could be breached. It shows how a threat actor could gain access somewhere in your IT infrastructure and make their way to sensitive data or systems. This is mostly manual and applies the skills of the pen tester to find a way in.

Red teaming: Also known as red team versus blue team exercises, these simulate a sustained attack (by the red team) to test the way your defenders (the blue team) detect and respond to an attack. The idea is to test systems, processes and people all at once.

The last two are sometimes confused with each other. What is pen testing compared to red team testing, exactly? The main difference is that pen testing tests specific systems (hardware and software). It’s human versus machine. Meanwhile, red team versus blue team exercises test your digital defenses as a whole — hardware, software, people, policies, procedures and more. It’s one team of humans against another, each with its respective tools and processes.

Before the Breach and Attack Simulation

The pre-simulation phase of red team security is often the lengthiest and most important part. Firstly, consider how often you should run red team versus blue team tests. They can take place once a year, every six months, quarterly, monthly or some other frequency.

Determine whether you’ll hire internal red teams or use internal staff. Each approach has merit, but decide in advance.

Gather threat intelligence before the faux attack. Research threat actors most likely to target your industry and deploy their aims and methods in the attack plan.

Establish the scope and purpose of your exercise. Make sure you identify targets and also non-targets — resources that are off-limits. Form, clearly articulate and document your objectives. One isolated red team objective might look like this: infiltrate a specific network segment, steal the credentials of a leader (C-level or an IT administrator) and exfiltrate financial data.

Get approval and buy-in from all leaders and stakeholders. One challenge is that offensive cybersecurity tools tend to be harder to justify on a budget than defensive ones. So take some care in making the return on investment case for the power of effective red team exercises and the importance of using the right red team tools in conducting them.

Define a starting point for the breach and attack simulation. This should be based on the assumed knowledge of the attacker. Are they getting their information only from public sources? Or do they have inside knowledge? Define what the simulated attacker knows and plan to begin the attack based only on that knowledge.

Plan communication. One option is for the red team to tell the blue team nothing about targets, methods and approaches. The other is a “purple team” approach, with open communication. Both work. But decide in advance and stick to it during the exercise.

Review the last exercise you conducted to refresh memories of how that went and how the next exercise might be improved over the last one.

During the Breach and Attack Simulation

At this stage, you’ll launch the attack. This often begins with a phishing attack to get a victim to install malware, depending on planning.

From here, focus on internal threats and openings for breaching security, stealing credentials, gaining access and stealing data. Attack simulation is a great training exercise, so make sure to include all who might benefit from it. Make sure all team members feel free to contribute and add their observations and opinions.

The red team should monitor both physical and digital access points. Focus not just on systems, but physical security, social engineering and the use of public data to gain access. Be aware of the staff most likely to be targeted in an attack — the C-suite, board members, accounting staff and others.

After the Breach and Attack Simulation

Afterward, judge the degree of success based on your stated goals and objectives. Do that formally, but capture everything.

Was the red team able to get anyone to open an attachment? Were they able to gain access to an area they shouldn’t have been in? Did an alarm fail to go off? Were they able to convince an employee to let them in, or slide through security with a group of employees without swiping their badge? Record everything.

Vulnerabilities and other problems should point the way to changes in tools, policies, practices and training. Craft a full report describing in detail the method and steps in the attack, conclusions and detailed recommendations to prevent that kind of attack in the future. This should focus on ranking findings based on the risk and value of the target to the organization. The report should clearly rank vulnerabilities and weak spots in order of which need to be fixed first.

After remediation, test the remedy by repeating the attack to see if the problem has really been solved.

Take notes as well to guide the next red team exercise. The idea is to improve not only cybersecurity each time, but the simulated attacks as well. Better, more careful red team attacks lead to better blue team security.

You will likely face a threat actor at some point. It is better to attack yourself first, find out the problems that would enable their success and fix them.

More from Intelligence & Analytics

Hive0051’s large scale malicious operations enabled by synchronized multi-channel DNS fluxing

12 min read - For the last year and a half, IBM X-Force has actively monitored the evolution of Hive0051’s malware capabilities. This Russian threat actor has accelerated its development efforts to support expanding operations since the onset of the Ukraine conflict. Recent analysis identified three key changes to capabilities: an improved multi-channel approach to DNS fluxing, obfuscated multi-stage scripts, and the use of fileless PowerShell variants of the Gamma malware. As of October 2023, IBM X-Force has also observed a significant increase in…

Email campaigns leverage updated DBatLoader to deliver RATs, stealers

11 min read - IBM X-Force has identified new capabilities in DBatLoader malware samples delivered in recent email campaigns, signaling a heightened risk of infection from commodity malware families associated with DBatLoader activity. X-Force has observed nearly two dozen email campaigns since late June leveraging the updated DBatLoader loader to deliver payloads such as Remcos, Warzone, Formbook, and AgentTesla. DBatLoader malware has been used since 2020 by cybercriminals to install commodity malware remote access Trojans (RATs) and infostealers, primarily via malicious spam (malspam). DBatLoader…

New Hive0117 phishing campaign imitates conscription summons to deliver DarkWatchman malware

8 min read - IBM X-Force uncovered a new phishing campaign likely conducted by Hive0117 delivering the fileless malware DarkWatchman, directed at individuals associated with major energy, finance, transport, and software security industries based in Russia, Kazakhstan, Latvia, and Estonia. DarkWatchman malware is capable of keylogging, collecting system information, and deploying secondary payloads. Imitating official correspondence from the Russian government in phishing emails aligns with previous Hive0117 campaigns delivering DarkWatchman malware, and shows a possible significant effort to induce a sense of urgency as…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today