Helpdesk Penetration Testing: Lessons from the DIVD Breach

When commissioning a security assessment, it is easy to focus on the website and the product customers use. Penetration testing should also consider the helpdesk: the tickets and documents it holds, who can access them, and the systems it connects to. The DIVD breach, with further details published in early October 2026, is a reason to check whether your support platform belongs in the testing scope.

What DIVD disclosed about the breach

The Dutch Institute for Vulnerability Disclosure (DIVD) publicly disclosed a breach of its infrastructure on September 24, 2026. According to its official incident record, updated on October 1, the attacker's first access occurred on September 21, and malicious activity was detected the following day. DIVD reported that entry involved two zero-day vulnerabilities in Zammad, a helpdesk ticketing system. The investigation remains open.

The related vulnerability record describes user-session hijacking leading to remote code execution and a local privilege-escalation vulnerability. Exploitation conditions depend on the version and environment. Organizations using Zammad should check current guidance against their own installation; exposure should not be assumed to be identical across deployments.

The practical lesson concerns the scope of support-system security testing. The disclosure does not establish that an earlier assessment would have found these vulnerabilities or tell us which tests DIVD conducted before the breach. It does give other organizations a useful question: do we understand the business consequences of unauthorized helpdesk access, and have we examined them under controlled conditions?

Start with the information your helpdesk holds

Before commissioning an assessment, meet with the support manager and the system owner to map the information passing through the platform. Check whether tickets retain customer documents, screenshots, infrastructure details, or files supplied during troubleshooting. These are questions for your organization, not a description of data exposed in the DIVD incident. The answers help identify worthwhile scenarios and decide what can be demonstrated using test data.

Next, list the user roles and what each should be able to see. Customers, support agents, and team managers may need different access. For example, an agreed test could examine whether one customer can view another customer's ticket, including its attachments. Adapt the scenario to the system and perform it only within the authorized scope.

The mapping exercise should produce clear business agreement about access boundaries. If the support team is unsure who should see a particular document, resolve that before testing. Otherwise, even a precise technical finding can lead to a lengthy debate over whether the behavior is a defect or an intended convenience.

Include connections to other business systems

The scope should reflect the integrations your organization actually uses. Establish whether the helpdesk connects to email, customer relationship management, an identity provider, or file storage. For each connection, record which information passes through it and the permissions involved. This helps select relevant scenarios without treating every integration as a vulnerability or extending testing into systems that have not been approved.

Suppose a helpdesk uses a service account to access documents. One proposed scenario would examine whether that account is restricted to the folder required for its work. If it can reach additional information, determine what permits that access and what changing the permissions would affect. This is an illustrative test scenario, not a finding from the DIVD investigation. Keeping the distinction explicit avoids attributing unpublished details to a real incident.

Where an external provider manages part of the environment, establish who can authorize testing and who owns remediation. Ask the proposal to identify exclusions and explain their implications. This makes it easier to judge whether the assessment will answer the business question or requires a separate discussion with the provider about controls the testing team cannot examine.

Define what the assessment should establish

Bring answerable questions to the scoping discussion. Can a customer reach another customer's documents? Can a support agent perform an action reserved for a manager? Can a service account access information beyond its defined purpose? Select only the questions that fit your environment. They give testers a concrete objective and help the system owner interpret the results.

The Open Worldwide Application Security Project (OWASP) Web Security Testing Guide emphasizes combining automated tools with testing that accounts for application context. Ask for the planned manual scenarios and required test accounts alongside the proposed scanning activities. A list of tools alone does not explain which questions the assessment will address.

Agree on execution boundaries, including the environment, testing window, contacts, and permitted data. Ask the report to distinguish an attempted action that was blocked from an action that could not be tested because of a limitation. That distinction prevents broad conclusions from limited coverage and helps plan follow-up work where the current engagement cannot cover every relevant scenario.

Decide how findings will be handled

Before work begins, identify who receives an urgent finding and who decides what happens next. If testing reveals document exposure, for example, someone should have clear authority to restrict access and understand what needs checking before a change. The decision depends on the environment and business operations. Testing should provide evidence to support it, without making the number of findings the sole measure of success.

For each significant finding, request the conditions under which it appeared, the information or action that was accessible, and a recommendation the responsible team can act on. Define how remediation will be verified. For an access-control issue, check both that unwanted access is blocked and that authorized users can still do their jobs. This connects the technical fix to the business outcome.

If there is reason to suspect an existing compromise, the organization needs incident assessment and response. Scheduling a future penetration test is insufficient, and fixing a vulnerability does not explain what happened earlier. Track remediation and incident investigation separately so each decision rests on the relevant evidence and specialist input.

How Cybecs helps with penetration testing

Cybecs performs penetration testing for web applications, application programming interfaces (APIs), mobile applications, cloud environments, and internal and external networks. A discussion about Cybecs penetration testing services can start with your helpdesk and the processes you want examined, then identify the assessment areas that fit that environment.

Prepare a list of systems, user roles, and provider integrations, along with the information whose access needs to be restricted. Identify which components your organization controls and which are managed externally. This gives the scoping discussion a practical basis and helps expose questions that need additional coordination before testing begins.

Frequently asked questions about penetration testing

Should a purchased support platform also be tested?

Consider the risk and the division of responsibility. Some work may focus on configurations and integrations your organization controls, while other activities require coordination with the provider. Obtain appropriate authorization before performing testing.

Does a penetration test find every zero-day vulnerability?

An assessment is limited by its duration, scope, and the access provided to the team. It may reveal previously unknown vulnerabilities, but that does not mean it will find every flaw. The published facts here do not establish what an earlier test would have discovered.

What should we prepare before a scoping discussion?

Prepare a short description of the platform, user roles, sensitive information, and connections to other services. Include the business questions you want answered and operational constraints. You do not need to send sensitive data or passwords to begin the conversation.

The next step in planning your assessment

Open the scope for your next assessment and check whether the helpdesk is included. If it is missing, establish who owns it, what information it holds, and why it was excluded. That creates a focused starting point for deciding whether the planned work addresses the risk your organization needs to examine.

Speak with Cybecs about penetration testing for your business systems.