How Pen Testing Uncovered Two Attack Techniques Hiding in Plain Sight

What makes a good penetration test? The answer lies in what it leaves behind: a clear view of what defenders could see, how they responded and which detections need to change before a real attacker tries the same route.

At one of our customers, a capable penetration tester recently triggered a priority incident before the internal IT team or our SOC knew an authorised exercise was underway. Our analysts identified the activity, worked with the customer to isolate affected assets and disable an account, then adjusted the response once the exercise was confirmed.

The review that followed gave us something valuable: a detailed record of how familiar attack techniques appeared in the customer's telemetry, where the existing detections worked and where a different approach could strengthen them. Those lessons have already informed new detection logic.

A Pen Tester Triggered a Priority Incident

The first signs looked like a genuine compromise. Suspicious activity appeared in the environment, our SOC raised a priority incident and the customer's team began containment under realistic operating conditions.

The internal IT team had not been told about the penetration test. Neither had we. That allowed the exercise to test the technology, the people monitoring it and the process for making decisions under pressure.

Once the activity was confirmed as authorised, the response changed. During a genuine incident, the immediate priority is to contain the attacker and prevent further harm. An authorised test needs enough room to continue within its agreed scope, giving the organisation a clearer view of how far a capable operator can progress and what the defenders can see along the way.

Our analysts had already identified the tester and escalated the activity. The next stage was to understand what happened after that first alert.

The First Alert Was Only Part of the Test

The tester supplied a detailed record of the actions taken during the exercise. Our analysts compared that sequence with the telemetry collected from the environment and reconstructed how each technique appeared in the logs.

That comparison matters because a detection rule looks for a defined pattern. When a tester or threat actor reaches the same objective through a different sequence, the underlying behaviour may be familiar while its presentation falls outside the conditions of an existing rule.

The telemetry can still hold the evidence. A careful post-exercise review shows where it sits, how it differs from previous activity and which signals are strong enough to support a useful alert in future.

Two techniques from this exercise gave our detection engineers exactly that opportunity.

Process Injection Appeared in a Different Form

One technique involved process injection, where code is made to run inside another process. Threat actors use it to conceal malicious activity within a legitimate Windows process, making the behaviour harder to distinguish from normal system activity.

Our SOC already had detection coverage for recognised process-injection patterns. In this exercise, the tester prepared the technique in a way that differed from the activity covered by the existing rule.

The review helped our analysts develop additional logic around suspicious attempts to obtain the process access required before injection takes place. That preparation can reveal intent before the final action occurs, much like someone testing a locked door before returning to enter the building. The permission request becomes a useful signal because it gives the SOC an earlier point to investigate.

The exercise showed how the technique appeared in a live environment, and our detection engineers could build around evidence drawn from the telemetry rather than a theoretical example.

A Trusted Windows Utility Took Another Route

The second technique involved mshta.exe, a legitimate Microsoft Windows utility that threat actors frequently abuse to execute malicious content.

Security teams treat unusual mshta.exe activity seriously because it can allow hostile scripts or HTML application content to run through a trusted Windows binary. Our SOC already monitored for recognised patterns of misuse, although the tester invoked the utility in a different way during this exercise.

The activity remained present in the logs and became clear when our analysts matched the tester's timeline against the customer's telemetry. That reconstruction showed why the existing rule had not surfaced this variation and gave the team the information needed to extend detection coverage.

Attackers do not need to invent a completely new technique every time. A different invocation, sequence or combination of legitimate tools can be enough to move around a rule written for the pattern defenders have seen before. Detection engineering closes that gap by turning each credible variation into a stronger view of the next one.

The Logging Gap Sat Inside the Application

The exercise also exposed a difference between system-level and application-level visibility.

The customer had logs from the operating system supporting a sensitive application. Those logs showed activity around the server, including the processes and services running underneath the platform. They provided far less detail about what someone was doing inside the application itself.

This distinction is common. System logs may show that a database service, browser or server process was active while leaving unanswered questions about which records were accessed, how an account moved through the application or whether a login pattern was unusual for that platform.

Application-level logging adds that context. Depending on the platform, the logs may need to be enabled, configured and forwarded into a central monitoring environment. Detection engineers then need to understand the application's normal behaviour well enough to surface meaningful deviations without filling an analyst's queue with routine activity.

The work can be substantial, especially for specialised or customised platforms. It also gives defenders a clearer account of what happened when sensitive information sits inside an application whose underlying server appears healthy.

Most Teams Need the Same Three Answers

A penetration-test report explains where the tester succeeded. A security operations review goes further by examining what the defenders could see while it happened.

Three questions usually expose the difference between broad coverage and useful visibility.

What did the SOC detect? The initial alerts show which controls and escalation processes worked under realistic conditions. The timing matters because an alert that arrives after the tester has achieved the objective carries less value than one that supports an early response.

What could the SOC reconstruct? Strong telemetry allows analysts to follow the tester's path, even when every step did not produce its own alert. That record gives detection engineers the evidence needed to extend existing rules without guessing.

Where did the logs stop? A monitored server can still host an application whose internal activity remains largely invisible. The boundary between infrastructure and application logging often becomes obvious only when someone tests it.

Organisations that can answer all three gain a practical view of their detection readiness. They can see where visibility is strong, where additional telemetry would help and where a rule needs to account for a different version of familiar behaviour.

Better Pen Tests Produce Better Detection

A productive penetration-testing program leaves more behind than a list of vulnerabilities. It gives internal IT teams and security providers a controlled opportunity to examine how their technology, people and processes behave under pressure.

The strongest exercises connect the tester's actions with the available logs, alerts and response decisions. From there, the findings can inform clearer escalation procedures, better logging coverage and detection rules grounded in activity that has already occurred in a real environment.

For customers protected by Lumara, those lessons can travel further. Where appropriate, a detection refined through one authorised exercise can strengthen monitoring across other customer environments that may encounter the same technique under much less controlled circumstances.

That feedback loop is part of the day-to-day work inside our SOC. Telemetry provides the record, analysts supply the context and detection engineers turn the finding into repeatable coverage.

Live Detection Is the Difference

Standing up an in-house Security Operations Centre with the time and expertise to reconstruct tester activity, identify new variations and maintain detection logic is out of reach for many Aussie organisations. Lumara provides that capability through continuous monitoring and our 24/7 Australian SOC.

Our analysts investigate the signals that matter, correlate activity across the environment and use what they learn to improve future detection. Penetration tests give that process a controlled workout, showing how the environment behaves before a real attacker chooses the timing and conditions.

If a capable tester used a variation that an existing rule had never seen, would the activity leave enough evidence for the security team to reconstruct it and improve? See how Lumara combines live monitoring, human investigation and detection engineering.