본문으로 건너뛰기
진석개발
저널 목록으로
Web SecurityPHPFree약 24분

패치 전에 이미 들어왔다면? 공격의 흔적 세 가지

PHP2Shell 수정을 적용해도 그 전에 침입당했다면 뒷문은 남습니다. JPCERT/CC가 제시한 흔적 세 가지와, 로그 보존부터 비밀번호 교체까지 확인 순서 5단계를 정리합니다.

글쓴이 Jeensuk Yang
공격의 흔적을 확인하는 순서를 설명하는 따뜻한기술 양진석 대표 일러스트

PHPFree · 웹 보안 · 위험편 04

웹 보안 · PHP · 침해 점검 PHPFree 04
읽는 시간 약 8분 업데이트 2026.10.24 글 양진석 (따뜻한기술 대표)

이런 분께 권합니다

  • 패치는 끝났지만, 그 전에 들어오지 않았는지 걱정되는 분
  • 무엇을 어떤 순서로 확인해야 할지 모르는 분
  • 제작사나 유지보수 회사에 무엇을 부탁할지 정리하고 싶은 분

이 글에서 알 수 있는 것

  • JPCERT/CC가 제시한 공격의 흔적 세 가지
  • 로그 보존부터 비밀번호 교체까지 확인 순서 5단계
  • 공유 렌탈 서버라면 누가 무엇을 확인하는지
진지한 표정으로 생각하는 양진석 대표
진석 대표의 안내

"아무것도 달라지지 않았으니 괜찮겠지." 정말 그럴까요?

침입한 쪽이 가장 바라는 것이 바로 그 "아무것도 달라지지 않은" 상태입니다. 들키지 않으면 뒷문을 오래 쓸 수 있기 때문입니다. 패치와는 별도로, "들어왔는지"를 확인하는 순서와 누구에게 무엇을 부탁하면 되는지 정리해 드리겠습니다.

01Keep the logs

침입 확인은 무엇부터 해야 할까?

로그를 지우지 않는 것부터입니다. 서버의 '로그'는 방범 카메라의 녹화와 같아서, 언제·어디에서·어떤 요청이 왔는지가 남아 있습니다. 그런데 서버를 재시작하거나 다시 만들면 로그가 사라질 수 있습니다. 미국 TechTarget은 재시작이나 재구축 전에 10월 20일 이후의 로그를 보존하라고 강하게 권합니다.1

  1. 로그를 보존한다 (재시작 전에. 10월 20일 이후)
  2. 흔적 세 가지를 확인한다 (JPCERT/CC 기준)
  3. 파일과 사용자를 확인한다 (모르는 PHP 파일, 모르는 관리자)
  4. 비밀번호와 키를 교체한다 (이상이 없어도)
  5. 수상하면 전원을 끄지 말고 분리한 뒤 상담

사내에 공유하기 쉽도록 확인 순서를 한 장에 모았습니다.

1번, 녹화부터 지키세요. 확인 순서를 가리키며 설명하는 양진석 대표
방범 카메라 녹화는, 지우기 전에 봐야 합니다.

진석 대표의 정리확인의 첫걸음은 '찾는 것'이 아니라 '지우지 않는 것'입니다.

02Why it's hard

오류가 없으면 괜찮은 걸까?

그렇다고 말할 수 없습니다. 이번 건에서는 "이 흔적이 있으면 확실히 침입당했다"고 말할 수 있는 결정적인 표식(IoC)이 아직 나오지 않아서, 평소와 다른 움직임으로 추측할 수밖에 없습니다.1

주의: Rocket Boys의 해설에 따르면, 공격이 성공해도 PHP 프로그램이 멈추지 않거나 정상을 뜻하는 '200' 응답이 돌아올 수 있습니다.2

진석 대표의 정리"오류가 안 나니까 괜찮다"는 판단은 이번에는 통하지 않습니다. 아래의 흔적을 직접 봐야 합니다.

03Three signs

JPCERT/CC가 제시한 흔적 세 가지는?

긴 PHPSESSID, 수상한 전송 뒤의 오류, 워커의 반복 재시작입니다. 일본 JPCERT/CC가 주의 환기 공지에서 확인하라고 당부했습니다.3·4 이것들은 공격을 받은 신호이지 침입이 확정됐다는 뜻은 아닙니다. 발견되면 더 자세히 조사할 계기로 삼아 주세요.

