References & case studies

Two web applications were tested for a company in the energy sector. The focus was on attack options for internal and external accounts within the web applications.

Several cross-site request forgery vulnerabilities were identified during the test within the web applications. With CSRF attacks, commands can be executed in the context of the victim if the victim clicks on a manipulated link.  This allows a CSRF attack to change an account password on both internal and external registered users. If successful, this would result in the victim's account being completely compromised.

To prevent CSRF attacks, it must be impossible to prepare a valid request to the web application in advance. This is usually ensured with a random value that changes with every call and is validated on the server side with every received request.

A company in the healthcare sector wanted to subject its internal backup infrastructure to a security check. The goal of this test was to check the configuration of the services and the servers belonging to the backup infrastructure. 

During the check, port 161/tcp was identified on which an SNMP endpoint was running. Additionally, it was possible to use the community string “public” to find out information about account names, the running services as well as the operating system. The identified operating system version was Microsoft Windows CE version 6.0 (Build 0). This embedded version of the Windows operating system was released in 2006 and has been end-of-life since 2022. An increased risk for this system was identified in connection with other open ports and associated vulnerabilities. Since this was concerning a disk management system, successful attacks could provide access to the company's sensitive data.

It was recommended to shut down services that are no longer in use. During penetration tests, we often find that some endpoints that were in use years ago are no longer being used, but still have the same configuration. If these endpoints are still used, for example to send information about the system to a monitoring application, the service must be secured to prevent third parties from reading the information. We also recommended keeping all systems up-to-date in order to neutralize known vulnerabilities via security patches. In this specific case, the accessibility of the services was additionally restricted at the network level to minimize the risk.

A security recheck was carried out by us for a global corporation with focus on an application that visualizes complex data structures.

A penetration recheck (or retest) verifies that the security vulnerabilities identified during an initial penetration test have been fixed. After the company has made corrections, the testers check the same areas again and determine whether the previously exploited vulnerabilities are now secure. This recheck ensures that the remediation was effective and that new vulnerabilities were not inadvertently introduced. Rechecks are essential for maintaining security posture and compliance as they confirm that the risk level has been reduced. Without rechecks, unresolved vulnerabilities could persist, leaving systems unprotected and negating the goals and investments of the original security review.

After the initial recheck, the parts of the application that had no vulnerabilities in the previous penetration test were also examined. Several Reflected Cross-Site Scripting (XSS) vulnerabilities were identified, which would allow attackers to perform operations in the victim's context if a victim clicked on a manipulated link. In order to prevent injection vulnerabilities, such as XSS, it is recommended to verify any input to the application and to remove the special characters.

We performed a Red Team Assessment for a bank, which aimed to recreate realistic attack scenarios in order to gain undetected access to the internal network without the company or the internal Blue Team detecting the attack.

To accomplish this, the first step was to search for information about the company using  freely available sources (OSINT). As no valid passwords or vulnerable systems could be identified, the next step was to send phishing emails to selected employees. The company was well prepared, as one phishing email was recognized and reported immediately. Another phishing email was not recognized and the payload was basically executed by the employee, but the code execution was blocked. Employees on the systems were not allowed to execute new programs, therefore the attack was mitigated.

For further analysis of the internal servers, internal tests were carried out from a notebook provided by the company. This revealed several vulnerabilities that could have been used to extend rights. The company was again well prepared and the Blue Team responded very quickly to the received alerts. As the company was already well prepared , it was recommended to continuously harden the internal systems and to further strengthen the security awareness among employees.

A rich client for the management of internal insurance policies was reviewed for an international group. The focus of this security check was on breaking out  of the client's kiosk mode. This client was provided by a third-party provider and was used by the company to insure its own employees.

If this worst-case scenario is reached during the test, a new attack surface for potential vulnerabilities with regard to the configuration of the underlying operating system is created. For this reason, the operating system and the configuration and patch management are normally also checked in this category of security checks.

In this concrete case, the worst-case scenario could be fulfilled in several ways. It was possible to start Microsoft Office applications and use the developer tools to start a Visual Basic script that opens a PowerShell. Another way the worst-case scenario was fulfilled, was to use the File Explorer under Windows, which made it possible to open a context menu with SHIFT+right-click to open a PowerShell window.

