From vulnerability scanning to red teaming

No one needs to be convinced anymore that the risk of cyberattacks affects every organization. Today, the fundamental question is: Are we an easy target? Attempts to scan, probe, and search for vulnerabilities in IT infrastructure are constantly taking place. An organization may not be aware of them, but that doesn’t mean they don’t exist. That is precisely why various types of security assessments are needed—from simple vulnerability scans to advanced attack simulations.

Their goal isn’t to simply “check cybersecurity off the to-do list." The point is to get concrete answers to the following questions: where are we vulnerable, how could that be exploited, and what should we improve first.

In cybersecurity, it’s easy to fall into the trap of black-and-white thinking: either we conduct a full, in-depth audit, or we do nothing. However, a mature approach involves tailoring the scope of the assessment to the organization’s actual needs, risk level, system architecture, and stage of development. Not every company needs to start right away with red team tests or complex attack simulations. Often, a very sensible first step is vulnerability scanning—that is, an automated review of systems to search for known vulnerabilities.

This type of scan provides a quick overview of the situation. It shows which systems are visible from the outside, where there are known configuration errors, outdated components, or basic security vulnerabilities. Its advantage is the relatively low cost of entry and the quick results in the form of a list of issues requiring attention. For many organizations, a vulnerability scan is a good starting point: it allows them to get the basics in order and see where the risks are greatest.

However, it’s important to remember that a vulnerability scan has its limitations. It won’t show you how to carry out an attack step by step. It won’t link the detected flaws into attack scenarios, and it won’t always assess whether a given vulnerability can actually be exploited in a specific environment. It’s also worth noting that scan results contain errors, including both false positives (reported issues that do not actually exist) and false negatives (real vulnerabilities that the scanner failed to detect). Therefore, you should not treat a scan report as an exhaustive list of threats.

Penetration tests represent the next level of security assessment. They differ from vulnerability scans in that they not only answer the question of what might be wrong, but also determine whether and how the identified issues could be exploited, and what the consequences might be for the organization.

In penetration testing, the work of a specialist—an ethical hacker—plays a major role. Their task is not only to find vulnerabilities, but also to verify whether they can be combined into a feasible attack scenario. Sometimes a single flaw does not seem critical. It is only when several weak points—such as a misconfiguration, excessive privileges, a weak password, or a vulnerable application—are combined that it becomes clear an attacker can take over an account, gain access to data, or move further into the network.

A well-conducted penetration test should not end with just a list of technical vulnerabilities. Its business value lies in illustrating a specific scenario: what could be compromised, how, how difficult it would be for an attacker, and what steps should be taken to mitigate the risk.

There is no single, universal security assessment that can answer all questions. Web applications are tested differently than network infrastructure, which is tested differently than industrial environments, and employees’ resistance to social engineering attacks is tested yet differently.

Therefore, when planning a security assessment, it’s a good idea to first identify which area of the organization is critical from a business risk perspective. Are the systems accessible via the Internet the most important? The customer-facing application? The internal network? Production systems? Or perhaps employee procedures and behaviors? Only then can you select the appropriate type of tests.

Web applications, customer portals, administrative panels, and APIs are among the most frequently targeted components of an IT environment. They are accessible via the Internet, are often under active development, and are connected to databases, transactional systems, or internal company services.

In this area, approaches based on OWASP standards are often used.

• The OWASP Top 10 is a list of the most common and serious categories of application vulnerabilities. It can be used as a starting point for assessing application security and as a basis for semi-automated testing. It allows you to relatively quickly check whether the application has common issues, such as access control flaws, authentication vulnerabilities, misconfigurations, or vulnerable components. However, the OWASP Top 10 should not be treated as a comprehensive application security test. Rather, it is a good starting point and a way to broadly cover the most common issues;
• A more in-depth approach is the OWASP WSTG, or Web Security Testing Guide. It is a detailed methodology for testing the security of web applications. It involves a manual, structured verification of many areas: from authentication logic, through session and permission management, to data validation, server configuration, and communication security. In practice, the OWASP WSTG allows us to determine not only whether an application contains common vulnerabilities, but also whether these vulnerabilities can be exploited in a real-world attack scenario.

IT infrastructure is a layer that end users typically do not see, but upon which the entire organization operates: networks, servers, workstations, directory services, access systems, internal resources, and connections between environments.

An infrastructure security assessment can be either external or internal.

• An external vulnerability scan checks what is visible from the Internet. It helps answer the question of which services, systems, and vulnerabilities a potential attacker can see without prior access to the organization. This is an important part of basic security hygiene, because attacks often begin with precisely these publicly accessible elements.
• An internal vulnerability scan reveals which issues are visible from the perspective of a person or device already on the corporate network. This is important because many incidents do not end with the initial entry into the environment. The real risk arises when an attacker can move further in: take over accounts, gain elevated privileges, and access additional systems.