흔적 1: 비정상적으로 긴 'PHPSESSID' 쿠키

PHPSESSID는 사이트가 방문자를 구별하는 번호표 같은 것으로, 보통은 정해진 길이의 짧은 문자열입니다. 부자연스럽게 긴 기록이 로그에 남아 있다면 공격 시도일 수 있습니다. 발견자 중 한 곳인 Wiz도 비정상적으로 큰 PHPSESSID를 확인 항목으로 꼽았습니다.5

흔적 2: 수상한 전송 직후의 메모리 부족 오류나 '500' 오류

파일을 보낼 때 쓰는 형식(multipart/form-data)의 수상한 요청 바로 뒤에, "메모리 한도를 넘었다"는 오류나 서버 오류를 뜻하는 'HTTP 500'이 나와 있는 경우입니다.3

흔적 3: PHP 프로그램이 몇 번이고 재시작되고 있다

PHP를 돌리는 프로그램(워커)이 짧은 시간에 여러 번 멈췄다가 다시 켜지는 경우입니다.3 Wiz도 워커 재시작이 갑자기 늘지 않았는지 보라고 권합니다.5

진석 대표의 정리세 가지 모두 로그에서 보는 것입니다. 그래서 1단계, 로그 보존이 먼저입니다.

04Files, users, shared hosting

흔적 세 가지 외에 무엇을 봐야 할까?

모르는 PHP 파일과 모르는 관리자입니다.

  1. 본 적 없는 PHP 파일: 업로드용 폴더처럼 원래 PHP 파일이 없어야 할 곳에 새 PHP 파일이 있는지. 한국의 보안 기업 지니언스가 권하는 확인입니다.6
  2. 본 적 없는 관리자 사용자: WordPress '사용자'에 모르는 관리자가 늘었는지. CybelAngel은 웹셸(원격 조종용 뒷문 파일)이나 관리자 계정 추가를, 만일을 위해 2026년 6월까지 거슬러 올라가 볼 것을 제안합니다.7
  3. 비밀번호와 키 교체: 데이터베이스, WordPress 관리자, API 키 등. 이상이 없어도 교체가 권장됩니다.8

수상한 것이 발견되면 전원을 끄지 말고 네트워크에서 분리한 뒤 JPCERT/CC에 인시던트를 보고하거나 IPA의 상담 창구에 문의합니다. 전원을 끄면 메모리 위의 단서가 사라지기 때문입니다. 한국인터넷진흥원(KISA)도 침입이 의심되면 전원을 끄지 말고 격리한 뒤 신고하라고 안내합니다.9

공유 렌탈 서버라면 누가 무엇을 할까?

단계공유 렌탈 서버에서 하는 쪽
1. 로그 보존서버 회사에 문의
2. 흔적 세 가지서버 회사에 문의
3. 파일과 사용자귀사(WordPress 관리 화면·파일 관리)
4. 비밀번호·키 교체귀사
5. 수상할 때서버 회사에 문의 + 전문 기관 상담

참고로 Sakura Internet는 악용에 의한 부정 접근은 보고되지 않았다고 밝혔고,10 Lolipop도 공격 시도는 관측했지만 부정 접근이나 정보 유출은 확인되지 않았다고 보고했습니다.11

진석 대표의 정리공유 서버라면 서버 전체의 로그는 볼 수 없는 경우가 많습니다. 3번과 4번만 귀사에서 하고, 나머지는 서버 회사에 물어보세요.

05What to do

그럼 귀사는 어떻게 할까?

선택할 수 있는 길은 세 가지입니다.

A. 사내에서 확인한다담당자가 있다면

위의 다섯 단계를 서버를 다룰 수 있는 담당자와 함께 진행합니다.

B. 관리하는 사람에게 맡긴다질문 두 개

"10월 20일 이후 로그는 보존했나요?", "JPCERT/CC의 흔적 세 가지는 확인했나요?"

C. 뒷문이 작동하지 않는 형태로확인한 뒤에

PHP가 없는 정적 사이트에는 PHP 파일을 실행하는 구조가 없어서, 이번 같은 뒷문 파일은 작동하지 않습니다.

진석 대표의 정리이번 확인을 마지막 확인으로 만들 수도 있습니다. 매번 이 확인을 하지 않아도 되는 형태를 고르면, "녹화를 돌려 볼" 일 자체가 줄어듭니다.