The internal infrastructure of a public sector  IT service provider and its external perimeter were subjected to a security audit. Several thousand objects were in the scope of the test. Vulnerabilities in the Active Directory configuration, the password policy configuration and the authorization concept in particular usually have flaws that can be easily exploited by attackers. Therefore, it should be ensured that security best practices are met.

When it comes to passwords and account policies, service accounts are often forgotten and frequently have weak passwords which can be used by attackers to authenticate themselves to systems, sometimes with elevated authorizations.

In this case, Network Access Accounts (NAA) were identified, which were used to install the operating systems on the hosts. The problem here is that the account logs on to the host system via the network and therefore the access information ends up in the system's memory. This information can be read with the appropriate authorizations. These NAA accounts usually have elevated rights on systems in the Active Directory environment in order to carry out their activities. If the access data is read out , attackers can extend their privileges.

In addition, files with plain-text passwords could also be identified on file shares during our test. It is always recommended to keep the files on shares as small as possible and to configure the permissions of the file shares according to the least privilege principle. Furthermore, passwords should never be stored in plain text to prevent unauthorized access.

We carried out a grey box check for a large energy company that focused on the company's critical infrastructure. The goal was to identify entry points into the OT network from the Internet or the internal office network. Additionally, physical entry points were also considered.

By evaluating the firewall rules, several systems were identified that had access to the OT network. Although this did not allow direct access, for example via code execution vulnerabilities, several weaknesses were, however, still identified in the systems and the network separation. In addition, there was no further segmentation of the systems in the OT network. This means that access to one system in the OT network would be sufficient to reach all the systems in the OT landscape.
Several weaknesses were identified during the physical walk-through of the site, making it possible to breach several security zones and enter critical zones. Attackers could use this to enter the company's critical zones unnoticed from the public space.

Therefore, we recommended to further restrict the firewall rules, to make the systems only accessible via additionally secured connections and to segment the flat OT network. For the physical security of the site, we advised to place better barriers and to increase employee awareness through training.

For a large industrial company, the external perimeter and the cloud infrastructure were reviewed  in the form of a grey box check. The goal was to identify vulnerabilities from the perspective of an external attacker and to examine the cloud infrastructure for weaknesses in the configuration.

A critical vulnerability was identified during the external check. The company  operated an outdated server that was directly accessible over  the Internet and  was affected by publicly known vulnerabilities that can lead to code execution. In addition, several other software versions with known vulnerabilities were found. Systems that allow login via unencrypted connections and other configuration vulnerabilities were found in the external perimeter. Several unencrypted communication channels were also secured in the cloud environment. A lack of multi-factor authentication, unencrypted database systems, missing access rules and other weaknesses offer attackers opportunities to gain access to sensitive data.

It was recommended to revise the process for updating systems and to update the systems promptly. Especially when critical vulnerabilities become known. Sensitive data, such as access data, should never be transmitted via unencrypted connections. It was recommended to harden the cloud environment using the CIS benchmark.

We carried out a grey box check of an energy management system for a large energy company. The goal was to identify critical weaknesses in the product solution.

The energy management system provides a client application to communicate with the system. A buffer overflow vulnerability was identified in the client application, which can be triggered via an additional API. Due to the limited test period, the vulnerability could not be fully exploited. Nonetheless, if the vulnerability in the client application is successfully exploited, this can subsequently lead to a compromise of the energy management system.

It was recommended to use secure functions in the client application and to validate all user input.

We were commissioned to review the control software for the OT (Operative Technology) of a large supplier in the energy sector. The purpose of the software is to give employees a graphical user interface to control, monitor and maintain physical components of energy supply equipment on a country level. Due to the criticality of the use case, our task was to verify that the supplied software, known as a Human Machine Interface or HMI for short, was suitable for protecting the underlying systems from unauthorized access.

During our investigations, however, we managed to find numerous ways to break out of the kiosk mode of the HMI application. This gave us access to the underlying system. From this point onwards, an attacker would have had numerous opportunities to spread further into the protected area of the network and exploit weaknesses in the configuration of the investigated systems.

