Inside the Threat: A Behind-the-Scenes Look at Stopping an Active Intrusion

Typically, by the time we’re brought in to investigate a ransomware incident, the damage is already done: data has been encrypted, leaving the company inoperable. In these situations, our investigation focuses on tracing how the attacker entered the systems and, more importantly, pinpointing when, so backups can potentially be used to safely restore operations. But this story is about something different.

Occasionally, we’re called in before disaster strikes—an investigation sparked by a suspicion, a gut feeling, but without clear evidence that the detected activity is malicious. If it turns out to be an active intrusion, we have the chance to slow it down and, if all goes well, stop the attack in its tracks by ejecting the threat actor before they can complete their mission. And that’s what this story is about.

A quick preface: This story is based on a real case from 2024, offering insight into how early detection can help mitigate financially motivated attacks. While certain details are modified or omitted to protect our client’s identity, the technical information and timelines remain accurate.

Initial Finding

The first suspicious behavior identified by our customer was an alert: The content of a password safe had been exported. As this database contained various important passwords to different administrative systems, for both the company itself and customers, the alarm bells rang immediately. The initial analysis revealed that the administrator who supposedly exported the credentials assures he did not perform such an action. Another member of the IT team then found an installation of the remote access tool AnyDesk on their remote access session. AnyDesk is not used in their infrastructure and is not supposed to be running on their systems. At this time, the findings were rated highly suspicious, and they assume their Citrix infrastructure might have been infiltrated. As a precaution they started to shutdown VPN-connections to their clients, to ensure their security if the suspicions that an attacker is currently creeping through their networks turns out to be true.

SEC Defence Steps In

A few days later, SEC Consult is brought in to support the investigation. The client shares all findings gathered so far, and we share their concern that their infrastructure could be compromised. However, the full scope is still unknown. Has the intrusion affected only these systems, or has it spread deeper? Could it even be the work of an external attacker?

We’re tasked with analyzing two systems flagged as suspicious to determine what’s happened and whether there’s an active threat. Along with the triage data for these systems, we receive log files from one of the domain controllers. It’s the middle of the afternoon, and we immediately dive into the investigation, with a dedicated team beginning to analyze the log files provided.

Uncovering the Scope of the Attack

The following day, we verify previously known findings and examine the AnyDesk logs. They show previous connections by the attacker and the outbound transfer of a file, the name of which is unfortunately not logged. No lateral movement was identified at the time of the AnyDesk connection, and no other signs of an intrusion were identified on the Citrix machines. The log files of the domain controller revealed the usage of PsExec, which allows the remote execution of commands on other systems.

The usage of PsExec is not malicious as it is a tool used by system administrators regularly. But because of its legitimacy, it is also one of the attacker favorite tools to fly under the radar of most security tools. As the log files alone were not enough to validate, whether the domain controller was affected by the attack as well, we request a full KAPE dump of the system in question. We opt to use KAPE to gather an image rather than our forensic endpoint agent, as at this stage, the customer is already familiar with its usage and deploying our forensic endpoint agent might have cost us another night. Time that we did not want to lose at this stage. Using KAPE more forensic artifacts than just eventlogs are gathered and a more thorough investigation of the domain controller can be conducted. As the domain controller is the central system in the network, this is our main priority at this stage. When financially motivated threat actors have taken over the domain controller, the rollout of ransomware is only a blink of an eye away.

The client quickly executed the collection script, and we received the forensic artifacts that same day by 5 p.m. While most of the office prepared to leave, we began a crucial phase of the analysis. We decided to take a preliminary look at the domain controller to check for any signs of compromise. One of the artifacts we take a closer look at is NTFS-Journal ($J). This is the NTFS-journal keeping track of file modifications on a file system. And there it was - Mimikatz, Rubeus. Distinct proof that the attacker had introduced well-known tools for credential access on the system and has deleted them again shortly afterwards. At this point, it was clear: the compromise extended beyond a few servers, affecting the entire domain. Given that financially motivated threat actors are often behind these attacks, it was likely only a matter of time before they attempted a full ransomware deployment. We notified the client immediately, and extensive security measures were swiftly implemented.

Scaling Up the Defense

With the intrusion affecting more than just a few systems, we decide to deploy our forensic endpoint agent across the entire domain. This way, we not only gain insights to a handful of systems at one point in time, but rather have complete oversight of the domain. Moreover, the customer rolls out an additional Endpoint Detection and Response tool (EDR) to identify and block attacker action automatically. Furthermore, we increase our logging capabilities by installing Sysmon. To disrupt any attacker communication with the systems and to gain time for the analysis, the whole domain is isolated from external sources. We call it a night at this point, to catch some sleep and to continue the analysis in the morning.

The first task of the next morning is to check the EDR for findings and indeed it has detected several malicious actions, but blocked them effectively. This cements the initial worry of an active intrusion. The attacker is not yet finished with our customer. More incident response analysts of our team get onboarded to the case and thorough investigations are started. We investigate everything that happened around the EDR alerts and previous findings. Which systems were affected? What user was used? In which stage of the killchain are those findings? . We track which systems and users are affected and analyze the progression of the attacker’s activity. To echo Rednex: Where did they come from? Where did they go?

