Penetration Testing

Your partner for preparing, planning, and executing penetration tests for corporate networks, applications, and systems. Competent by your side.

Penetration Testing

Penetration Testing

Do you need support analyzing your IT systems?


Our expertise is at your service - feel free to contact us.


CONTACT US

Identify Security Vulnerabilities Before Others Do

In a business world increasingly threatened by cyberattacks, companies must urgently protect their IT systems. Otherwise, investments in product development, patents, and business processes are at risk. To reduce the likelihood of successful attacks, it is crucial for manufacturers and operators to conduct regular penetration tests. Penetration testing is a highly effective tool for identifying potential security vulnerabilities, determining remediation steps, and enhancing overall security. By performing regular penetration tests, companies can proactively address threats and better protect their data and business operations.

Our Offer for You

With our expertise, we are equipped to thoroughly test your products or systems. We are here to provide guidance and offer the following security testing services:

IoT & Embedded

Using state-of-the-art laboratory equipment, we can analyze all aspects of your embedded systems and IoT devices, from individual sensors to complete ecosystems. As part of our security tests, we provide comprehensive analysis of:

  • All internal (e.g., JTAG, I²C, SPI) and external interfaces (e.g., USB, Ethernet), including wireless interfaces (e.g., Wi-Fi, Bluetooth/BLE, ZigBee, LoRaWAN, cellular networks)
  • Internal (e.g., onboard flash memory) and external storage (e.g., SD cards)
  • Firmware, including network services and firmware update processes
  • Automotive hardware and software, including control units, entire vehicles, and mobile apps for vehicle control

Web Applications and Services

In the realm of web components, we provide penetration testing in accordance with established guidelines like the OWASP Web Security Testing Guide (WSTG). Our services include:

  • Web applications built on a wide range of technologies
  • APIs (e.g., REST, SOAP)

We also conduct thorough source code analysis to identify vulnerabilities in your applications and APIs.

OT- & IT-Infrastructures and Components

By conducting security tests on your OT and IT environments, you can assess the security of your infrastructure components and internal networks. We offer comprehensive analysis of:

  • Perimeter systems
  • Corporate networks
  • Cloud environments
  • Infrastructure as Code architectures
  • Hardening measures for servers, databases, etc.
  • Connections between OT and IT infrastructures
  • Production facilities and control systems

Mobile Applications

For mobile applications (Android, iOS), we also offer penetration testing based on well-known and up-to-date guidelines such as the OWASP Mobile Application Security Testing Guide (MASTG). Depending on your needs, we conduct the following analyses:

  • Static and dynamic analysis of mobile applications
  • Examination of all communication channels (e.g., communication with backend systems)
  • Source code analysis

Our Methodology

The penetration testing process of BDO Cyber Security GmbH is based on the five-step approach defined in “Study A Penetration Testing Model”, published by the German Federal Office for Information Security (BSI).

  Phase 1
  Preparation

During the first phase of the penetration test, test objectives as well as organizational, technical, and legal aspects are coordinated with the client, including:

  • Components that should be in scope of the test as well as associated key aspects of testing (test scope),
  • Components and test cases that should not be in scope of the test (out of scope),
  • Overall testing strategy, including:
    • Information basis (e.g., Black-Box, Gray-Box, or White-Box approach)
    • Level of aggressiveness (e.g., passive scanning, cautious, balanced, or aggressive)
    • Approach (covert or overt)
    • Starting point for the test (external perspective, internal perspective)
  • Potential (technical) issues that might affect the testing procedure and results
  • Contacts list, including an emergency contact on either side in case that urgent communication or help is required

The results of this phase are documented in a contract, which serves as the legal basis for the penetration testing engagement.

  Phase 2
  Reconnaissance

In phase 2, the information and documents provided by the customer are examined, thereby gathering preliminary information about the test object, e.g.,

  • Used technologies, frameworks, and software versions
  • Reachable hosts and / or (sub-)domains
  • Accessible (hardware) interfaces

In parallel, it will be verified whether access to all test components is possible. 

  Phase 3
  Analysis of Information

Based on the information gathered during previous phases, the list of planned test cases - and therefore the time required - can be adjusted for selected components according to their relevance. This involves identifying, analyzing, and prioritizing potential threats and attack vectors (e.g., based on damage potential, likelihood of success, and possible impacts).

  Phase 4
  Active Intrusion Attempts

Following the initial analyses, active intrusion attempts are conducted. For this purpose, selected test cases for each component in scope will be executed.

