PHP2Shell 취약점 패치 후 웹셸 확인 방법과 서버 침해 점검 절차

핵심 답변

PHP2Shell 취약점을 패치한 뒤에도 웹셸이 남아 있는지 별도로 확인해야 합니다. 웹 루트의 신규 PHP 파일과 최근 수정 파일, 웹서버 접근 로그, PHP 프로세스가 실행한 의심 명령, 비정상적인 외부 통신을 함께 점검하는 것이 중요합니다. 패치 성공은 추가 공격을 막는 조치이지, 이미 발생한 침해를 자동으로 복구하는 조치는 아닙니다.

PHP 서버의 웹셸과 침해 흔적을 점검하는 보안 모니터링 화면

PHP2Shell은 PHP 실행 환경 자체의 취약점을 악용해 원격 코드 실행으로 이어질 수 있는 보안 문제입니다. 취약한 서버가 공격에 노출된 상태였다면 업데이트를 완료했더라도 공격자가 남겨둔 웹셸이나 지속성 설정이 존재할 가능성을 고려해야 합니다.

따라서 점검은 단순히 PHP 버전을 확인하는 데서 끝내면 안 됩니다. 서버 파일, 프로세스, 계정, 예약 작업, 네트워크 연결까지 확인해야 침해 여부를 보다 정확하게 판단할 수 있습니다.

1. 패치 이후에도 웹셸을 확인해야 하는 이유

PHP2Shell은 애플리케이션 코드가 아니라 PHP 런타임의 메모리 처리 과정과 관련된 취약점입니다. 공격에 성공하면 웹서버 프로세스 권한으로 명령을 실행할 수 있으므로 웹셸 설치, 계정 탈취, 추가 악성 파일 생성 등의 후속 침해로 이어질 수 있습니다.

2026년 10월 21일 공개된 보안 업데이트는 취약한 PHP 실행 환경을 수정하기 위한 것입니다. 이미 공격자가 서버에 접근해 생성한 파일이나 변경한 설정까지 되돌려 주지는 않습니다.

따라서 다음 두 가지를 구분해야 합니다.

취약점 조치: 영향을 받는 PHP 버전을 수정된 버전으로 업데이트합니다.
침해 여부 확인: 업데이트 이전에 공격이 성공했는지, 악성 파일이나 계정이 남아 있는지 조사합니다.

특히 인터넷에 직접 노출된 서버, 업데이트가 늦어진 서버, PHP-FPM이나 Apache mod_php 등을 사용하는 서버는 우선 점검 대상에 포함하는 것이 좋습니다.

2. 웹셸이 남아 있는지 확인하는 방법

① 최근 생성되거나 수정된 PHP 파일 확인

가장 먼저 확인할 곳은 웹사이트의 문서 루트입니다. 일반적으로 웹셸은 웹서버가 접근할 수 있는 디렉터리에 PHP 파일 형태로 남을 수 있습니다.

Linux 환경에서는 다음 명령으로 최근 변경된 PHP 파일을 확인할 수 있습니다.

find /var/www -type f -iname "*.php" -mtime -14 -ls

위 명령은 지정한 디렉터리에서 최근 14일 이내 수정된 PHP 파일을 찾습니다. 실제 웹 루트가 다른 경로라면 해당 경로로 변경해야 합니다.

다음 항목을 집중적으로 살펴봅니다.

최근 생성되었지만 서비스 기능과 관련이 없는 PHP 파일
기존 파일과 이름이 비슷하지만 위치가 다른 파일
정상적인 플러그인이나 테마에 속하지 않는 PHP 파일
관리자 페이지와 무관한 업로드 디렉터리의 PHP 파일
파일 소유자나 권한이 기존 배포 파일과 다른 파일

단, 수정 시간이 최근이라는 이유만으로 악성 파일이라고 판단하면 안 됩니다. 정상적인 업데이트나 배포로 변경된 파일일 수도 있으므로 기준 백업이나 정상 배포본과 비교해야 합니다.

② 의심스러운 PHP 코드 검사

웹셸은 명령 실행, 코드 해석, 외부에서 전달된 입력 처리 등의 기능을 포함하는 경우가 있습니다.

다음과 같은 PHP 함수나 코드 패턴은 점검의 단서가 될 수 있습니다.

