At Syndis, we’ve assisted in numerous incidents following cyberattacks, ranging from those affecting individual users to attacks that cripple entire computer systems and organizations. The frequency of such attacks has become significant, with hardly a week passing without the need to investigate some form of breach. However, media coverage of these incidents is limited. Based on our experience, likely only 10–20% of system breaches make it to the news, and often, only the most extensive attacks become public.
There are two key considerations to keep in mind before an incident occurs:
As Robert S. Mueller III, former FBI Director, stated in 2012:
" I am convinced that there are only two types of companies: those that have been hacked and those that will be. And even they are converging into one category: companies that have been hacked and will be hacked again. "
FBI — Combating Threats in the Cyber World: Outsmarting Terrorists, Hackers, and Spies
Unfortunately, many incidents are discovered only when the attacker reveals themselves, such as by altering a website, issuing ransom demands due to data theft or encryption, or when external parties report receiving emails from compromised accounts.
However, there are also numerous instances where security measures—like SOC monitoring, EDR solutions, firewalls, and others—flag unusual behavior. In such cases, it’s crucial to have clear incident management procedures or to consult with incident management experts, as inaction or incorrect actions can exacerbate the situation.
Once an incident is detected, damage mitigation actions must be undertaken. These can range from changing passwords and deactivating user sessions to disconnecting critical servers or systems from others. It’s essential to have clear authorizations in place regarding who can perform such actions, what is required to authorize them, and, importantly, how these actions are executed.
After mitigation, it’s necessary to assess the full scope of the incident. Is it limited to individual users, specific systems/servers, or is the entire environment affected?
The scope assessment reveals the extent of the incident, allowing for evaluation of its impact on operations and determination of additional necessary actions.
Consider the following questions:
What is the operational impact if a single user’s mailbox is compromised?
What if the entire cloud sector is affected?
What if the entire Active Directory environment is compromised?
These questions help in understanding the incident’s impact, which is particularly important as incidents can lead to:
Inoperable web systems
Theft of confidential or personally identifiable information
Partial or complete operational shutdown
Reputational damage
Legal violations, e.g., GDPR, NIS, or DORA
Effects on employees and customers
Subsequently, actions must be taken to restore systems to normal operation. The scope assessment can indicate whether and to what extent expert assistance is needed.
Since the attacker gained access to the system, it’s imperative to ensure they are entirely removed and that the system is returned to a normal state. Such actions depend on the attack’s extent and whether it’s possible to determine what actions the attacker performed within the environment. In various cases investigated by Syndis, one of the attacker’s initial steps was to establish persistent access through backdoors.
To address this, consider the following questions:
How did the attacker gain access to the system?
When did the attacker infiltrate the system?
What actions did the attacker perform within the system?
Were any backdoors installed in the environment?
Once these questions are answered, appropriate actions can be taken to restore the system to its normal state.
Following up after an incident is crucial. This review should cover what happened, what could have been done better, and how to prevent a similar incident from occurring again. Identifying the root cause is key. Were there additional controls that should have been in place—ones that might have minimized the damage or made the attack more visible earlier, enabling a quicker response?
The organization should also evaluate its incident management procedures: What went well? What could have been done differently?
Here are some important questions to ask before an incident occurs:
Is there a Business Continuity Plan or at least an Incident Response Plan?
When was it last updated? Where is it stored? (Plans are often outdated or stored within compromised systems, making them inaccessible during an attack.)
How comprehensive is our centralized visibility across IT systems through security solutions?
It’s common to focus on Windows servers while overlooking Linux servers, user endpoints, or network equipment.
What does logging look like across all systems?
Many systems are set up without recording key events, or they have limited log retention—sometimes only a few hours of data are accessible.
Who responds to incidents?
Is incident response handled as a side duty during office hours only? Who is responsible during nights and weekends? (Attackers often act outside business hours, so 24/7 response capability is vital.)
How are backups isolated from other systems?
Are they stored externally and write-protected? Who has access to the backups?
How are employees trained in information security?
Attacks targeting employees—especially phishing—are very common. Continuous training is critical to reduce incident risk.