The Information System was already compromised

The FIR (Force d’Intervention Rapide or Rapid Intervention Force) had been on-site for just over an hour when the first remediation action was implemented. The idea was to isolate the subnetwork where the infected machines were running before redirecting client traffic to the backup infrastructure. Several endless hours of service interruptions had already passed, and the CISO had lived through the nightmare he had promised himself to avoid when he took the job eight months earlier.

What he didn’t know was that, at the moment he sealed his arrival with the symbolic handshake from the CIO, the information system he inherited the responsibility to protect was already compromised.

It wasn’t an obvious failing on his predecessor's part. Patches had always been applied on time. Vulnerability monitoring was done, and audits were carried out diligently.

The budget allocated to security solutions, user awareness, and the recruitment of cybersecurity engineers was respectable. Yet, on a cold winter night, the EDR and the CPUs flared up as the hacker failed to slip his cryptominer under the radar.

You might hastily think the story has a happy ending since the malware execution attempts were immediately blocked, and the SOC was notified. But what about the beginning?

The affected company confirmed the statistics. The threat had been present in the system for a little over six months, which is above the average dwell time. The loading of the malicious library, its execution attempt, and the subsequent denial of service were merely the crude, uninhibited actions of an attacker confident that many quieter actions should have been detected long before.

As always, the post-mortem analysis and identification of the infection vector were conducted with much less stress than during the first hour of the intervention.

Once the logs were carefully examined and the memory images of the virtual machines scrutinized, the event history slowly became clear.

The attack surface was human

One of the tedious tasks of securing an information system involves the precise listing and maintenance of the assets on the company's network. Among the objectives is obtaining a general overview of the technologies in use and the associated risks. The saying goes that the overall security of a system is only as strong as its weakest link, and most cybersecurity professionals readily agree with this view.

In practice, it needs to be put into perspective. It’s more a conceptual view. It’s rare for a company to completely rid itself of shadow IT. There will inevitably be outdated, unregistered systems and solutions on the network, and the vulnerabilities they harbor represent an ideal entry point for a hacker.

Does that mean these entry points are systematically chosen by attackers? Are they always identified during the discovery phase that precedes compromise attempts? It’s common for critical vulnerabilities, especially in large systems, to go unnoticed by both sides.

On the defense side, due to the difficult task of obtaining a comprehensive, accurate view of the IS, which can naturally allow for oversights.

On the attack side, out of habit, poor methodology, and sometimes because they believe easier paths to their goal exist.

Here, the attacker had no reason to scan the company's internet-exposed ports, try to find configuration errors, default passwords, development flaws in applications, or outdated systems. He had no reason to do so because he had already been inside the network for many years.

He hadn’t gotten there by sending a malicious email, stealing VPN credentials, or manipulating employees. He didn’t use lock-picking tools, bypass surveillance cameras, or stand in front of the access badge reader, tapping his pockets in the hopes someone would let him in.

He had done none of that.

He had sent in a CV and been interviewed by HR, followed by his future manager.

Everything went as expected. Technical questions were answered accurately, and the salary, although considered a bit high by the company, was eventually accepted. The profile was in demand, and everyone was pleased.

However, at the time of his entry, the new hire had no ill intentions.

Things change. After several years, conflicts with his superiors, or out of boredom and the lure of easy money, the engineer, familiar with internal processes and systems, began to be tempted by illegal activity.

The daily use and knowledge of security parameters on his workstation or the network, his discussions with peers, and the access he had accumulated over the years pushed him to act.

Or perhaps it was the reward promised by the group that had approached him?

Thus, for far too long, sensitive company information was quietly harvested. It wouldn’t be published on the darknet until several months after the incident had ended, and well after the budding hacker decided to break free from his handler and operate on his own, triggering the SOC’s first alerts.

Never trust, always verify

The law of large numbers spares no one. Where there is a large number of employees, the risk is mechanically higher.

Over the years, the notion of trust in cybersecurity has evolved.

Today, it’s more common to consider securing an information system through a Zero Trust approach, often seen as a philosophy, a set of principles that moves away from a binary model in which there were once two distinct parts:

The outside world, dangerous, from which one needed protection, representing the main threat. In other words, what was outside the company perimeter, whether technically or humanly, required validation to earn trust.
The inner circle, made up of trusted individuals who had passed this validation. In more “IT” terms: all company assets, considered healthy and posing no threat. At least, in theory.

The Zero Trust approach has a paradigm of intertwining these two worlds by considering that any environment, any individual, or any system component is potentially hostile, applying continuous verification, considering the principle of least privilege as a non-negotiable foundation, and assuming that threats are already within the system.

Zero Trust applied to the network (Zero Trust Network Access or ZTNA) is the technical solution to this vision. It’s a way of translating the purely philosophical aspect of Zero Trust into rigorously applied rules that can effectively combat current threats.

Don’t miss the upcoming posts on this topic: