4개월 분량의 로그에서 발견된 Panchan — AI를 활용한 Honeypot 심층 분석과 '알려진' 판정의 사각지대

이전에 개인적으로 T-Pot을 사용한 Honeypot이나 OpenCTI 같은 Threat Intelligence 환경을 자택에서 운영해 왔습니다.

로그나 악성코드 샘플은 조금씩 쌓여갔지만, 이것들을 하나하나 깊이 조사하는 데는 상당한 시간이 걸립니다.

최근에는 Claude Code를 조사 에이전트처럼 활용하여 필요한 코드 작성, 로그 집계, 샘플 분석 등을 맡기면서, 지금까지 축적된 데이터를 조금씩 파헤치기 시작했습니다.

이번에 발견된 Panchan 역시 그 과정에서 우연히 마주친 것이었습니다. 처음부터 Panchan을 찾으려 했던 것은 아니었습니다.

시작은 불완전한 ELF 파일 하나였습니다.

계기가 된 'C2가 발견되지 않은 ELF'

T-Pot이 포획했던 특정 ELF 파일을 조사하고 있었습니다.

SHA256:
60bd5e8ce856893acb89e88174daf8353c7217abe879368927b852200cd42fb1
File size:
...

목적은 이 샘플의 C2를 조사하는 것이었습니다.

그런데 분석해도 C2로 보이는 문자열이나 마이닝 풀 같은 정보가 발견되지 않았습니다.

그래서 분석 방법을 의심하기 전에 파일 자체를 확인해 보았습니다.

ELF 구조에서 필요한 파일 크기를 계산하자,

실제 파일 길이 401,408 bytes
필요 파일 길이 8,350,992 bytes
complete ≒ 4.8%

이 되었습니다.

즉, 손에 가지고 있던 것은 본래 파일의 약 4.8%밖에 아니었던 것입니다. .rodata도 포함되어 있지 않았습니다.

문자열이 난독화된 것이 아니라, 문자열이 존재하는 부분 자체가 결여되어 있었던 것입니다.

그럼에도 남아있던 코드를 조사하자, XMRig과 일치하는 처리가 확인되었습니다.

여기서 궁금해진 점은, 똑같이 중간에 잘린 샘플이 다른 곳에도 있지 않을까 하는 것이었습니다.

ELF의 79%가 불완전했다

그래서 보관하고 있던 악성코드 아카이브 전체를 조사했습니다.

아카이브 전체 154건
ELF64 33건
불완전한 ELF 26건

ELF64의 약 79%가 불완전한 상태였습니다.

더욱 흥미로웠던 점은, 26건 중 25건이 같은 30,304,472 바이트 바이너리 조각이었다는 것입니다.

잘린 위치만 달랐을 뿐입니다. 그리고 그 완전판도 같은 아카이브에 남아있었습니다.

많은 조각들이 'known' 상태였다

처음에는 이런 조각들이 각각 미지 샘플로 취급되고 있는 것이 아닌가 생각했습니다.

실제로는 반대였습니다.

Verdict 건수

known 19
unknown 6
판정 없음 1

26건 중 19건이 known이었습니다.

게다가, 같은 바이너리 조각임에도 불구하고 Prometei, Mirai, CoinMiner 등 다른 패밀리 이름이 붙어 있는 것도 있었습니다.

제 트리아지에서는 주로 unknown을 우선하여 조사했습니다.

샘플
↓
외부 TI 등으로 대조
...

하지만, known은 외부에서 이미 관측되고 있다는 것만을 의미합니다.

자신의 환경에서 조사할 가치가 없다는 의미는 아닙니다.

이번 조사에서 처음 발견한 사각지대였습니다.

완전판은 Panchan이었다

발견된 완전판은 약 30MB의 Go 바이너리였습니다.

SHA256:
94f2e4d8d4436874785cd14e6e6d403507b8750852f7f2040352069a75da4c00

Build Info나 함수, 내장된 바이너리 등을 조사하자 SSH를 통한 확산, P2P 통신, credential 처리, 마이닝, XMRig/NBMiner 관련 처리가 확인되었습니다.

더 나아가 내부에서 XMRig 6.16.4와 NBMiner를 추출할 수 있었고, 그 해시값은 손에 가지고 있던 OpenCTI에 등록되어 있던 Panchan 관련 Indicator와도 일치했습니다.

이러한 여러 증거(Evidence)들을 통해 이 샘플을 Panchan으로 판단했습니다.

과거 로그를 파헤치니 4개월 분량의 활동이 남아있었다

정체가 밝혀졌으므로, 다음으로 Cowrie의 과거 로그를 조사했습니다.

손에 가지고 있던 관측에서는 2026년 5월 9일부터 9월 14일까지 관련 활동이 기록되어 있었습니다.

실행 명령어는 1,867건이었고, 거기서 다음 정보를 확인할 수 있었습니다.

관측 항목 | 결과
:---|
공격원 IP | 42
sshd를 사칭하는 이름 | 29종

xinetd

가장 많이 위장하는 이름 1종
숨겨진 디렉터리 30종
인수(argument)에 포함된 고유 IP 608
공격원과 인수에 모두 나타나는 IP 12

특히 흥미로웠던 점은 Panchan 실행 시 인수에 다수의 IP 주소가 포함되어 있었다는 것입니다. 총합하면 608개였습니다.

다만, 여기서는 구별해서 생각할 필요가 있습니다.

Observed:
실행 인수(execution argument)에 608개의 고유 IP가 존재함
Inferred:
...

