To Reinstall or Not After a Webshell Infection: Criteria and Essential Post-Reinstallation Steps

After cleanup, the real issue is not “whether it was deleted cleanly,” but “whether you can prove it was cleaned completely”. If you cannot prove it, reinstalling is the more responsible choice.

This decision does not depend on how long the cleanup took, but on whether the scope of the intrusion can be determined.

Core Criteria

If you can fully list the affected scope and verify each item → Reinstallation may not be necessary;
If you cannot prove the completeness of the cleanup → Reinstallation is recommended.

Situations Favoring Reinstallation

# Check if system files have been tampered with (RPM-based systems)
rpm -Va | head -30
# A large number of modified system files in the output → Lean towards reinstallation

# Check for abnormal kernel modules
lsmod | grep -vE '^(Module|nf_|ipt_|xfrm|bridge|br_)' | head

# Find SUID files (often used for privilege escalation)
find / -perm -4000 -type f 2>/dev/null | head -20

Situations Where Reinstallation May Be Skipped

• Entry point is clear: e.g., confirmed vulnerability in a specific application plugin
• Impact scope is limited: confined to the web directory, did not affect system layers
• All modified files can be listed and compared against original versions
• Complete backups are available for comparison (and the backup timestamp predates the intrusion)

# WordPress can use checksums to verify core file integrity
wp core verify-checksums

# Plugins/themes can be reinstalled from official sources to overwrite existing ones
wp plugin install <plugin_name> --force

Reinstallation Does Not Guarantee Safety

This is the most common misconception. Restoring backups immediately after reinstallation may restore the backdoor along with the data.

Four Essential Steps During Reinstallation

1. Reinstall programs from official sources; do not reuse old program files
2. Restore only the “content” part of the data (scan database records and uploaded media files before using them)
3. Change all credentials (SSH keys, database passwords, admin panel passwords, API Keys)
4. Patch the original intrusion vector (otherwise, it will happen again)

# ① Scan uploaded media files before using them
grep -rlE '<?php|<?=' /var/www/html/wp-content/uploads/ --include='*.jpg' --include='*.png'

# ② Disable execution in upload directories (configure this after reinstallation)
# Nginx: location ~ .php$ { deny all; } within the uploads directory

# ③ Change keys and passwords
ssh-keygen -t ed25519
mysql -e "ALTER USER 'appuser'@'localhost' IDENTIFIED BY 'NewPassword';"
wp user update 1 --user_pass='StrongNewPassword'

Decision Flow

Decide whether to reinstall
├─ Can you identify the intrusion entry point?
│  └─ No → Reinstall
├─ Was root privilege possibly compromised?
│  └─ Yes → Reinstall
├─ Can you list all modified files?
│  └─ No → Reinstall
├─ Was the system re-checked after cleanup (e.g., next day)?
│  └─ Issues reappeared → Reinstall
└─ All above confirmed
   └─ Cleanup is possible, but must:
      Overwrite programs with official sources, change all passwords,
      check cron jobs and accounts, and re-verify after a day.

After Reinstallation
├─ Reinstall programs; do not reuse old ones
├─ Restore only content data (scan media files first)
├─ Change all credentials
└─ Patch the original intrusion vector

Scenario Analysis: To Clean or Reinstall? A Two-Day Debate

Phenomenon: A server was found to be compromised and cleaned. The team disagreed on whether to reinstall the OS: one side argued the cleanup was sufficient, while the other insisted on reinstallation. The debate lasted two days, leaving the business in uncertainty.

1. Stop arguing and clarify three questions → Which layer was breached (application or system)? What is the time range? How long would reconstruction take?
2. Check for evidence of system-level compromise → Inspect dynamic library preloading, check if system commands were replaced, look for unexpected new accounts. In this case, none were found.
3. Determine the intrusion timeline → Logs were complete, usable backups existed, and the time range could be defined.
4. Evaluate reconstruction cost → Environment had full configuration documentation, allowing rapid reconstruction.
5. Draw conclusion based on criteria → Since the breach was limited to application-layer writes, the time range was clear, and there were no signs of root compromise, cleaning and monitoring was chosen.
6. Even without reinstallation, two things are mandatory → Preserve the current scene for archiving and perform periodic re-inspections.

