Which Changes in Your IT Environment Can Create New Attack Paths?

Geplaatst op: 27 September 2026

Every change in your IT environment can create new attack paths: combinations of vulnerabilities, misconfigurations, identities, and permissions that an attacker can chain together to gain access to systems or data. The larger and faster the changes, the greater the chance that temporary blind spots emerge that fall outside the view of existing security measures. The questions below help you understand which changes introduce the most risk and how to proactively limit that risk.

Which IT changes increase the likelihood of a successful attack?

IT changes that increase the likelihood of a successful attack are typically changes that introduce new entry points, expand existing permissions, or reduce the visibility of your security. Think of cloud migrations, new vendor integrations, changes to account permissions, and the rollout of new applications. Each of these changes shifts the attack surface, often without security controls being adjusted immediately.

What many organizations underestimate is that an attacker is not looking for one big mistake. An attacker looks at the combination of small weaknesses that together form a working path. A new cloud resource with an overly permissive configuration may not be critical on its own. But combined with an account that has too many privileges and a vendor with direct network access, it suddenly becomes a realistic route to sensitive systems.

The most high-risk IT changes are:

• Expansion of cloud infrastructure without corresponding reconfiguration of access policies
• New user accounts or service accounts with overly broad permissions
• Integrations with external parties that are granted direct network or data access
• Changes to applications that bypass or modify existing security controls
• Adjustments to firewall rules or network segmentation that accidentally open up too much

The core of the problem is that security is often configured at a specific point in time, while the environment continues to change afterward. A manual pentest as a baseline provides insight into the situation at that moment, but the day after the test the environment begins to shift again.

How does an attack path emerge after a cloud migration?

After a cloud migration, new attack paths emerge because cloud resources are configured differently by default than on-premises systems, and because the combination of identities, roles, and permissions in the cloud is far more complex and dynamic. Misconfigurations in cloud storage, overly permissive IAM permissions, and insufficient network segmentation are the most common causes.

During a cloud migration, systems and data are moved to an environment where the rules of the game are fundamentally different. On-premises, you had physical and logical boundaries that were relatively stable. In the cloud, resources are quickly created, permissions easily expanded, and connections effortlessly established — which also means mistakes are made quickly and not always noticed.

Concrete examples of how attack paths emerge after a migration:

• A storage bucket that was accidentally made publicly accessible during the migration
• Service accounts with administrator privileges that were created for temporary migration work and never removed
• Insufficient separation between production and test environments, allowing an attacker to pivot from the test environment into production
• Legacy systems that were temporarily connected to the cloud, thereby forming a bridge between old and new

An attacker only needs to find one of these weaknesses to gain an initial foothold. From that starting point, they can then move laterally through the environment, looking for privileges that take them further. That is precisely why cloud migrations should always be accompanied by a thorough security evaluation — not only at the start but also in the weeks and months that follow.

Why are new vendor integrations a security risk?

New vendor integrations are a security risk because they grant an external party access to your systems, networks, or data, while you have limited control over the security posture of that party. An attacker who compromises the vendor automatically gains a path into your environment.

This type of attack, also known as a supply chain attack, is one of the most effective methods for attackers. Instead of directly attacking a well-secured organisation, they target a smaller or less well-secured vendor with access to that organisation. The connection between vendor and client thus becomes the weakest link in the chain.

What makes this extra dangerous is that the access vendors receive often extends further than strictly necessary. Think of:

• Administrators from external parties with permanent access via VPN or remote desktop
• API integrations that share more data than necessary for the specific function
• Shared accounts or credentials that are not individual and therefore cannot be properly monitored
• Vendors that have access to multiple client environments simultaneously

For Managed Service Providers, this risk is especially acute. An MSP typically manages the IT environments of multiple clients simultaneously, which means that compromising one MSP can directly provide access to all those client environments. This makes MSPs an attractive target for attackers who want to cause maximum damage with a single breach. More about how these types of scenarios are tested in practice can be found on the page about red teaming.

How quickly can attackers exploit a new attack path?

Attackers can exploit a new attack path within days or even hours, depending on the visibility of the vulnerability and the motivation of the attacker. Publicly visible misconfigurations, such as a publicly accessible cloud resource, are often discovered by attackers’ automated scanners within 24 hours.

This is precisely why the traditional approach of one pentest per year is so problematic. An annual pentest is a snapshot: it shows what the security looks like on the day of the test. But the day after the test, the environment begins to change again. Applications are updated, accounts are added, permissions are adjusted, new cloud resources are created. Every change can introduce a new attack path that goes undetected for months until the next test.

Cybercriminals work 365 days a year. They actively track new vulnerabilities, continuously scan the internet for misconfigurations, and adapt their techniques as soon as new opportunities arise. An organisation that only has insight into its attack surface on the day of the test is effectively blind to new risks for the remaining 364 days.

The speed at which an attack path can be exploited depends on:

• The visibility of the vulnerability (externally visible versus internal)
• The value of the data or systems reachable via the path
• Whether the attacker has previously had access and is waiting for a new opening
• The complexity of the exploitation (some paths require more steps and time)

How do you detect new attack paths before attackers do?

You detect new attack paths by continuously monitoring your environment for changes that affect the attack surface, and by regularly testing whether those changes have created new attack opportunities. This requires a combination of technical monitoring, periodic manual tests, and a clear overview of who has access to what.

The first step is visibility. You cannot defend what you cannot see. That means you need an up-to-date picture of your IT environment: which systems are running, which accounts exist, what permissions those accounts have, and which connections exist with external parties. For many organisations, this overview is already a challenge, especially when the environment is growing quickly or changing regularly.

Practical measures to detect new attack paths early:

1. Conduct a thorough baseline pentest as a starting point, so you know what the current attack paths are
2. Establish change management processes in which security implications are weighed with every IT change
3. Actively monitor identities and permissions for anomalies, such as accounts that suddenly have more permissions than usual
4. Test after significant changes, not just once a year but whenever the environment changes substantially
5. Think like an attacker: with every change, ask yourself how an attacker could exploit it in combination with existing weaknesses

The difference between a vulnerability scan and a real attack path analysis is crucial here. An automated scan finds individual vulnerabilities. But an attacker combines those vulnerabilities with misconfigurations, identities, and permissions into a working path. Only by testing the way a real attacker tests do you gain insight into the actual risks. More background on how this type of research is conducted can be found on the page about cyber research.

Continuous insight also begins with a solid understanding of compliance and policy around access management and change management. A solid compliance and policy framework helps you to structurally factor in security implications when making IT decisions.

How Q-Cyber helps map new attack paths

We help organisations detect new attack paths before attackers do, by combining what an automated scan cannot: thinking like a real attacker. Our approach is concrete and pragmatic:

• Baseline pentest: we start with a thorough manual pentest that not only exposes individual vulnerabilities, but also the combinations of weaknesses that together form a working attack path
• Continuous insight via Continuous-Q®: after the baseline, our specialists continue to monitor changes in your environment, so that new attack paths are identified as soon as they emerge and not only at the next annual test
• Independent advice: we are not tied to software vendors or tooling, which means our advice is always in your best interest
• Technical and policy-based: we combine technical depth with advice on access management, permission structures, and security policy

Whether you have just completed a cloud migration, connected new vendors, or simply want to know whether your current security can withstand the way attackers operate today: get in touch and we will look together at the right first step. More about our approach can be found on the page about Continuous-Q®.

Lees meer

Why Are Known Vulnerabilities Only Part of the Security Risk?

Geplaatst op: 26 September 2026

