미쓰비시 전기의 야마모토입니다.

미쓰비시 전기 정보기술종합연구소에서는 제품 개발 시의 보안 대책에 피드백하기 위한 목적으로, 여러 종류의 허니팟 (Honeypot)을 설치 및 운용하고 있습니다. 허니팟 (Honeypot)이란, 의도적으로 외부에서 액세스할 수 있는 상태로 두어 그곳으로 들어오는 수상한 통신을 관측하기 위한 '미끼' 서버를 말합니다.

이번에 당사 허니팟 (Honeypot)에 대하여, SOCKS 프록시 (SOCKS Proxy) 또는 HTTP 프록시 (HTTP Proxy)로 악용할 수 있는지 확인하려는 것으로 보이는 통신을 관측했습니다. SOCKS4, SOCKS5, HTTP CONNECT와 같은 여러 방식을 구분하여 사용하며 탐색하는 모습이 보여, 관측 사례로서 흥미로운 내용이었습니다.

본 기사에서는 이 관측 결과를 소개함과 동시에, 다음 날 관측된 유사한 통신 로그를 사용하여 생성형 AI (Generative AI)에 의한 자동 분석 경향도 검증합니다.

(본 기사에서는 일부 데이터를 마스킹 처리하였습니다.)

본 기사에서 알 수 있는 것:

• 허니팟 (Honeypot)에서 관측된, 오픈 프록시 (Open Proxy) 탐색으로 보이는 통신의 특징
• 관측 로그만으로 단정할 수 있는 것과 없는 것
• SOCKS5 / SOCKS4 / HTTP CONNECT의 기본적인 구별 방법
• 생성형 AI (Generative AI)에게 로그 분석을 맡겼을 때 나타난 '과도한 단정'의 경향
• 스프레드시트의 자동 변환이 AI의 분석에 미친 영향

SOCKS를 알고 계신 분은 다음 절인 'SOCKS란 무엇인가'를 건너뛰고 '관측 결과'부터 읽으셔도 무방합니다.

본 기사에서는 관측 로그로부터 비교적 강하게 말할 수 있는 사실과, 단정할 수 없는 사항을 구분하여 기술합니다.

관측 로그를 통해 말할 수 있는 것은, 외부 송신처가 당사 허니팟 (Honeypot)을 SOCKS/HTTP 프록시 (Proxy)로 이용 가능한지 확인했을 가능성이 높다는 점입니다. 반면, 실제로 중계가 성공했는지, 발판(踏み台)으로 악용되었는지, C2 통신(공격자가 장악한 기기에 명령을 보내거나 탈취한 정보를 회수하기 위한 통신)인지는 이번 관측 로그만으로는 단정할 수 없습니다.

따라서 본 기사에서는 통신의 송신처를 '스캔 주체' 또는 '송신처'라고 표기합니다. 허니팟 (Honeypot)을 대상으로 하는 통신의 특성상 악의가 의심되는 동작이지만, 개별 주체의 의도나 속성을 단정할 의도는 없습니다.

참고로, 페이로드 (Payload)란 통신의 내용에 해당하는 데이터 그 자체를 가리키는 용어입니다. 본 기사에서는 1바이트 (8비트, 2자리의 16진수로 표현할 수 있는 정보의 단위)를 2자리의 16진수로 나타내며, 바이트 사이를 콜론(:)으로 구분하여 표기합니다 (예: 05:01:00).

SOCKS는 네트워크 프록시 프로토콜 (Network Proxy Protocol)입니다. 프록시 (Proxy)란 친숙한 예로 우편물의 사서함과 같은 구조로, 송신자를 대신하여 다른 상대와 직접 주고받는 중계 역할을 의미합니다. SOCKS는 클라이언트 (Client, 통신을 시작하는 측의 기기)가 프록시 서버 (Proxy Server)를 경유하여 외부 서버와 통신하기 위한 구조로, 주로 방화벽 (Firewall)을 넘거나 익명성을 확보하기 위한 목적으로 사용됩니다. [1][7]