Over the next few days, we analyze all these factors, testing and refining hypotheses based on new evidence. New indicators of compromise emerge, guiding us to uncover affected systems and users across the domain. No stone is left unturned and we begin to get a full picture of the compromise. We identify the systems on which the attacker performed reconnaisance of the infrastructure early on. The time of the initial compromise gets pushed back by a couple of days. The first clearly malicious action took place 5 days before the password safe was stolen. The threat actor installed ngrok, a legitimate reverse proxy tool, to open a secure tunnel from a system inside the network to the outside. Later analysis showed that these connection attempts were not successful due to effective preparation.

An early suspicion is that the attacker exploited the Citrix vulnerability “Citrix Bleed” for initial access, as Citrix was running a vulnerable version. As Citrix was running in an affected vulnerable version and later analysis showed early lateral movements via RDP from a compromised Citrix session. The threat actor used several technologies to establish command and control: AnyDesk, ngrok, SystemBC and Cobalt Strike where all found in the analysis. For persistence, the attacker created a scheduled task passing as something innocent - an update task for a windows application. But instead of an innocent update, this scheduled task was used to enable the attacker to connect via MeshCentral. Another command and control technique.

Uncovering the Hidden Vulnerability

Throughout the investigation, one nagging question remains: if the network is isolated, how can the attacker still be active at night? This question leads to eight days of back-and-forth between analysts and the client. Analysts claim that the attacker is still active. The customer assures the firewall is blocking all communication. The firewall logs are sent as proof and indeed don't show any of the connections the analysts claim to observe. During this time of back-and-forth it is evident to the analysts that something is still amiss. When everything is supposed to be behind the firewall and the firewall shuts down all connection attempts to and from the outside world, how do we still see new attacker actions?

At this point several attacker introduced persistence mechanisms and older communication attempts via scheduled tasks are identified and removed. On day 5 of the analysis, the attacker even starts to change some of his behavior in an attempt to regain control. They unsuccessfully use EDRSandBlast in an attempt to disrupt the EDR and successfully install a new service, switching the known naming scheme from posing as legitimate tasks and services to random strings. Additionally, the attacker try to fool us by creating a new user passing as a legitimate user account. Which again, is detected fast and remediated. At this point, we seem to be in a sort of stalemate. The attacker still somehow has some access to systems, but also cannot really achieve their goal as they are detected and blocked right away.

On day eight, the client’s network administrators uncover a critical oversight: a fast-path policy (or prefilter rule) in the firewall configuration. A fast path action allows the matching traffic to bypass any inspection of the firewall. The firewall itself is not using any rules on the matching traffic and therefore also does not log anything, because as far as the firewall is concerned, it does not exist. This old and long-forgotten setting concerning one sole proxy was enough for the attacker to remain a small foothold in the network. The customer gets rid of the prefilter rule and we finally achieve full network isolation.

From this point on, the remediation is in full-mode. As the full attack path is known at this stage, we can focus on remediation and complete the clean-up that has already been started days prior. The restoration of the systems starts the very next day. We accompany this phase not only from a consulting perspective, but use our forensic endpoint agent to conduct through threat hunting activities and the EDR for monitoring of the recovered systems. A few days later the company is fully up and while the effects of the attack will spike change in the organization, they are back on their feet and can resume their operations again.

Disrupting the Attacker’s Playbook

Keen readers may have noticed the wide array of communication channels used by the attacker: AnyDesk, Cobalt Strike, Mesh Central, Ngrok, and SystemBC. This is indeed quite unusual. While we often experience change in C2-communication tools, especially when we deal with initial access brokers, we hardly see this much of a variety. The explanation for the changes is quite simple though.

Due to preparation steps for effective handling of a compromise in their environment, the firewall of the customer had a threat intelligence module active which blocked the early command and control attempts of the attacker. The attacker tried to establish a connection on the second day of the compromise using Cobalt Strike. As these connections were blocked automatically by the firewall, they tried using SystemBC and a different IP address half an hour later. Again, the attempts were fruitless and blocked by the firewall. In the beginning, the only way to perform their malicious actions was via Citrix and AnyDesk. It took the attacker multiple days, to identify the proxy that did not route the traffic trough the firewall. This slowed down the progress of the attack significantly. In the later stages of the attack, after we have been tasked to assist, the introduced EDR decelerated the attacker even more. We firmly believe, that the firewall and the EDR played a vital part in the successful defense of a compromise that was at the verge of being successful for the attacker.

What We Learned from This Incident

What can we take away from this story? Effective monitoring of critical assets—and promptly investigating alerts—forms the backbone of a robust security strategy. If the attempted password database dump had gone unnoticed, the company could have lost valuable time to defend against the intrusion, potentially resulting in failure.

Though users are often cited as a primary security risk, in this case, a vigilant user detected a suspicious tool in their Citrix session, demonstrating that attentive employees can be a tremendous asset to a company’s security posture. Another crucial defense was the firewall’s threat intelligence module, which slowed the attacker’s progress and bought precious time. However, a regular review of firewall settings—not just rule configurations but also actions like fast path—would have further limited the attacker’s access.

This case ultimately exemplifies a successful, active defense against an ongoing threat. While SEC Defence is prepared for such scenarios, it takes time to coordinate, assess, and address the full scope of an incident. Without the company’s initial, effective defenses to delay the attacker, disaster could have unfolded before we could respond. This case reinforces the value of a layered approach: delaying an attacker to allow time for response can be an effective strategy, whether in traditional security or Incident Response.

This post is the first in a two-part series on this incident. In the next installment, we’ll interview the project lead to dive deeper into the investigation and answer outstanding questions. Stay tuned!

This blogpost has been conducted by Barbara Obermair and published on behalf of SEC Defence.