Every week, dozens of new vulnerabilities appear in software systems. Security teams scan, patch, and report, yet organizations are still getting hacked. How is that possible? The answer has everything to do with a persistent misconception: that known vulnerabilities represent the greatest security risk. In reality, they are merely the tip of a much larger iceberg.

In this article, we explain step by step what a vulnerability actually is, why known vulnerabilities don’t come close to showing the full risk picture, and which risks organizations structurally overlook. By the end, it will be clear why a different approach to cybersecurity is necessary to truly protect yourself.

What is a vulnerability and how does it become ‘known’?

A vulnerability is a weakness in software, hardware, or a configuration that an attacker can exploit to gain unauthorized access or cause damage. Think of a flaw in a web server’s code that allows an attacker to read files not intended for them.

Vulnerabilities become ‘known’ through a standardized system: once a researcher or vendor discovers and publishes a vulnerability, it receives a CVE number (Common Vulnerabilities and Exposures). This number makes the vulnerability officially traceable. Security teams, scanners, and vendors can then respond with patches or workarounds.

The crucial point is that a vulnerability only becomes ‘known’ after someone has discovered, documented, and published it. That process takes time. And during that interim period, the vulnerability already exists — it just isn’t yet visible to defenders.

How known vulnerabilities are merely the tip of the iceberg

The CVE system is valuable, but it only covers what has already been discovered and published. Beneath it lies a much larger invisible portion, comparable to an iceberg: what you see at the surface is only a fraction of what actually exists.

Three categories together make up that hidden portion of risk:

• Zero-day vulnerabilities: vulnerabilities that are not yet publicly known and for which no patch exists. Attackers, particularly sophisticated groups, actively exploit these before vendors are even aware of them.
• Misconfigurations: incorrectly configured systems, cloud services, or access rights that have no official CVE number, but can still be exploited. A cloud storage container that is accidentally publicly accessible won’t appear on any patch list.
• Logical weaknesses in identities and permissions: an account with excessive privileges, a service account with access to critical systems, or a vendor with unnecessary administrative rights. These are not technical bugs, but structural risks that scanners systematically miss.

An attacker doesn’t necessarily need to exploit a known CVE. Sometimes a combination of a misconfiguration, an account with too many privileges, and a poorly secured vendor portal is enough to penetrate deep into a network — without a single vulnerability scanner raising the alarm. Read more about how attackers approach this on the page about red teaming.

Why organizations still focus primarily on known risks

If known vulnerabilities only represent part of the risk, why do so many organizations focus almost exclusively on them? The answer is understandable: known vulnerabilities are measurable, reportable, and manageable.

Vulnerability management tools generate clear lists with CVE numbers, priority scores, and patch recommendations. That provides a sense of control. Auditors accept it as evidence of active security management. And after resolving twenty vulnerabilities, an organization feels demonstrably safer — even if the actual attack surface has barely changed.

This is precisely the danger of false security: the feeling that you’re doing well, while the risks that truly matter remain out of sight. Misconfigurations, identity issues, and logical weaknesses are harder to quantify and fit less neatly into a dashboard. As a result, they are structurally underexposed — not because they are less dangerous, but because they are less visible.

Which risks outside the patch list are most frequently exploited

Real attackers don’t think in CVE numbers. They think in attack paths: which combination of weaknesses will get me to my target as quickly as possible? And those paths rarely run through the most obvious known vulnerability.

The risks most frequently exploited but falling outside the patch list are:

• Identity and access issues: accounts with excessive privileges, weak passwords, reused credentials, or service accounts without monitoring.
• Cloud misconfigurations: incorrectly configured access controls, unsecured APIs, or publicly accessible storage buckets.
• Supply chain access: vendors and managed service providers with access to systems that are themselves insufficiently secured.
• Human behavior: employees who open phishing emails, share login credentials, or take shortcuts in security procedures.

An attacker who compromises an MSP instantly gains access to all of that MSP’s clients. That’s not a technical exploit — it’s a logical weakness in the structure of trust relationships. No standard vulnerability scan maps this type of risk.

Continuous testing as a response to a moving target

Building on everything explained above, one conclusion becomes unavoidable: a snapshot is insufficient to manage a dynamic risk. Your environment changes constantly. New applications are deployed, accounts are created, permissions are modified, cloud resources come and go. Every change can open a new attack path.

An annual pentest provides insight on a single day. But what happens after that remains out of sight. Cybercriminals develop new techniques throughout the year and continuously explore new attack paths. A traditional pentest is therefore comparable to a photograph of a moving target: accurate at the moment of capture, but quickly outdated.

The alternative is an approach where testing is not a one-time activity, but an ongoing process. It starts with a thorough baseline pentest that uncovers not only technical vulnerabilities, but also misconfigurations, identity risks, and logical weaknesses in attack paths. Changes in the environment are then actively tracked, so new risks are identified as soon as they arise — not only at the next annual test. Read more about this approach on the page about Continuous-Q®.

How Q-Cyber helps with vulnerability management

Q-Cyber helps organizations look beyond the patch list. Our approach combines technical depth with reasoning like a real attacker, so that not only known vulnerabilities come into view, but the full attack surface.

What we concretely offer:

• Manual pentests in which our ethical hackers actively search for attack paths that go beyond CVEs, including misconfigurations, identity risks, and logical weaknesses.
• Continuous-Q®, our ongoing testing program that continues to monitor the environment after the initial pentest and identifies new risks in a timely manner.
• Independent advice without ties to software vendors, so our recommendations are always in your best interest.
• Concrete reports with priorities and practical next steps, so you immediately know where action is needed.

Want to know how your organization truly stands — beyond the patch list? Get in touch with Q-Cyber and discover how we help you gain a complete and up-to-date picture of your security risk.

Lees meer

Why Are Misconfigurations Interesting to Hackers?

Geplaatst op: 25 September 2026

Imagine: an attacker spends months trying to gain access to a corporate network through advanced exploits, but fails. Then he discovers that a cloud environment was accidentally made publicly accessible by an administrator who had misconfigured a setting. Within an hour, he has access to sensitive data. This scenario is no exception. Misconfigurations are among the most common causes of successful cyberattacks worldwide.

In this article, you’ll learn step by step what misconfigurations are, how they occur, why they are so attractive to attackers, and what you can do to prevent them. We build the knowledge progressively: from the core of the concept to a practical approach to protecting your organization.

What is a misconfiguration in cybersecurity?

A misconfiguration is an incorrect or insecure setting in a system, application, network device, or cloud environment. Rather than a technical flaw in the software itself, it is an error in the way that software or system has been configured by an administrator or developer.

The difference from a traditional vulnerability (a so-called CVE) is important to understand. A CVE is a flaw in the code of software that the vendor must fix via a patch. A misconfiguration is an error in the configuration that the administrator has made or overlooked. The software works correctly from a technical standpoint, but the settings create a security gap.

A simple example: a database is secured by default with a password, but an administrator disables that security during a testing phase and forgets to re-enable it afterwards. The database itself has no bug, but the setting makes it vulnerable to anyone who knows where to look.

How do misconfigurations occur in practice?

Misconfigurations are rarely the result of negligence or ignorance alone. They arise from a combination of factors that exist in virtually every organization.

Complexity and speed

Modern IT environments consist of dozens, sometimes hundreds of systems and services. Cloud environments such as Azure or AWS contain thousands of configuration options. The more complex the environment, the greater the chance that a setting is incorrect somewhere. Especially when teams work under time pressure and need to deploy new systems quickly, security settings are sometimes deliberately or inadvertently skipped.

Default settings that are not adjusted