If a test case reveals a (potential) vulnerability, its exploitability and impact are examined:

  • Exploitability refers to conditions affecting the success of an intrusion attempt, such as the accessibility of the vulnerable component, required permissions and expertise, safeguards and protection mechanisms, etc.
  • Impact refers to the consequences that a successful attack would have, e.g., on confidentiality, integrity and availability of systems, user accounts or data

Furthermore, evidence is gathered for each vulnerability, such as screenshots or step-by-step instructions to reproduce the attack or provoke specific system behaviors.

If applicable, activities from phases 2 and/or 3 will be repeated based on the results and information obtained during this phase. This may involve adding or adjusting test cases, as the presence of certain vulnerabilities could indicate susceptibility to other types of attacks.

  Phase 5
  Final Analysis and Clean-Up

The penetration test is concluded with the Final Analysis and Clean-Up Phase. During the final analysis, all results from the previous phases are compiled into a detailed report, including:

  • A summary of the test approach and test results, including an assessment of the test object’s overall security level
  • A detailed description of each discovered vulnerability, including proof-of-concept and screenshots
  • A rating of each vulnerability regarding of its severity
  • General recommendations for remediation or mitigation of the identified vulnerabilities

If necessary, remnants of the test activities are also removed during this phase.

All tests are primarily conducted manually. This approach allows for the identification of vulnerabilities that automated tools, such as vulnerability scanners, might miss. If feasible, individual test steps may be facilitated using (semi) automated tools. Results, produced by such tools, are reviewed, and analyzed by the test team. If in doubt, automated tests are repeated manually, thereby eliminating false positives.

Testing Based on Established Frameworks

In the context of the penetration test, test cases are selected and executed based on testing guidelines. While the BSI model for penetration tests categorizes test cases into modules for information gathering (I-Modules) and intrusion attempts (E-Modules), BDO Cyber Security GmbH employs its own framework. The primary reason for this is that the I- and E-Modules are limited to certain technologies, which restricts the testing process.

BDO Cyber Security GmbH's framework is based on recognized, current standards. Specifically, the following guidelines are used depending on the specific test subject:

  • Web Applications and Web Services: Testing of web-based solutions is conducted based on the OWASP Web Security Testing Guide (WSTG).
  • Mobile Applications: Testing of mobile applications (Android and iOS) is carried out using the OWASP Mobile Application Security Testing Guide (MASTG).
  • IT Infrastructures and Infrastructure Components: Testing of IT infrastructures and individual infrastructure components is based on a test case catalog developed and maintained by BDO Cyber Security GmbH.
  • Hardware Devices: Testing of hardware devices is based on the OWASP IoT Security Testing Guide as well as a test case catalog developed and maintained by BDO Cyber Security GmbH.
  • Security Audits/Hardening Checks: Security audits and hardening checks are performed based on the CIS Benchmarks.

Contact us!

Dr. Antje Winkler

Dr. Antje Winkler

Partner | Offensive Security
View bio
Luca Pascal Rotsch

Luca Pascal Rotsch

Manager | Offensive Security
View bio

FAQ Penetration Testing at BDO Cyber Security GmbH

A penetration test simulates real-world attacks on IT systems, devices, applications or networks in order to identify security vulnerabilities at an early stage. It highlights which vulnerabilities could realistically be exploited and what impact this could have on systems, data and business processes. This provides companies with a realistic assessment of their security posture and enables them to mitigate risks before they are exploited by attackers.

The benefits can be demonstrated in particular by the following points:

  • Early risk detection: Vulnerabilities are identified before they can be exploited by attackers. 
  • Preventing damage: Rectifying critical security vulnerabilities can reduce the risk of system failures, data loss and security incidents. 
  • Prioritising measures: The results help to target security investments at the most significant risks. 
  • Meeting requirements: Penetration tests help organisations meet security, compliance and customer requirements. 
  • Demonstrating security standards: Organisations can demonstrate to customers, partners and internal stakeholders that they are actively managing cyber security. 

A penetration test is therefore not merely a technical assessment, but a tool for sound risk assessment and decision-making support for management.

Whether and to what extent penetration tests are required depends on the applicable regulations and the company’s individual risk profile. There is no general legal obligation for every company to carry out penetration tests.

However, various legal, regulatory or sector-specific requirements may mandate the regular review of the effectiveness of security measures. Examples of these include the NIS2 Directive, the Cyber Resilience Act (CRA) and other national and international regulatory frameworks.

