Security
How We Approach Security Incidents
A compromised server is a question of evidence before it is a question of cleanup. This is the process we follow, and the reasoning behind it.
- 01
Initial assessment
We read your incident details and establish the basics: what you observed, when it started, whether the system is still running and whether production is affected. The immediate question is whether containment is more urgent than investigation.
- 02
Determine scope
We establish what the incident could plausibly have reached — which accounts, which services, which connected systems, and which credentials were stored where an attacker could read them.
- 03
Identify suspicious activity
A structured review of running processes, network connections, user accounts, authentication records and recently modified files, separating what belongs on the system from what does not.
- 04
Investigate persistence
Malicious access usually survives a reboot by design. We check service units, cron and timer entries, shell profiles, preloaded libraries, SSH keys and startup hooks for mechanisms that would restore access.
- 05
Determine containment strategy
With the scope understood, we recommend how to stop ongoing harm — network isolation, disabling accounts, rotating credentials or taking the system offline — balanced against evidence preservation and your business needs.
- 06
Recovery
We weigh cleaning in place, restoring from a backup that pre-dates the incident, and rebuilding from a known-good image. The choice depends on how deep the compromise goes and what your recovery objectives are.
- 07
Hardening
Once the system is trustworthy again, we reduce the attack surface: SSH policy, firewall rules, exposed services, account and sudo configuration, automatic security updates, and logging that will produce usable evidence next time.
- 08
Recommendations & report
You receive a written summary: what we found, what we changed, what the evidence supports, what remains uncertain, and what we recommend doing next.
When rebuilding is the right answer
Cleaning a compromised system means proving a negative: that nothing malicious remains. On a system where an attacker had root access, that proof gets progressively harder — system binaries can be replaced, kernel modules loaded, and persistence hidden in places that look entirely ordinary.
For deeply compromised systems, rebuilding from a known-good image is often safer and frequently faster than attempting to clean the existing one. A rebuild gives you a system whose state you can reason about, rather than one you are hoping is clean.
When that is our assessment, we will say so directly — including when it means a shorter engagement. Rebuilding still requires understanding how the original compromise happened, or the new system inherits the same weakness.
How we handle your data
We never ask for secrets through the form
The incident form does not ask for passwords, private keys, tokens or credentials, and you should never put them there. If hands-on access becomes necessary, we agree the method with you first and provide instructions for sharing it securely.
Incident details are not stored on this website
Submissions are validated, emailed to our team and then discarded. There is no database behind this site and no copy of your submission is retained by the web application.
We do not log your submission contents
Server logs record that a request was received and whether it succeeded. The contents of your incident description are not written to application logs.
Least access, agreed in advance
Where access is required, we ask for what the work needs and no more, and we tell you what we intend to run before we run it on a production system.
What we don't promise
We don't promise every server can be cleaned
Some compromises go deep enough that no amount of cleaning produces a system you should trust again. When that is the case, we say so.
Rebuilding is sometimes the safer choice
For deeply compromised systems, rebuilding from a known-good image is often safer and faster than attempting to clean the existing one. We will recommend it when it is the right call.
We never ask for your passwords or private keys
Not through the contact form, not by email. If secure access is needed later, we will provide instructions for sharing it safely.
We don't guarantee a specific recovery time
Recovery depends on your backups, your architecture and the extent of the compromise. We will give you a realistic estimate once we understand the situation.
The 1-hour target is the initial response
It means a real reply from someone who has read your incident details. It is not a promise of resolution, recovery or removal within that hour.
Reporting a security issue with this website
If you believe you've found a vulnerability in this website, we'd like to hear about it. Email help@myserverhacked.com with the details and we'll respond. Please don't run automated scanners or load tests against the site, and don't access data that isn't yours.
Think your server has been compromised?
Tell us what happened. We'll review your request and provide an initial response within 1 hour.