SOCKS 프록시 (SOCKS Proxy)와 HTTP 프록시 (HTTP Proxy)의 차이점은 다음과 같습니다. 표의 용어는 이후 본문에서도 차례대로 설명하겠습니다.

표의 보충 설명: SOCKS는 애플리케이션 데이터의 내용을 세세하게 해석하기보다는, 접속 대상의 지정이나 중계 방법을 다루는 프록시 프로토콜 (Proxy Protocol)입니다. CONNECT라는 명령을 사용하면 HTTP 프록시 (HTTP Proxy)로도 다른 통신을 터널 (Tunnel, 내부를 그대로 통과시키는 경로)로 만들 수 있습니다. ATYP는 목적지 주소의 종류를 나타내는 값, 사용자 이름/비밀번호 인증은 RFC 1929 [8]에서 정의된 인증 방식, GSSAPI는 Kerberos 인증 등과 조합하여 사용되는 범용 인증 프레임워크입니다.

SOCKS는 접속 대상의 지정이나 인증 방식 등의 제어 정보는 해석하지만, 중계가 시작된 이후의 HTTP 등 애플리케이션 데이터의 내용은 기본적으로 해석하지 않습니다. 이러한 특성 때문에 HTTP 이외의 프로토콜(SSH, FTP, 게임 등)에도 사용할 수 있다는 것이 특징입니다. 반면, 그 높은 자유도가 악용되어, 踏み台プロキシ(Footprint Proxy, 공격자가 신원을 숨기기 위해 경유하는 중계 서버)로 악용되는 경우가 있습니다.

참고로, 상기 표는 SOCKS5(RFC 1928 [7])를 전제로 하고 있습니다. SOCKS4는 TCP만 지원하며 UDP에는 대응하지 않고, 도메인 이름 지정도 할 수 없습니다(SOCKS4a 확장 제외). 또한, HTTP 프록시도 CONNECT를 사용하면 다른 TCP 통신을 터널링(Tunneling)할 수 있기 때문에, "SOCKS는 범용, HTTP는 Web 전용"이라는 구분은 엄격한 것이 아닙니다.

"건수"가 무엇을 센 것인지에 따라 해석이 달라지므로, 본 기사의 수치는 다음과 같은 정의로 집계하였습니다.

• 관측 기간: 2026년 4월 20일 00:00:00 ～ 23:59:59
• 대상: 당사 허니팟(Honeypot)의 TCP 1080번 포트
• 건수의 단위: 허니팟이 출력한 로그 라인(Line) 단위

따라서, 본 기사의 건수는 TCP 세션 수나 페이로드(Payload)의 유니크(Unique) 출현 횟수와 일치하지 않을 수 있습니다.

또한, 후술할 AI 비교 실험에서 사용한 검증용 샘플은 본 절의 관측 기간과는 다른 날(4월 21일)에 취득한 데이터입니다. 동일한 스캔 활동으로 보이는 유사한 통신이 다음 날도 관측되었기에, AI 모델의 분석 능력을 검증할 목적으로 그 일부를 검증용 데이터로 선정했습니다. 본 절의 관측 결과(121,863건 등)와는 독립된 집계이므로, 양자의 수치를 혼동하지 않도록 주의하시기 바랍니다.

• SOCKS/HTTP 프록시 관련 통신: 121,863건
• 유니크(Unique) 송신원 IP 주소: 약 50개 이상. 주요 송신원 대역은 다음 두 가지입니다.

AA.BB.CC.*: 33개

DD.EE.FF.*: 17개

※ "*"는 제1~제3 옥텟(Octet)이 공통이며, 제4 옥텟만 다른 여러 IP 주소를 나타냅니다.

• 상기 통신 건수(121,863건)에서 차지하는 비율:

AA.BB.CC.*: 약 65.9%

DD.EE.FF.*: 약 33.8%

이 두 대역이 통신 건수의 약 99.7%를 차지합니다. 나머지 약 0.3%는 이 두 대역 이외의 소수 송신원에 의한 것입니다.