# Key checks to determine "which layer was breached"
# ① Check for abnormally preloaded dynamic libraries (this file should not normally exist)
cat /etc/ld.so.preload 2>/dev/null && echo '!! Content exists, verify source'

# ② Check if system commands were replaced or if new login accounts exist
awk -F: '$3>=1000 && $7 !~ /nologin|false/ {print $1,$3,$7}' /etc/passwd
last -10

# ③ Check cron jobs and startup items
crontab -l -u root; ls -la /etc/cron.d/
systemctl list-unit-files --type=service | grep enabled

# ④ Regardless of the final decision, preserve the scene first
ps auxf > /tmp/ps-$(date +%F-%H%M).txt
ss -tanp > /tmp/ss-$(date +%F-%H%M).txt

Root Cause: The decision lacked basis, and the argument stayed at the level of personal experience. Answering these three questions—”Which layer was breached? Can the scope be determined? How long does reconstruction take?”—makes the conclusion obvious.

Two Key Takeaways:

• “Inability to determine the intrusion time range” is itself a reason to reinstall. The prerequisite for cleanup is knowing what to clean; without knowing the scope, you can only guarantee that discovered parts are removed.
• Regardless of the final decision, preserve the scene before taking action. Remediation actions destroy evidence; archiving is the only reliable basis for post-incident review and analysis.

Decision Tree: To Reinstall or Not?

Intrusion Detected
├─ Can you determine the intrusion timestamp?
│  ├─ Yes (complete logs and backups) → Evaluate "cleanup only"
│  └─ No → Lean towards reinstallation
├─ Is there evidence of root privilege compromise?
│  ├─ Yes (privilege escalation, rootkit signs) → Reinstall
│  └─ No (only Web-layer writes) → Clean first
├─ Were system binaries modified or abnormal dynamic libraries loaded?
│  ├─ Yes (ld.so.preload has content, commands replaced) → Reinstall
│  └─ No → Continue evaluation
├─ Can services on the machine be rebuilt quickly?
│  ├─ Yes (scripts/images/docs available) → Low reinstallation cost, prioritize reinstall
│  └─ No (environment relies on manual memory) → Build reconstruction capability first
└─ Must-do before reinstallation
   ├─ Backup current scene (including malicious samples) for post-analysis
   ├─ List services and configuration sources
   └─ Confirm data can be restored independently

The true purpose of this tree is not to give a “reinstall / don’t reinstall” answer, but to force answers to three essential questions: Which layer was breached? Can the scope be determined? How long does reconstruction take? Once these are clear, the answer emerges naturally.

“Inability to determine the intrusion timestamp” is itself a reason to reinstall. The prerequisite for cleanup is knowing what to clean; without knowing what the attacker did, you can only guarantee that “discovered parts are removed.” There is a significant gap between this guarantee and being “clean.”

8 Common Pitfalls

1. Judging by cleanup duration: The criterion is proof of completeness.
2. Repeated cleanup without strategy change: Leads to infinite loops.
3. Full backup restoration after reinstallation: Brings back backdoors.
4. Retaining old passwords: Entry points remain open.
5. Not fixing original vulnerabilities: Rapid re-intrusion.
6. Not changing SSH keys: Attackers retain access.
7. Using unscanned media files: Image trojans are reintroduced.
8. No post-reinstallation verification: Cannot confirm cleanliness.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations and maintenance services on Alibaba Cloud, Tencent Cloud, and Huawei Cloud Cloud Markets (service providers include our store and peers; provided for reference only, not fictional tickets from this site):

1****8 Rating: 5.0 Oct 29, 2019 22:35 Good 1

1****1 Rating: 5.0 Jun 18, 2020 11:50 1****1 Rating: 5.0 Apr 26, 2020 18:46 1****1 Rating: 5.0 Apr 26, 2020 18:45 1****1 Rating: 5.0 Apr 26, 2020 18:45 1****1 Rating: 5.0 Apr 26, 2020 18:45 1****1 Rating: 5.0 Apr 26, 2020 18:44 He****She Rating: 5.0 Sep 26, 2019 09:47