In addition to the usual suggestions for improving and hardening the system, our recommendations included targeted measures to prevent potential attackers from leaving kiosk mode. Should an attacker nevertheless succeed, measures based on the security-in-depth principle ensure that an attacker has little chance of spreading further into the system. Many of these measures can be implemented relatively easily through the functionality of the operating system.

A fintech company commissioned us with a test of two web applications, carrying out a review of the associated AWS cloud infrastructure and the check of mobile apps for Android and iOS. The holistic approach provided a better insight into the interaction between the components in order to gain a better overview of their secure programming and configuration.

In the course of the security check, a template injection vulnerability was identified in the admin backend, which allowed the execution of operating system commands. It was recommended to not include any provided data in templates and, if not otherwise possible, to validate them beforehand. Multi-factor authentication could also be bypassed in the mobile app by our testing team. It is important to ensure that there are no interfaces in the web application that allow access without multi-factor authentication. In AWS, data was transmitted unencrypted by the load balancer. We recommended to enforce data encryption on all transmission paths.

Close cooperation between people who design processes and people who implement the processes in IT is of great importance. During a payment security project for a large industrial company, we identified the main payment processes to be already streamlined and secured. However, secondary processes, such as HR payments in other countries, were still performed via a large number of manual steps.

Due to unencrypted connections to the used file shares, it would have been possible to intervene with the payment transactions (within the payment files) and thus manipulate the target bank accounts. This would mean that transfers could be diverted to the wrong accounts without being noticed in the later steps of the process.

When designing processes, we always recommend ensuring that employees cannot gain access to payment files (whether during storage or during transfer). This is improved, for example, by activating encrypted transmission, hardening the used systems and implementing the principle of least privilege.

We conducted a comprehensive red team assessment for a renowned bank, specifically aimed at identifying vulnerabilities related to technical phishing attacks. The goal was to test the bank’s phishing attack surface from the perspective of an employee and identify potential security gaps that could allow attackers to access confidential systems.

Besides other vulnerabilities, one stood out as the most critical: During an internal “assume breach” assessment, we discovered outdated system images on accessible network shares that could be accessed by any domain user. These images contained credentials for an active domain admin account, posing a significant threat to the overall infrastructure.

This assessment highlighted the importance of conducting thorough and ongoing security evaluations. Critical vulnerabilities, such as old accessible system images, along with other identified risks, can provide attackers with access to confidential areas of the IT infrastructure and cause significant damage. Identifying and addressing such vulnerabilities early is crucial to ensuring the long-term security of IT systems.

A database management system for buildings was examined for vulnerabilities for a large software company. A red team approach was used, therefore the blue team was not informed about a check being carried out. The starting point for the test scenario was a stolen notebook.

Several vulnerabilities were identified during the test. Access data was transmitted via an unencrypted connection to a higher port. The applications running on the system were written in JAVA and were susceptible to deserialization vulnerabilities, which can lead to code execution. After consultation with the customer, the execution of code was  refrained,  as it would have affected  a production system. Cross-site scripting vulnerabilities, outdated software and privilege escalation vulnerabilities were also identified. The actions of the testers did not cause any alarms, therefore their actions were (unfortunately) omitted from the blue team.

It was recommended to only use encrypted connections, apply patches to mitigate deserialization vulnerabilities and software updates, clean up and encode any user input, and further harden the system. In addition, it was recommended to sharpen the alerting and detection on the notebooks.

A global technology company conducted a Purple Team assessment in which the testers operated from an "Assume Compromise" position. They were given access to a Windows notebook within the corporate network and a Linux server to simulate attacks from the inside. The focus was on detecting attacks and communicating with the company's IT security team.

One particularly noteworthy finding from this assessment was the configuration of a Windows service on all clients, which allowed for privilege escalation from a regular user to an administrator, textbook style. Through this assessment, the IT security team was not only able to test and train their detection capabilities in a realistic scenario, but critical vulnerabilities were also uncovered.

Public infrastructure affects us all, therefore identifying potential vulnerabilities as early as possible and thus enable them to be remedied is essential. That is why we were enquired to perform a security review of a company’s IT and OT environment, as well as a review of the components that are hosted in the cloud.

As part of the project, applications produced by different development companies  were tested, which were used for communication between critical parts of our client’s infrastructure.

