References & case studies

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.

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.

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!

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.

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.

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.

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. 

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.   

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.

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 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.

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.

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.

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.

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.