• 송신원 포트 번호: 에페머럴 포트(Ephemeral Port) 대역으로 보이는 다양한 값

RFC 1928 [7] 및 참고 해설 [2]를 바탕으로, 관측된 패킷에 포함된 페이로드(Payload)의 일부를 소개합니다.

SOCKS5 인증 방식 네고시에이션 (Negotiation)

# 송신원→허니팟
05:01:00

각각의 의미는 다음과 같습니다.

05

= SOCKS version 5

01

= 제시하는 인증 방식의 수

00

= No Authentication (인증 없음)

송신원은 허니팟에 대해 "SOCKS5를 사용하며, 인증 방식으로서 인증 없음을 제시한다"는 네고시에이션(Negotiation)을 시작하고 있습니다. 이 단계에서는 아직 목적지로의 접속 요청은 이루어지지 않았습니다.

SOCKS5 인증 방식 선택 응답

# 허니팟→송신원
05:00
# 허니팟→송신원
...

각각의 의미는 다음과 같습니다.

05

= SOCKS version 5

00

= No Authentication Required (인증 없음 방식을 선택)

ff

= No acceptable authentication methods (수용 가능한 인증 방식 없음)

허니팟은 송신원에 대해 05:00 (인증 방식으로서 "인증 없음"을 선택) 또는 05:ff (수용 가능한 인증 방식 없음)를 응답하고 있습니다. 이는 인증 방식의 선택 결과이며, 목적지로의 중계 접속이 성공했음을 의미하는 것은 아닙니다.

참고로, SOCKS4나 HTTP GET 등 SOCKS5의 네고시에이션으로 해석할 수 없는 통신에 대해서도, 이번 검증용 샘플에서 허니팟은 동일한 05:ff를 반환하고 있었습니다. 05:ff는 SOCKS5의 인증 방식 선택 응답으로 정의된 값이며, SOCKS4나 HTTP의 사양상의 정식 거부 응답은 아닙니다. 이번 로그에서는 허니팟 구현이 해석할 수 없는 입력에 대해 이 값을 반환한 것으로 생각됩니다.

SOCKS5 접속 요청

# 송신원→허니팟
05:01:00:01:GG:HH:II:JJ:KK:LL

SOCKS5의 CONNECT 요청은 VER CMD RSV ATYP DST.ADDR DST.PORT 형식을 가집니다. 이 6가지 항목은 각각 "버전", "명령 종류", "예약 영역 (RSV, 현재는 사용되지 않는 부분)", "목적지 지정 방식", "목적지 주소", "목적지 포트 번호"를 나타냅니다. IPv4 목적지인 경우, 각각의 의미는 다음과 같습니다.

05 = SOCKS version 5

• 01 = CONNECT (연결을 요청하는 명령)
• 00 = RSV. Reserved (예약 영역)로, 현시점에서는 의미를 갖지 않음
• 01 = ATYP (Address Type, 목적지 주소 유형)가 01이면 IPv4 주소 지정임을 나타냄
• GG:HH:II:JJ = 목적지 IPv4 주소
• KK:LL = 목적지 포트 번호 $p$. 16bit big-endian (2바이트의 수치를 큰 자릿수부터 나열하는 표기 방식)으로 표현됨

송신원은 허니팟을 경유하여 GG.HH.II.JJ:p로 접속을 시도하고 있습니다.

응답 페이로드(Payload) 해석 시 유의점

로그상에는 위의 05:00 / 05:ff 외에도, 05:00:00 및 05:09:…로 시작하는 응답도 기록되어 있었습니다. 당초에는 이러한 값들을 해석하기 위해 원래의 바이너리 로그를 확인해야 한다고 생각했습니다. 하지만 검증용으로 추출한 30초 분량의 샘플 데이터를 상세히 분석한 결과, 다음과 같은 사실을 알 수 있었습니다.