A review of the network was also carried out to assess the security of the environment. For reasons of efficiency, the first step, compromising the environment, was omitted and the test was performed using a provided client ("Assume-Breach-Assessment").

The test showed that robust processes are the be-all and end-all, especially in environments that have been in place for a long time. Therefore, in addition to technical improvement measures, a review and expansion of the patch management process and the handling of accounts were also recommended. With regard to the cloud environment, it has been shown that although default settings have become more secure in recent years, they should not be trusted blindly and some measures still need to be adapted to the environment.

For an energy company, a review of the external perimeter and internal firewalls was performed. The external perimeter was very well secured and only the use of some outdated cryptographic algorithms could be identified. 
The analysis of the firewall was performed as a configuration review which did not include active attacks, but allowed to check many configuration settings within a short amount of time.

Through the review it was possible to identify vulnerabilities which could be mitigated through updating the firewall, activating communication encryption for specific connections and restricting the firewall rules.

We regularly conduct payment security checks in cooperation with our partner company Schwabe, Ley und Greiner (SLG). The reviews are split into a processual and a technical workshop, where SLG is in charge of the processual analysis. We provide the technical part of the review and try to identify technical possibilities for the manipulation or redirection of payments. Through the combination of processual and technical expertise it possible to identify new possible attack scenarios.

Such a review was performed for a large German residential and industrial construction company. It was identified during a spot check on the password quality for the ERP and TMS systems that several weak passwords were in use. Due to the use of a weak database password it was possible to circumvent all security mechanisms of the treasury management application and therefore allow an attacker direct access to the database of the application. Such a weak spot can also easily allow for modification of payment data which can lead to manipulated payments.

We often see that data base systems, for example, are set up with weak passwords during implementation which are not changed after going productive and therefore stay active. In general, that is why we recommend to watch out for database passwords, SAP system or Windows service accounts, as they can be easily forgotten during implementation of password policies.

During the review of a web application for HR services at a global corporation, several critical security vulnerabilities were identified. It was possible to bypass authentication and gain administrative privileges. Additionally, during the automated review of the web application, a Denial-of-Service (DoS) condition was triggered, which could only be resolved with the intervention of the backend team.

This assessment highlights the importance of combining automated tools with manual review. Without this comprehensive approach, critical vulnerabilities could be overlooked and potentially exploited during an attack.

Online shopping and customer support – almost everyone knows these things from everyday life and the industry sector is no different. For example when a company runs two portals for online shopping and customer support and wants to ensure a secure experience with both services by inquiring/striving for regular security test.

The fact that regular testing – and above all a review of the measures implemented – makes sense was particularly evident in this case. A new test was carried out by HACKNER Security on the occasion of the merging of the portals and came to the conclusion that existing measures were only partially remediated, but still existed in some form due to oversights of edge cases.

Due to planned infrastructure changes, the reverse proxy used was also tested, in which additional vulnerabilities were identified (in this case, however, at an early stage) and appropriate recommendations for their remediation were elaborated.

We were commissioned by a global pharmaceutical company to conduct an external IT red teaming. Unlike typical red teaming, there were limitations in the scope: social engineering (including phishing) and physical access were excluded from the test. This meant that the testing team had to find a way into the company through the external IT infrastructure. Further attacks within the internal network were also out of scope.

The assessment began with an OSINT (Open Source Intelligence) phase, during which information from publicly accessible sources was gathered. This included IP addresses, domains, email addresses, passwords, and other company-related information. The size of the company was reflected in the amount of available information. The next phase involved identifying potential attack vectors from the internet. Due to the large external IT landscape of the client, a brief alignment was conducted before each actual attack to ensure that no critical or out-of-scope systems were targeted.

During the red teaming, administrative access to a web application was obtained using leaked credentials. This web application allowed access to the backend database. However, due to various restrictions, it was not possible to obtain shell access to the system.

How can such an attack be prevented? Leaked passwords are only useful to attackers as long as the passwords are still valid. Therefore, it is important to use tools and services that continuously monitor the dark web and other sources for leaked credentials and issue alerts when company data is affected. Additionally, special attention should be paid to legacy systems that may not be connected to the central user database.

