Khi WordPress bị hack, access log hữu ích nhất để dựng timeline và kiểm tra correlation giữa request với file change, account activity, redirect hoặc spam. Log không tự chứng minh exploit thành công; phải đọc đúng format, timezone và phạm vi retention trước khi kết luận.
Một dòng access log cần đọc những trường nào?
| Field | Ví dụ khái quát | Cách dùng |
|---|---|---|
| Client address | Địa chỉ client/proxy | Correlation; không dùng một mình để attribution |
| Timestamp | Ngày giờ + timezone | Nối với file/auth/deploy timeline |
| Method + path | GET/POST + endpoint | Xác định khu vực cần kiểm tra |
| Status | 2xx/3xx/4xx/5xx | Kết quả HTTP ở một lớp; không chứng minh compromise |
| Referrer | Trang nguồn nếu có | Context request |
| User-Agent | Chuỗi client | Context, dễ thay đổi |
Bắt đầu từ incident window
- Xác định thời điểm đầu tiên thấy redirect, spam, Admin lạ hoặc file change.
- Chuẩn hóa timezone giữa access log, application log, database và filesystem.
- Lấy cửa sổ thời gian trước/sau event thay vì đọc toàn bộ traffic không mục tiêu.
- Lọc theo endpoint hoặc component đã liên quan tới IOC.
- Đối chiếu sequence request với thay đổi server-side.
Annotated log example
Một record điển hình thường có cấu trúc: client → timestamp → method/path → status → bytes → referrer → user-agent. Khi audit, annotate từng field vào timeline thay vì chỉ nhìn IP hoặc status. Ví dụ, một request tới endpoint liên quan xảy ra trước file change vài giây là correlation cần kiểm tra tiếp, chưa phải bằng chứng exploit thành công.
Correlation table mẫu
| Time | Log event | Server event | Interpretation | Confidence |
|---|---|---|---|---|
| T0 | Request tới endpoint liên quan | Không có change | Request tồn tại, chưa chứng minh impact | Low |
| T1 | Request/login sequence | Account hoặc file change sau đó | Correlation cần kiểm chứng | Medium |
| T2 | Event lặp trước mỗi recurrence | Payload tái tạo | Hypothesis mạnh hơn | Medium/High tùy evidence |
Cách lọc log an toàn
Dùng chức năng search/filter chỉ đọc của log viewer, SIEM hoặc text editor để thu hẹp theo thời gian, method, path, status hoặc component đã biết. Mục tiêu là giảm nhiễu, không phải dùng một pattern chung để tự động gắn nhãn request là độc hại.
Proxy/CDN: client IP có thể không phải source IP thực
Nếu site đi qua CDN, load balancer hoặc reverse proxy, origin log có thể ghi địa chỉ của proxy. Forwarding headers chỉ đáng tin theo cấu hình proxy tin cậy. Trước khi phân tích IP, xác định log được ghi ở layer nào và server đang trust proxy nào; không lấy một header do client tự gửi làm attribution.
Status 200/302/500 không chứng minh exploit
Status code chỉ cho biết HTTP handling. Muốn nói request gây compromise cần evidence tiếp theo như file/data/account change hoặc behavior tương ứng. Ngược lại, status lỗi cũng không bảo đảm không có side effect.
Đối chiếu với file và account
Nếu file mới/sửa nằm trong incident window, nối mtime/hash với request gần đó và deploy history. Nếu có Admin lạ, đối chiếu auth/application log với access log nhưng tránh suy diễn từ một login. Dùng workflow file change và workflow Admin lạ.
Timeline output nên bàn giao
| Timestamp | Source | Event | Related IOC | Notes |
|---|---|---|---|---|
| … | Access log | Request/path/status | File/account/redirect | Timezone + correlation |
| … | Filesystem | File created/modified | Payload | Hash/path |
| … | Auth/app log | Login/change | Account | Owner/state |
Nếu malware tái xuất hiện, đưa timeline này vào root-cause hypothesis workflow.
Giới hạn của access log
- Retention có thể không phủ thời điểm compromise.
- CDN/proxy có thể thay đổi source fields.
- Một số action không tạo log đủ chi tiết ở layer đang xem.
- “Không thấy request” không chứng minh request chưa xảy ra.
Khi nào nên escalation?
Nếu log cho thấy incident có thể liên quan nhiều hệ thống/account, activity vẫn tiếp diễn hoặc cần correlation vượt phạm vi một WordPress site, cân nhắc Incident Response.
Nguồn kỹ thuật tham khảo
Kết luận
Đọc access log hiệu quả bắt đầu từ timeline và IOC cụ thể. Hãy chuẩn hóa timezone, hiểu proxy/CDN, lọc theo endpoint liên quan rồi correlation với file/account/data change; không attribution hoặc kết luận exploit chỉ từ IP, user-agent hay status code.