Security Is Not About Tools – It’s About Thoughtful Decisions

If you were to describe a typical attack scenario on a company in a few steps – from the initial entry point to full infrastructure takeover – what would it look like?

First, let me clarify how attacks themselves should be perceived, because there are fundamental principles we must understand first. In cybersecurity, there is still a convenient myth that organizations lose because attackers are becoming increasingly advanced. In practice, the opposite is true. Most incidents do not result from breakthrough techniques but from predictable flaws in environment design, identity management, and a lack of control over privilege flow.

From the perspective of someone who regularly simulates attacks on enterprise environments, it is clear that an attack is not a chaotic event. It is a process of navigating a system of dependencies that the organization itself has created. That is precisely why it can be predicted. An attack is often a consequence of architecture, not merely a classically perceived incident.

The biggest strategic mistake lies in treating an attack as “entering the system.” In reality, entry is only the initial moment. The key question is what the environment allows an attacker to do next.

In practice, this means that a single-entry point is rarely a problem in itself; what truly matters is how identities are managed and used within the infrastructure. An attack evolves according to the logic of the environment, not solely the creativity of the attacker. If the infrastructure allows the abuse of one identity to obtain others, then the attack does not need to be sophisticated, it only needs to be consistent.

Credential theft, Pass-the-Hash, Kerberoasting – why are these techniques still so effective today, and why is MFA alone not a sufficient defense?

The main task of security teams is to do everything possible to reduce the risk of a breach. For many years now, MFA has been bypassable, and with a well-executed phishing campaign, bypassing it is often relatively simple. The problem, therefore, does not lie in whether we deploy a specific solution, but in how we approach security techniques.

Pass-the-Hash, Kerberoasting, and many other attack techniques all have defensive counterparts. However, from a strategic perspective, the root causes remain repetitive:

1. Lack of control over identity – privileges are granted ad hoc, without full visibility into their downstream consequences.

2. Excessive trust in architecture and a lack of regular, well-executed (not ad hoc) audits. This inevitably raises the question of whose skills we trust. It is critical that the team performing the tests is experienced not only in testing itself, but also in overall infrastructure security.

3. Lack of logical segmentation, not just network segmentation – boundaries are defined by organizational structure rather than by risk levels.

4. A focus on tools instead of the security model – technology often masks problems rather than solving them.

What are the most surprising security vulnerabilities your team encounters during audits? Are there errors that still surprise you?

When planning a cybersecurity strategy, the most important objective is achieving complete transparency. This means identifying the data sources that tell us what is happening within the infrastructure and correlating that data in a reliable SIEM system. For me, this is the “hello world” of cybersecurity. A lack of transparency in this area remains one of the most serious security gaps I observe.

A theoretically secure cloud environment today requires a thorough understanding of what information is being logged so that, for example, during an incident, we can reconstruct what actually happened. In practice, we almost never see cloud environments properly aligned with current security standards – and the same applies to Active Directory.

In both cases, permissions are often granted unnecessarily or at excessively high levels, which leads directly to privilege escalation. In Active Directory, for example, permissions such as GenericWrite may be granted – sometimes by external applications – only to become lethal to the infrastructure when viewed in a broader security context.

Many organizations implemented Active Directory years ago and have changed little in the configuration since then. How big a risk does this pose, and where should they start “cleaning up”?

In Active Directory based environments – which is practically all enterprise environments – an organization’s actual security level is directly proportional to the quality of its configuration. The same is true for cloud environments and other components.

Of course, new attack techniques continue to emerge, and organizations must respond to them. A good example is PetitPotam, an attack vector discovered several years ago that often still works today. It demonstrated how authentication can be coerced and abused in relay scenarios, particularly in the context of Active Directory Certificate Services (AD CS).

In practice, however, the key is not reacting to individual techniques but eliminating entire classes of problems that enable their use. In the case of AD CS, this includes removing legacy web enrollment pages that allow authentication-related certificate requests.

It is also worth noting that the NTLM authentication protocol – including NTLMv2 – is now a de facto obsolete mechanism that is being systematically phased out. Nevertheless, it remains widespread in enterprise environments due to backward compatibility and dependencies on legacy applications. In practice, it enables the vast majority of “zero-to-hero” attacks – where basic network access is enough to compromise the most privileged account, the Domain Admin. Every organization should already have a plan in place to remove it, if it has not done so already.

From a cybersecurity strategist’s perspective, maintaining long-term control over the state of the environment is far more important than addressing individual vulnerabilities. Active Directory rarely “breaks” all at once; instead, it degrades gradually through operational changes – extended permissions, added exceptions, shortened access paths.

Regular reviews, such as Health Checks, should therefore be treated not as audits, but as elements of continuous risk management. Their purpose is not to find isolated errors, but to identify excessive permissions, uncontrolled trust relationships, escalation paths created by configuration choices, and deviations from the adopted security model.

A particularly critical area is the tiered model, or so-called tiering. In a correctly designed environment, access to the most sensitive resources – Tier 0 – is strictly limited to systems and accounts responsible for identity management and domain control, such as domain controllers, AD management systems, and privileged administrative accounts.

The challenge lies not only in defining these tiers, but in enforcing them. A lack of proper separation inevitably leads to scenarios in which the compromise of a single workstation enables the takeover of the entire domain. A domain compromise, therefore, is not the “next stage” of an attack – it is the logical conclusion of a process that was possible from the very beginning.

When an attack has already occurred, what is the most common mistake organizations make in the first hours after detecting a breach?

The worst mistake is acting without first establishing what actually happened. Most organizations do not lose because they are weak – they lose because they are blind. Therefore, infected components should be isolated as quickly as possible, and internet access should be cut off to prevent further attacker activity.

It is equally important to properly secure forensic evidence – certainly not by restoring machines in the same location – while also focusing on restoring critical business services. Organizations must identify persistence mechanisms, where attackers may remain hidden until infrastructure and internet access are partially restored.

Speed is essential, not only because of regulatory obligations such as the 72-hour incident reporting window, but also because determining what happened is the only way to respond appropriately.

I have been professionally responding to global incidents for many years, and if an organization cannot clearly answer three questions:

1. What happened?

2. Where did it spread?

3. What was accessed – and did any data leak? If so, what data?

…then there is no true incident response readiness. Instead of managing the incident, a narrative is created around it.

The real question is whether we could answer these questions today if we simulated an attack. In the European Union, providing such answers is, to varying degrees, a legal requirement.

During incidents, one thing becomes painfully obvious: a lack of transparency destroys the response. Common problems include:

1. Distributed telemetry

2. Inconsistent logging practices

3. Missing or hidden contextual data

4. Delayed access to critical information

That is why transparency is not about reporting – it is about control. Transparency turns chaos into evidence, evidence into decisions, and decisions into actions that mitigate impact.

And that is exactly where the real fight is won.

Join Paula and the CQURE team at Black Hat Las Vegas for hands-on workshops!

This article was originally published in Polish on the Poradnik biznesu website, available at this link: https://www.poradnikbiznesu.info/cyberbezpieczenstwo/bezpieczenstwo-to-nie-narzedzia-to-przemyslane-decyzje/

Want to know more?