Many systems are delivered with default settings that prioritize convenience over security. Default passwords, open ports, broad access rights: these are settings designed to get a system up and running quickly, not to secure it optimally. If administrators do not actively adjust these defaults, they remain like an open door.

Changes without a security check

IT environments are constantly changing. Accounts are created, permissions adjusted, new applications deployed, and cloud resources added. Every change can introduce a new misconfiguration. Without a structured process to review changes for security implications, the gaps in security grow along with the environment.

Why are misconfigurations so attractive to attackers?

Attackers choose the path of least resistance. Misconfigurations are particularly attractive to them for three concrete reasons.

First, they are relatively easy to find. Many misconfigurations are visible through publicly accessible information, automated scans, or simply by attempting to connect to a system. An attacker doesn’t need to write a sophisticated exploit; they just need to look for what is already exposed.

Second, they raise no suspicion. An attack via a misconfiguration often looks like normal traffic to monitoring systems. There is no malicious code to trigger an antivirus program. The attacker uses a legitimate access route that happens to be left open by accident.

Third, they can be combined into an attack path. This is an insight central to how modern attackers operate: they don’t look at individual vulnerabilities, but at how multiple small weaknesses together form a route to sensitive systems. A misconfiguration in a cloud identity, combined with overly broad access rights and an incorrect firewall setting, can together lead to full access to critical data, while none of the three individually would be assessed as critical.

This principle, also known as attack path testing, shows why simply fixing individual findings is not enough to truly protect an organization.

Which systems and settings are most frequently misconfigured?

Certain categories of systems repeatedly appear as sources of misconfigurations. Knowing this helps you focus your attention on the areas where the risk is greatest.

• Cloud environments: Azure, AWS, and Google Cloud offer enormous flexibility, but also an enormous number of configuration options. Incorrectly configured access roles (RBAC), publicly accessible storage buckets, and overly broad managed identity permissions are classic examples.
• Firewalls and network devices: Unnecessary open ports, outdated rules, and insecure default settings on routers and switches regularly create access opportunities that should not exist.
• Identity and access management (IAM): Accounts with excessive privileges, inactive accounts that have not been removed, and weakly configured multi-factor authentication are vulnerabilities that attackers actively seek out.
• Web applications and APIs: Error messages that reveal too much technical information, missing security headers, and unsecured API endpoints are common misconfigurations in application layers.
• Collaboration tools and email platforms: Incorrectly configured Microsoft 365 or Google Workspace environments can lead to unwanted external access or data breaches.

How do you discover misconfigurations before a hacker does?

Building on the understanding of where misconfigurations originate and which systems are most vulnerable, the next step is to actively search for them. A fundamental principle applies here: you can only defend what you test.

Vulnerability scans as a starting point

Automated vulnerability scans can quickly map known misconfigurations and weak settings. They are valuable as a basic check, but have an important limitation: they find what is in their database, not what a creative attacker would discover. They see individual findings, not attack paths.

Manual pentests for the deeper layer

In a manual pentest, an ethical hacker thinks like a real attacker. He combines discovered misconfigurations with other weaknesses to assess whether a viable attack path exists. A misconfiguration that appears low-risk on its own can suddenly turn out to be critical in combination with another weakness. This level of insight is only achievable with human reasoning, not with automated tools.

Red teaming for the full picture

For organizations that want to go a step further, red teaming offers a realistic simulation of a complete attack. A red team attempts to gain access in every possible way, including via misconfigurations, social engineering, and supply chain weaknesses, to test whether an organization’s defenses hold up in practice.

Preventing misconfigurations with a structural approach

Discovering misconfigurations is valuable, but structurally preventing them is the ultimate goal. A one-time test provides insight at a single moment, while the environment may already change the next day. A sustainable approach therefore requires continuity.

Some concrete measures that contribute to a structural approach:

• Establish a baseline: Document the desired configuration of each system and use it as a reference point for future changes.
• Integrate security into change management: Every change in the IT environment, no matter how small, must be assessed for security implications before it is implemented.
• Limit permissions to what is necessary: Apply the principle of least privilege: grant accounts and systems only the permissions they actually need.
• Actively review default settings: Make it a fixed habit to review the default settings of new systems and services before they are put into use.
• Test continuously, not just once: Because environments are constantly changing, periodic or continuous testing is the only way to maintain up-to-date insight into the security status.

An annual test gives you a snapshot of a moving target. What you truly need is a continuous view of how your environment evolves and where new gaps emerge. Read more about how continuous testing works in practice on the Continuous-Q page.

How Q-Cyber helps with detecting misconfigurations

Misconfigurations are subtle, widespread, and change along with your environment. They require a partner who not only looks at individual findings, but understands how an attacker combines them into a working attack path. That is precisely what we focus on.

At Q-Cyber, we address misconfigurations with a layered approach:

• Manual pentests in which our ethical hackers think like real attackers and assess misconfigurations in the context of the full attack path, not as isolated findings.
• Red teaming for organizations that want to know whether their defenses hold up against a realistic, full attack simulation.
• Continuous-Q, our program for continuous insight, so you know where you stand not just on the day of the test, but throughout the entire year.
• Concrete reporting and advice with clear priorities, so you immediately know which misconfigurations pose the greatest risks and what to do about them.

Want to know which misconfigurations are present in your environment before an attacker finds them? Contact us and we’ll discuss which approach best fits your organization.

Lees meer

Which Organizations Benefit From Continuous Manual Penetration Testing?

Geplaatst op: 24 September 2026

Continuous manual penetration testing is relevant for organizations that are responsible for the digital security of others, operate in sectors with a high attack risk, or understand that security is not a one-time project but an ongoing process. Managed Service Providers in particular, as well as organizations in critical sectors and companies that are growing rapidly or managing large amounts of cloud infrastructure, benefit most from continuous and manual security testing. In this article, we answer the most frequently asked questions about who needs continuous penetration testing and when an organization is ready for it.

What makes an organization an attractive target for attackers?

An organization becomes an attractive target when it provides access to valuable data, manages third-party systems, or has weaknesses that are relatively easy to exploit. Attackers do not think in terms of individual vulnerabilities, but in attack paths: combinations of small weaknesses that together lead to significant damage.

What makes an organization vulnerable is rarely one major mistake. More often it is a combination of factors: overly broad access rights, misconfigured cloud environments, weak identity management processes, and vendors with direct access to systems. An attacker looks at the organizational structure, the supply chain, and the identities present in a network. Only once they understand how everything fits together do they decide where to strike.

Organizations that think they are too small to be of interest to attackers underestimate how attackers select their targets. It is not the size of the organization that matters, but the value of the access it provides — directly or indirectly through customers and partners.

For which sectors is continuous penetration testing most relevant?

Continuous security testing is most relevant for sectors where digital continuity directly impacts customers, patients, or society: IT services, financial services, healthcare, logistics, and government. In these sectors, the consequences of a successful attack are not only financial, but also operational and reputational.

Within the IT sector, Managed Service Providers in particular occupy a unique position. But organizations in the financial sector, healthcare, and government also work with sensitive data and are legally required to demonstrably operate securely, including under legislation such as NIS2. For them, manual penetration testing is not a luxury but a necessity.

Furthermore: the more an organization depends on cloud infrastructure, external vendors, and distributed teams, the larger the attack surface. In those environments, an annual snapshot is simply no longer sufficient.

Why are MSPs the primary target of cybercriminals?

MSPs are the preferred target of cybercriminals because compromising a single MSP provides direct access to all of that MSP’s customers. Rather than attacking dozens of organizations individually, an attacker only needs to find one entry point at the service provider.

