로그가 비어도 실행은 남는다, AI 해킹을 입증하는 법

핵심 요약 AI 요약

1

AI 관여와 실행:AI가 공격에 관여했는지와 서버에서 명령이 실행됐는지는 서로 다른 기록으로 입증해야 하며, 이번 공개 자료에는 AI의 판단을 확인할 모델 호출이나 작업 세션이 없다.

2

셸 실행 35건:공개된 PHP2Shell 허니팟 자료를 재집계한 결과, 아파치가 직접 생성한 고유 셸 실행 35건을 완전한 POST 요청 및 소켓 기록과 연결했다.

3

접근 로그의 공백:35건의 공개 접근 로그에서 실행 요청의 완료 기록은 찾지 못했지만, 패킷과 프로세스 기록으로 요청과 셸 생성을 확인했다.

4

성공률 산출 불가:공개 자료는 성공 사례를 중심으로 선별됐고 전체 실패 시도의 분모가 없어, 확인된 35건으로 공격 성공률을 계산할 수 없다.

5

입증 범위의 한계:확인된 셸은 모두 웹서비스 계정으로 실행됐으며, 이 기록만으로 관리자 권한 획득이나 다른 서버 구성에서의 공격 성공을 단정할 수 없다.

기사 목차 펼치기 / 접기

AI 사용과 공격 성공은 서로 다른 기록으로 입증해야 한다. 공개된 PHP2Shell 자료를 재집계해 셸 실행 35건을 확인했고, 공개 접근 로그에서 찾지 못한 실행을 패킷과 프로세스로 대조했다. AI가 실행을 지시했는지는 이 자료에 남아 있지 않다.

앞선 두 편은 국내 사건의 AI 사용 근거와 자동화 구조를 살폈으며, 이번에는 공격 성공과 AI 사용을 각각 어떤 기록으로 확인할 수 있는지 따진다.

AI를 썼다는 증거와 실행됐다는 증거

헌트리스(Huntress)는 피해 고객 측 관측만으로는 AI 개입을 독립 확인하지 못했다고 설명했다. 클라우드스트라이크(CrowdStrike)가 공개한 국내 분석의 근거는 공격 인프라에 남아 있던 설정과 작업 세션 파일들이다. 두 회사가 다룬 사건과 관측 위치가 모두 다르므로, 같은 해킹을 설명할 때도 어떤 기록으로 어떤 주장을 입증하는지 나눠야 한다.

공개된 자료로 어떤 주장까지 확인했는지 나누는 기준이며, 이번에 직접 재집계한 범위는 두 번째 줄이다. AI 사용을 입증한 다른 사건의 기록을 이 실행 사례에 대신 붙일 수는 없다.

공개된 것은 전체 원본이 아니었다

보안 연구자 아델 카리미(Adel Karimi)가 공개한 저장소에는 PHP2Shell 공격의 사건별 패킷과 로그가 있다. 분석용으로 공격을 관찰하는 허니팟에서 수집한 자료다. 실제 금융사 서버의 기록은 아니며, 국내 사건과 같은 도구를 사용했다는 증거도 없다.

공개 설명은 성공 사례 주변의 기록을 골랐고, 주소를 익명화했으며 메모리 누출 내용 일부를 가렸다고 밝힌다. 무가공 전체 원본이라고 부를 수 없는 이유다. 정확한 범위는 사건별로 공개한 파생 자료이며, 공개 전의 전체 캡처는 확보하지 못했다.

커밋을 고정한 저장소에서 284개 파일을 확보했다. 체크섬 목록 자체를 제외한 283개 파일을 대조했고, 공개된 SHA-256 값과 모두 일치했다. 수집 중 파일이 변하지 않았음을 확인한 것으로 공개 전 원본의 진정성까지 증명하는 절차는 아니다. 공개 요청 본문의 해시는 비공개 원본 메타데이터와 14건이 같았고, 21건은 달랐다. 주소 치환 명세는 있지만 비공개 원본이 없어 변환 전체를 역검증하지는 못했다.

성공의 단위를 셸 실행으로 잡았다

웹 요청에 명령이 들어 있다는 이유만으로 성공을 세지 않았다. 서버의 웹프로세스가 실제로 셸을 생성했는지를 먼저 확인했다. 셸은 운영체제 명령을 실행하는 프로그램으로, 요청과 실행을 연결해야 코드가 작동했는지 판단할 수 있다.

프로세스 기록에서 아파치(Apache)를 직접 부모로 둔 /bin/sh 실행을 추출했다. 대상 별칭과 실행 식별자를 기준으로 중복을 제거하자, 고유 실행 35건이 남았다. 공개 사건 목록의 시각과 부모 프로세스도 각각 맞았다.

패킷은 여러 조각으로 나뉜 요청을 순서대로 재조립했다. 빈 구간이나 서로 다른 재전송 내용이 있는지 검사하고 요청 본문의 길이를 대조했다. 35개 사례 모두 실행 단계의 완전한 POST 요청이 있었으며 선행 정보 노출 기록과 셸 부모의 소켓도 연결됐다.