FAQ

침입 확인에 관해 자주 묻는 질문

흔적 세 가지 중 하나가 있으면 침입당한 건가요?

아닙니다. 공격을 받은 신호일 뿐 침입이 확정된 것은 아닙니다. 파일과 사용자를 더 자세히 확인하는 계기로 삼으세요.

수상할 때 서버 전원을 끄면 안 되나요?

끄지 않는 것이 좋습니다. 전원을 끄면 메모리 위의 단서가 사라지므로, 네트워크에서 분리한 뒤 전문가나 기관에 상담하세요.

공유 렌탈 서버라서 로그를 볼 수 없으면 어떻게 하나요?

서버 회사에 문의합니다. 로그 보존과 흔적 확인은 서버 회사에 묻고, 모르는 파일·관리자 확인과 비밀번호 교체는 귀사에서 합니다.

SOURCES

  1. TechTarget 「PHP2Shell: 22M exposed servers at risk as emergency patches released」(2026년 10월 21일) techtarget.com
  2. Rocket Boys(일본어, 2026년 10월 21일) rocket-boys.co.jp
  3. JPCERT/CC 주의 환기 JPCERT-AT-2026-0033(일본어, 2026년 10월 22일) jpcert.or.jp
  4. @IT(일본어, 2026년 10월 23일) atmarkit.itmedia.co.jp
  5. Wiz Research 「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」(2026년 10월 21일) wiz.io
  6. 지니언스 시큐리티 센터 「PHP 원격 코드 실행 취약점 긴급 안내 보고서」(2026년 10월 21일) genians.co.kr
  7. CybelAngel 「2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming」(2026년 10월 21일) cybelangel.com
  8. 바이라인네트워크 「KISA, 'PHP2Shell' 보안 취약점 긴급 대응 수칙 공개」(2026년 10월 22일) byline.network
  9. KISA 보호나라 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」(2026년 10월 22일) boho.or.kr
  10. Sakura Internet 공지(일본어, 2026년 10월 22일) sakura.ad.jp
  11. Lolipop 공지(일본어, 2026년 10월 22일) lolipop.jp
PHPFree 위험편

PHP2Shell을 계기로, 중소기업 홈페이지가 알아 둘 위험을 다섯 편으로 정리합니다.

  1. PHP2Shell이란? 중소기업 홈페이지에 무슨 일이 있었나
  2. 패치가 끝났는데 왜 안심할 수 없을까? 세 가지 경우
  3. VPS·자사 서버의 PHP 사이트는 왜 아직 위험할까
  4. 패치 전에 이미 들어왔다면? 공격의 흔적 세 가지 (이 글)
  5. PHP 8.2 지원 종료(12월 31일) 전에 정해 둘 것

다른 글은 따뜻한기술 블로그에서 볼 수 있습니다.

PHPFree 30초 체크 · 무료

확인을 혼자 하기 어렵다면.

사이트 주소만 넣으면 PHP 사용 여부와 서버 회사의 대응 상황을 바로 알려 드립니다. 해당되지 않는다면 "지금은 옮기지 않아도 됩니다"라고 그대로 알려 드립니다.

무료로 30초 체크하기

결과를 보고 상담이 필요하시면 따뜻한기술에 문의하기

최종 수정 2026년 10월 24일

함께 읽기

PHP 취약점 대처 순서를 설명하는 따뜻한기술 양진석 대표 일러스트
Web Security약 32분

PHP 취약점 대처 가이드: 확인부터 PHP 탈피까지

PHP2Shell 이후 회사 홈페이지가 할 일을 한 장에 정리했습니다. 한국·일본·미국·중국 자료 40건이 공통으로 권한 확인, 업데이트, 임시 조치, 침입 점검의 순서와 PHP를 쓰지 않는 선택까지 설명합니다.

PHP 8.2 지원 종료를 설명하는 따뜻한기술 양진석 대표 일러스트
Web Security약 23분

PHP 8.2 지원 종료(12월 31일) 전에 정해 둘 것

PHP 8.2 지원은 2026년 12월 31일에 끝납니다. 옛 PHP로 해를 넘기는 위험, 최신 PHP로 올릴 때의 함정, 연말까지의 달력과 중소기업이 고를 수 있는 세 가지 길을 정리합니다.