This makes MSP security structurally more complex than securing a regular organization. An MSP manages not only its own network, but also the networks, identities, and systems of its customers. The responsibility that comes with this is considerably greater. A weakness at the MSP is effectively a weakness across all of its customers.

Attackers are well aware of this. They target the tooling that MSPs use, the administrator accounts they deploy, and the connections they maintain with customer environments. That is precisely why continuous security testing for MSPs is not an optional extra, but the cornerstone of responsible service delivery.

What is the difference between an annual pentest and continuous testing?

An annual pentest is a snapshot: it shows how secure an organization is at the moment of testing. Continuous penetration testing is an ongoing process that measures security as the environment, threats, and attack techniques continuously evolve.

The problem with an annual pentest is not that it is worthless, but that it quickly becomes outdated. Cybercriminals develop new techniques throughout the year. A vulnerability that did not exist in January may already be actively exploited by March. A test conducted once a year misses that development entirely.

Continuous manual penetration testing works differently: it builds on previous findings, tracks changes in the environment, and actively tests whether previously identified weaknesses have been resolved and whether new ones have emerged. This shifts security from reactive to proactive. Attackers do not wait for the next testing moment, and a solid security strategy should not either.

When is an organization ready for continuous penetration testing?

An organization is ready for continuous penetration testing when it understands that security has no endpoint, is willing to act seriously on findings, and has its basic security in order. Continuous testing is not a replacement for foundational measures, but a next step for organizations that want to go beyond compliance.

There are three concrete signals that an organization is ready for continuous testing:

• Growing attack surface: the organization manages multiple cloud environments, works with external vendors, or has employees across multiple locations.
• Responsibility for others: the organization manages systems or data belonging to customers, patients, or partners.
• Conscious security mindset: management understands that security is an ongoing process and not something you arrange once.

Organizations that believe they are already secure because they have had a pentest conducted are precisely those that are not yet ready. Continuous testing requires a willingness to discover that there is always something to improve — and to actually act on it. More background on how red teaming plays a role in this helps to better understand the distinction.

How does continuous testing differ from traditional security audits?

A traditional security audit assesses whether an organization complies with established standards and guidelines. Continuous penetration testing assesses whether an organization can actually withstand a real attacker. That is a fundamentally different starting point.

Audits are valuable for compliance and policy development, but they measure conformity, not resilience. An organization can fully comply with all requirements of an audit and still be vulnerable to an attacker who creatively exploits attack paths that fall outside the audit framework.

Continuous testing instead looks at what an attacker sees: not individual findings, but combined attack chains. Small misconfigurations that appear harmless in isolation can together lead to full access to critical systems. That kind of insight is not something an audit delivers. Compliance and policy are a solid foundation, but they do not replace active testing.

How Q-Cyber helps with continuous penetration testing

Q-Cyber offers organizations that are ready for the next step in security a concrete program that goes beyond a one-time test. Our approach combines technical depth with a pragmatic view of what actually makes your organization more secure.

• Mandatory baseline assessment: every engagement begins with a manual pentest that not only maps vulnerabilities, but also evaluates the security mindset within your organization.
• Ongoing testing: through our Continuous-Q® program, we test continuously so that new vulnerabilities are discovered before attackers find them.
• Attack path analysis: we do not look at individual findings, but at how combinations of weaknesses lead to real attack chains.
• Independent advice: we are not tied to software vendors or suppliers and provide advice that is exclusively in your interest.
• Selective admission: we only work with organizations that understand that security is an ongoing process, not a final destination.

Would you like to know whether your organization is ready for continuous manual penetration testing? Get in touch and we will discuss together what the right approach is for your situation.

Lees meer

SOC vs. Continuous Penetration Testing: What’s the Difference?

Geplaatst op: 21 September 2026

A SOC and continuous penetration testing are two fundamentally different security measures: a SOC monitors and detects suspicious activities in real time, while continuous penetration testing actively identifies vulnerabilities by simulating attacks. They complement each other, but are not interchangeable. This article covers the core differences, the limitations of both approaches, and when you need which measure.

What does a SOC actually do for an organization?

A Security Operations Center (SOC) is a team of security analysts that continuously monitors an organization’s IT environment. The SOC detects suspicious activities, analyzes security incidents, and responds when something goes wrong. The focus is entirely on what is already happening in the environment, not on what could still go wrong.

In practice, a SOC works with tools such as SIEM systems (Security Information and Event Management) that collect log data from servers, networks, applications, and endpoints. Based on that data, the SOC team determines whether an event is a legitimate action or a potential incident. When an alert is triggered, immediate action is taken: accounts are blocked, systems are isolated, or administrators are notified.

A SOC thus provides valuable, reactive protection. It is strong at limiting damage once an attacker is already inside. But the SOC can only detect what it can see, and it can only respond to attacks that are already underway. It does not identify vulnerabilities before an attacker finds them.

How does continuous penetration testing work in practice?

Continuous penetration testing is an approach in which ethical hackers systematically and repeatedly simulate attacks on an organization’s systems, rather than doing this once a year. The goal is to find vulnerabilities and keep finding them, because the attack landscape is constantly changing.

Where a traditional pentest is a snapshot in time, a continuous approach provides a living picture of the actual security status. New configurations, updates, cloud changes, and application modifications continuously introduce new risks. A test that gave the green light six months ago says nothing about the situation today.

With continuous penetration testing, ethical hackers look beyond known vulnerabilities such as CVEs or missing patches. They also investigate:

• Misconfigurations in cloud and identity environments, such as overly permissive settings in Azure or incorrect RBAC configurations
• Attack paths that arise by combining multiple small weaknesses
• Identity weaknesses and insecure application settings that appear harmless in isolation

This last point is crucial. Attackers don’t see isolated findings — they see attack paths. An SSRF vulnerability combined with a managed identity, a broad Azure RBAC role, and access to a Key Vault can together lead to full control over cloud resources, even though no individual finding is classified as critical. Continuous penetration testing is designed to expose exactly those correlated attack paths.

What is the difference between detection and simulating attacks?

The core difference between a SOC and continuous penetration testing lies in the direction of focus: a SOC looks at what is currently happening in the environment, while penetration testing investigates what could happen if an attacker attempts to gain access. Detection is reactive; attack simulation is proactive.

A SOC operates based on known attack patterns and behavioral anomalies. It recognizes what it already knows. A sophisticated attacker who works slowly and methodically, or uses a technique not yet covered by detection rules, can go undetected for weeks. That is not a shortcoming of the SOC team — it is a structural limitation of the detection model.

Penetration testing reverses the logic: instead of waiting for an attack to manifest, it actively searches for the paths an attacker could take. A red team thinks like an attacker and combines technical vulnerabilities with human and process-related weaknesses. This makes risks visible before they are exploited, not after.

When is a SOC insufficient as the sole security measure?

A SOC is insufficient as the sole measure when an organization wants to find vulnerabilities before attackers do. A SOC detects attacks, but does not eliminate the vulnerabilities that make attacks possible. Without periodic or continuous testing, weaknesses in systems, configurations, and applications remain invisible — even to the SOC itself.

Concrete situations in which a SOC falls short as the only line of defense:

• The organization has recently expanded or configured cloud services without validating the security of those configurations
• Applications or APIs are in use whose security settings have never been offensively tested
• Employees have broader access rights than necessary, without this having been considered as an attack path
• The organization is a Managed Service Provider (MSP) and therefore also manages its clients’ environments, meaning a compromise at the MSP directly affects all clients