• 05:00:00은 스프레드시트 소프트웨어가 05:00 (2바이트)이라는 콜론 구분 문자열을 시간 값으로 자동 변환한 결과였습니다. 이번에 사용한 환경에서는 셀의 표시 형식(h:mm 및 h:mm:ss)에 변환 전 콜론 구분 숫자에 대응하는 단서가 남아 있었기에, 이를 바탕으로 기계적으로 복원할 수 있었습니다. RFC 1928상, 인증 방식 선택 응답은 VER METHOD의 2바이트 고정입니다. 따라서 적어도 "인증 방식 선택 응답"으로서의 05:00:00은 사양에 부합하지 않습니다. 이번 샘플에서는 스프레드시트 소프트웨어에 의한 시간 값 자동 변환이 원인임을 확인했습니다.
• 05:09:…은 바이트 길이와 필드 배치 측면에서 SOCKS5 CONNECT 응답 형식에 부합하는 10바이트 열이었습니다. 이 형식은 VER REP RSV ATYP BND.ADDR BND.PORT이며, 각각 "버전", "응답 결과", "예약 영역", "주소 유형", "서버 측에서 바인딩된 주소", "서버 측에서 바인딩된 포트"를 나타냅니다. 이번 REP 필드(응답 결과를 나타내는 1바이트)는 09였습니다. RFC 1928에서 정의된 REP 필드 값은 00~08이며, 09는 정의되지 않았습니다. 따라서 표준적인 SOCKS5 응답으로서의 의미는 단정할 수 없습니다. BND.ADDR/BND.PORT가 0.0.0.0:0인 점은 유효한 접속 정보가 반환되지 않은 상태와 일치합니다. 참고로, 이 09라는 값의 원인(허니팟 구현상의 독자적인 사양인지, 로그 변환 처리인지, 혹은 기타 요인인지)은 이번 관측 로그만으로는 단정하지 않았습니다.
• 콜론으로 구분된 바이트 열은 스프레드시트 소프트웨어에서 시간 값으로 자동 변환될 수 있습니다. 집계 시에는 문자열로 유지해야 합니다.

SOCKS4 접속 요청

# 송신원→허니팟
04:01:KK:LL:GG:HH:II:JJ:00

SOCKS4의 CONNECT 요청은 VN CD DSTPORT DSTIP USERID 형식입니다. SOCKS5와 달리 인증 방식 협상(Negotiation)이 없으며, 곧바로 접속 요청부터 시작됩니다.

• 04 = SOCKS version 4
• 01 = CONNECT
• KK:LL = 목적지 포트 번호
• GG:HH:II:JJ = 목적지 IPv4 주소
• 00 = USERID (사용자 식별자)의 종료 지점. 이번 로그에서는 내용이 비어 있었습니다.

이번 로그에서는 SOCKS5뿐만 아니라, 이 형식에 부합하는 통신도 일정 수 관측되었습니다. 이번 허니팟 구현에서는 SOCKS4 형식의 요청을 SOCKS4 프록시 요청으로 수락하지 않고, SOCKS5의 인증 방식 선택 응답인 05:ff를 반환했습니다.

HTTP CONNECT

# 송신원→허니팟
CONNECT GG.HH.II.JJ:p HTTP/1.1
Host: abcde.fgh

CONNECT는 HTTP 프록시(HTTP Proxy)에 대해 임의의 목적지 host:port로의 TCP 터널(TCP Tunnel) 확립을 요청하는 메서드(Method)입니다[9]. 따라서 이 통신은 허니팟(Honeypot)이 SOCKS 프록시뿐만 아니라 HTTP 프록시로서도 이용 가능한지 확인하려는 시도로 생각됩니다.

HTTP/1.1 200 Connection Established

등의 성공 응답은 확인되지 않았으며, CONNECT를 통한 중계가 성립되었다는 증적은 없습니다. 또한, 위의 예시에서는 CONNECT의 목적지가 IP 주소이고 Host 헤더가 도메인 이름으로 되어 있어 양자가 일치하지 않는데, 이는 검증용 샘플에서도 원본 데이터 그대로의 동작이며 마스킹(Masking)에 의한 차이가 아님을 확인했습니다. HTTP/1.1의 CONNECT에서는 요청 타겟의 authority(host:port)와 Host 헤더의 값은 통상적으로 일치해야 합니다. 따라서 이러한 불일치는 일반적인 웹 클라이언트(Web Client)와는 다른 동작 중 하나로 생각됩니다.