eval(
assert(
base64_decode(
gzinflate(
shell_exec(
system(
passthru(
proc_open(
popen(

파일을 빠르게 조사하려면 다음과 같이 검색할 수 있습니다.

grep -RInE \
'eval|base64_decode|gzinflate|shell_exec|passthru|proc_open' \
/var/www --include="*.php"

이 명령은 해당 함수나 문자열이 포함된 파일과 줄 번호를 출력합니다.

주의할 점은 이런 함수가 발견되었다고 웹셸로 확정할 수는 없다는 것입니다. 정상적인 CMS, 플러그인, 프레임워크에서도 일부 함수가 사용됩니다. 코드의 실행 흐름과 파일 생성 시점, 파일 출처를 함께 확인해야 합니다.

③ 웹서버 접근 로그 확인

웹셸이 설치되었다면 공격자가 PHP 파일을 업로드하거나 해당 파일에 접근한 흔적이 남아 있을 수 있습니다.

Apache와 Nginx의 접근 로그에서 다음과 같은 행위를 조사합니다.

평소 파일 업로드 기능이 없는 경로에 전달된 POST 요청
PHP_SESSION_UPLOAD_PROGRESS 값이 포함된 요청
정상적인 애플리케이션 흐름과 맞지 않는 PHP 파일 접근
관리자 인증 없이 접근한 업로드 및 실행 관련 경로
짧은 시간 동안 반복된 비정상적인 요청

예를 들어 로그에서 POST 요청을 추출하려면 다음과 같이 확인할 수 있습니다.

grep '"POST ' /var/log/nginx/access.log

로그 위치는 서버 설정에 따라 달라집니다. Apache에서는 access.log, Nginx에서는 access.log와 같은 파일명을 사용하는 경우가 많지만 실제 설정 파일에서 기록 경로를 확인해야 합니다.

중요한 점은 PHP2Shell의 공격이 애플리케이션 코드가 실행되기 전에 발생할 수 있다는 것입니다. 따라서 일반적인 애플리케이션 로그에 공격 흔적이 없다고 해서 침해가 없었다고 단정하면 안 됩니다. 요청 본문을 저장하지 않는 접근 로그도 많으므로 WAF와 프록시 로그를 함께 살펴보는 것이 좋습니다.

④ PHP 및 웹서버 프로세스 확인

웹셸이 실행되면 PHP 또는 웹서버 프로세스가 비정상적인 자식 프로세스를 실행할 수 있습니다.

현재 실행 중인 프로세스는 다음 명령으로 확인할 수 있습니다.

ps auxf

다음과 같은 프로세스가 웹서버 또는 PHP 프로세스의 하위에서 실행되고 있는지 살펴봅니다.

bash, sh 등 명령 해석기
curl, wget 등 외부 다운로드 도구
python, perl 등 스크립트 실행기
서비스 기능과 무관한 시스템 명령

이러한 프로세스가 반드시 악성인 것은 아닙니다. 정상적인 관리 작업이나 배포 작업에서도 실행될 수 있습니다. 부모 프로세스, 실행 사용자, 실행 시각, 명령 인자를 함께 확인해야 합니다.

⑤ 외부 네트워크 통신 확인

공격자가 웹셸을 설치한 뒤 외부 서버와 통신하거나 추가 파일을 다운로드하도록 설정했을 수 있습니다.

현재 연결 상태는 다음 명령으로 확인할 수 있습니다.

ss -plant

특히 PHP-FPM이나 웹서버 프로세스에서 평소 사용하지 않는 외부 IP와 통신하는지 확인합니다.

현재 연결만으로 과거 침해를 확인할 수는 없습니다. 연결이 종료되었거나 공격자가 통신 흔적을 지웠을 수도 있기 때문에 방화벽 로그, DNS 기록, 네트워크 모니터링 자료도 함께 확인해야 합니다.

3. 웹셸 외에 확인해야 할 침해 흔적

웹셸 파일만 삭제하는 것으로 점검을 끝내면 안 됩니다. 공격자가 서버에 접근한 뒤 다른 방법으로 권한과 접근 경로를 유지했을 가능성도 있습니다.

다음 항목을 추가로 확인합니다.

계정: 새로 생성된 관리자 계정, 알 수 없는 SSH 공개키, 비정상적인 로그인 기록
예약 작업: crontab과 시스템 서비스에 추가된 의심스러운 실행 항목
시작 프로그램: systemd 서비스 등 부팅 시 자동 실행되는 항목
설정 파일: .htaccess, php.ini, 웹서버 설정의 예상하지 못한 변경
업로드 폴더: 이미지나 문서 업로드 디렉터리에 존재하는 실행 가능한 파일
인증정보: 데이터베이스 비밀번호, API 키, 관리자 세션 및 접근 토큰의 유출 가능성

특히 데이터베이스 접속정보나 서비스 계정의 비밀번호가 유출되었을 가능성이 있다면 정상적인 서버로 복구한 이후에도 기존 인증정보를 그대로 사용하지 않는 것이 중요합니다.

4. 의심 파일이나 침해 흔적을 발견했다면?

악성 파일로 의심되는 항목을 발견했다면 바로 삭제하는 것보다 증거를 보존하는 것이 우선입니다.

서버 격리: 추가 피해를 막기 위해 외부 접근과 불필요한 통신을 제한합니다. 단, 업무와 증거 보존에 미치는 영향을 고려합니다.
증거 보존: 파일, 해시값, 로그, 프로세스 정보, 시간 정보를 보존합니다.
침해 범위 조사: 최초 접근 시점과 악성 파일 생성 시점, 추가 계정 및 권한 변경 여부를 조사합니다.
정상 환경 복구: 신뢰할 수 있는 백업이나 검증된 배포본으로 서버를 복구합니다.
인증정보 변경: 유출 가능성이 있는 관리자 비밀번호와 API 키, 데이터베이스 계정 등을 교체합니다.
재점검: PHP 버전과 서버 설정, 외부 통신, 파일 무결성을 다시 확인합니다.

침해가 확인된 서버에서 웹셸 하나만 삭제하고 계속 운영하는 방식은 권장하지 않습니다. 공격자가 다른 지속성 수단을 설치했을 수 있기 때문입니다.

침해 범위가 불분명하거나 관리자 권한까지 탈취된 것으로 의심된다면 보안 담당자 또는 침해사고 대응 전문기관의 조사를 받는 것이 안전합니다.

5. PHP2Shell 패치 적용 여부도 재확인하기

웹셸 점검과 별도로 실제 서비스에서 실행 중인 PHP 버전이 수정된 버전인지 확인해야 합니다.

2026년 10월 21일 공개된 PHP 보안 업데이트의 수정 버전은 다음과 같습니다.

PHP 계열	수정 버전
PHP 8.5.x	8.5.12
PHP 8.4.x	8.4.27
PHP 8.3.x	8.3.36
PHP 8.2.x	8.2.35

위 버전은 해당 취약점에 대한 수정 기준입니다. 이후 보안 업데이트가 나왔다면 해당 계열의 더 최신 보안 버전을 적용하는 것이 좋습니다.

버전 확인은 다음 명령으로 시작할 수 있습니다.

php -v

다만 명령줄에서 확인한 PHP와 실제 웹 요청을 처리하는 PHP의 버전이 다를 수 있습니다. PHP-FPM, Apache mod_php, 컨테이너, 별도 설치된 PHP 바이너리 등을 구분해 확인해야 합니다.

배포판에서 자체 보안 패치를 적용한 패키지를 제공하는 경우에는 단순한 버전 문자열만으로 취약 여부를 판단하기 어려울 수 있습니다. 운영체제 및 패키지 공급자의 보안 공지도 함께 확인해야 합니다.

마치며

PHP2Shell 패치 후에는 업데이트 성공 여부와 별개로 서버 침해 여부를 확인해야 합니다. 최근 변경된 PHP 파일, 웹서버 로그, PHP 프로세스의 자식 프로세스, 외부 네트워크 연결, 관리자 계정과 예약 작업을 함께 점검하는 것이 중요합니다.

특히 정상 파일인지 판단하기 어려운 항목이 발견되었다면 무작정 삭제하지 말고 먼저 증거를 보존해야 합니다. 패치 적용, 침해 범위 조사, 인증정보 교체, 정상 환경 복구까지 마쳐야 실질적인 보안 조치가 완료됩니다.

참고 출처

이 블로그 검색

MINDLIFETECH