In all these cases, the SOC is monitoring an environment whose actual vulnerabilities are unknown. That is comparable to a security guard doing rounds in a building whose locks have never been checked.

Which organizations benefit from continuous penetration testing?

Continuous penetration testing is most valuable for organizations that bear a high level of responsibility for the security of others, operate in a rapidly changing IT landscape, or are an attractive target for cybercriminals. These are primarily Managed Service Providers, but also organizations in sectors such as finance, healthcare, and critical infrastructure.

MSPs are particularly vulnerable for a specific reason: compromising a single MSP gives attackers direct access to all of that MSP’s clients. The security posture of the MSP is therefore effectively also the security posture of its clients. This makes continuous testing not just an internal matter, but a responsibility toward the entire chain.

More generally, any organization benefits from continuous penetration testing when:

• The IT environment changes regularly due to new applications, cloud migrations, or integrations
• Compliance requirements such as NIS2 demonstrably require active security management
• An annual pentest no longer keeps pace with the speed at which the organization and the threat landscape are evolving

For organizations that want to understand how their compliance and policy align with their technical security practice, continuous testing also provides a direct link between policy and reality.

Do organizations have to choose between a SOC and continuous penetration testing?

No, organizations do not have to choose. A SOC and continuous penetration testing complement each other and each address a different part of the security challenge. A SOC protects the organization while it operates; continuous penetration testing ensures that the environment the SOC monitors offers as little attack surface as possible.

The combination works as follows: penetration testing maps vulnerabilities and attack paths so they can be remediated before an attacker exploits them. The SOC then detects attempts to abuse those or other weaknesses in real time. Together, they form a defense strategy that is both proactive and reactive.

Organizations that only have a SOC are defending an environment whose actual vulnerabilities are unknown. Organizations that only conduct pentests know where the weaknesses are but lack the real-time visibility to stop an attack in progress. The strongest security combines both layers, with continuous testing continually improving the quality of the environment being defended.

How Q-Cyber helps with continuous penetration testing

At Q-Cyber, we offer Continuous-Q®, a program specifically designed for organizations that understand that security is never a finished product. Instead of an annual snapshot of a moving target, we provide ongoing insight into the actual vulnerabilities of your environment.

What we offer within this program:

• Ongoing pentests conducted by certified ethical hackers who think and act like real attackers
• Attack path analysis in which we not only report individual findings, but investigate how multiple small vulnerabilities together form a critical attack path
• Independent advice without dependency on software vendors or suppliers
• Pragmatic reporting with concrete priorities, so you immediately know where action is required
• Selective admission: the first pentest also serves as a mindset test, as we only work with organizations that take security seriously

Would you like to know whether your organization qualifies for Continuous-Q® or would you like to learn more about our approach? Contact us and we will be happy to discuss what continuous testing can mean for your organization.

Lees meer

How Does Continuous Penetration Testing Work in a Changing Cloud Environment?

Geplaatst op: 20 September 2026

Cloud environments are inherently dynamic: new services are added, configurations change, and infrastructure scales with demand. That flexibility is a major advantage, but it also continuously introduces new attack surfaces. A one-time pentest gives you a snapshot, but as soon as your environment changes, that picture is already outdated. Continuous penetration testing provides the answer: a structured, repeating testing process that scales with your cloud security and exposes vulnerabilities before attackers find them.

In this guide, you’ll read step by step how to set up continuous penetration testing for a changing cloud environment, from the initial inventory to scaling your program as your organization grows.

Map your cloud environment before you begin

Before you run a single test, you need to know exactly what you’re testing. Many organizations underestimate how fragmented their cloud environment is: multiple providers, dozens of services, temporary environments, and shadow IT running outside the IT department’s view. An incomplete inventory means you’re building blind spots into your testing program.

1. Create a complete asset inventory of all cloud accounts, subscriptions, and projects within your organization.
2. Map out per asset which services are active, who the owner is, and what data is being processed.
3. Identify connections between cloud environments and to on-premises systems.
4. Document which environments are production, acceptance, or development, so that testing risks remain manageable.

After this step, expect an overview document or asset register that is maintained as a living document. If you find more active services than expected after the inventory, that’s a signal that your governance around cloud usage needs strengthening. That’s valuable information even before the first test.

Establish a testing cadence that matches changes in the cloud

With your inventory in order, you determine how often and when to test. The cadence of continuous penetration testing depends directly on the speed at which your cloud environment changes. An environment with daily deployments requires a different schedule than a stable environment with monthly releases.

1. Link your testing frequency to your deployment cadence: the more often you deploy, the shorter the test cycle.
2. Schedule in-depth manual pentests at fixed intervals, for example quarterly, for the most critical systems.
3. Add automated scans between manual tests so that newly introduced vulnerabilities become visible quickly.
4. Set triggers for additional tests during major changes, such as migrations, new integrations, or adding a cloud provider.

Verify that your schedule actually aligns with the rate of change in your environment by tracking how many significant changes occur between tests during the first three months. Adjust the cadence if you notice that vulnerabilities are only discovered after they’ve been present for an extended period.

Automate recurring tests without losing manual oversight

Automation is essential to make continuous testing scalable, but it doesn’t fully replace manual work. Automated tools excel at recognizing known patterns and configuration errors, but lack the creativity and context that an experienced ethical hacker brings to complex attack chains.

1. Integrate automated vulnerability scans into your CI/CD pipeline so that every deployment is immediately checked for known weaknesses.
2. Use cloud-native security tools from your provider, such as configuration checks and identity audits, as a supplement to external scans.
3. Set thresholds for automatic alerts on critical findings so the team can take immediate action.
4. Schedule manual reviews of automated results at fixed intervals to identify patterns that individual alerts don’t reveal.

After setting up automation, you can expect a constant stream of test results. The risk is that teams get overwhelmed by notifications. Make sure your tooling prioritizes based on severity and exposure, and that only real action items reach the team. Current threat research helps you give the right context to automated findings.

Incorporate test results directly into your security process

Test results have no value if they remain sitting in a report. The power of continuous penetration testing lies in the speed with which findings are converted into improvements. The faster you close the cycle from testing to remediation, the smaller the risk window for attackers.

1. Link findings directly to a ticket system or backlog so that every vulnerability has an owner and a deadline.
2. Prioritize based on exploitability and impact, not just on CVSS scores, because context determines the actual risk.
3. Set a maximum remediation time per risk category: critical findings within 24 hours, high risk within one week.
4. After remediation, verify that the vulnerability has actually been resolved by performing a targeted retest.

You know this process is working when the average time between discovery and remediation structurally decreases. Organizations subject to NIS2 obligations benefit especially from this process: demonstrably fast response to vulnerabilities is a concrete fulfillment of the duty of care imposed by the directive.

Validate that your cloud environment remains resilient after every change

Every change in your cloud environment, no matter how small, can unintentionally introduce new vulnerabilities or undo existing security measures. Validation after changes is therefore not an optional step, but a fixed part of your change management process.

1. Define per type of change which tests must be performed at minimum before the change goes to production.
2. Test not only the changed component, but also the adjacent systems and integrations that may be affected by it.
3. After every significant change, perform a targeted regression test on previously found and remediated vulnerabilities.
4. Record test results per change so that you build a historical overview of the security level over time.

After every validated change, you know with certainty that your security level has at least remained the same. If you notice that changes regularly introduce new vulnerabilities, that’s a signal to incorporate security requirements earlier in the development process, for example through threat modeling when designing new functionality. For complex attack scenarios, red teaming offers an additional layer of validation that goes beyond standard pentests.