Penetration tests are regarded as a tried-and-tested method for identifying vulnerabilities, assessing risks and supporting compliance requirements. In this way, they support the implementation of risk-based security management, as required, for example, by NIS2.

No. Penetration tests are an important component of a comprehensive security strategy, but they are no substitute for organisational and technical security measures.

These include, for example:

  • Maintaining staff awareness
  • Vulnerability management
  • Patch management
  • Monitoring
  • Incident response
  • Security policies and processes

Yes. Cyberattacks are by no means limited to large enterprises. Small and medium-sized enterprises also frequently process sensitive data or operate business-critical systems, and are therefore just as likely to be targeted by attackers.

Furthermore, many attacks – such as ransomware and phishing attacks – are not only targeted at specific companies, but are often automated and cast a wide net. Attackers search for vulnerabilities regardless of a company’s size or sector. This means that even smaller businesses can fall victim to such an attack purely by chance, for example if a known security vulnerability remains unpatched.

A penetration test helps to identify risks at an early stage and to improve security measures in a targeted manner.

A penetration test typically comprises the following phases:

  1. Preparation: The client and service provider jointly discuss the test objectives, test procedures and scope, any specific restrictions, and organisational and technical framework conditions (in particular, points of contact and communication channels).
  2. Information gathering: Depending on the type of test, different information may be required. The specific information required depends largely on the scope and nature of the penetration test. For a black-box penetration test, for example, user accounts or internal information are not usually provided, whilst grey-box or white-box tests may require more detailed information. The information actually required is agreed upon before the penetration test begins as part of the project clarification and scope definition.
  3. Evaluation of the information: The test team analyses the test objectives and identifies potential attack vectors. The possible test cases are then prioritised based on the expected potential for damage and the likelihood of success.
  4. Active penetration attempts: The test cases are executed and active manipulation and penetration attempts are carried out. For any vulnerabilities identified, their exploitability and impact are assessed, and evidence such as screenshots, commands and logs is collected.
  5. Final analysis and clean-up: A detailed report is produced at the end of the process. In addition to a management summary, this report contains detailed descriptions of each identified vulnerability, including a description of the procedure and screenshots for demonstration purposes, a severity rating and recommendations for action. The results are discussed with the client during a debriefing.

Once the penetration test has been carried out and the client has implemented the resulting measures, a retest can also be carried out on request. This retest verifies whether the previously identified vulnerabilities have been successfully rectified. This provides companies with evidence of the effectiveness of the security measures implemented.

The basic procedure for a hardware penetration test is the same as that for a traditional penetration test: starting with an analysis of the hardware (e.g. an IoT or embedded device), potential vulnerabilities are identified, specifically tested for exploitability, and the results are then evaluated and documented.

However, a hardware penetration test places particular emphasis on the following aspects:

  • Device firmware, including the associated firmware update mechanisms
  • Bus systems as well as on-board and debug interfaces, such as SPI, UART or JTAG
  • External interfaces, such as USB, Ethernet or CAN
  • Wireless interfaces, such as Wi-Fi, Bluetooth, Bluetooth Low Energy and ZigBee
  • Control options and user interfaces, such as touchscreens
  • Communication channels to the device’s connected ecosystem (e.g. cloud backend, mobile app, other devices)
  • Memory modules that may contain sensitive data
  • Secure boot mechanisms designed to ensure the integrity of the system at start-up
  • Cryptographic implementations to ensure the confidentiality and integrity of data

The hardware penetration test therefore goes beyond a purely software-based penetration test and also takes into account potential avenues of manipulation via physical interfaces or weaknesses in the hardware-related security architecture.

In a black-box test, the testers have no access to internal information.

In a grey-box test, selected information or user accounts are made available. This additional information enables testers to carry out more in-depth analyses and identify vulnerabilities that might otherwise remain hidden in a purely black-box scenario.

In a white-box test, testers are provided with extensive information such as source code, architectural or network documentation. White-box tests are particularly suitable for security-critical applications.

A penetration test can, for example, identify the following vulnerabilities:

  • Incorrect configurations
  • Insecure authentication methods and the use of default passwords
  • Security vulnerabilities caused by programming errors in applications (e.g. web, mobile, desktop), APIs and devices
  • Out-of-date software, as well as insecure update processes for software and firmware
  • Insecure network services and communication protocols
  • Cryptographic weaknesses
  • Openly accessible management interfaces and device interfaces (e.g. for debugging)