HTTP GET

# 송신원→허니팟
GET /check_3c29f...48e HTTP/1.1
Host: abcde.fgh
...

/check_<random>이라는 경로는 도달성 확인이나 프록시 체커(Proxy Checker) 유래의 통신일 가능성이 있습니다. 이 요청 라인(Request Line)은 GET /check_<random> HTTP/1.1이라는 형식(origin-form)이며, HTTP 프록시에 직접 보낼 때 전형적인 GET http://host/check_<random> HTTP/1.1이라는 형식(absolute-form)이 아닙니다. origin-form만으로는 프록시를 경유한 확인과 HTTP 서버로의 직접 액세스를 구별할 수 없기 때문에 추가적인 확인이 필요합니다. 검증용 샘플에서는 이 GET 요청이 SOCKS 네고시에이션(SOCKS Negotiation)이나 HTTP CONNECT를 전혀 거치지 않고, TCP 연결 직후의 첫 번째 애플리케이션 데이터(Application Data)로서 도착하는 것을 확인했습니다. 즉, 터널 내의 요청이 아니라 1080번 포트로 직접 던져진 것입니다. 허니팟은 이를 해석하지 못하고 05:ff를 반환하고 있습니다.

다만, 이 경로의 목적 그 자체(프록시 생존 확인인지, 다른 의도가 있는지)는 응답 내용에 의한 뒷받침이 없기 때문에 단정할 수 없습니다. 지금까지 언급한 세 가지 점——05:ff의 해석, 시간 변환 사고, 이 경로의 목적——은 모두 후술할 AI 비교 실험에서 다시 다루겠습니다.

관측 로그로부터 다음과 같은 특징이 확인되었습니다.

• 4월 20일의 관측 기간 전체에 걸쳐, 짧은 시간 동안 서로 다른 포트에서 다수의 접속 발생
• SOCKS4, SOCKS5, HTTP CONNECT, HTTP GET이 혼재
• HTTP GET으로 /check_<random>을 요청
• TCP 플래그(Flag)와 시계열을 확인한 범위 내에서, 애플리케이션 데이터 전송 후 짧은 시간 내에 FIN 또는 RST에 의해 연결이 종료됨

상황을 도식화하면 다음과 같습니다. 그림의 왼쪽이 송신원, 중앙이 당사 허니팟, 오른쪽이 송신원이 지정한 접속 대상입니다. 화살표는 "그러한 통신이 도착했다"는 것을 나타내는 것이며, 실제로 중계가 성공했음을 의미하지는 않습니다.

※ 상단의 /check_<random>에 대해서도 요청이 정상적으로 처리되었음을 나타내는 것은 아닙니다. 이 요청에 대해서는 HTTP로서의 응답이 아니라, 허니팟 구현에 의한 05:ff만이 관측되었습니다.

비교적 강하게 말할 수 있는 점은 다음과 같습니다.

• 짧은 시간 동안 다수의 송신원으로부터 SOCKS4/SOCKS5/HTTP CONNECT/HTTP GET을 섞은 통신이 도착하고 있으며, 이는 오픈 프록시(Open Proxy)로 이용 가능한 호스트를 탐색하는 동작과 일치합니다. AA.BB.CC., DD.EE.FF. 대역에서 오픈 프록시 탐색을 목적으로 한 통신이 송신되었을 가능성이 높다고 판단됩니다.

반면, 관측 로그만으로는 다음을 단정할 수 없습니다.

• 실제로 중계가 성공했는지 여부. SOCKS5 CONNECT 응답에서의 성공 코드(REP=00) 및 HTTP/1.1 200 Connection Established

확인되지 않았습니다.