Scale your testing program alongside a growing cloud environment

A testing program that works today for ten cloud services will hit a wall tomorrow when your organization grows to a hundred services. Building in scalability from the start prevents your security program from falling behind the growth of your environment.

1. Document your testing methodology and criteria so that new team members and environments can be onboarded quickly.
2. Categorize assets based on risk and set an appropriate testing level per category so that capacity is deployed purposefully.
3. Evaluate your testing program at least annually for completeness, effectiveness, and alignment with current threats.
4. Expand your program step by step with new testing methods as your environment becomes more complex.

A mature, scalable testing program grows with your organization without a drop in quality. Also use the annual evaluation to assess whether your testing program still aligns with changes in laws and regulations and the current threat landscape in 2026.

How Q-Cyber helps with continuous penetration testing in the cloud

We understand that setting up and maintaining a continuous penetration testing program for a changing cloud environment requires both technical depth and practical insight. That’s exactly where we make the difference. Through Continuous-Q®, we offer a program that doesn’t stop at a one-time pentest, but continuously moves with your cloud environment.

Concretely, we help you with:

• A baseline assessment via a manual pentest by certified ethical hackers who work like real attackers, including advanced techniques that automated tools miss.
• A tailored testing cadence that aligns with your deployment cadence and the rate of change in your cloud environment.
• Concrete reports with prioritized findings, so your team immediately knows what requires action and in what order.
• Independent advice without dependency on software vendors, so our recommendations are always in your best interest.
• Support with NIS2 compliance, where demonstrable continuous testing contributes to your duty of care.

Want to know whether your cloud environment can withstand today’s threats? Get in touch and we’ll discuss together what a continuous penetration testing program looks like for your organization.

Lees meer

Annual Pentest vs. Continuous Penetration Testing: What’s the Difference?

Geplaatst op: 19 September 2026

An annual pentest and continuous penetration testing are fundamentally different in approach and effectiveness. An annual pentest gives you a snapshot of your security at one specific point in time, while continuous penetration testing tests your environment on an ongoing basis and identifies vulnerabilities as they arise. For organizations in a rapidly changing threat landscape, that difference is decisive. In this article, we answer the most frequently asked questions about both approaches, so you can determine what best fits your situation.

What are the disadvantages of an annual pentest?

The biggest disadvantage of an annual pentest is that it is a static measurement in a dynamic reality. You get an accurate picture of your security on the day of the test, but cybercriminals work 365 days a year on new attack techniques. What seems secure today can be vulnerable tomorrow due to a new CVE, a configuration change, or a deployed application update.

Compare it to a photo of a moving target: the photo is accurate at the moment it is taken, but immediately afterward the situation changes. In concrete terms, this means an annual pentest has the following weaknesses:

• New vulnerabilities are not picked up between two test moments, even if they have been present for months.
• Configuration changes after the pentest, such as new cloud instances or adjusted permissions, fall entirely outside the window of visibility.
• Attack chains that arise from combined weaknesses are missed when individual findings occur at different points in time.
• Compliance-driven testing leads to a checkbox mentality: the test becomes an end in itself, not a means to actually become more secure.

An annual pentest is also highly dependent on the scope agreed upon in advance. Systems outside the scope are simply not tested, while an attacker does not take defined boundaries into account. The result is a security report that feels reassuring but gives a distorted picture of the actual risks.

How does continuous penetration testing work in practice?

Continuous penetration testing is an ongoing process in which ethical hackers and automated tools test your environment regularly and systematically, rather than once a year. In practice, this means your security posture is continuously measured, new vulnerabilities are quickly identified, and findings are immediately followed up on, without waiting for the next test moment.

Where a traditional pentest is a defined project with a start and end date, continuous penetration testing is a living program. It typically operates in cycles: regular technical tests are combined with monitoring for new vulnerabilities and periodic in-depth attack simulations.

A good continuous testing program looks not only at individual technical findings, but at attack paths. Attackers do not see individual vulnerabilities; they see how multiple small weaknesses together form a route to your crown jewels. Think of a combination of a misconfiguration in Azure, overly broad permissions, and an identity weakness that each seem harmless in isolation, but together can grant full access to cloud resources. Insight into such attack chains is precisely what distinguishes continuous testing from an annual snapshot.

Which threats does an annual pentest miss that continuous testing catches?

An annual pentest primarily misses threats that arise after the test date: newly published vulnerabilities, changes in your IT environment, and attack chains that gradually develop. Continuous penetration testing catches these threats because testing is an ongoing part of your security program rather than an annual exercise.

Concretely, there are three categories of threats that an annual pentest structurally misses:

1. Known vulnerabilities that appear after the test: New CVEs are published daily. If your systems are not monitored and tested for new exploits, you are always lagging behind attackers.
2. Configuration errors caused by changes: Every update, migration, or new application can introduce new weaknesses. Incorrect Azure configurations, overly broad permissions, or insecure application settings can easily creep in within an actively changing environment.
3. Correlated attack paths: This is the most underestimated category. An attacker combines multiple small weaknesses into a single attack chain. A low-severity finding that you would normally assign low priority can, in combination with two other findings, lead to full system compromise. Continuous testing keeps the complete picture in view, not just individual findings.

Managed Service Providers face additional risk here: compromising a single MSP gives an attacker immediate access to all of that MSP’s clients. For an MSP, an annual pentest is therefore particularly inadequate, because the consequences of a missed vulnerability reach far beyond the organization itself.

When is an annual pentest still sufficient?

An annual pentest is sufficient when you have a stable, limited IT environment that changes little, does not process sensitive customer data, and is not actively exposed to targeted attacks. For small organizations without complex cloud infrastructure or critical systems, an annual pentest can be a good baseline check, provided you actually follow up on the findings.

An annual pentest also has value as a starting point. It provides a baseline measurement of your security and makes clear where the greatest risks lie. From that foundation, you can implement targeted improvements and decide whether an ongoing testing program is the next step.

However, there are clear situations in which an annual pentest falls short:

• Your environment changes regularly due to updates, migrations, or new applications.
• You process personal data, financial data, or other sensitive information.
• You are a service provider with responsibility for the security of clients.
• You fall under regulations such as NIS2, which require a demonstrable and continuous level of security.

In those cases, an annual pentest provides insufficient assurance. The compliance requirements around NIS2 also make clear that a snapshot is no longer sufficient as evidence of adequate security.

What does continuous penetration testing cost compared to an annual pentest?

Continuous penetration testing typically costs more on an annual basis than a one-off annual pentest, but the comparison is more nuanced than price alone. An annual pentest may seem cheaper, but the actual costs of a missed vulnerability, a data breach, or a security incident are almost always higher than the investment in ongoing testing.

An annual pentest is a project-based expense: you pay once for the execution and the report. Continuous penetration testing typically works via a subscription model, where you pay monthly for ongoing testing capacity, reporting, and follow-up. This makes costs more predictable and easier to justify as a structural security investment.

What further influences the comparison:

• Economies of scale: With continuous testing, findings are addressed immediately, which means remediation costs are lower than resolving a year’s worth of accumulated issues all at once.
• Insurance value: Demonstrably continuous testing strengthens your position with cyber insurers and during audits.
• Risk reduction: The likelihood of an incident, and with it the associated costs, decreases significantly with ongoing monitoring and testing.

How do you choose the right pentesting approach for your organization?

You choose the right pentesting approach based on three factors: the complexity and rate of change of your IT environment, the sensitivity of the data you process, and the responsibility you bear for the security of others. The higher the risk on each of these points, the stronger the arguments for continuous penetration testing.

