Phát hiện file WordPress thay đổi bất thường bằng File Integrity

File Integrity Monitoring (FIM) giúp phát hiện drift, nhưng file thay đổi không tự động đồng nghĩa với malware. Một finding chỉ có giá trị khi được so với baseline đáng tin cậy và đặt cạnh deployment, account, request, process và business context. Mục tiêu là trả lời: file nào thay đổi, thay đổi có owner không, source nào tạo nó, behavior có phù hợp expected state không và cần update baseline hay mở incident? Case file PHP thay đổi bất thường trên WordPress minh họa cách dùng checksum, diff và change attribution trước khi kết luận malware. Nếu thay đổi nằm trong wp-config.php, .htaccess hoặc index.php, đối chiếu thêm case PHP Backdoor trong file cấu hình WordPress để kiểm loader/include chain thay vì chỉ nhìn hash mismatch.

Vì vậy workflow đúng là baseline → detect → diff → provenance → correlation → classification → remediation/acceptance → verify → promote baseline, không phải “hash khác là xóa file”.

Baseline và phạm vi giám sát File Integrity

File Integrity đo những gì?

Tín hiệu	Trả lời được	Giới hạn
Hash/checksum	Nội dung có khác baseline không?	Không giải thích khác ở đâu hoặc vì sao
Content diff	Dòng/đoạn nào thêm, xóa, sửa?	Cần baseline/source text phù hợp
Timestamp	Thay đổi có thể xảy ra khi nào?	Có thể đổi do deploy/restore/copy
Permission/owner	Filesystem state có drift không?	Không chứng minh actor thật
File creation/deletion	Artefact nào mới xuất hiện/biến mất?	Generated/cache/update cũng tạo file hợp lệ

Khu vực nên ưu tiên theo dõi

WordPress core.
Plugin/theme đang sử dụng và custom code.
MU-plugin.
wp-config.php và config liên quan.
.htaccess hoặc web-server config nếu thuộc scope.
Executable/script xuất hiện trong vùng vốn chủ yếu chứa media/data.
File bootstrap/loader hoặc code có khả năng chạy trên mọi request.

Không cần alert cùng mức cho mọi file. Cache, generated CSS, image derivative hoặc temporary file cần policy khác core/config/custom executable code.

Baseline đáng tin cậy lấy từ đâu?

Loại code	Baseline ưu tiên
WordPress core	Checksum/package chính thức đúng version/locale
Plugin/theme public	Package release/source phù hợp version
Custom code	Repository + deployment artifact đã approve
Config	Versioned/snapshotted known-good state
Generated file	Rule/profile về path, owner, lifecycle thay vì hash tĩnh

Không promote production state đang nghi compromise thành “known good” chỉ vì site đang chạy được. Baseline phải có provenance và thời điểm xác minh.

File Integrity Manifest mẫu

Manifest dưới đây là worksheet; hash/path thật phải được lấy từ hệ thống hoặc source đáng tin cậy.

baseline_id: FIM-BASE-YYYY-NNN
asset: example.com
created_at_utc: ...
source: official-package|repository|verified-snapshot
approved_by: ...
files:
  - path: wp-includes/example.php
    sha256: ...
    size: ...
    owner_class: core
    expected_change: core-update
  - path: wp-content/plugins/example/file.php
    sha256: ...
    size: ...
    owner_class: plugin:example
    expected_change: approved-plugin-update