• 허니팟(Honeypot)이 발판(踏み台, stepping stone)으로 지속적으로 악용되었다는 점.
• 허니팟이 요청된 목적지로 실제로 아웃바운드 연결(Outbound connection)을 시도했다는 점. 본 기사의 로그는 송신측/수신측 IP 주소를 스캔 주체인 IP 주소로 필터링하여 추출한 것입니다. 설령 허니팟이 요청된 목적지(필터 조건에 포함되지 않는 IP)로 연결을 시도했더라도, 그 통신 자체는 이 추출 데이터에 포함되지 않습니다. "로그에 없다"는 것이 "발생하지 않았다"는 증거는 될 수 없다는 점에 주의가 필요합니다.
• C2 통신인지 여부 또한 이번 관측 로그만으로는 단정할 수 없습니다. 기지의 C2 도메인/IP와의 일치, 멀웨어(Malware) 검체와의 관련성, 정기적인 비콘(Beacon) 특성, C2 프레임워크 고유의 URI나 User-Agent와 같은 근거는 확인되지 않았습니다. 따라서 본 기사에서는 C2라고 단정하지 않고, 주요 해석을 오픈 프록시(Open Proxy) 탐색으로 간주합니다.

여기까지는 사람이 직접 관측 로그를 해석하는 과정을 설명했습니다. 이제부터는 동일한 분석을 생성형 AI(Generative AI)에게 맡겼을 경우, 어디까지 올바르게 해석할 수 있는지 검증하겠습니다. 특히 주목한 점은 "로그를 통해 판단할 수 없는 것을 그럼에도 불구하고 단정해 버리지는 않는가" 하는 점입니다.

이번에 3가지 생성형 AI 모델(Claude Sonnet 4.6 [3], Claude Opus 4.8 [4], GPT-5.5 [6])을 사용하여, 동일한 패킷 로그를 두 가지 조건으로 분석시키는 실험을 수행했습니다. 조건은 페이로드(Payload) 열을 문자열 그대로 유지한 것(조건 S)과, 앞서 언급한 시각 변환 사고를 재현한 상태(조건 E)입니다. 각 모델 및 각 조건별로 5회씩 실행하여 총 30회의 결과를 미리 준비한 정답 데이터와 기계적으로 대조했습니다. 상세한 절차는 【보충】에 게재되어 있습니다.

참고로, GPT-5.4 mini [5]는 xlsx 파일을 화면 표시용 프리뷰로만 다룰 수 있어 610행 규모의 데이터를 정확하게 처리하지 못했기 때문에 비교 대상에서 제외했습니다. 이 검증은 당사 독자 GUI를 통해 수행되었으며, 모델 자체의 한계인지 GUI 측의 파일 처리 구현 방식에 의한 것인지는 구분할 수 없습니다. GPT-5.5 또한 동일한 독자 GUI를 통해 실행되었으므로(Claude 2 모델은 Anthropic 공식 채팅 화면을 사용), 이하에서 보고하는 GPT-5.5의 결과 역시 모델 자체의 성질인지 실행 경로의 차이에 의한 것인지를 완전히 구분할 수 없다는 점에 유의하시기 바랍니다.

본 비교는 각 AI 모델의 절대적인 우열을 나타내는 것이 아니라, 이번 조건하에서 관찰된 해석의 경향이나 한계를 보여주는 것입니다. 각 조건 5회라는 소규모 시행이므로, 이하에서 언급하는 차이는 모두 통계적인 우열이 아니라 이번 데이터와 실행 환경에서의 관찰 결과로 취급합니다(이하, 이 유의 사항은 생략합니다).

정답 데이터에는 관측 로그만으로는 본래 판단할 수 없어야 할 항목을 2가지 의도적으로 준비했습니다.

• 허니팟이 실제로 외부로의 연결을 시도했는지 여부
• /check_<random> 이라는 경로의 목적이 무엇이었는지

둘 다 정답은 "판단할 수 없음"입니다. 전자는 앞서 언급한 바와 같이 데이터가 필터링된 추출 데이터이기 때문이며, 후자는 /check_<random>에 대한 요청에 대해 허니팟으로부터 05:ff만이 반환되어 응답 내용에 의한 뒷받침이 없기 때문입니다.

