Employees were probably sitting at home by the Christmas tree with their children, unwrapping presents, when strange things started happening on one of our clients’ production web servers. At the beginning of an incident that took place on Christmas Eve last year was a request targeting a vulnerable, unpatched endpoint of a web application. Within seconds, the server started doing something it should never do: attempting to communicate outbound with the attacker’s infrastructure.
This story is not based on a hypothetical scenario. It is a real, anonymized incident from practice, handled around the turn of the year by the Binary Confidence team.The client operated a web server hosting multiple applications and processed sensitive personal data. After the incident was confirmed, our task was not only to determine how the attacker got inside, but also whether they could have accessed the data or sent it outside the environment.
A Known Vulnerability Was the Gateway Into the System
Our investigation showed that the attack targeted a vulnerability in the Laravel Livewire component. It was a critical Remote Code Execution vulnerability, meaning a flaw that can allow an attacker to run their own code on a server.
These vulnerabilities become especially dangerous once their technical details appear online. “When a vulnerability becomes publicly known and automated tools exist for it, the internet starts being scanned almost immediately,” says Jozef Rusnák, expert at Binary Confidence
In this case, the first successful requests were recorded on the evening of December 24. Within a matter of seconds, the server started communicating outbound. That is exactly the moment when a potential technical issue becomes a serious security incident.
“ET Phoned Home” and the Attacker Gained Access to Server Files
The vulnerability itself was the entry point. Subsequent analysis revealed the presence of malicious PHP files known as web shells, which allowed the attacker to read, modify, or delete files accessible to the web process. In an environment that processes sensitive data, this is a serious problem even if mass exfiltration is not later confirmed.
The very fact that the attacker abused outbound server communication to gain the ability to execute code in its environment represents a significant threat. “A user should be able to connect to a website. That is normal. But when a server starts calling out to unknown infrastructure after a vulnerability has been exploited, that is behavior that must immediately trigger all alarms,” explains Jozef Rusnák
How Did We Stop the Attack?
Security controls detected the suspicious communication. The firewall identified the connections as a threat and terminated them. At the same time, forensic analysis found no evidence of successful mass data theft, database dumps, or suspicious archives prepared for transfer.
Still, that does not make the incident any less serious. The attacker got inside, malicious tools were found on the server, and the system attempted to communicate with external infrastructure. The difference was that monitoring and security controls helped limit the impact.
Lesson 1: Your Cybersecurity Now Depends on Patching
The resilience of any system often fails on things that do not look dramatic at all. Usually, it is not a Hollywood scenario in which hackers use ultra-sophisticated methods. More often, your security can be broken by a quiet, outdated component of a web application. Usually, it is a library, plugin, or framework that someone deployed years ago, the application kept running reliably on it, and it slowly disappeared from the center of attention.
Hackers no longer target only large and well-known systems. Ransomware attacks increasingly target small and medium-sized businesses, which represent low-hanging fruit: easy prey with underdeveloped security. With automated systems scanning the entire internet for vulnerabilities that someone failed or forgot to fix, the difference between a secure and compromised server can be a matter of seconds.
It is not enough to update only the operating system, firewall, or the most visible applications. Modern websites rely on dozens of components, libraries, and plugins. These are precisely the parts that can become the weak point. A company must know what it operates, where it runs, whether it is exposed to the internet, and whether a fix is available. Without this inventory, patching becomes guesswork.
Lesson 2: You Need Backups. Ideally Clean Ones
One of the options during incident response was to restore the system from an older backup. The problem appeared when it turned out that the oldest available backup already contained signs of compromise. In practice, this meant there was no clean restore point to which the client could safely return.
“In incident response, having a backup is not enough. You need to know whether that backup is clean. If the attacker got into the system before it was created, you will restore the compromised state as well,” warns Jozef Rusnák. Backups must not only be created, but also tested regularly. Their timeframe, integrity, and security must be verified. Ideally, in an isolated environment, not directly in production.
Lesson 3: Logs Are an Essential Investigation Tool
Logs are the memory of a system. They show what happened, when it happened, and where the activity came from. If an organization stores logs only for a short period of time, the investigation can quickly run into a dead end.
In this investigation, the short retention period significantly complicated our team’s retrospective analysis. The company had system activity records available only for the previous two weeks at most. The attacker could have been present in the environment for longer, but without older logs, this could not be reliably confirmed or ruled out.
Centralized logging, SIEM, monitoring of web user behavior, file integrity monitoring, and longer log retention are good practices that support you when things go wrong and are prerequisites for a high-quality incident response.
Better Security Can Start With Discipline
The incident from last Christmas provides a simple example: basic cybersecurity does not necessarily stand, and usually does not stand, only on large projects and expensive technologies. It mainly requires discipline in fundamental processes, such as software patching and backups.
These processes usually do not require extreme technology purchases or a major burden on your IT team. At the end of the day, however, they can mean the difference between safety and the total compromise of your business.
If you want to protect your data, reputation, and business, you can always turn to experts. Well-built processes can work wonders, and if you need advice, with us, you always know who is knocking on your infrastructure and how to show them the way out. Binary Confidence helps companies detect, stop, and understand attacks before a technical problem becomes an expensive crisis. At the same time, we specialize in threat hunting and threat anticipation, including monitoring criminal activity.Hackers love showing up during holidays, but we watch them even then.
Táto aktivita je podporovaná European Cybersecurity Competence Centre (ECCC) ako súčasť projektu s grantovým kódom: 101145856 a Ministerstvom investícií, regionálneho rozvoja a informatizácie ako súčasť projektu Plán obnovy pod grantovým kódom: 17I04-04-V02-00001.
