Một website có thể được cleanup đúng kỹ thuật nhưng vẫn bị tái xâm nhập nếu credential đã lộ trước đó còn hiệu lực. Khi attacker vẫn giữ password, API key, SSH key, database credential hoặc session/token hợp lệ, việc xóa malware chỉ xử lý hậu quả chứ chưa đóng đường quay lại.
OWASP xem weak, reused hoặc stolen credentials là nguồn phổ biến của account compromise và khuyến nghị MFA để giảm phần lớn password-based attacks. Microsoft incident response hướng dẫn với compromised account phải reset credential, revoke active sessions/tokens và review MFA methods; chỉ đổi password có thể chưa đủ nếu session còn sống. Nguồn: OWASP — Credential Stuffing Prevention, OWASP — MFA Cheat Sheet và Microsoft Entra — Revoke User Access.
Bối cảnh: cleanup xong nhưng credential cũ vẫn mở cửa
Giả sử website bị compromise, đội vận hành xóa malicious files, cập nhật plugin và đổi mật khẩu WordPress admin. Vài ngày sau attacker quay lại, lần này qua hosting panel hoặc SSH bằng credential đã lộ nhưng chưa được rotate. Website bị tái nhiễm dù cleanup lần đầu nhìn bề ngoài đã thành công.
Những tín hiệu cho thấy re-entry liên quan credential
- Successful login xuất hiện sau cleanup từ account cũ hoặc source bất thường.
- Không có exploit request mới trước thời điểm compromise lần hai.
- Credential chưa được rotate ở hosting, SSH, database hoặc API service.
- Session/token cũ vẫn hoạt động sau password change.
- Cùng password/key được reuse ở nhiều service.
- Attacker truy cập thẳng control plane thay vì application endpoint.
Investigation: chứng minh re-compromise qua credential còn hiệu lực
Bước 1: dựng timeline từ cleanup tới lần truy cập mới
Cần đối chiếu thời điểm cleanup hoàn tất, credential nào đã đổi, session nào đã revoke và thời điểm access bất thường xuất hiện trở lại. Nếu successful authentication xảy ra trước khi có malicious file mới, giả thuyết credential re-entry mạnh hơn giả thuyết exploit lại application.
Timeline nên giữ riêng authentication evidence, file/process changes và application requests để tránh suy diễn chỉ từ một log source.
Bước 2: inventory toàn bộ credential chain
Không nên chỉ đổi WordPress password. Cần inventory những credential mà attacker có thể đã đọc hoặc sử dụng trong incident trước: WordPress admin, hosting/control panel, SSH/SFTP, database, deployment token, API key, email/recovery account, CDN/DNS, backup storage và security salts/keys.
Tham chiếu Credential Rotation sau website compromise và Server Secrets Management để map owner, privilege và dependency.
Bước 3: phân biệt password, token và session
Password reset không tự động đảm bảo mọi session, refresh token hoặc API token đều bị vô hiệu. Microsoft lưu ý khi account bị compromise cần revoke active sessions/refresh tokens, đồng thời review MFA methods và application consent nếu môi trường hỗ trợ.
Với non-human credential như API key hoặc SSH key, remediation phải diễn ra tại issuer hoặc authorized-keys/config layer; đổi password người dùng không ảnh hưởng các credential đó.
Khi nào có thể xác nhận credential leak là đường tái xâm nhập?
Không nên kết luận chỉ vì credential từng bị lộ. Confidence mạnh khi authentication và post-login activity khớp với timeline re-compromise.
- Credential vẫn còn hợp lệ sau cleanup.
- Successful authentication được ghi nhận bằng credential/account đó.
- Không có exploit chain khác xuất hiện trước re-entry.
- Privileged action hoặc file change xảy ra ngay sau authentication.
- Sau revoke/rotate toàn chain, cùng access path không còn hoạt động.
Containment: revoke trước khi attacker kịp quay lại lần nữa
Thu hồi quyền truy cập đang hoạt động
Microsoft khuyến nghị block/disable compromised identity khi cần và revoke active sessions để cắt access đang tồn tại. Với website stack, tương đương là terminate WordPress/admin sessions, revoke token/key, remove SSH key và rotate credential có risk đã bị sao chép.
- Revoke session/token trước hoặc đồng thời với password reset.
- Rotate SSH/API/database/hosting credential theo blast radius.
- Review và xóa MFA/recovery factor không nhận diện.
- Disable account hoặc key không còn owner rõ ràng.
- Giữ evidence của authentication events trước khi cleanup log.
Remediation: phá credential reuse và secret sprawl
Rotate theo dependency, không rotate ngẫu nhiên
Credential rotation cần thứ tự để tránh outage: xác định consumer, tạo credential mới, cập nhật application/automation, validate hoạt động rồi revoke credential cũ. Với credential bị compromise rõ ràng và có nguy cơ abuse tức thì, containment có thể ưu tiên revoke trước business continuity tùy mức độ rủi ro.
MFA giúp giảm credential stuffing và password spraying nhưng không thay thế việc revoke secret đã lộ. OWASP cũng khuyến nghị tránh password reuse và áp dụng defense-in-depth quanh authentication.
Tách credential theo service và privilege
- Không reuse password/key giữa WordPress, hosting, SSH và database.
- Tách service account khỏi human admin account.
- Dùng least privilege cho API key/database user.
- Không hard-code secret trong source/artifact.
- Đặt owner, expiry/rotation policy và audit trail cho credential quan trọng.
Đọc thêm case API key và config artifact bị lộ để phân biệt exposure incident với re-compromise thực tế.
Validation sau credential rotation
| Kiểm tra | Kết quả mong đợi |
|---|---|
| Old password/key | Không còn sử dụng được |
| Active sessions/tokens | Đã terminate/revoke |
| MFA/recovery methods | Chỉ còn factor hợp lệ |
| Application/automation | Hoạt động bằng credential mới |
| SSH/API/database access | Chỉ còn principal được phép |
| Login/audit monitoring | Không còn re-entry từ credential cũ |
| Privilege | Được giảm về mức cần thiết |
Bài học vận hành
- Cleanup malware không đóng được đường vào nếu credential cũ vẫn sống.
- Password reset và session revocation là hai control khác nhau.
- Credential chain của website rộng hơn WordPress admin account.
- Reuse credential làm tăng blast radius và khả năng tái xâm nhập.
- MFA giảm password-based attacks nhưng không vô hiệu secret đã lộ.
- Closure chỉ nên xảy ra sau khi old credential thực sự fail và không còn re-entry signal.