Triskele Labs Blog

External penetration testing reveals exploitable gaps in public-facing infrastructure

Written by Mike Higgo | Feb 12, 2026 11:49:55 PM

Prepared by: Mike Higgo, Head of Offensive Security | Last update: 13 February 2026

How we uncovered a high-risk vulnerability chain that could have led to internal system compromise at a national organisation.

This case study demonstrates how seemingly minor vulnerabilities enable deep access into a client’s internal network.

The challenge 

A national organisation with offices across Sydney, Melbourne, Brisbane, and Perth sought assurance that its internet-facing systems were protected from cyber threats. With increasing reliance on remote access and inter-office connectivity, they needed to understand whether a malicious outsider could potentially access internal systems, data, or services posing a threat to their operations and reputation.

Triskele Labs was engaged to perform a thorough penetration test to evaluate this risk.

The discovery 

Our team began by assessing the client’s public-facing infrastructure. Most systems had common, low-severity issues, but one server stood out. It had a known software vulnerability that many organisations overlook: outdated components that attackers could exploit. This server allowed file uploads from users but lacked the necessary security checks to ensure those files were safe. 

This meant an attacker could upload malicious files disguised as harmless ones, like a fake image that actually contained harmful code. Worse, the server would automatically process these files without question. 

The exploitation 

By carefully combining two known software weaknesses, our team was able to simulate a real-world attack scenario:

  1. File Upload Exploit – We uploaded a disguised file to the vulnerable server.
  2. Deserialisation Exploit – This file was then automatically interpreted and processed by the system, giving us deeper access.

As a result, we were able to take control of the server, simulating the kind of access a real attacker might gain. This included the ability to run commands on the system remotely, as if we were sitting right in front of it.

The implication 

This access wasn’t just limited to one server. Because the vulnerable machine was part of the client’s internal network, it could have served as a launch point for broader attacks, like exploring other systems, stealing sensitive data, or interrupting operations.

While our engagement didn’t include further testing within the internal network (per the agreed scope), we were able to show that serious compromise was possible.