An even more thorough form of verification is infrastructure penetration testing. In the external variant, these tests check whether an attacker from the Internet can gain access to the organization’s systems. In the internal scenario, they demonstrate what an intruder who is already inside the network—for example, through a compromised account, an infected computer, an unsecured VPN connection, or an employee error—can do.

From a business perspective, the most important question is: How far can an attacker go, and what resources can they compromise? Infrastructure testing helps assess whether a company has effective network segmentation, proper permissions management, and adequate control over access to critical systems.

Red team exercises represent the most advanced level of assessing an organization’s resilience. They do not focus solely on identifying technical vulnerabilities. Their goal is to simulate a realistic attack on the organization using various methods, which may include technical intrusion attempts, social engineering, phishing, bypassing physical security measures, or testing the response of security teams.

Red teaming answers the question: Can an organization detect, understand, and stop a real attack?

This approach is particularly valuable for companies that have already implemented basic and intermediate security measures and now want to test their effectiveness in practice. In such cases, a list of vulnerabilities alone is not enough. What matters is whether the monitoring systems, procedures, people, and technology work together when a real threat arises.

Red teaming is not usually the first step for an organization that is just beginning to get its cybersecurity in order. Rather, it is a subsequent stage of maturity.

In manufacturing companies, OT (Operational Technology) systems are of particular importance. These are environments responsible for controlling physical processes: production lines, industrial automation, PLCs, SCADA systems, technical installations, power systems, and HVAC.

For years, industrial systems were treated as separate from traditional IT. Today, they are increasingly connected to corporate networks, reporting systems, remote access solutions, or cloud environments. This increases operational efficiency but also creates new attack vectors.

In the case of OT, the consequences of an incident can extend far beyond data loss. An attack can lead to production shutdowns, disruptions to technological processes, equipment damage, financial losses, and, in some environments, even threats to human safety.

An OT security assessment should include, among other things, the identification of vulnerable devices and protocols, an analysis of industrial communications, verification of the segmentation between IT and OT, and an assessment of the potential for unauthorized access to control systems.

Testing in OT environments requires special caution. The goal is not to aggressively push the system to its limits, but to conduct a controlled risk assessment in a way that does not disrupt production or technical infrastructure.

If a company provides a mobile app to its customers, partners, or employees, that app should also be included in the security assessment. The user sees the app’s interface and features. An attacker takes a broader view: they analyze how data is stored, communication with the server, authentication mechanisms, the app’s logic, and the possibility of bypassing security measures.

Mobile app testing allows you to verify, among other things, whether sensitive data can be extracted from the device, whether communication with the backend is properly secured, whether the app correctly verifies certificates, whether it stores tokens or passwords in an insecure manner, and whether it is possible to bypass security mechanisms. This is particularly important for apps that handle customer data, payments, sales processes, service requests, employee access, or confidential information.

Many organizations still use applications installed locally on employees’ computers. These may include industry-specific systems, engineering tools, administrative applications, and warehouse, financial, or manufacturing software. Such solutions can also pose a significant risk.

Testing desktop applications—often referred to as “fat clients“—allows you to determine whether it is possible to modify the application, bypass its security measures, analyze its business logic, intercept communication with the server, or gain access to data that should not be available to the user.

In this case, it is particularly important to verify that security is not based solely on the assumption that “the user will not look inside the application.” An attacker will look inside.

Not every attack starts with a technical vulnerability. Sometimes all it takes is a well-crafted email, a phone call from someone posing as an IT employee, a fake login page, or an attempt to gain access to the office as a “service technician.”

Social engineering tests assess an organization’s resilience to attacks targeting people and procedures. They may include phishing campaigns, attempts to extract data, simulated phone calls, employee response tests, or controlled attempts to gain physical access. The goal is not to “catch” employees making mistakes. Well-designed social engineering tests reveal where an organization needs improved procedures, training, communication, or technical security measures.

This is often one of the most practical types of assessment, because many incidents start with a person: clicking on a link, entering a password, approving a fraudulent request, or letting an unauthorized person in.

Cybersecurity doesn’t work like a switch that can be set to “secure" or “insecure." Rather, it’s the level of difficulty an organization presents to an attacker.

The lack of any verification means that the company does not know where its vulnerabilities lie. A vulnerability scan helps identify the most obvious problems. A penetration test reveals which of these vulnerabilities could actually be exploited. More advanced simulations allow you to check whether the organization can detect and stop an attack.

Each of these steps raises awareness and reduces risk. You don’t always have to start with the most comprehensive approach. The worst decision, however, is to do nothing.

In practice, a sensible approach might look like this: first, a vulnerability scan; then, penetration tests of the most critical systems; followed by regular verification of the infrastructure and applications; and, at a higher level of maturity, red team exercises or resilience tests of the entire organization.

And most importantly—cybersecurity involves ongoing efforts, regular testing, patching security vulnerabilities, and further testing.

The most important thing is to stop treating security assessments as a technical cost. It is a business risk management tool. It allows you to make decisions based on facts, not assumptions.