It is important to note, however, that whilst a penetration test identifies security vulnerabilities, it cannot guarantee their complete absence. As time and resources are limited, it is not possible to test all functions, inputs and scenarios. Furthermore, a penetration test only ever reflects the security status at the time it is carried out. Regular testing and a continuous security strategy are therefore essential.

The assessment takes into account technical risks and potential impacts on the organisation. Factors such as exploitability, confidentiality, integrity, availability and business impact are considered.

A standardised assessment system for classifying the severity of security vulnerabilities is the Common Vulnerability Scoring System (CVSS) or the CVSS score. The CVSS enables vulnerabilities to be assessed on the basis of objective criteria and their severity to be better categorised.

The CVSS score is expressed on a scale from 0.0 to 10.0: 0.0 (no impact), 0.1 to 3.9 (low severity), 4.0 to 6.9 (moderate severity), 7.0 to 8.9 (high severity), 9.0 to 10.0 (critical severity).

The assessment takes various factors into account, including:

  • how easily the vulnerability can be exploited 
  • whether, and if so, with what privileges, an attacker must be authenticated 
  • whether user interaction is required 
  • the impact on confidentiality, integrity and availability 

High and critical vulnerabilities with significant impact and ease of exploitation should be addressed as a matter of priority. We are happy to assist in assessing vulnerabilities within the relevant business context and in defining and prioritising appropriate measures.

The CVSS score provides a standardised basis for prioritising vulnerabilities and is used by many manufacturers, security service providers and databases, such as the National Vulnerability Database (NVD).

However, it is important to note that the CVSS score merely describes the technical severity of a vulnerability. The actual risk to a company also depends on factors such as system criticality and specific business processes.

Many organisations carry out tests annually or every six months. Penetration tests are recommended:

  • before going live
  • following major functional or architectural changes
  • following security-related incidents
  • on a regular basis as part of the security programme

The duration of a penetration test depends on the scope and complexity of the project. Smaller assessments can be carried out within a few days, whilst extensive infrastructure, cloud or red-teaming projects can be considerably more complex. The effort involved depends, amongst other things, on:

  • Number of systems
  • Complexity
  • Depth of testing
  • Available information
  • Test methodology
  • Compliance requirements

Automated security scans are an important part of security assessment, but cannot fully replace a penetration test. They are designed to identify known vulnerabilities, misconfigurations and outdated software versions. In doing so, they operate predominantly on a rule- and signature-based approach.

A penetration test goes far beyond this. It assesses the actual exploitability of vulnerabilities and takes into account the specific application context and business logic. Many security-related vulnerabilities can only be detected to a limited extent, if at all, by automated scanners.

The limitations of automated scans include, in particular:

  • Failure to assess business logic errors and complex attack paths 
  • Limited detection of authorisation and access control issues 
  • No realistic assessment of the actual impact of a vulnerability 
  • Limited ability to identify vulnerabilities affecting multiple systems or functions 
  • False positives that require manual verification 
  • Overlooking vulnerabilities not covered by known signatures or rules 

A penetration test combines automated tools with manual checks and the expertise of experienced security professionals. This enables even complex vulnerabilities, misconfigurations and attack scenarios to be identified, which often go undetected by security scans alone.

Automated security scans and penetration tests should therefore be regarded not as alternatives, but as complementary measures. Whilst security scans enable an efficient and regular check for known vulnerabilities, a penetration test provides an in-depth analysis of a system’s actual security status.

A report typically contains:

  • a management summary with an overall assessment and an overview of the current security status
  • information on the agreed scope of the test and the methodology used
  • detailed descriptions of the vulnerabilities found, including (where possible) a proof-of-concept and screenshots 
  • assessments of the identified vulnerabilities in terms of their severity

general recommendations for countermeasures to rectify or mitigate the identified vulnerabilities

The final report produced following the penetration test contains specific recommendations for action to rectify the identified vulnerabilities. The results should be analysed, prioritised and translated into concrete measures. A subsequent retest can confirm that the vulnerabilities have been successfully rectified.

Possible measures include:

  • Installing security updates
  • Configuration adjustments
  • Hardening measures
  • Improved access controls
  • Process optimisations

Professionally planned penetration tests minimise the impact on business operations. However, by agreeing in advance on the scope, critical systems and applications, as well as test times and escalation procedures, any potential disruption can be reduced or identified at an early stage and managed effectively.