Backdoors give attackers a way to bypass normal authentication systems, and are used to secure remote access to a system.
Backdoor SSH access incidents indicate that an attacker might have changed the configuration of a resource to enable remote access to the resource.
In the following incident, you can see two audits.
The first audit is a file system event that shows a new certificate was created in /etc/ssl/certs.
An attacker could use this certificate for follow-on access to the container.
The first step in an investigation is to validate that the changes represent a bona fide security incident.
In this example, it’s unlikely that a new cert named bad_guy.pem.pub is a valid change, but it might not always be so clear.
After validating that this is a security incident, the next step is determining how an attacker was able to modify the system configuration.
This would, generally, be a post-compromise approach to maintain access to the compromised systems.
Check Incident Explorer for other potentially related incidents, such as hijacked processes.
Review additional runtime audits for the source to see if there are other clues.
Review access to the container and ensure that accesses weren’t subsequently used for further access to systems and data.
A full mitigation strategy for this incident begins with resolving the issues that allowed the attacker to modify the system configuration.
Ensure that compliance benchmarks are appropriately applied to the affected resources.
For example, if the critical file systems in the container are mounted read-only, it will be more difficult for an attacker to change a configuration to their advantage.