weblogchecker

웹 서버 로그에는 이미 공격을 받았는지 여부가 기록되어 있습니다. weblogchecker가 그 로그를 읽습니다.

phpscan은 PHP가 노출되어 있는지 알려줍니다. phpscan hunt는 웹루트에서 셸을 검색합니다. weblogchecker는 세 번째 질문 — 실제로 누군가 그것들을 사용했는가? — 에 답합니다. 대부분의 사이트가 이미 보유하고 있지만 아무도 읽지 않는 단 하나의 기록, 즉 액세스 로그를 통해 말입니다.

이 도구는 당신이 소유한 Apache 및 nginx 액세스 로그를 스트리밍하며, 중요한 상호작용 — 요청에 응답하는 웹셸, 리다이렉트로 끝나는 브루트포스 폭주, 200 응답을 받은 익스플로잇 패턴 — 을 찾아내고, 각각을 심각도, 신뢰도, 증거로서의 실제 로그 라인, 그리고 대응 방법과 함께 보고합니다.

weblogchecker analyze /var/log/apache2/access.log

종료 코드: 0 = 지표 없음, 1 = 지표 발견, 2 = 사용법 오류. 기계 판독 가능한 출력을 위해 --format json을, 기간을 제한하려면 --since 2026-10-01을 추가하세요. .gz 로그는 직접 읽으며, -는 stdin을 읽습니다.

0.2.0의 새로운 기능 — 베이스라인 diff. 시그니처 목록은 이미 이름이 붙은 셸만 알고 있습니다. 당신의 사이트에 침투하는 셸은 무작위 이름을 가집니다. weblogchecker에 같은 사이트의 신뢰할 수 있는 과거 로그를 제공하면 이전에는 없었던 실행 파일을 보고합니다:

weblogchecker analyze access.log --baseline access.log.last-month

처음 등장하는 모든 실행 가능 경로(.php, .phtml, .cgi, .asp, .jsp…)는 로그만으로 다섯 가지 약한 신호 — 2xx/3xx 응답, POST/PUT 사용, 리퍼러 없음, 최대 2개 IP에서만 접근, upload/cache/temp 디렉터리 하위 위치 — 를 기준으로 점수가 매겨지며, 신호, 횟수, 로그 라인을 증거로 삼아 NEW로 보고됩니다. 최초 발견만으로는 낮은 심각도의 참고 사항일 뿐이며, 심각도는 신호가 누적될 때만 올라가므로(자세한 내용은 아래 참조) 지난주에 설치한 플러그인이 사건으로 읽히지 않습니다.

설치

PyPI에서 한 줄로 설치합니다(파이썬 3.11 이상, 표준 라이브러리만 사용 — 의존성 없음):

pip install weblogchecker

첫 PyPI 릴리스 대기 중. PyPI 신뢰할 수 있는 게시자가 구성될 때까지, GitHub에서 동일한 코드를 설치하세요: pip install git+https://github.com/PHPatch/weblogchecker.git (또는 아래의 서명된 릴리스 tarball을 다운로드하세요). 위의 pip install weblogchecker 줄은 첫 PyPI 릴리스가 나오는 즉시 작동합니다.

"externally-managed-environment" 오류로 거부하는 시스템 (Debian/Ubuntu 및 Homebrew Python)에서는 대신 pipx를 사용하세요:

python3 -m pip install --user pipx   # if you don't have pipx yet
pipx install weblogchecker

서명된 릴리스(sdist + wheel + PGP 서명 + SBOM)는 GitHub releases 페이지에 있습니다. pgp-key.asc의 키로 서명을 검증하세요 — 지문은 BAA1 586A AD37 18C0 CE41 D288 FE23 A624 54E3 5307입니다. SECURITY.md를 참조하세요.

탐지 항목

