During web application penetration testing, our goal is to detect vulnerabilities in the web application as fully as possible, using both automatic and manual methods. Using automatic tools can dramatically decrease the time the auditor has to spend on a web application, but automatic analysis can never replace a thorough manual testing.  In order to verify the vulnerabilities found by the automatic tools (e.g: logical mistakes), and to eliminate the false positive, we test the application manually as well. Also, automatic tools can find only typical threats, so a manual overview is always required for a thorough analysis.

Our web application testing methodology is largely based on the industry standard OWASP (Open Web Application Security Project). The OWAPS suggestions for application development and maintenance are widely accepted and used by standard like the Payment Card Industry Data Security Standard (PCI-DSS), which is a requirement for any e-commerce organization that store, handle or transmit credit card information.

The purpose of the testing is to examine the security of our customer’s designated infrastructure elements – the operating environment of critical business applications, specific servers, workstations, network devices, etc. – or even the entire internal network of our customers or only a specific network domain, to identify vulnerabilities, whether they occur in a network, operating system, database, interface, or application component.

During hardening assessment, we reveal the security risks resulting from inaproppriate settings. Exploring them may happen through analysis of the outputs created during running the scripts we previously handed over and the Client pre-examined or in possession of the admin rights provided by the Client.

In order to achieve success during the tests, we use well-established methodologies and check-lists which also make up the testing base of multinational corporations, military- and government branches, such as the Center for Internet Security (CIS) and Defense Information Systems Agency (DISA) benchmark sets, and also the recommendations made on the given services by the manufacturer.

During mobile application penetration testing, we are looking for answers to two questions: is it safe for the user (is the data managed by the application protected) and can the background system be operated securely.

Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are also used. For Static Application Security Testing (SAST), we do not run the application, we only scan the application based on the source code or the executable file. This includes checking for proper use of the security features provided by the mobile platform.

During Dynamic Application Security Testing (DAST), the application is tested while running. In this section, the main test points are communication with the background system and changes to the file system and the security of the data stored. In the most of the cases, the background system is a web API, so our web application testing methodology can be applied, but our team is prepared to test custom, even completely closed solutions.

During thick client penetration testing, we are looking for answers to two questions: is it safe for the user (is the data managed by the application protected) and can the background system be operated securely.

Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) are also used. For Static Application Security Testing (SAST), we do not run the application, we only scan the application based on the source code or the executable file.

During Dynamic Application Security Testing (DAST), the application is tested while running. In this section, the main test points are communication with the background system and changes to the file system and the security of the data stored. If the communication with the background system is established with a web API, our web application testing methodology would be applied, but our team is prepared to test custom, even completely closed solutions.

The reviews include the discovery of wireless networks, the mapping of available APs and ad-hoc connections with the aircrack-ng software package. In doing so, we try to gain access to sensitive information and authentication data by intercepting network traffic. We examine the encryptions used, we try to get the passwords using brute-force methods. In the case of WPA2 networks, instead of / in addition to the attack based on catching a 4-way handshake between the AP client, we also attempt to attack based on the so-called PMKID hacking.

In addition to the above, client-side attacks are part of the tests. During the process, we create a network with the same name as the SSID of the Client’s network to try to get the login information of the clients.

The growing prevalence of cloud services justifies extending security testing to cloud-based infrastructure elements. The tests are not fundamentally different from general infrastructure penetration testing and configuration security review, but due to the characteristics of the cloud, these may require different methods, tools, and knowledge from the test specialist.

During our firewall security assessment, we review the general settings based on the manufacturer’s and other industry recommendations. We uncover the security risks arising from inadequately designed rules or inadequate configuration. The second, usually larger part of the reviews, is the examination of the ACLs. In doing so, we explore the risks posed by overly permissive rules, allowing unsafe services / data traffic, and other logical, design mistakes.

The source code analysis of the examined system is done by sampling. The first step of this method is to determine which are the key parts of the code from the angle of security (data validation, authentication/authorization, workflow management, sensitive data management, encryption, etc.). The further tests will be conducted on these. The purpose of all tests is to validate if the application is properly implementing the functions listed above.

Naturally, source code testing does not only verify the adequate implementation of the security controls but also examines the whole source code in terms of security, checking for logical mistakes, and checking for security solutions provided by specific languages, frameworks, components used, or the frequent “traps” that affect them.

In contrast to traditional penetration testing, the goal of our Red Teaming assessments is not to identify and potentially exploit the vulnerabilities of a component as extensively as possible, but to identify and exploit the vulnerabilities necessary to compromise predefined targets.

While general vulnerability assessments and penetration tests usually target isolated system components, red teaming tests cover all system components that can be used to reach the final target and provide a true picture of the organization’s infrastructure from a security perspective. It demonstrates whether vulnerabilities exist in the tested infrastructure or organisation that could allow a real attacker to compromise internal resources, while also aiming to realize how prepared the organisation is to defend against such attacks, and thus identify any Blue Team – or defensive – process and organizational vulnerabilities.

Vulnerability assessment and penetration testing are two different approaches with two different goals. While vulnerability assessment is a non-intrusive process, penetration testing actively exploits vulnerabilities of resources found in the testing scope. Performing a penetration test always involves a certain risk (e.g. denial of service), but it also provides a more precise summary of the vulnerabilities of the IT infrastructure and penetration test always includes a vulnerability assessment.

During vulnerability assessment, our goal is to detect known vulnerabilities in our customer’s IT system components using security software, primarily Nessus, and to filter out false-positive findings that can be identified without a penetration test.

Scroll to Top