exceptions:
  - path_pattern: wp-content/cache/*
    policy: generated-not-hash-pinned

Điều tra file thay đổi bất thường

Phân loại finding trước khi escalation

Finding	Context hợp lệ có thể có	Cần điều tra khi
Core hash mismatch	Version/locale/package khác dự kiến	Không có update/change record hoặc diff bất thường
Plugin/theme file mới	Approved update/deploy	Không owner hoặc package không khớp
PHP trong uploads	Hiếm, có custom use case rõ	Executable code không provenance
`wp-config.php` đổi	Approved config/secret rotation	Change ngoài window hoặc không owner
Permission/owner drift	Deploy/host operation	Không có change context hoặc tạo execution risk
File deletion	Cleanup/update hợp lệ	Security/control file mất ngoài change window

False-positive Gate

Trước khi gắn nhãn malicious, kiểm tối thiểu:

Có update/deploy/change record cùng time window không?
Version/package/repository có giải thích file/diff không?
File là generated/cache/temp hay source/executable?
Owner/team có xác nhận change không?
Hash/diff có thể do restore, migration hoặc normalization không?
Có auth/audit/request event nào làm confidence tăng không?

UNKNOWN không đồng nghĩa SAFE. Nếu không xác định được owner/provenance, giữ finding mở và tiếp tục điều tra thay vì tự động update baseline.

Workflow điều tra file thay đổi bất thường

Snapshot path, hash, size, timestamp, owner và permission hiện tại.
Khóa baseline/source dùng để so sánh.
Review diff hoặc package mismatch.
Đối chiếu deploy/update/restore/change log.
Correlate admin/auth/access/WAF/process event trong cùng timeline.
Phân loại Expected / Needs Review / Suspicious / Confirmed Malicious / Unknown.
Nếu incident còn mở, bảo toàn evidence trước remediation.
Xử lý source/persistence nếu malicious.
Retest và theo dõi recurrence.
Chỉ promote baseline mới sau khi state được xác minh.

File Change Evidence Record mẫu

finding_id: FIM-YYYY-NNN
asset: ...
path: ...
change_type: create|modify|delete|permission|owner
first_seen_utc: ...
baseline_id: ...
baseline_sha256: ...
observed_sha256: ...
size_before: ...
size_after: ...
owner_before: ...
owner_after: ...
permission_before: ...
permission_after: ...
diff_ref: ...
package_or_repo_match: yes|no|unknown
change_record: ...
related_auth_event: ...
related_request_event: ...
classification: expected|needs-review|suspicious|confirmed-malicious|unknown
confidence: low|medium|high
next_action: ...
evidence_refs: [...]

Correlation giúp tăng confidence

File change có giá trị cao hơn khi khớp với timeline khác. Ví dụ plugin file thay đổi đúng lúc approved deployment khác hoàn toàn PHP mới trong uploads xuất hiện vài phút sau admin login từ nguồn chưa từng thấy.

Kết hợp Audit log WordPress, Security Monitoring WordPress và access/WAF/server telemetry khi cần.

WP-CLI checksum dùng thế nào cho đúng?

Với WordPress core, wp core verify-checksums giúp đối chiếu file với checksum chính thức. PASS cho thấy các file được kiểm khớp checksum của release tương ứng; FAIL/mismatch cần điều tra version, locale, package và change history. Checksum không kiểm chứng custom code hoặc toàn bộ persistence mechanism.

Không coi checksum PASS là bằng chứng toàn site sạch malware; nó chỉ trả lời phạm vi file mà checksum đó bao phủ.

Verification và promote baseline

Known-Good Promotion Gate

Điều kiện	PASS để tạo baseline mới
Change provenance	Mọi change quan trọng có owner/source hợp lệ
Security findings	Không còn finding suspicious/unknown chưa giải thích trong scope
Business function	Smoke test route/chức năng chính PASS
Persistence	Nếu sau incident, persistence verification PASS
Evidence	Snapshot/manifest/version được lưu và approve

Nếu một finding còn UNKNOWN và có thể thay đổi kết luận compromise, không được “reset baseline” để làm alert biến mất.

Remediation Verification Matrix

Check	PASS	FAIL
Malicious file	Đã loại bỏ/replace bằng known-good source	Vẫn tồn tại hoặc không rõ source
Recurrence	Không tái xuất hiện trong observation window	File/payload quay lại
Source closure	Account/process/persistence tạo change đã xử lý	Chỉ sửa file bề mặt
Application	Business flow PASS	Cleanup phá chức năng
Baseline	Known-good mới được approve sau verify	Baseline cập nhật trước khi investigation đóng

Nếu file hoặc payload đã xóa nhưng quay lại sau cleanup, đừng chỉ reset baseline; dùng case Backdoor còn tồn tại sau Cleanup để kiểm persistence chain và source tái tạo artefact.

Không nên làm gì?

Không xóa file lạ trước khi bảo toàn evidence nếu incident đang mở.
Không coi mọi mismatch là malware.
Không dựa riêng vào modified time.
Không reset hàng loạt production files khi chưa biết dependency.
Không tạo baseline mới để “clear alert”.
Không dùng FIM thay patching, account security hoặc incident investigation.

PASS/FAIL/HOLD cho File Integrity finding

PASS — Expected: provenance/change/source khớp và diff đúng dự kiến; có thể update baseline qua gate.
PASS — Remediated: malicious change/source đã xử lý, không recurrence và known-good state được verify.
FAIL: chỉ xóa mismatch, không biết source; baseline không đáng tin; hoặc update baseline trên state chưa xác minh.
HOLD: change không owner/provenance hoặc evidence còn mâu thuẫn. HOLD cần điều tra tiếp.

Khi nào chuyển Incident Response?

Nếu có executable file không rõ nguồn, core/config bị sửa trái phép, persistence code, repeated changes sau restore hoặc finding đi cùng account/network anomaly, chuyển sang incident response thay vì chỉ sửa file. Ưu tiên evidence, scope và containment.

Nguồn kỹ thuật

Kết luận

File Integrity có giá trị khi biến một file change thành chuỗi baseline → diff → provenance → correlation → classification → verification. Hash mismatch chỉ là trigger để điều tra. Known-good baseline chỉ được cập nhật sau khi state đã được xác minh, không phải để làm alert biến mất.