한 건을 시간순으로 다시 따라갔다

35건 가운데 A01을 골라 요청과 프로세스 기록을 다시 연결했다. 공개 사건 메타데이터에는 대상 T1과 셸 실행 시각이 담겨 있다. 접속 요청의 출처 포트와 시각을 맞춰 패킷을 재조립했으며, 아래는 공개 파일에서 직접 대조한 구간이다.

실행 연결의 첫 데이터부터 셸 생성까지는 약 0.363초였지만, 이미 탐색과 앞선 요청을 거친 뒤의 마지막 처리 구간이다. 이 시간으로 전체 침투 속도나 AI의 판단 시간을 계산할 수는 없다. 계정을 확인하는 후속 프로세스도 관리자 권한 획득을 입증하지 않는다.

접근 로그만 봤다면 무엇을 놓쳤나

기록 하나가 비었다고 실행까지 없었던 것은 아니다.

35개 사례의 공개 접근 로그에서는 실행 단계 요청의 완료 기록을 찾을 수 없었다. 하지만 패킷에는 요청이 있었고, 프로세스 기록에는 셸이 생성돼 있었다. 기록 하나의 부재가 실행의 부재로 이어지지 않았으며, 이 자료에서는 네트워크와 서버 실행 기록을 함께 봐야 경과가 맞았다.

원보고서는 웹 작업 프로세스가 충돌하면 해당 요청의 접근 로그가 남지 않을 수 있다고 설명한다. 자체 분석은 공개 선택 자료의 부재와 실제 실행을 대조했다. 전체 웹 로그가 제공되지 않았으므로, 모든 기록 부재의 원인을 충돌 하나로 독립 확정한 것은 아니다.

확인한 셸은 모두 웹서비스 계정 UID 33으로 실행됐다. 관리자 권한을 얻었다는 증거는 아니다. 셸 이후 어떤 파일을 읽고 어디까지 이동했는지는 추가 기록이 있어야 안다.

실행의 증거를 회사 전체 장악으로 확대할 수는 없다.

그러면 공개 공격은 어디서나 성공하나

같은 취약점도 서버 구성에 따라 결과가 갈린다.

위즈(Wiz)는 10월 27일 자체 관측 환경에서 완전한 공격 성공을 확인하지 못했다고 보고했다. 요청 크기 제한과 필요한 메모리 상태 유발 실패 등, 여러 실패 조건을 설명한 분석이다. 같은 글에서 아델 카리미의 실행 증거도 인정했으며, 두 결과는 서로 다른 서버 구성에서 나왔다.

아델 카리미의 환경은 단일 작업 프로세스의 아파치 mod_php 구성이라는 설명이다. 위즈는 PHP-CGI 등을 포함해 다른 배포 환경을 검토했다. 특정 구성에서 작동한 공격 코드가 다른 구성에서도 그대로 성공한다고 보장할 수 없다. 두 보고서를 성공률 순위로 세울 비교 조건도 없으며, 위즈의 원본 관측 기록은 확보하지 못해 업체의 분석으로 귀속한다.

유닛42(Unit 42)는 10월 25일 유럽 정부기관 침해의 최초 진입을 PHP2Shell 취약점과 연결할 수 없다며, 23일 업데이트를 철회했다. 침해를 관측한 것과 특정 취약점이 원인이었다는 것은 다르다. 한 단계의 불확실성을 지우면 AI 공격 사례의 목록도 잘못 커지므로, 수정된 설명까지 반영해야 한다.

35건으로는 성공률을 계산할 수 없다

이번 자료는 성공한 사례를 중심으로 골랐다.

전체 실패 시도와 누락된 관측의 분모가 없으므로, 공개 목록 35건에서 실행을 모두 확인했다고 성공률이 100%가 되지는 않는다. 웹 기록 144행으로 나눠도 단위가 맞지 않는다. 웹 기록을 합칠 때도 분석 범위를 같은 기준으로 맞췄다. 사건별 웹 기록은 모두 185행이었지만 겹치는 구간을 제거하니 144행이 남았다.

선택 창을 단순 합산하면 41행을 더 센다. 대상 별칭을 피해회사로, 출처 IP를 공격자 수로 바꾸는 집계도 성립하지 않는다. 자료의 행 수와 실제 사건의 단위를 구분하지 않으면 중복을 제거한 뒤에도 다른 종류의 오류가 남는다.

최종 실행 요청의 첫 데이터부터 셸 생성까지는 약 0.035~0.890초였다. 이미 준비된 마지막 요청을 처리한 구간이며, 최초 탐색과 판단에 걸린 시간은 들어 있지 않다. ‘AI가 1초 만에 해킹했다’는 결론은 여기서 나오지 않는다.

AI가 어느 판단을 대신했는지 확인할 모델 호출과 작업 세션은 이번 공개 자료에 들어 있지 않다.