An IT services company’s web application for creating and managing events and its planned successor were examined.

As invitations to events are naturally sent out as part of such applications, the main attack vector was defined as the attempt to  phishing event guests in order to obtain data. Additionally, it was important to pay attention to common web application vulnerabilities that would allow attacks such as injection attacks or the like.

The test showed that the existing application was already very robust, but the new one still contained a few vulnerabilities that were overlooked during development. This experience shows that problems can always arise with new developments, even if previous products were already almost flawless.

Who hasn't experienced it? Many (potential) customers, a long list of contracts and products and no desire for Excel spreadsheets. One of our clients had exactly this problem, which is why they developed an application for managing the information. To make sure that the stored data is safe and sound, HACKNER Security was contracted to perform a security assessment to evaluate the application’s security level and provide improvement measures.

As the contracts could also be viewed by the respective contractual partners, the authorization system was the primary focus of the assessment. After all, no one wants prices to suddenly be changed within established contracts that differ from those negotiated or for unauthorized persons to gain access to the data of contractors!

Although changing the data could not be achieved during the test, the assessment nevertheless brought up some interesting weaknesses, including the possibility of unauthorized read-access of other contractors' contracts. As always, appropriate solutions were developed for the given scenario and discussed accordingly with the client.

A large German hospital contacted us to carry out an external black box check. The main focus was on scanning 15 IP addresses.

First, we performed a port scan to identify the services on the servers. When we examined these services more closely, we found known vulnerabilities (including a server spoofing vulnerability on the Exchange server). There were also vulnerabilities which are almost always present. However, in the spirit of defense in depth, identifying these is just as important: we noticed invalid certificates, weak TLS cipher suites and the disclosure of information.

We recommended updating the old systems to the latest version and hardening the external services (improved cryptographic algorithms for cipher suites, use of valid certificates and restrictions on the information disclosed).

There are high security requirements for systems in the OT area because a system failure could have serious consequences. As part of a security check, we tested a control device used in the energy sector.

The device can be operated via touchscreen. By using mouse and keyboard, it was possible to break out of the restricted kiosk mode and gain full access to the device. Additionally, through using a proprietary protocol, admin access could be obtained over the network with a standard account.

To mitigate the kiosk mode breakout, it was recommended to disable the use of peripheral devices. In addition, it should be made sure that no applications (e.g. a Linux console) can be opened on the used touchpad operating system. For the attack vector via the network, it was recommended to restrict the permissions of the standard account so that it cannot access critical functionalities.

During an external security check, we were able to find weak passwords for several accounts. In a classical manner, parts of the passwords included names, dates or company/department names. This not only enables possible attackers to identify sensitive data of employees and the company, but in the worst case might also enable attackers to break into the internal network.

To prevent this kind of attack, it is important to ensure that a good password policy is in place and is applied comprehensively. Long-standing accounts often still use weak passwords, as they are easily “forgotten”. It is important to close these accounts if there are no longer needed.

In general, multi-factor authentication should be enforced, and old accounts must not be forgotten here either, otherwise attackers can simply add a second factor themselves the moment an account has been hijacked.

Using a Word document with macros disguised as a resume, it was possible to break into a system and specifically attack the developer systems. This made it possible to read locally stored login credentials and gain access to a fallback jump host on the Internet. It was ultimately possible to gain access to the agreed target, the developer network, via the jump host.

For a phishing assessment, we used a MS Teams message to request login credentials. With the data obtained, a VPN connection was possible, which also enabled internal network access. Due to incorrect configurations in the certificate services, our testers were able to perform privilege escalation to domain admin permissions.

We carried out an internal penetration test in the healthcare sector. Since confidential data is processed here, these systems must be secured against attacks in the internal network. The systems should be configured according to the least privilege principle in order to prevent medical data from being accessible to unauthorized individuals.

The task was to gain access to a large office building with reception desk. In preparation, a building plan from the architect with the exact rooms for the first two floors could be found on the Internet.

Five entrances and paths could be identified from the plan, allowing the reception desk to be bypassed. Most of these entrances were closed, but not locked, and could be opened with simple means.

The room plans of an educational institution were publicly visible, which meant that critical rooms, such as server, heating or archive rooms, could be identified for the physical security penetration test.