30회의 실행 중 이 2가지 항목을 올바르게 보류(유보)할 수 있었던 횟수는 다음과 같습니다. 여기서 "단정한 횟수"는 "시도했다", "목적은 이렇다"와 같이 단정적으로 말한 경우와 "시도하지 않았다"와 같이 부정을 단정적으로 말한 경우를 모두 포함합니다.

3개 모델 모두 거의 모든 시행에서 "로그에 없다"는 것을 "발생하지 않았다"는 증거로 취급했습니다. 그럴듯한 추측을 확인된 사실인 것처럼 단정해 버린 것입니다. 모델 간의 성능 차이는 거의 보이지 않았습니다. 이 2가지 점에 대해서는 3개 모델이 동일한 맹점을 공유하고 있었다는 것이 이번 실험에서 가장 강력하게 나타난 결과입니다.

데이터의 유래나 범위에 제약이 있는 경우, 그 제약을 스스로 의심하는 것을 적어도 이번 3개 모델은 하지 않았습니다. 분석 대상 데이터가 어떤 조건으로 추출된 것인지를 명시적으로 전달하거나, "데이터에 없는 사실을 단정하지 마라"고 구체적으로 지시하는 등의 대책이 필요할 것으로 보입니다.

반면, 다음 2가지 점에는 모델 간의 차이가 있었습니다.

이번 5회씩의 시도에서는 Claude Opus 4.8과 Claude Sonnet 4.6에서 인증 판정을 잘못 내리는 답변이 GPT-5.5보다 더 많이 관찰되었습니다. 올바른 답변은 "SOCKS5로서 올바르게 네고시에이션(Negotiation)한 통신에서는 인증 방식으로서 No Authentication Required가 선택되어 있다"이지만, Opus 4.8은 10회 중 4회, Sonnet 4.6은 10회 중 3회, "일부 승인·일부 거부가 혼재함"이라고 오답했습니다. GPT-5.5는 이 실수를 한 번도 하지 않았습니다. 이는 거부 응답이 비(Non) SOCKS5 통신(SOCKS4나 HTTP 등)에 대한 것이라는 점을 간과한 결과입니다.

시간 변환 사고에 대한 대응도 3개 모델 간에 의견이 갈렸습니다.

올바른 2바이트로 복원하는 데 5회 중 5회 모두 도달한 모델은 없었습니다 (※ 소규모 시도, 이하 동일).

건수나 IOC(침해 지표) 등 사실로서 정답이 정해져 있는 항목에서도 정밀도에 차이가 있었습니다. 조건 S에서는 대체로 높은 정밀도를 보였으나, 조건 E(시간 변환 포함)에서는 3개 모델 모두 정밀도가 하락했으며, 하락하는 정도는 모델마다 달랐습니다 (구체적인 수치는 【보충】 참조). 또한, GPT-5.5는 당사 독자 GUI를 통해 실행되었으므로, 이 경로의 차이가 스코어 차이에 영향을 미쳤을 가능성을 완전히 배제할 수는 없습니다.

정답 데이터와 비교하지 않더라도, 답변 단독의 내부 모순에서 발견되는 실패도 있었습니다. GPT-5.5와 Claude Opus 4.8이 각각 1회씩, "어떤 바이트 열을 올바르게 디코딩하여 기재하고 있음에도 불구하고, 해당 종류의 건수를 0이라고 답변하는" 모순을 일으켰습니다. 이는 디코딩 능력과 그 결과를 집계에 반영하는 능력이 반드시 일치하지 않음을 보여줍니다.

여기까지 읽어주셔서 감사합니다.

앞으로도 허니팟(Honeypot)에서 관측·분석한 결과에 대해 계속해서 발신할 예정입니다. 질문이나 코멘트 기다리겠습니다.

[1] remote.it, SOCKS Proxies: What They Are and What They're Used For (https://www.remote.it/resources/understanding-socks-proxies/)

