공격 시도인가, 침입 성공인가?

01변경 전 증거 보존 →02의심되거나 확인된 침입 차단 →03신뢰 상태에서 복구 →

공격 시도인가, 침입 성공인가?

이상 multipart나 WAF 경고는 시도일 수 있습니다. OOM, SIGSEGV/SIGABRT와 HTTP 500 급증에는 정상 장애 원인도 있습니다. 예기치 않은 PHP 자식 프로세스, 외부 연결, 파일 변경과 계정은 조사해야 합니다. 메모리 유출은 웹셸이나 파일을 남기지 않을 수 있어 깨끗한 파일 검사로 배제할 수 없습니다.

여러 로그를 시간순으로 연결

원래 시간대와 시계 오차를 보존하세요. 프록시 요청 ID/시간을 PHP/FPM 오류, PID, WAF, 프로세스/네트워크 이벤트와 맞추세요. 수신 쿠키뿐 아니라 응답 Set-Cookie의 PHPSESSID를 확인하세요. 긴 값과 퍼센트 인코딩은 검토 단서이며 로컬 패턴이 PHP2Shell을 입증하지 않습니다.

일치가 없어도 침입을 배제하지 못함

일반 로그는 본문, 응답 헤더와 세션을 생략합니다. 허용된 복호화 없이는 암호화 HTTP를 볼 수 없습니다. 보관 기간, 누락 복제본과 메모리 활동은 사각지대입니다. 확인한 호스트/기간을 기록하고 업체 로그를 요청하며 위험은 전문가에게 넘기세요. 업데이트는 과거 사건을 설명하지 못합니다.

의심스러운 로그 신호 검토 ↗

명령 예시

journalctl -u php8.3-fpm --since "2026-10-21 00:00:00 UTC" --until "2026-10-22 23:59:59 UTC" --no-pager
journalctl -k --since "2026-10-21 00:00:00 UTC" --no-pager
ps -eo pid,ppid,lstart,args
ss -tpn
# Only use an independently trusted pre-incident manifest:
sha256sum -c /path/to/trusted-manifest.sha256

일차 출처 및 추가 자료

PHP security team원문 읽기 ↗CVE-2026-109618원문 읽기 ↗CVE-2026-109619원문 읽기 ↗php2shell.uk원문 읽기 ↗

공격 시도인가, 침입 성공인가?