Start with an honest assessment of your situation. Ask yourself how often your environment changes, what the consequences of a security incident would be for you and your clients, and whether you comply with regulations that require demonstrable, continuous security. Based on those answers, the choice quickly becomes clearer.

Also consider how you view security. An organization that sees security as a checklist for the auditor needs a different approach than one that understands security is never a final destination. Red team exercises and continuous testing fit that second mindset: security as a living capability, not an annual project.

Practical steps to make the choice:

1. Map out how often your IT environment changes and how many systems would fall outside a regular annual scope.
2. Determine what data you process and what the impact of a data breach or system outage would be.
3. Check whether you fall under NIS2 or other regulations that require continuous security.
4. Assess whether you bear responsibility for the security of clients, as is the case with an MSP.
5. Use an initial pentest as a baseline measurement, regardless of which approach you choose, so you know where you stand.

How Q-Cyber helps you choose the right testing approach

At Q-Cyber, we help organizations transition from a static security approach to a dynamic, ongoing testing strategy. We offer concrete solutions tailored to your situation:

• Manual pentests by certified ethical hackers who not only identify individual vulnerabilities, but also expose correlated attack paths that automated tools miss.
• Continuous-Q®, our ongoing penetration testing program developed specifically for Managed Service Providers and organizations with a high level of responsibility for client security.
• Independent advice on which approach fits your environment, without dependency on software vendors or other suppliers.
• NIS2 guidance for organizations that must demonstrably and continuously meet security requirements.

We always start with an initial pentest as a baseline measurement: a technical assessment of your actual vulnerabilities and a test of the security mindset within your organization. Because you cannot defend what you do not test. Want to know which approach best fits your organization? Contact us for a no-obligation conversation.

Lees meer

How Can Service Accounts Be Abused?

Geplaatst op: 18 September 2026

Service accounts are one of the most underestimated risks in modern IT environments. They run in the background, are rarely monitored, and often have more permissions than strictly necessary. That makes them an attractive target for attackers seeking access to systems, data, or cloud resources. When a service account is compromised, an attacker can move through a network undetected and escalate privileges without triggering any alarms.

In this guide, you’ll find a step-by-step breakdown of how to identify vulnerable service accounts, what attack techniques to expect, and which measures you can take immediately to reduce the risks of service account abuse.

How to identify vulnerable service accounts in your environment

Before you can secure anything, you need to know what you have. Many organizations have dozens or even hundreds of service accounts that were created over the years and never cleaned up. Start with an inventory of all accounts that are not interactive users but do have access to systems, applications, or networks.

During your inventory, look for the following characteristics that indicate elevated risk:

• Service accounts with a password that hasn’t been changed in years
• Accounts with Domain Admin or other high privileges that don’t require them
• Accounts linked to multiple systems or applications simultaneously
• Accounts without an owner or without clear documentation of their purpose
• Inactive accounts that are still active in Active Directory or a cloud platform

Use tools such as Active Directory Users and Computers, Azure AD (Entra ID), or PowerShell scripts to create a complete overview. Also check whether any service accounts exist with the ability to log in interactively, as this is not necessary for most automated processes and unnecessarily increases the attack surface. With this overview as a foundation, you can start cleaning up and securing in a targeted way.

Common attack techniques targeting service accounts

Understanding how attackers operate is essential to setting up your defenses properly. Service account attacks often follow a recognizable pattern, where the attacker exploits misconfigurations and overly broad permissions rather than advanced exploits. An attacker doesn’t always need to exploit a critical vulnerability; sometimes a poorly configured account is enough to gain full access.

The most common techniques are:

• Kerberoasting: An attacker requests Kerberos service tickets for accounts with a Service Principal Name (SPN) and attempts to crack them offline. Service accounts with weak passwords are particularly vulnerable to this.
• Pass-the-Hash and Pass-the-Ticket: Stolen password hashes or authentication tickets are reused to gain access to other systems without knowing the actual password.
• Privilege escalation via misconfigurations: A service account with overly broad permissions in a cloud platform such as Azure can be abused to gain access to sensitive resources via managed identities or RBAC roles.
• Lateral movement: Once in possession of a service account, the attacker moves laterally through the network toward higher-value systems.

What these techniques have in common is that they often exploit combinations of small weaknesses. A service account with an old password, overly broad permissions, and no monitoring is an open door. That is precisely why good pentest specialists look not only at individual vulnerabilities, but at the full attack chain.

Restrict permissions with the principle of least privilege

Least privilege is the foundation of secure service account security. The principle is simple: each account is granted only the permissions strictly necessary for the task it was created for, nothing more and nothing less. In practice, this principle is regularly violated because it is easier to grant broad permissions than to precisely determine what an account actually needs.

Carry out the following steps to apply least privilege to existing and new service accounts:

1. Document per service account which systems, applications, or data the account needs to perform its task.
2. Remove all permissions not listed in that documentation, including unnecessary group memberships.
3. Replace broad roles (such as Domain Admin or Global Administrator) with specific, custom-built roles.
4. Use separate managed identities in cloud platforms such as Azure instead of shared service accounts where possible.
5. Set up a review cycle, at minimum quarterly, in which permissions are reassessed.

After this step, each service account should have a clearly defined and limited set of permissions. Verify this by exporting the effective permissions and comparing them with the documentation. If an account has more permissions than documented, immediate action is required.

Configure strong authentication and password policies

With permissions restricted, the next step is strengthening authentication. Many service account risks arise because passwords are not changed for years or because they are based on predictable patterns. Attackers who apply Kerberoasting count on service accounts having weak passwords that can be cracked offline quickly.

Configure the password policy for service accounts as follows:

1. Use passwords of at least 25 characters with a combination of letters, numbers, and special characters. The longer the password, the harder it is to crack.
2. Set up automatic password rotation using tools such as Group Managed Service Accounts (gMSA) in Active Directory, so passwords are automatically and regularly renewed without manual intervention.
3. Disable interactive login for service accounts that do not require it, by setting the appropriate account options in Active Directory or the identity platform.
4. Implement certificate-based authentication or managed identities as an alternative to passwords wherever possible.

After configuration, verify that the gMSA accounts are functioning correctly by testing the linked services. Also check whether any regular service accounts still exist that can be migrated to gMSA, as this virtually eliminates password management as a risk factor.

Enable logging and detect anomalous behavior

Even with strong authentication and restricted permissions, monitoring is indispensable. Attackers who gain access to a service account try to stay under the radar for as long as possible. Without active logging and detection, a breach can go undetected for weeks or months. Research into cyberattacks repeatedly shows that the time between intrusion and discovery is one of the most decisive factors in the damage an attack causes.

Enable the following logging and detection measures:

1. Enable audit logging for all service accounts, including successful and failed logins, permission changes, and access to sensitive resources.
2. Set up alerts for anomalous behavior, such as logins outside business hours, logins from unknown IP addresses, or the use of a service account for interactive sessions.
3. Centralize logs in a SIEM platform so you can correlate events across different systems.
4. Define a baseline of normal behavior per service account, so deviations are spotted more quickly.

A good way to verify that your logging works is a simulated test: log in with a service account at an unusual time and check whether the alert is triggered. If it is not, the detection rules are not properly configured and you need to adjust the settings before proceeding.

Validate your configuration with a service account audit

The previous steps have made your environment considerably more secure, but validation is the final and crucial step. It is one thing to implement measures; it is another to confirm that they actually work as intended. A service account audit maps the remaining weaknesses before an attacker does.

Conduct a thorough audit with the following actions:

