Get the attacker out, then make getting back in expensive.

Security Engineering & Incident Response

A compromised production server is not a ticket, it is a clock. Every hour the attacker holds root is another hour of exfiltrated data, another persistence mechanism planted, another customer record at risk. I do the full incident response workflow — triage without destroying evidence, eradication, credential rotation, patching, and the hardening that makes a second compromise expensive.

Why it matters

Most breaches are not sophisticated. They are an unpatched CVE, a reused password, or an exposed admin panel. What separates a bad week from a company-ending event is whether anyone was watching, whether the response preserved evidence, and whether the hardening afterward was real or theatrical.

What you get

  • →Triage that preserves evidence — process tree, network connections, auth logs and a full disk image captured before anything is killed.
  • →Malware eradication: cryptominers, reverse shells, persistence crontabs, unauthorized SSH keys, modified rc.local.
  • →CVE mitigation — including custom patches when the vendor fix has not shipped yet (CVE-2024-45519 was closed with a hand-written Perl patch on a live Zimbra server).
  • →Full credential rotation on the assumption the attacker has everything.
  • →fail2ban + firewalld hardening, SSH key-only auth, root login disabled, auditd rules on sensitive paths.
  • →Application-layer security: AES-256-GCM encryption at rest, JWT with refresh-token rotation, RBAC, TOTP 2FA, audit logging.
  • →Penetration testing against your own stack before an attacker does it for you.
  • →A written incident report with the compromise timeline, actions taken, and residual risks — the document your lawyer and your insurer will ask for.
  • →Optional weekly SOC review on retainer for early detection of re-compromise.

Stack

  • Incident Response
  • Perl / Bash custom patching
  • fail2ban
  • firewalld
  • auditd
  • Zimbra
  • CentOS / Ubuntu
  • Nmap
  • Burp Suite
  • AES-256-GCM
  • JWT
  • TOTP 2FA
  • Sentry
  • rclone offsite backups

Delivered projects using this stack

Frequently asked questions

Our server is compromised right now. How fast can you start?+

Immediately. The first two hours are pure observation — no reboots, no kills — because a reboot destroys the volatile evidence that tells you what the attacker did and how they got in. Send SSH access and a description of what you observed, and triage starts the same hour.

What if the vendor has not released a patch for the CVE yet?+

Then we write one. On the Hilong Ecuador engagement the official Zimbra fix for CVE-2024-45519 had not shipped and the mail server needed to be back online that day. A 40-line Perl patch closed the exploitable surface, logged attempts, and was removed 4 days later when the official patch landed. It is not a permanent fix — it is a bridge that keeps the business running.

Do you offer ongoing monitoring, or only one-off incident work?+

Both. Incident response is a defined-scope engagement. Weekly SOC review — auth failures, unusual processes, outbound connections, filesystem changes on sensitive paths — is a small monthly retainer. Most clients who go through an incident take the retainer afterward.

Can you do penetration testing before anything goes wrong?+

Yes, with written authorization from the system owner. Scope is agreed in advance, testing is non-destructive by default, and the deliverable is a written report with findings ranked by exploitability and a remediation plan. No testing happens without a signed scope — that is the line between security work and a crime.

Ready to start?

Send a written brief with the business problem to solve. I come back with a concrete plan against that document, in the client's language.

Contact →

Other services