따라서 본 기사에서는 '608대의 감염된 단말'이 아니라, 608개의 P2P 피어 후보로 보고 있습니다.

마찬가지로 42개의 공격원 IP도 그 소유자가 Panchan의 공격자와는 반드시 일치하지 않습니다. Panchan 자체가 SSH를 통해 자가 복제하기 때문에, 감염된 호스트가 다음 호스트로 확산하고 있을 가능성이 있기 때문입니다.

TOP 1000에도 포함되지 않았다

또 다른 문제점도 발견했습니다.

제가 매일 수행하는 조사에서는 공격 건수가 많은 IP를 TOP 1000까지 추출하여 상세 조사를 진행해 왔습니다.

그런데 이번에 확인한 Panchan 관련 42개 IP는 단 한 번도 TOP 1000에 포함된 적이 없었습니다.

소량
+
장기간
...

이러한 활동은 공격 건수를 기준으로 하는 트리아지(triage)에서 누락될 가능성이 있습니다.

Panchan은 Malware triage에서는 known에 숨어 있고, Network triage에서는 TOP-N 밖에 존재했던 것입니다.

둘 다 단독으로는 그리 비정상적인 설계는 아닙니다. 하지만 여러 필터를 조합한 결과, 4개월간의 활동이 조사 대상에서 벗어나 있었습니다.

AI나 도구의 결과를 그대로 믿지 않기

이번 조사에서는 Claude Code뿐만 아니라 OpenCTI나 VirusTotal 같은 정보를 교차하는 자체 제작 도구도 사용했습니다.

그 과정에서 Panchan으로부터 무관해 보이는 PE나 APK, 다른 악성코드와 Relationship이 연결되는 경우도 있었습니다.

조사해 본 결과, ELF에서 잘라낸 .rodata 같은 단편을 일반 파일과 동일하게 취급했거나, 다수의 부모(parent)를 가진 Relationship 중 일부만 보고 있었던 것이 원인이었습니다.

이에 따라 자체 제작 도구 측에도 작은 단편의 제외 처리, 높은 카디널리티(high cardinality) 관계를 무조건 추적하지 않는 처리, Relationship의 모수 확인 등을 추가했습니다.

Relationship이 존재한다는 것과, 그 Relationship이 조사상 의미가 있다는 것은 별개입니다.

이는 AI의 출력에 대해서도 동일하게 느낍니다.

조사 후 트리아지를 변경했다

이번 조사를 거쳐 ELF 파일에 대해서는,

actual_size
required_size
complete_pct
...

를 기록하도록 했습니다.

또한, known / unknown만으로 조사 대상을 결정하지 않고, 불완전한 파일이나 동종 계열의 단편에 대해서도 확인할 수 있도록 하고 있습니다.

이번 성과는 단순히,

Panchan을 발견했다

뿐만이 아니라,

왜 Panchan이 보이지 않았는지 알게 되었다
↓
같은 이유로 다음 샘플을 놓치지 않도록 했다

하는 것이었습니다.

AI를 활용한 Security Research에 대하여

이번 분석과 집계에서는 Claude Code를 상당히 많이 사용했습니다.

제가 조사하고 싶은 것, 또는 의문을 제기하면 Claude Code가 코드를 작성하거나, 데이터를 집계하거나, 분석 후보를 제시하는 형태입니다.

이전부터 Honeypot이나 TI(Threat Intelligence) 환경을 보유하고 있었지만, 개인적으로 수개월간의 로그나 대량의 샘플을 교차 조사하기에는 시간과 구현 작업이 큰 장벽이었습니다.

AI 코딩 에이전트 덕분에 그 허들이 상당히 낮아졌다고 느낍니다.

반면, 이번 조사에서는 AI나 자체 제작 도구가 가장 그럴듯한 잘못된 방향을 제시하는 경우도 있었습니다.

그래서 중간부터 특히 의식했던 것이,

• 왜 그렇게 판단할 수 있는지
• Evidence는 어디에 있는지
• 다른 설명은 할 수 없는지

라는 확인 과정이었습니다.

AI 덕분에 조사할 수 있는 범위가 넓어진 만큼, 결과를 어떻게 검증하는지가 이전보다 중요해졌다고 느낍니다.

아직 알지 못하는 것들

이번 조사를 통해 모든 것이 밝혀진 것은 아닙니다.

• 자체 Honeypot에서 Panchan 실행 후의 통신을 직접 관측한 것은 아니다
• 608개의 P2P 피어 후보 모두가 감염 호스트인지는 확인하지 못했다
• 특정 Threat Actor나 Campaign에 대한 귀속은 확인할 수 없다
• 공개된 Panchan의 과거 보고서와 상세하게 비교한 것은 아직 진행하지 않았다

이 부분들은 앞으로 추가적으로 조사하고 싶습니다.

맺음말

이번 조사는 Panchan을 찾는 것에서 시작된 것이 아니었습니다.

처음에는 C2가 발견되지 않은 하나의 ELF였습니다.

C2가 발견되지 않음
↓
파일이 4.8%에 불과함
...

Panchan을 발견한 것 자체도 흥미로웠지만, 그보다 더 중요했던 것은 자신의 시스템이 '무엇을 보지 못하고 있었는지'를 발견할 수 있었다는 점이라고 생각합니다.

앞으로도 Honeypot이나 TI 환경에 축적된 데이터를 AI와 함께 파헤치면서, 조사 내용이나 실패한 가설, 그리고 거기서 개선한 내용을 기록해 나가겠습니다.

논의