On site, the rooms described were usually not locked and could be opened in a short time using simple means. Access to the server room was not possible, but access to the heating control and rooms with important documents was possible.

Our recommendation was to apply similar security measures as for the server and to design the public space plans according to a need-to-know principle.

The starting point with this project was access to an office building. Despite existing security measures, it was possible to obtain public information online about the company's dress code and ID card design.

By adjusting the clothing style and creating similar ID cards, tailgating was possible without problems. After entering, the testers were able to move around the entire building undisturbed, where they found unsecured network ports and ID cards.

A large energy company ordered a purple team assessment. Objectives were initial access, detection tests on known attack strategies, execution of an implant during active EDR,  testing the detection possibilities through EDR or monitoring solutions, as well as, execution of TTPs for lateral movement or persistence.

During the assessment, the blue team was able to develop custom-made detections in the EDR console to detect attack behaviour the EDR would not expose on its own.   

A workshop for common web application exploits (focus on OWASP Top 10:2021) was hosted for the development department of a bigger software company. Main focus point was on demonstrating the exploits in practice and whenever possible allow the attendees to recognize and exploit on their own as part of practical exercises. 

At the end of the workshop a capture-the-flag contest was held to give individual groups an opportunity to apply the knowledge they have acquired. 

From time to time, we receive exceptional requests: For example, a company’s order for securing their web portal against denial-of-service attacks. To put it in blunt words: “Send requests towards our portal until a certain request limit and we want to see if we can stand our ground!” The special challenge was to purposefully exploit logical technical weaknesses for the attack.

This was quite a new project for us, as we usually do not conduct denial-of-service attacks, but the specific attack strategy made us curious. Which paid out in the end, as exploiting a programming error made it possible to not just make the site unavailable but also to go down.

Insurance companies process personal data. Therefore, a web application focused on vehicle registration was subjected to a security check. In addition to classic web attacks, there are also risks such as the manipulation of data after a contract has been concluded. This can lead to insurance fraud by customers and insurance employees.

An energy company already had a zone concept for the entire system and wanted to have this concept checked through a physical inspection. Critical areas should be particularly secured. There were already existing isolation gates at the entrance, also considering trucks.

Our inspection revealed that the isolation gates could be bypassed at the right places, allowing attackers direct access to the company premises. Access doors could also be opened with a door hinge or opening pin. We recommended further structural measures to secure the site and replacing the access doors with burglary-resistant doors.

To gain access to the internal network in a social engineering assessment, we first had to gain access to the company building. So we developed the following scenario and realized it: 

An employee of ours, dressed up in suit and tie, waited for their cue word in front of the company building. A second employee, out of sight, called the front desk with a faked supervisor number: "The supervisor has a very important meeting but the customer is late. When the customer arrives, they need to be let through as quickly as possible." 

The first employee of ours now ran stressed to the front desk, had no need to say much more and was allowed to pass without a control. The result: Free movement within the building!

For a global sportswear company, the security of payment processes was assessed on three company locations. Securing the interfaces between the different payment tools is usually an underestimated attack vector in this scenario. Not many people are aware of the use of payment files (mostly XML), which contain all the bank account information, including the receiving account.

File transfer, you say? The word "interface" is not always correct in this context because the interface is a human who copies the payment file from their local work station to a network share. This leads to the files being modifiable not only during transmission but also at the location they are being stored at. Internal attackers can utilize this by changing the receiving account in the file to their own account. Depending on the receiver you could make quite some money with this trick.

But how can I prevent this? In short term it is worth to secure payment processes with available methods, meaning encryption of transmission paths and restricting file access. In the long term, this unfortunately is a more elaborate task! Structures and interfaces need to be established that prevent employees from having access to files altogether.

For a global corporation, we tested a web application and a rich client used for software development. Additionally, an agent application played an important role, which could be connected from the web and the rich client. A complex system with many components - and possibilities for security holes!

Sometimes it pays off to test an application over a longer time frame to comb through every small corner. Because during the last days of the project, we identified a vulnerability that could be exploited to run arbitrary commands on the agent software. Furthermore, it was possible to spawn and stop customer server instances in the customer's environment.