Selected work
Four jobs, described honestly.
Client names, domains and software versions are deliberately left out — publishing them would tell the next attacker exactly where to look. What is described here is the shape of each problem and how it was solved.
Case 01
Eighteen accounts moved to a server I control
The situation. A shared reseller platform that had become unreliable, with a provider slow to answer and a licence position that did not stand up to inspection. Around eighteen client accounts were sitting on it, several with heavy mailbox use.
The work. Every account was packaged with the platform's own account-packaging tool rather than by hand, so mail, cron jobs, DNS zones and database users came across intact instead of being rebuilt from memory. Each one was restored onto the new server and tested there while the old site was still live and serving traffic.
The part that matters. DNS was only repointed after the restored copy had been checked domain by domain. Mailboxes with real volume were synchronised again immediately before cutover, so nothing that arrived during the move was lost.
Outcome. All accounts live on infrastructure I administer, with off-site backups verified against a checksum after every run. The old platform was decommissioned only after the new one had been running clean.
Case 02
A hacked CMS, traced to the extension that let them in
The situation. An antivirus alert on a client site, and a defacement file sitting in the document root. The obvious response — delete the file, run a scan, declare it clean — would have been wrong, because the same site had been written to more than once over the preceding weeks.
The work. Web server logs were read back across the whole period rather than just around the alert. That produced a clear pattern: before each successful write, the attacker deleted the hardening file that blocks PHP execution in the uploads directory. Following those requests backwards led to a third-party extension exposing an unauthenticated upload-and-delete endpoint.
The part that matters. The vulnerable extension — and one dead dependency that would have broken if it were removed alone — were uninstalled at source, not merely blocked. Suspect files were quarantined with a manifest rather than deleted, so there was evidence to work from.
Outcome. Entry point closed, every hardening file restored and strengthened across all sites on the server, and a written report of what was found and when. A scheduled check now alerts if any of those hardening files goes missing again — because their disappearance turned out to be the earliest reliable signal of a compromise.
Case 03
A login attack stopped before it reached PHP
The situation. Rising server load and hundreds of login attempts an hour against several CMS sites. The firewall showed nothing at all, which was the interesting part.
The work. A failed login on that CMS returns a normal success status to the web server — the form simply renders again — so the firewall rule that counts failed logins had nothing to count. Worse, the traffic arrived from roughly 290 distinct addresses in twenty-five minutes, most of which tried exactly once. No per-address threshold, however tight, would have caught that.
The part that matters. The fix had to move down a layer. HTTP authentication was placed in front of the login page itself, so the web server rejects the request before the CMS boots. That removed the CPU cost as well as the exposure — an in-application login blocker still pays for a full CMS startup on every bot hit.
Outcome. Attempts now stop at the web server. Two subtle failure modes found during rollout — one where the challenge silently became a redirect loop, one where a permissions detail made every correct password fail — are now on a checklist and tested every time, with wrong credentials as well as right ones.
Case 04
Making the code read-only, without breaking updates
The situation. Repeat infections on sites where the attacker's first move was always to write a file into a directory the web server could write to. Ordinary permissions were not enough, because the web server legitimately runs as the site owner.
The work. Application code was made immutable at the filesystem level, with only the directories that genuinely need writing — uploads, cache, temporary files, logs — left writable. The two major CMS platforms need different recipes: locking the whole document root works on one and produces a fatal error on the other.
The part that matters. A locked site fails updates silently — no error in the browser, the update simply does not happen. So the lock is only half the work. The other half is a scripted cycle that snapshots the exact locked file set, unlocks, updates, verifies with checksums, and re-locks — with a trap that restores the lock even if the script is interrupted or the connection drops.
Outcome. Sites where the code cannot be modified by the web server, and an update process that is a single command and leaves an audit log. Tested by killing the script mid-run to confirm the lock came back.
Who I work with
Mostly businesses in and around Dehradun.
Different trades, same underlying need — an identity that looks consistent, a site that works, mail that arrives, and someone who picks up the phone.
- Dental & medicalClinics, colleges, diagnostics
- Schools & institutesAdmissions, prospectus
- AutomotiveDealerships, workshops
- LogisticsTransport, fleet
- Retail & interiorsShowrooms, home decor
- NGOs & trustsReports, disclosures, archives
- WellnessYoga schools, retreats
- Hotels & travelStays, tour operators
Your turn
Got a project or a problem in one of these shapes?
A brand that needs rebuilding, a site that is slow, hacked or stuck on an old version, or a host that will not answer the phone. All routine.