1. Export a complete overview of all service accounts, their permissions, password age, and last activity.
2. Compare the current permissions with the documented least privilege configuration and note all deviations.
3. Check whether all gMSA accounts are correctly configured and whether no outdated regular service accounts exist alongside them.
4. Review the audit logs from the past period for unexpected activity or login patterns that were previously missed.
5. Run a Kerberoasting simulation using a tool such as Rubeus or Impacket to check which accounts are vulnerable to offline cracking attacks.

After the audit, you will have an up-to-date and reliable picture of the state of your service account security. Repeat this audit at minimum every quarter or after significant changes to the IT environment, such as a cloud migration, a new application, or a reorganization. Security is not a destination, but an ongoing process.

How Q-Cyber helps with service account security

Knowing what to do is one thing; being certain it has been done correctly is another. Service accounts are a favorite attack path for attackers precisely because they are so often overlooked. We help organizations map this blind spot and close it structurally.

What we do for this:

• We conduct a thorough pentest in which we actively attempt to abuse service accounts using techniques such as Kerberoasting, privilege escalation, and lateral movement, exactly as a real attacker would.
• We map attack paths that arise from combinations of misconfigurations, overly broad permissions, and weak authentication, even when no individual finding appears critical on its own.
• Via Continuous-Q® we continuously monitor your environment, so that new service accounts or permission changes do not go unnoticed and introduce new risks.
• We deliver concrete recommendations that are immediately actionable, without unnecessary technical noise.

Want to know how vulnerable your service accounts are right now? Get in touch with us and we’ll discuss together which approach best suits your environment.

Lees meer

Why Are Identities and Permissions Important Within Attack Paths?

Geplaatst op: 17 September 2026

An attacker who infiltrates an organization rarely does so through one spectacular vulnerability. More often, it is a combination of small steps: an account with too many privileges here, a misconfiguration there, and an identity that has access somewhere it doesn’t actually need. Precisely that combination forms what in cybersecurity is called an attack path. This article explains what identities and permissions are, why they play such a central role within attack paths, and how your organization can gain control over this underestimated risk.

We build the explanation step by step: from the basic concepts to the way attackers combine these elements, and ultimately to what good defense looks like in practice.

What are identities and permissions in cybersecurity?

An identity in the context of cybersecurity is anything that can authenticate within a digital environment. These are not only human users, but also service accounts, applications, scripts, and cloud resources that act on behalf of a system. Every identity has a digital identity that determines who or what gains access to which systems.

Permissions are the rights linked to an identity. They determine what an identity is allowed to do: read files, change settings, create new accounts, or grant access to others. Together, identities and permissions form the core of access management within every organization.

A simple analogy: imagine an office building. An identity is an employee’s badge. The permissions determine which doors that badge opens. A cleaner has access to the office spaces, but not to the server room. An IT administrator does. In digital environments it works exactly the same way, except the number of doors and badges quickly runs into the hundreds or thousands.

How do attackers build an attack path through identities?

An attack path analysis shows how an attacker moves step by step through an environment by exploiting existing identities and permissions. What is remarkable is that this often requires no technical exploit. An attacker looks for what already exists and how it can be abused.

The process typically unfolds in phases:

1. Reconnaissance: The attacker maps out which identities exist, what rights they have, and which systems they can reach.
2. Initial access: Through a compromised account, a phishing attack, or a weak password, a first identity is taken over.
3. Privilege escalation: From that starting point, the attacker looks for accounts or configurations that offer more rights.
4. Lateral movement: With the acquired rights, the attacker moves through the network, from system to system, getting ever closer to the ultimate target.

What makes this dangerous is that each step on its own can appear innocent. A service account with read access to a certain folder, combined with a misconfiguration in cloud storage and an administrator who reuses the same password: none of these elements is alarming on its own. Together, however, they form a working attack path straight to the crown jewels of the organization.

Why are overprivileged accounts so dangerous?

Privilege escalation is one of the most commonly used techniques in attacks, and overprivileged accounts make it considerably easier. An overprivileged account is an identity that has more rights than strictly necessary for the associated task.

This often arises not through intent, but through convenience. An employee temporarily receives extra rights for a project and those are never revoked. An administrator configures a service account with broad access to prevent future problems. A cloud resource is given administrator rights by default because that was the quickest way to get it working.

From an attacker’s perspective, an overprivileged account is a gift. Whoever compromises such an account no longer needs to perform privilege escalation themselves. The rights are already there. This significantly shortens the attack path and increases the damage an attacker can cause before being detected. Consider an employee whose account has been taken over via phishing: if that account also has administrator access to the cloud environment, the attacker immediately has a critical position.

Permissions in practice: where does it go wrong?

In most organizations, permissions grow organically alongside the organization, without a systematic process to review them periodically. This leads to a number of recurring problems that attackers actively exploit.

Rights that are never revoked

Employees who change roles or leave the organization often retain their original access rights. A former system administrator who now works in a different role may still have full access to critical systems. If that account is compromised, the consequences are proportional.

Service accounts with overly broad rights

Applications and automated processes also need identities to function. In practice, these service accounts are often granted broader rights than necessary, because configuring minimal rights takes more time. Attackers specifically target these accounts because they are rarely actively monitored.

Misconfigurations in cloud platforms

Cloud platforms such as Microsoft Azure or AWS work with complex permission structures. Default settings are not always secure, and small configuration errors can have major consequences. A storage container that is accidentally publicly accessible, or a role that is defined too broadly, can be part of an attack path without anyone realizing it. A thorough pentest can expose these kinds of hidden weaknesses.

Identity management as a defense against attack paths

Effective identity management is one of the most powerful measures to break attack paths. The core is the principle of least privilege: every identity receives only the rights necessary for the specific task, and no more.

In practice, this means a number of concrete steps:

• Regular access reviews: Periodically checking which identities have which rights, and revoking rights that are no longer needed.
• Separation of duties: Critical actions require multiple accounts or approvals, so that a single compromised identity is not sufficient for an attacker.
• Multi-factor authentication (MFA): Taking over an identity becomes considerably more difficult when a password alone is not enough.
• Monitoring of identity-related activity: Anomalous behavior from accounts, such as unusual login times or access to systems not normally used, can be an early signal of a compromised identity.
• Minimal rights for service accounts: Automated processes and applications receive only the rights they genuinely need, nothing more.

Building on the principles discussed earlier: an attacker looking to construct an attack path searches for the weakest link in the chain of identities and permissions. The tighter that management is set up, the more steps an attacker needs, and the greater the chance of being detected before reaching the target. Policy around access management is an indispensable foundation for this.

It is also important to recognize that identity management is not a one-time exercise. Environments change constantly: new employees, new applications, new cloud resources. Each of those changes can introduce new identities and permissions that an attacker can exploit. Continuous insight is therefore essential, not just on the day of an audit.

How Q-Cyber helps with identity and permission management

At Q-Cyber, we understand that identities and permissions are not just a technical issue, but a strategic risk that requires ongoing attention. We help organizations map attack paths and identify the weak links in access management, before an attacker does.

What we offer:

• Manual pentests in which our ethical hackers actively search for attack paths via identities, permissions, and misconfigurations
• Red team exercises in which we reason like a real attacker, including combining weaknesses that automated tools miss
• Advice and policy development around least privilege, access reviews, and identity management
• Continuous insight through our Continuous-Q® program, so you know where you stand not just on the day of testing, but throughout the entire year

Want to know how your organization is performing in the area of identities and attack paths? Get in touch with us and we will be happy to think along with you.

Lees meer