[2] nogawa.blog, SOCKS 프로토콜을 완전히 이해하기 (https://nogawa.blog/2026/05/09/socks-protocol-complete-guide-socks5/)

[3] anthropic.com, Claude Sonnet 4.6 (https://www.anthropic.com/news/claude-sonnet-4-6)

[4] anthropic.com, Claude Opus 4.8 (https://www.anthropic.com/news/claude-opus-4-8)

[5] openai.com, GPT 5.4 mini (https://openai.com/ja-JP/index/introducing-gpt-5-4-mini-and-nano/)

[6] openai.com, GPT 5.5 (https://openai.com/ja-JP/index/introducing-gpt-5-5/)

[7] IETF, RFC 1928: SOCKS Protocol Version 5 (https://www.rfc-editor.org/rfc/rfc1928)

[8] IETF, RFC 1929: Username/Password Authentication for SOCKS V5 (https://www.rfc-editor.org/rfc/rfc1929)

[9] IETF, RFC 9110: HTTP Semantics (https://www.rfc-editor.org/rfc/rfc9110)

본 절에서는 생성 AI를 사용한 자동 분석 절차와 그 평가 방법을 소개합니다.

※ AI의 출력은 비결정적(Non-deterministic)이므로, 본 절에서 소개하는 자동 분석 절차를 재현하더라도 본 절에서 제시하는 결과가 얻어지지 않을 가능성이 있습니다.

AI에게 비교·채점까지 시키면, 비교 대상인 모델 자신이 채점을 담당하게 되어 공정한 평가라고 할 수 없습니다 (자기 평가 편향 (Self-evaluation bias)). 그래서 이번에는 다음과 같은 설계로 진행했습니다.

• 반복 횟수: AI의 답변은 매번 동일하지 않을 수 있으므로, 각 모델 및 각 조건당 5회씩 실행하여 총 30회분의 결과를 수집했습니다. -
  답변 형식: 미리 항목을 정해둔 '답변 용지'(JSON 형식의 스키마)에 기입하도록 했습니다. 개수를 답하는 칸이 14개, 판단을 답하는 칸이 8개 있으며, 그 외에 IOC (Indicator of Compromise, 침해 흔적이 되는 IP 주소나 도메인 이름 등의 단서) 및 비표준값(사양상 정의되지 않은 값)을 작성하는 칸이 있습니다. -
  채점 방법: 미리 준비한 정답과 기계적으로 대조하여 자동 채점했습니다. 사람이나 AI에 의한 주관적 채점은 수행하지 않았습니다. -
  정답 생성 방법: 정답 데이터 작성 시에는 비교 대상에서 제외된 모델의 독립 분석을 참고 정보로 사용했습니다. 단, 최종적인 정답은 AI의 출력을 그대로 채택한 것이 아니라, RFC 1928의 기술 내용과 실제 바이트 열(Byte stream)의 길이를 사람이 대조하여 확정했습니다.

이상의 흐름을 도표로 정리하면 다음과 같습니다. 상단은 실제로 AI에게 분석을 시키는 흐름이며, 하단은 채점 기준이 되는 정답 데이터를 사전에 확정하는 흐름입니다. 양자는 우측 끝의 '자동 채점'에서 합류합니다.

분석 대상은 앞서 언급한 '관측 결과' 절에서 다룬 날(4월 20일)과는 다른 날(4월 21일)에 관측한 데이터입니다. 동일한 스캔 활동으로 보이는 통신이 다음 날에도 도착해 있었습니다. 그중에서 허니팟(Honeypot)이 30초 동안 송수신한 패킷 중, 송신측과 수신측의 IP 주소가 스캔 주체인 것들만 추출한 610건을 사용했습니다. 파일에 포함된 항목은 통신 시각, 송신측 국가, 송신측 IP 주소, 송신측 포트 번호, 페이로드 (Payload, 통신의 내용), 프로토콜 명, 수신측 IP 주소, 수신측 포트 번호, TCP 플래그 (TCP Flag, 통신의 상태를 나타내는 제어 정보)의 9개입니다.