로그에서의 패턴	심각도 / 신뢰도	중요한 이유
2xx로 응답하는 알려진 웹셸(c99, r57, FilesMan, b374k, WSO)	높음 / 높음	셸이 존재하며 요청을 처리했다
동일한 이름으로 프로브되었으나 404/403	낮음 / 낮음	누군가 찾아봤으나 아무것도 발견되지 않음 — 경보가 아닌 맥락
응답하는 eval-stdin.php (phpunit)	높음 / 높음	2026년 10월 php2shell 파동의 UnitTest 셸이 POST된 코드를 실행한다
/uploads/, /media/, /files/… 내부의 실행 파일(.php 등)이 응답, 특히 POST	높음 / 높음	업로드 디렉터리는 절대 코드를 실행해서는 안 된다
정적 파일(.jpg, .css…)에 대한 POST/PUT이 2xx로 응답	높음 / 중간	브라우저는 이미지에 POST하지 않는다; "이미지"는 종종 스크립트다
URI 내 익스플로잇 패턴(트래버설, eval(, php://, 긴 base64 토큰)이 2xx로 응답	높음 / 중간	시도가 성공했을 수 있다
동일한 패턴이 차단됨 / 404	낮음 / 낮음	배경 잡음; 캠페인 맥락으로만 유용
wp-login.php / xmlrpc.php에 대한 브루트포스 폭주(10분당 ≥20 POST)	중간 / 중간	단일 IP, 비인간적 속도
반복된 실패 후 해당 폭주 내의 302	높음 / 중간	올바른 비밀번호의 형태 — 계정 탈취 가능성
스캐너 사용자 에이전트(sqlmap, nuclei, nikto…)	낮음 / 낮음	정보성; 스캔은 침해가 아니다
--baseline 로그에 없던 실행 파일 경로가 요청에 응답	낮음 → 높음 / ≤ 중간	어떤 블록리스트도 모르는 이름 없는 셸; 심각도는 POST, 리퍼러 누락, 적은 IP 수, 업로드 디렉터리와 함께 누적된다

모든 발견 클래스에는 대응 조치 텍스트가 포함됩니다: 파일 격리, 자격 증명 교체, 해당 IP가 접촉한 모든 것 검토. 웹셸 발견은 동반 도구인 phpscan hunt (pip install phpscan, github.com/PHPatch/phpscan)를 가리킵니다 — 이 도구는 이러한 로그 패턴이 가리키는 셸을 웹루트 자체에서 스캔합니다.

정직성 원칙

이 도구는 phpscan과 동일한 원칙 아래 구축되었습니다:

• 판결이 아닌 지표. 발견은 "이 패턴이 이 신뢰도로 당신의 로그에 나타난다"고 말할 뿐 — 결코 "당신이 해킹당했다"고 말하지 않습니다. 깨끗한 결과는 "이 기간에 이러한 패턴이 나타나지 않는다"고 말할 뿐 — 결코 "당신은 안전하다"고 말하지 않습니다. SSH, 탈취된 세션 쿠키, 또는 서버가 기록하지 않은 로그를 통해 침입한 공격자는 이 도구가 찾을 수 있는 것을 남기지 않습니다.
• 실패한 시도는 낮게 유지된다. 404 프로브는 누군가 노크한 것이지, 누군가 내부에 있는 것이 아닙니다. 심각도는 요청의 의도가 아닌 서버의 응답을 따릅니다.
• 오탐 방지 규율은 약속이 아닌 테스트로 검증된다. 테스트 스위트에는 정상적으로 바쁜 WordPress 하루의 픽스처 — 관리자 로그인, 플러그인 업데이트, wp-cron, wp-admin을 통한 이미지 업로드, Jetpack xmlrpc 핑 — 가 포함되어 있으며, 이것이 발견 사항 0건을 생성함을 검증합니다. 두 번째 픽스처 쌍은 베이스라인 모드를 다룹니다: 정상적인 WordPress 베이스라인과, 그 이후의 유일한 새로운 항목이 wp-admin을 통해 설치된 플러그인, 새 핸들러로 POST하는 연락처 양식, 그리고 새 게시물인 로그는 중간/높음 발견 사항 0건을 생성해야 합니다. 만약 탐지기가 일상적인 관리자 작업에서 발동한다면, 그것은 버그입니다; 제보해 주세요.
• 최초 발견은 고발이 아닌 기록이다. 베이스라인 모드에서 새로운 실행 파일은 낮은 심각도로 시작하고, 독립적인 약한 신호들이 누적될 때만 상승하며(최초 등장만으로는 절대 상승하지 않음), 첫 히트가 wp-admin 페이지에서 도착한 경우 — 당신이 무언가를 설치하는 형태 — 상한이 적용되고, 신뢰도는 중간을 초과하지 않습니다. 발견은 "이 파일은 당신의 베이스라인에 없었으며 이렇게 행동한다"고 말하며, 스스로 판단할 수 있도록 카운트를 제공합니다.
• 읽기 전용 및 오프라인. weblogchecker는 네트워크 연결을 열지 않으며 분석하는 로그를 절대 수정하지 않습니다. 방문자의 IP를 드러내는 당신의 로그는 절대 당신의 머신을 떠나지 않습니다.

성능

파싱은 라인 스트리밍 방식이다. 파일은 메모리에 전혀 로드되지 않으며, 집계는 발견 항목당 최대 다섯 개의 증거 라인만 유지한다. 이 프로젝트의 픽스처 생성기(366,306줄, 72 MB의 현실적인 결합 로그)에서 측정한 결과, 적당한 사양의 VM에서 7.6초, 최대 RSS 12.8 MB였다. 2 GB 로그도 동일한 메모리를 사용하며, 시간은 비례하여 늘어난다.

예시

$ weblogchecker analyze access.log
weblogchecker 0.2.0 - access-log compromise analysis
Log: access.log
Lines read: 13 | parsed: 13 | unparseable (skipped): 0

Indicators found. These are leads for investigation, not proof of
compromise: work through the findings in severity order ...

SUMMARY: 10 findings (4 high, 1 medium, 5 low) across 9 incidents, 2 IPs flagged

INCIDENT TIMELINE (grouped by IP + path):
  [HIGH] 198.51.100.66 /wp-content/uploads/2026/10/c99.php
       classes: webshell-access, exec-in-upload-dir | requests: 6 | ...
  ...

1. [high severity / high confidence] Known webshell filename answered a request
   198.51.100.66 /wp-content/uploads/2026/10/c99.php - 3 request(s), ...
   | 198.51.100.66 - - [28/Oct/2026:03:13:40 +0000] "GET /wp-content/..." 200 ...
   Remediation: Treat the named file as a live webshell until you have
   proven otherwise. Locate it in the webroot and quarantine it ...

패밀리

• phpscan — PHP가 노출되어 있습니까? (버전/CVE 판정, composer 감사, 디스크 상의 셸 탐지를 위한 hunt)
• weblogchecker — 누군가 이를 악용했습니까? (이 도구, 로그에서 확인)
• wpchecker — WordPress 플러그인 스택이 노출되어 있습니까? (동반 스캐너)

모두 무료이며 모두 오픈 소스이고, 어느 것도 익스플로잇 프로브를 전송하지 않습니다.

라이선스

MIT — LICENSE를 참조하십시오. 보안 신고: SECURITY.md를 참조하십시오.