PHP 서버 해킹 흔적 확인하는 방법: 로그·변조 파일·의심 프로세스 점검
핵심 답변
PHP 취약점 공격이 의심된다면 웹서버 접속 로그와 오류 로그, 새로 생성되거나 수정된 PHP 파일, 관리자 계정, 예약 작업, 비정상적인 프로세스를 함께 확인해야 합니다. 의심스러운 흔적이 발견되면 로그와 증거를 보존하고 서버를 격리하는 등 추가 피해 방지 조치를 우선하세요. PHP를 업데이트하는 것만으로 이미 발생한 침해까지 해결되지는 않습니다.
![]() |
| 서버 로그와 보안 상태를 점검하는 컴퓨터 화면 |
서버에서 PHP 취약점이 발견되었거나 공격 가능성이 제기되면 가장 먼저 확인해야 할 것은 실제 침해가 발생했는지 여부입니다. 서비스가 정상적으로 열리고 있다는 사실만으로 안전하다고 판단할 수는 없습니다.
특히 인터넷에 공개된 PHP 서버라면 공격 요청이 들어왔는지, 웹 애플리케이션 파일이 변경되었는지, PHP 프로세스가 예상하지 못한 명령을 실행했는지를 구분해서 점검하는 것이 중요합니다.
1. PHP 서버 해킹 흔적은 어디서 확인할까?
우선순위는 접속 로그, 오류 로그, 파일 변경 내역, 계정 및 예약 작업, 실행 중인 프로세스입니다. 한 가지 징후만으로 해킹을 확정하지 말고 여러 기록을 서로 대조해야 합니다.
웹서버 접속 로그와 오류 로그
웹서버 로그에서는 공격자가 보낸 요청과 서버의 반응을 확인할 수 있습니다. 평소와 다른 요청이 갑자기 증가했거나, 비정상적인 POST 요청이 반복되거나, 오류가 집중적으로 발생했다면 관련 시간대의 기록을 자세히 살펴보세요.
- 평소와 비교해 비정상적으로 증가한 요청이나 오류
- 특정 IP에서 반복적으로 들어오는 대량의 요청
- 정상적인 서비스 이용으로 설명하기 어려운 POST 요청
- PHP 오류, 메모리 부족 오류, PHP-FPM 작업 프로세스의 비정상 종료
- 공격이 의심되는 시간 전후의 요청 패턴 변화
로그 위치는 운영 환경에 따라 다릅니다. Linux 서버에서는 웹서버 설정과 서비스 관리 방식에 따라 Apache 또는 Nginx 로그가 서로 다른 경로에 저장될 수 있습니다. PHP-FPM을 사용한다면 해당 서비스의 오류 로그와 시스템 로그도 확인해야 합니다.
예를 들어 Linux에서 systemd를 사용하는 환경이라면 서비스 이름을 확인한 후 다음과 같이 관련 로그를 살펴볼 수 있습니다.
sudo journalctl -u php-fpm --since "24 hours ago"
위 명령은 서비스 이름이 실제로 php-fpm인 환경에서 사용할 수 있는 예시입니다. 배포판이나 설치 방식에 따라 서비스 이름이 다를 수 있으므로 먼저 실제 서비스명을 확인하세요. 로그가 해당 서비스에 기록되지 않는 환경에서는 설정된 로그 파일을 직접 확인해야 합니다.
오류가 많다는 사실만으로 침해를 단정할 수는 없습니다. 정상적인 트래픽 증가나 애플리케이션 오류도 비슷한 현상을 만들 수 있으므로 파일 변경 및 프로세스 기록과 함께 판단해야 합니다.
새로 생성되거나 수정된 PHP 파일
웹사이트 파일도 중요합니다. 공격자는 취약점을 악용해 웹 루트에 악성 PHP 파일을 남기거나 기존 파일을 수정해 이후에도 서버에 접근할 수 있습니다.
다음과 같은 변화가 있는지 확인하세요.
- 최근 생성되었지만 배포 기록에는 없는 PHP 파일
- 정상적인 업데이트 이력과 일치하지 않는 파일 수정
- 출처를 알 수 없는 업로드 파일이나 낯선 플러그인
- 관리자 계정이나 애플리케이션 설정 파일의 예상치 못한 변경
- 백업 파일, 임시 파일 또는 숨겨진 경로에 존재하는 의심스러운 코드
Linux 환경에서는 다음 명령으로 특정 디렉터리 아래의 최근 수정 파일을 확인할 수 있습니다.
find /var/www -type f -mtime -3 -print
이 명령은 지정한 경로에서 최근 3일 이내에 수정된 파일을 나열하는 예시입니다. 실제 웹 루트가 다른 곳에 있다면 경로를 바꿔야 합니다. 정상적인 배포나 콘텐츠 수정도 결과에 포함되므로 출력된 파일이 모두 악성 파일이라는 뜻은 아닙니다.
가능하다면 배포 기록이나 정상 백업본과 파일을 비교하세요. 의심스러운 파일을 발견하더라도 즉시 삭제하거나 덮어쓰지 않는 것이 좋습니다. 파일의 시간 정보와 내용을 포함한 증거가 사라질 수 있기 때문입니다.
2. 해킹을 의심해야 하는 추가 징후
PHP 프로세스가 낯선 명령을 실행하는 경우
PHP-FPM이나 웹서버 프로세스가 예상하지 못한 셸, 스크립트 실행 도구 또는 파일 다운로드 프로그램을 실행했다면 주의해야 합니다. 정상적인 작업인지 확인하려면 프로세스의 실행 경로, 명령행, 부모 프로세스, 실행 시각을 함께 살펴보세요.
특히 PHP 프로세스가 외부 주소에서 파일을 내려받거나, 시스템 명령을 실행하거나, 예상하지 못한 외부 연결을 지속하는 경우에는 침해 가능성을 조사해야 합니다. 다만 일부 정상적인 애플리케이션도 외부 프로그램을 실행하므로 실행 목적과 기존 운영 기록을 비교해야 합니다.
관리자 계정과 예약 작업 확인
공격자는 취약점을 악용한 뒤 접근을 유지하기 위해 새로운 계정이나 예약 작업을 추가할 수 있습니다. 다음 항목을 확인하세요.
- 승인 없이 생성된 관리자 계정
- 알 수 없는 cron 작업이나 시스템 예약 작업
- 기존에 없던 서비스 또는 자동 실행 항목
- 설명하기 어려운 외부 네트워크 연결
- 예상하지 못한 인증 기록이나 권한 변경
예약 작업은 시스템 전체뿐 아니라 웹 애플리케이션을 실행하는 계정에도 설정될 수 있습니다. 서버의 운영 구조에 따라 점검 범위가 달라지므로 관리자 권한으로 확인할 수 있는 시스템 기록과 애플리케이션 자체 기록을 함께 검토해야 합니다.
3. PHP 취약점 패치 후에도 추가 점검이 필요한 이유
취약한 PHP 버전을 수정하면 알려진 취약점에 대한 노출을 줄일 수 있지만, 공격자가 이미 악성 파일을 설치했거나 계정을 추가했다면 그 흔적은 그대로 남아 있을 수 있습니다.
2026년 10월 PHP 공식 보안 공지는 CVE-2026-109618 및 CVE-2026-109619와 관련된 취약점을 해결하기 위해 보안 업데이트를 적용하도록 안내했습니다. PHP 공식 발표에서는 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 수정 버전으로 안내하고 있습니다. 실제 서버는 운영체제 배포판이나 호스팅 업체가 제공하는 패키지를 사용할 수 있으므로 해당 환경에 적용되는 수정 버전도 확인해야 합니다.
또한 PHP 8.2는 2026년 12월 31일 지원 종료 예정이므로 장기적으로 사용할 서버라면 이후 보안 업데이트를 받을 수 있는 버전으로의 이전 계획도 세워야 합니다.
버전 확인만으로 점검을 끝내지 마세요. 운영 환경에서 실제로 실행 중인 PHP 버전이 수정된 버전인지 확인하고, 웹서버와 PHP 관련 서비스를 필요한 방식으로 재시작하거나 재배포한 뒤 적용 상태를 검증해야 합니다.
공식 자료:
4. 해킹 흔적을 발견했다면 어떻게 대응할까?
의심스러운 파일이나 프로세스를 발견했다면 무작정 삭제하거나 서버를 초기화하기보다 추가 피해 방지와 증거 보존을 먼저 고려해야 합니다.
- 영향받는 시스템을 격리합니다. 공격이 계속되거나 추가 피해 위험이 있다면 네트워크 접근을 제한하는 등 적절한 격리 조치를 시행합니다. 운영 중단이 어렵더라도 보안 담당자나 호스팅 업체와 신속히 대응 방법을 결정하세요.
- 로그와 증거를 보존합니다. 웹서버 및 PHP 로그, 의심스러운 파일, 관련 프로세스 정보와 시간 기록을 안전하게 보관합니다. 가능한 경우 원본을 보존하고 별도 복사본으로 분석합니다.
- 접근 경로를 조사합니다. 취약한 PHP 버전뿐 아니라 애플리케이션, 플러그인, 계정, 파일 권한 등 공격이 가능했던 경로를 함께 확인합니다.
- 침해 범위를 파악합니다. 악성 파일, 비정상 계정, 예약 작업, 권한 변경, 외부 연결 등 추가 흔적이 있는지 점검합니다.
- 복구와 보안 조치를 진행합니다. 취약점을 수정하고 신뢰할 수 있는 백업 또는 검증된 배포본을 사용해 복구합니다. 계정과 인증 정보가 노출되었을 가능성이 있다면 안전한 환경에서 관련 비밀번호와 키를 교체합니다.
- 재발 여부를 확인합니다. 복구 후 로그와 프로세스를 모니터링하고, 같은 유형의 요청이나 파일 변경이 다시 발생하는지 확인합니다.
침해가 의심되는 상황에서는 시스템을 무조건 재부팅하거나 파일을 일괄 삭제하지 마세요. 이런 조치는 일부 증거를 없애거나 상황을 복잡하게 만들 수 있습니다. 전문적인 사고 대응이 필요하다면 서버 관리자, 보안 담당자 또는 호스팅 업체의 지원을 받는 것이 좋습니다.
마치며
PHP 서버의 해킹 흔적은 접속 로그 하나만 보는 것으로 충분하지 않습니다. 로그, 파일 변경, 프로세스, 계정과 예약 작업을 함께 살펴보고 서로 연결되는 이상 징후가 있는지 확인해야 합니다.
취약점 패치는 우선적으로 진행하되, 이미 침해가 발생했을 가능성도 별도로 조사하세요. 의심스러운 흔적이 있다면 증거를 보존하고 추가 피해를 차단한 뒤 복구하는 것이 안전합니다.
