[26년 2분기 | 인텔리전스 보고서] 글로벌 위협 인프라 동향

샌즈랩 위협 분석팀은 수집된 정보로 매분기 인텔리전스 보고서를 작성합니다.

전문 분석을 통해 파악한 악성코드의 특징과 위협 동향, 연관 정보 등을 공유해 안전한 사이버 환경을 만들어 가고자 합니다.

더 상세한 정보는 사이버 위협 인텔리전스 서비스 <CTX>에서 확인하실 수 있습니다.

1. 요약

지난 분기 보고서의 핵심은 단순 IOC 목록을 넘어서는 것이었다. IP와 도메인은 빠르게 바뀌지만, 공격 인프라를 운영하는 과정에서 반복적으로 남는 메타데이터는 더 오래 유지된다. 인증서, port, URI, ASN, 시간대, C2 통신 구조는 단순 차단 목록보다 긴 수명을 갖는 단서다. 이 보고서는 그 문제의식을 이어받아, 공격자가 어떤 인프라를 선택하고 어떤 방식으로 운영하는지에 더 초점을 맞췄다.

2분기 자료도 그 연장선에 있다. 위협 인프라는 사라진 것이 아니라, 정상 서비스의 경계 안으로 더 깊게 들어왔다. ClearFake와 ClickFix는 Cloudflare와 주요 Cloud/Shared 호스팅 환경에서 대량으로 탐지됐고, 오래된 도메인과 침해된 웹 자산을 이용해 평판 기반 차단을 우회했다. 여기서 중요한 점은 특정 provider를 악성으로 단정하는 일이 아니다. 방어자가 실제로 마주한 문제는 정상 업무 트래픽과 악성 캠페인 흔적이 같은 서비스 환경 안에 섞여 있을 때, 무엇을 근거로 둘을 갈라낼 것인가다.

수명 주기를 봐도 같은 결론에 도달한다. 전체 IoC의 수명주기 중앙값은 짧지만, 모든 위협이 짧게 끝나는 것은 아니다. 어떤 IoC는 탐지 직후 소모되고, 어떤 캠페인은 탐지된 뒤에도 오래 남거나 active/dead 상태를 반복한다. 결국 핵심 질문은 "얼마나 많이 보였는가"가 아니라 "지금도 보안 대응 범위 안에 남아 있는지, 다시 살아날 가능성이 있는지, 같은 Infrastructure fingerprint를 반복하는가"다.

그래서 보고서의 중심은 특정 공격 도구가 아니다. 더 의미 있는 축은 공격자가 어떤 인프라 provider를 어떤 역할로 반복 선택했는가다. Cloudflare는 악성 페이로드와 리다이렉트가 정상 CDN 안에 섞이는 대표 사례였고, Hostinger, Hetzner, Railnet, Namecheap 계열은 페이로드 전달과 Active C2/backend 대응이 필요한 인프라로 나타났다. Alibaba, Tencent, Yancy 계열 ASN은 C2/framework 성격의 위협 태그가 높은 비중으로 몰려 있었다. 단순히 탐지 양을 비교하는 것보다 인프라 제공자별 악용 역할과 대응 우선순위를 구분해 보는 편이 더 큰 인텔리전스 가치를 제공한다.

Provider 선택은 결국 C2 운영 방식의 문제로 이어진다. 공격자는 C2를 하나의 서버에 몰아넣기보다 페이로드 전달, 설정 값 제공, 명령 제어, 업로드/유출, 대체 경로 후보 역할로 나누고, 각 역할에 맞는 서비스를 선택한다. CDN과 오래된 도메인은 접근성과 평판 은닉에, self-service 호스팅은 빠른 교체와 페이로드 전달에, 특정 지역권 Cloud ASN은 핵심 제어 인프라 측면에 더 자주 활용됐다.

Analyst's Pick으로 선정한 북한 연계 행위자의 개발자 대상 JavaScript C2 사례는 이 흐름을 가장 선명하게 보여준다. 이 사례에서 중요한 것은 특정 IP 하나가 아니다. 개발자 업무 신뢰 체인, SaaS 기반 설정 값 전달 구간, Socket.IO/WebSocket 제어 채널, 업로드/유출 채널이 하나의 작전 구조로 연결된다는 점이다. 특히 validation 헤더와 호스트 메타데이터 필드, Node.js 의존성 조합은 서버가 바뀌어도 남을 수 있는 C2 특성이며, 파일 탐지와 네트워크 패킷 탐지로 전환할 수 있는 근거다.

보고서의 목표는 수집된 위협 단서를 방어자가 실제로 운용할 수 있는 기준으로 바꾸는 데 있다. 즉시 차단할 수 있는 Active C2/backend와 캠페인 증거 기반 IoC는 빠르게 분리하고, 클라우드/CDN/공유 호스팅처럼 업무 영향이 큰 IOC는 검토 대상으로 관리해야 한다. ASN/Provider 프로파일, C2 운영 모델, URI/header, SPKI/ASN_Port, File artifact는 장기 헌팅 시그널로 남기는 편이 좋다. 분석의 의미는 변화하는 인프라 속에서도 방어자가 실제로 운용할 수 있는 탐지 논리를 분리해 내는 데 있다.

2. 개요

인텔리전스 보고서가 실제 방어에 도움이 되려면, 수집된 IoC를 그대로 나열하면 안 된다. 이미 무력화된 엔드포인트를 많이 아는 것보다 중요한 것은 공격자가 인프라를 어떤 방식으로 구성하고, 어떤 서비스를 반복해서 선택하며, 어떤 흔적을 남기는지다.

이번 보고서는 2026년 3월 1일부터 6월 15일까지 수집된 59,833 건의 IOC를 기반으로 작성했다. 분석 기준은 단일 IoC 가 아니다. 인프라 제공자, ASN, 국가, 위협 태그, URI 경로, 포트, TLS/SPKI fingerprint, 수명주기, 클러스터 증거를 분석하였다.

데이터 기준으로 위협 인프라는 두 방향으로 갈라진다. 한쪽에는 즉시 차단해야 하는 Active C2/backend와 페이로드 전달 인프라가 있다. 다른 한쪽에는 정상 서비스와 섞여 있어 인프라 제공자 단위로 막기 어려운 공유 인프라 악용이 있다. 이 둘을 같은 방식으로 처리하면 방어 정책의 신뢰성이 훼손된다. 차단리스트로 적용하면 업무 영향도가 커지고, 검토로만 두면 실제 Active C2를 놓친다.

그래서 수집량보다 방어 의사결정에 필요한 기준을 우선한다. 지금 살아 있는지, 다시 살아날 수 있는지, 정상 서비스와 얼마나 섞여 있는지, 같은 fingerprint를 반복하는지, 공격자가 어떤 인프라 제공자와 C2 운영 모델을 선호하는지를 기준으로 위협 인프라를 다시 나눈다. 이후 장에서는 인프라 분포, 인프라 제공자별 악용 양상, 공격자가 선호하는 C2 운영 방식, 운영 시간, 탐지 회피 패턴, SPKI 기반 캠페인 연결, Analyst's Pick, 그리고 실행 가능한 방어 산출물을 순서대로 다룬다.

3. 26년 2분기 생태계 현황

3.1. 정상 서비스 안으로 들어온 공격 인프라

공격 인프라는 저 신뢰 호스팅 환경에만 머물지 않았다. 오히려 방어자가 함부로 차단하기 어려운 정상 서비스 환경 안으로 들어왔다. Cloudflare와 주요 Cloud/Shared 호스팅은 페이로드 전달, 리다이렉션, 캠페인 전개에 반복적으로 악용됐고, 이 때문에 방어자의 질문도 바뀌어야 한다. 이제 문제는 "많이 보이는 인프라 제공자를 막을 것인가"가 아니라 "정상 서비스 안에 섞인 악성 캠페인을 어떻게 구분할 것인가"다.

그 중심에는 CLOUDFLARENET이 있다. ASN-role/Tag 기준 IOC 26,213 건으로 인프라 Provider 중 가장 큰 비중을 차지했고, 그 안에서 ClearFake 18,644건(71.1%), ClickFix 2,081건, Vidar 1,108건이 반복적으로 확인됐다. ASN-role 기준으로도 Payload delivery 22,549건(86.0%)이 핵심 역할이었다. 이 숫자는 Cloudflare를 공격 기반으로 단정하는 근거가 아니다. 정상 서비스와 악성 Delivery 인프라가 같은 공유 인프라 안에 공존하고 있다는 경고에 가깝다.

따라서 Cloudflare 관련 IOC는 Blocklist보다 Shared infra review list에 두는 편이 현실적이다. URI, Host 헤더, 인증서, 위협 태그, 최신 상태를 함께 보면서 탐지 조건을 좁혀야 한다. 대규모 인프라 제공자 단위 차단은 오탐으로 인한 장애가 발생한다.

3.2. ClearFake와 ClickFix는 탐지 이후에도 남아 있다

ClearFake와 ClickFix는 가장 많이 보인 캠페인이지만, 단순히 볼륨이 큰 사례로만 보면 중요한 지점을 놓친다. 이들은 공유 인프라와 노후화된 도메인을 활용해 탐지 이후에도 상당 기간 대응 범위 안에 남았다. 한번 차단하고 끝낼 대상이 아닌, 계속 상태를 확인하고 과거 로그를 되짚어야 하는 유형에 가깝다.

분기 전체 태그 기준으로 ClearFake는 15,535건, ClickFix는 10,648건이었다. ClearFake는 Active 9,993건, Active ratio 64.33%였고, ClickFix는 Active 8,123건, Active ratio 76.29%였다. MTTD(Mean Time To Death)도 각각 Median 1,289시간, 1,489.7시간으로 길다. 이 수치는 두 캠페인이 탐지된 뒤에도 대응 대상에서 쉽게 사라지지 않는다는 뜻이다. 따라서 ClearFake/ClickFix는 일회성 IoC 폐기보다 공유 인프라 검토, 살아있는 도메인/URI 재검증, 인증서와 URI 구조를 결합한 사후 검토형 헌팅으로 관리해야 한다.

3.3. 죽는 것은 IoC이고, 남는 것은 fingerprint다

수명주기는 가장 조심해서 읽어야 할 지표다. 전체 수명주기 중앙값은 약 0.35일로 짧다. 이 숫자만 보면 대부분의 IoC가 금방 의미를 잃는 것처럼 보인다. 하지만 같은 기간 SPKI 재사용률은 40.47%였고, 전략적 헌팅 시그니처 128건 중 115건이 SPKI 기반이었다. 엔드포인트는 빨리 사라지지만, 인증서와 배포 흔적은 반복된다는 뜻이다.

방어 관점에서는 이 둘을 분리해야 한다. IP와 도메인 기반 차단리스트는 TTL을 짧게 가져가고, SPKI와 통신 패턴, URI, 헤더 조합은 장기 헌팅 신호로 남겨야 한다. 핵심은 IoC는 빨리 죽지만 Infrastructure fingerprint는 오래 남는다는 점이다.

3.4. 공격 도구보다 인프라 선택이 더 많은 것을 말해준다

데이터는 "어떤 공격 도구가 많았는가"보다 "어떤 인프라 제공자가 어떤 역할로 반복 악용됐는가"를 더 선명하게 보여준다. Cloudflare는 페이로드 전달과 리다이렉트가 정상 CDN 안에 섞이는 리뷰 대상이고, Hostinger와 Namecheap은 ClickFix 중심 페이로드 전달이 차단리스트로 많이 전환되는 인프라 Provider다. Hetzner와 Railnet은 페이로드 전달과 botnet/C2 역할이 섞인 현재 대응이 필요한 대상이고, Alibaba/Tencent/Yancy 계열은 C2/framework 태그가 특정 ASN에 집중되는 핵심 운영 인프라로 나타난다.

이 관점에서는 개별 도구도 독립 주제가 아니라 인프라 제공자별 악용 양상을 설명하는 단서로만 다룬다. 예를 들어 Yancy Limited는 botnet_cc role 100%에 가깝고 C2/framework 태그가 96.2%를 차지했으며, Hangzhou Alibaba와 Shenzhen Tencent 역시 botnet_cc role이 대부분이고 C2/framework 성격의 태그가 높게 몰렸다. 반대로 Cloudflare, DigitalOcean, Vultr, Amazon은 정상 서비스와 악성 캠페인이 혼재된 공유 인프라 대상으로 다뤄야 한다. 핵심 헌팅 축은 도구가 아니라 ASN/인프라 Provider 역할, 태그 집중도, 활성 상태, 악용 양상의 결합이다.

3.5. C2는 서버가 아니라 운영 모델로 봐야 한다

C2 인프라는 하나의 서버가 모든 기능을 수행하는 방식보다 역할 분리형 운영에 가깝다. 페이로드 전달, 리다이렉션, 설정값 제공, 명령 제어, 업로드/유출, 대체 경로 후보가 서로 다른 인프라 환경에 배치된다. 공격자는 각 기능에 맞는 서비스를 고르고, 방어자는 그 조합을 하나의 C2 운영 모델로 읽어야 한다.

이 모델에서 Cloudflare와 오래된 도메인은 정상 서비스의 신뢰도를 이용한 은닉과 페이로드 전달에, Hostinger, Namecheap, Hetzner, Railnet은 페이로드 전달과 활성화된 서버에, Alibaba/Tencent/Yancy 계열은 C2/framework 집중도가 높은 핵심 제어 인프라에 더 가깝다. 북한 JavaScript C2 사례 역시 Vercel 설정값 전달, Git hook/precommit 설정, 터미널/API 연결 구간 후보, Socket.IO/WebSocket 기반 제어 채널, 업로드/유출 채널이 분리되어 있어 같은 운영 논리를 질적으로 보여준다.

3.6. 분석가 선정 사례: 개발자 업무 흐름과 C2의 연결

Analyst's Pick은 대량으로 확인된 캠페인이 아니다. 수량만 보면 앞선 대형 캠페인보다 작다. 그럼에도 이 사례를 별도로 봐야 하는 이유는 개발자 업무 흐름이 C2 운영 구조와 직접 연결되기 때문이다. 정상 개발 환경, SaaS 기반 설정 값 전달, Git hook/precommit 흐름, 터미널/API 연결 구간 후보, 샘플에서 확인된 C2 백엔드가 하나의 공격 경로로 이어질 수 있음을 보여준다.

Cluster 2046은 46개의 IoC, 76개의 활성기록, 4개의 SPKI로 구성되며, 희소한 태그는 북한 관련 태그, ‘contagiousinter view’, ‘lazarus’, ‘web3-targeting’, ‘novara1o1’에 집중된다. Vercel 기반 OS별 설정값 전달 엔드포인트, ‘precommit.ver cel.app’ Git hook/precommit config, ‘lab99.sbs /api/terminal/*’ 터미널/API 연결 구간 후보, ROUTERHOSTING 기반 백엔드 pivot 후보, 그리고 정적 분석으로 확인된 ‘216.126.225.243:8087’ Socket.IO/WebSocket 기반 제어 채널 및 ‘8085 /8086’ 업로드/유출 채널을 역할별로 분리해 해석할 수 있다. 이 사례의 핵심은 IOC 자체보다 C2 통신 방식과 역할 분리다.

4. 인프라 분포와 제공자별 악용 양상

4.1. 특정 제공자에 IoC가 몰리는 데는 이유가 있다

인프라 제공자 분포는 단순한 점유율 순위가 아니다. 공격자가 정상 서비스의 신뢰도와 운영 편의성을 어디에서 얻고 있는지 보여주는 단서에 가깝다. 상위권에는 Cloudflare 같은 CDN/공유 인프라, DigitalOcean/Vultr/Amazon 같은 퍼블릭 클라우드, Hostinger/Namecheap 계열 셀프서비스형 hosting, Hetzner/Railnet/ Yancy/Alibaba/Tencent 계열 VPS와 지역권 클라우드 ASN이 함께 나타난다. 같은 IoC라도 어느 제공자에서 확인됐는지에 따라 차단, 검토, 헌팅의 기준이 달라져야 한다.

[표 1] 상위 인프라 제공자별 IOC 분포

[그림 1] ASN 기준 상위 인프라 제공자별 위협 유형 구성

Cloudflare의 압도적 비중은 직접 차단 후보가 많다는 뜻이 아니다. 오히려 정상 서비스와 악성 캠페인이 같은 인프라 안에 섞이는 범위가 커졌다는 신호에 가깝다. 별첨의 shared infra review list는 32,448건이며, 이 중 CLOUDFLARENET만 26,209건이다. 따라서 방어 정책은 많이 보이는 ASN을 막는것이 아니라 많이 보이는 공유 인프라 안에서 악성 캠페인 근거를 좁혀내는 것에 가까워야 한다. Cloudflare, DigitalOcean, Vultr, Amazon 계열은 제공자 단위 차단보다 Host 헤더, URI, 인증서, 태그, 활성 상태를 결합한 정밀 검토가 우선이다.

4.2. ASN과 태그를 함께 보면 역할이 보인다

ASN과 태그의 결합은 특정 제공자를 악성으로 단정하기 위한 지표가 아니다. 같은 인프라 제공자 안에서 어떤 캠페인 또는 C2 성격의 활동이 반복되는지 확인하고, 그 조합을 차단/검토/헌팅 기준으로 바꾸기 위한 분석 축이다. 비율이 높은 조합일수록 공격자가 해당 인프라의 특성을 반복적으로 활용하고 있을 가능성이 크다. 가장 강하게 확인된 ASN-태그 결합은 다음과 같다. 여기서 비율은 전체 IOC 대비 비중이 아니라, 해당 인프라 제공자 전체 IOC 중 특정 태그가 차지하는 비중이다.

[표 2] 주요 ASN-태그 결합과 비율

[그림 2] 주요 ASN-태그 결합 집중도

중요한 것은 개별 도구명이 아니라 결합의 방향이다. Cloudflare에서는 ClearFake, ClickFix, Vidar가 같은 CDN/공유 인프라 안에서 반복되고, Hostinger와 Namecheap에서는 ClickFix 중심의 페이로드 전달 성격이 강하게 나타난다. Yancy, Hangzhou Alibaba, Shenzhen Tencent의 cobaltstrike 태그 집중은 특정 도구 하나의 문제라기보다 C2/framework 성격의 활동이 일부 ASN에 몰리는 신호로 읽는 것이 타당하다. 이런 조합은 제공자 단위 차단 여부를 단독으로 결정하기보다 SPKI, port, TLS 활성 상태, URI/Host 정보를 결합한 헌팅 조건으로 전환하는 것이 타당하다.

4.3. 제공자별 악용 방식은 서로 다르다

같은 IoC라도 CDN/공유 인프라, 셀프서비스형 호스팅, 클라우드별 리젼, VPS 사업자 중 어디에 위치하느냐에 따라 방어 방식이 달라진다. 이 절에서는 상위 인프라 제공자를 공격자가 활용한 특성에 따라 묶고, 차단/검토/헌팅 기준을 분리한다. ASN/인프라 제공자는 단순 소유자 정보가 아니라 공격자가 선택한 운영 인프라로 해석해야 한다.

[표 3] 인프라 제공자별 악용 유형과 대응 기준

특정 인프라 제공자를 악성 사업자로 단정하기 위한 것이 아니다. 인텔리전스 관점에서 중요한 것은 "공격자가 어떤 제공자 특성을 반복적으로 활용했는가"다. 무료 체험/크레딧 제공 여부, 셀프서비스 가입 절차, 악용 신고 처리 속도, KYC 수준, CDN/프록시 기능, VPS 생성 자동화 가능성은 OSINT로 별도 확인해야 할 보강 정보다. 공개 약관상 대부분의 사업자는 악용을 금지하므로 쉽게 결론 내릴 순 없다.

[그림 3] 상위 인프라 제공자별 위협 유형 분포

4.4. C2 운영은 기능별로 나뉘어 움직인다

여기서 더 중요한 질문은 어떤 C2가 있었는지가 아니라 공격자가 C2를 어떤 방식으로 운영했는가이다. 확인된 패턴은 단일 C2 서버 중심이 아니라 역할 분리, 평판 은닉, 빠른 교체, 재사용 fingerprint를 결합한 운영 모델에 가깝다. 아래 항목은 공격 절차를 재현하기 위한 설명이 아니라, 방어자가 보안 로그와 네트워크 기록에서 식별해야 할 운영 흔적이다.

[표 4] C2 운영 방식별 확인 신호와 방어 가치

이 관점에서 공격자가 선호하는 방식은 숨기기 쉬운 환경에서 페이로드를 전달하고, 교체하기 쉬운 인프라에서 운영하며, 필요한 경우 특정 ASN/지역에 핵심 제어 기능을 집중시키는 구조로 요약된다. 따라서 방어자는 IOC 차단, 공유 인프라 정밀 검토, ASN/인프라 제공자 모니터링, SPKI/URI/헤더 기반 헌팅을 서로 다른 업무로 나누지 말고 하나의 C2 운영 모델 안에서 연결해야 한다.

4.5. 국가보다 중요한 것은 인프라의 역할이다

국가별 분포에서는 미국이 9,010건으로 가장 많고, 독일 2,577건, 네덜란드 2,300건, 중국 1,995건, 홍콩 1,797건이 뒤따른다. 다만 국가 분포는 공격자 귀속 근거가 아니라 인프라 역할을 분리해 보기 위한 기준으로 해석해야 한다. 미국은 Other/ Uncategorized 6,644건과 Core C2 Framework 1,798건이 동시에 나타나며, 정상 클라우드 트래픽과 악성 캠페인이 섞인 대규모 공유 클라우드 환경에 가깝다. 중국과 홍콩은 Core C2 Framework 비중이 각각 54.84%, 56.59%로 높아, 단순 트래픽 양보다 핵심 제어 역할 측면에서 주목할 필요가 있다. 싱가포르 역시 Core C2 Framework 47.8%로 높은 편이다.

[그림 4] 국가별 인프라 역할 누적 분포

[그림 5] 국가별 인프라 역할 집중도

5. 수명주기: 빨리 사라지는 IOC와 오래 남는 흔적

5.1. 짧게 소모되는 IOC와 오래 남는 IOC는 구분해야 한다

전체 IOC 수명 중앙값은 약 0.35일이고, 평균 수명은 약 5.54일이다. 이 수치만 보면 대부분의 IOC가 매우 빠르게 소모되는 것처럼 보인다. 그러나 태그별 MTTD(Mean Time To Death) 를 나눠 보면 이야기가 달라진다.

[표 5] 주요 태그별 수명주기와 Dead 비율

[그림 6] 주요 태그별 MTTD와 활성 상태 분포

ClearFake, ClickFix, StrelaStealer, QuasarRAT는 장기 생존형에 가깝고, Mozi, Kimwolf, Aisuru, Metasploit은 단기 소모형 또는 탐지 직후 무력화되는 성격이 강하다. C2 프레임워크 계열 일부는 중앙값이 짧아도 예외적으로 오래 살아남는 개체가 있어 평균 수명을 크게 끌어올린다. 따라서 수명 중앙값만 보고 IoC를 폐기하기보다, SPKI와 인프라 fingerprint가 반복되는지 확인해 장기 헌팅 대상으로 남겨야 한다.

5.2. 노후화된 도메인은 차단을 어렵게 만든다

도메인 생성 시점을 기준으로 보면 19,032개 기록 중 오래된 도메인에 해당하는 Aged ( >1y )가 13,550건으로 가장 많고, Intermediate 3,144건, Fresh (0-1d) 2,338건이 뒤따른다. 고유 도메인 기준으로는 9,516개가 확인됐다.

[표 6] 도메인 생성 시점 기준 분포

[그림 7] 도메인 생성 시점과 악성 활동 시점 간 분포

이 분포에서 먼저 봐야 할 것은 Fresh (0-1d)가 적지 않다는 사실이 아니라, Aged ( >1y )가 전체의 71.2%를 차지한다는 점이다. 신규 등록 도메인은 여전히 초기 차단과 경보 우선순위에 유효하지만, 이 데이터에서는 악성 활동의 중심이 신규 도메인에만 있지 않았다. 기록 기준 19,032건 중 13,550건이 생성 후 1년이 지난 도메인이었고, 고유 도메인 기준으로도 6,775개가 Aged 구간에 속했다. 따라서 도메인 생성일만으로 위험도를 낮게 보는 정책은 ClearFake, ClickFix 같은 대량 캠페인을 놓칠 수 있다.

상단 분포를 보면 1일 이하 Fresh 구간에도 뚜렷한 막대가 있지만, 더 큰 무게중심은 오른쪽의 오래된 도메인 구간에 있다. 특히 10,000일을 넘는 기록도 8,660건으로 전체의 45.5%를 차지한다. 이는 공격자가 항상 새 도메인을 등록해 인프라를 만드는 것이 아니라, 오래 유지된 정상 도메인, 침해된 웹 자산, 또는 오래된 상위 도메인 하위의 경로와 서브도메인을 악용할 수 있음을 보여준다. 이런 경우 도메인 평판이나 생성일 기반 필터만으로는 악성 페이로드 전달과 redirect를 안정적으로 걸러내기 어렵다.

태그별 분포도 같은 결론을 뒷받침한다. ClearFake는 5,908개 고유 도메인에서 생성 후 경과 기간 중앙값이 11,494일이었고, 기록 기준 81.1%가 Aged 구간에 속했다. ClickFix 역시 1,029개 고유 도메인에서 중앙값 1,153일, Aged 비중 69.3%로 나타났다. StrelaStealer, QuasarRAT, RemcosRAT도 오른쪽으로 긴 분포를 보이며 오래된 도메인 악용 경향이 확인된다. 반면 Vidar나 CobaltStrike 일부는 상대적으로 중간 구간에 더 많이 걸쳐 있어, 도메인 생성 시점은 캠페인별로 다르게 해석해야 한다.

결국 이 차트의 의미는 "오래된 도메인은 안전하다"는 가정을 버려야 한다는 데 있다. 신규 도메인은 빠른 차단 후보로 관리하되, 오래된 도메인은 신뢰 대상으로 자동 분류하지 말고 URI, Host 헤더, 리다이렉트 구조, 태그, 인증서, 인프라 제공자 정보를 결합해 검토해야 한다. 특히 ClearFake와 ClickFix처럼 정상 웹 리소스처럼 보이는 경로를 사용하는 캠페인에서는 실제 요청 경로와 캠페인 흔적이 더 중요한 판단 기준이 된다.

5.3. 활성 상태 변화는 재등장 가능성을 보여준다

활성 상태 데이터에서는 태그 확장 기록 기준 [D]Unstable 32,054건, [E]Mixed 16,122건, [C]Heartbeat 12,560건, [A]AlwaysOn 12,145건, [B]OfficeWorker 613건이 확인됐다. 즉 위협 인프라는 항상 켜져 있는 형태보다 활성/비활성 상태가 반복되는 불안정형 또는 혼합형이 더 많다. 활성/비활성 전환이 큰 태그로는 Tofsee, WordPress, EtherHiding, Polygon, compromised, Vidar, ClickFix가 나타난다. ClickFix는 10,261개 기록에서 평균 전환 횟수 14.29, 중앙값 15.0을 보였다. 이는 단순 네트워크 오류라기보다 침해된 웹 인프라와 공유 호스팅 환경에서 활성/비활성 상태가 반복되는 운영 특성으로 해석하는 편이 자연스럽다.

[그림 8] 태그별 활성 상태 변화와 수명주기 패턴

6. 탐지 회피와 통신 패턴

6.1. 포트를 바꿔 쓰는 방식도 운영 흔적이다

전체 포트 분석에서는 전체적으로 포트 재사용률이 95.91%로 높았다. 다만 일부 태그에서는 비표준 포트를 넓게 바꿔 쓰는 양상이 뚜렷했다. 단순히 "어떤 포트를 썼는가"보다 "얼마나 자주 바꾸며 운영했는가"가 더 중요한 지점이다.

[그림 9] 태그별 고유 포트 수와 비표준 포트 비중

[표 7] 태그별 비표준 포트 사용 양상

위 차트는 1:1 기준선을 중심으로 봐야 한다. 기준선 오른쪽에 있는 태그는 표준 포트보다 비표준 포트를 더 자주 사용한 경우다. aisuru는 표준 포트 대비 96.00배, tofsee는 84.67배, kimwolf는 80.67배로 나타나며, metasploit, antidot, vshell, adaptixc2도 비표준 포트 의존도가 높다. 이 유형은 포트 80/443 중심의 웹 트래픽 검토만으로는 충분하지 않다. 방화벽, Proxy, NDR에서 외부로 나가는 비표준 포트 연결과 프로토콜 불일치, 신규 ASN/포트 조합을 함께 봐야 한다.

[그림 10] 태그별 고유 포트 사용 비율

해당 차트는 비표준 포트 비중과 고유 포트 수를 함께 보여준다. 오른쪽 위에 위치한 mozi, vshell, metasploit, adaptixc2는 비표준 포트 비중도 높고 포트 폭도 넓다. 특히 mozi는 표준 포트 기록이 없어 이전 배율 차트에서는 산정하기 어렵지만, 산점도에서는 536개 IoC가 모두 비표준 포트에 있고 고유 포트 수도 517개로 확인된다. 이 경우 특정 포트 하나를 차단하는 방식보다 태그, ASN, 프로토콜, 연결 방향, 반복되는 포트 생성 패턴을 함께 보는 편이 맞다.

반대로 cobaltstrike, remcosrat, asyncrat, quasarrat는 조금 다르게 읽어야 한다. 이들은 비표준 포트 비중만 보면 vshell이나 metasploit보다 낮지만, 고유 비표준 포트 수는 많다. cobaltstrike는 4,240개 IOC 중 1,737개가 비표준 포트였고 고유 비표준 포트도 228개였다. remcosrat도 771개 비표준 포트 IOC와 377개 고유 비표준 포트를 보였다. 즉 이들은 비표준 포트를 주 경로로만 쓰는 유형이라기보다, 표준 포트와 비표준 포트를 함께 운용하면서 인프라를 넓게 흩뜨리는 C2/프레임워크 계열로 보는 편이 자연스럽다.

clearfake, clickfix, strelastealer, vidar처럼 대량으로 확인된 태그는 산점도 하단에 몰려 있다. 이들은 포트 기준으로는 80/443 등 표준 웹 포트에 강하게 붙어 있고, 비표준 포트 비중은 낮다. 따라서 이 계열을 포트 중심으로 탐지하려 하면 차별성이 약해진다. 앞 절에서 본 오래된 도메인, 정상 웹 리소스처럼 보이는 URI, Host header, 인증서, redirect 구조가 더 중요한 헌팅 축이다.

결국 포트 분석의 결론은 태그마다 대응 기준이 다르다는 것이다. 비표준 포트 우세형은 방화벽, Proxy, NDR 로그에서 우선 점검하고, 허용 정책에 없는 외부 목적지/포트 조합은 차단 또는 경보 후보로 관리해야 한다. 포트 범위가 넓은 C2/framework 계열은 ASN+포트, SPKI, 프로토콜 특성을 장기 헌팅 신호로 남겨야 한다. 반대로 표준 포트에 머무는 페이로드 전달 계열은 포트가 아니라 웹 요청 구조와 인프라 맥락으로 좁혀야 한다.

6.2. URI 패턴은 캠페인의 성격을 드러낸다

URI 무작위성 분석에서는 Glassworm, CalendarC2, MaskgramStealer, ClearFake, AmadeyBot, FakeAdobe, Stealc, FakeZoom 등이 높은 값을 보였다. Glassworm은 평균 엔트로피 4.511, 중앙값 4.634로 가장 높았고, 무작위성이 높은 경로를 이용해 정적 시그니처 탐지를 피하려는 성격이 강하다. 반대로 Mozi는 평균 엔트로피 1.004, Formbook은 2.253, C2 프레임워크 계열 일부는 2점대 후반으로 낮았다. 낮은 엔트로피는 무작위성이 낮다는 뜻이지만, 정상 리소스처럼 보이는 짧고 단순한 URI를 반복해 휴리스틱 탐지를 피할 수 있다. 상위 반복 URI는 다음과 같다.

[표 8] 주요 반복 URI와 캠페인 태그

[그림 11] URI 엔트로피 기반 캠페인별 경로 패턴

7. 지속성: 바뀌는 IoC 사이에서 남는 연결고리

7.1. SPKI는 흩어진 캠페인을 다시 묶어준다​

위협 인텔리전스의 주요 목적 중 하나는 단일 침해지표의 평면적 차단을 넘어, 표면적으로 무관해 보이는 인프라 간의 연관성을 메타 데이터 기반으로 군집화하여 선제적 방어 체계를 구축하는 데 있다. 본 사례 연구에서는 2026년 1분기 수집된 위협 인프라 중 가장 큰 군집을 형성한 특정 CobaltStrike 연관 단일 인증서 공개키 해시(SPKI: 6691ce9450b4eb3d35709bbefaa63e3819c8940e8a7db70e796070e3d5cb5c93) 클러스터를 분석 대상으로 선정했다. 초기 식별된 84개의 기본 지표를 바탕으로 포트 및 프로토콜 분기 상태를 반영한 최종 데이터셋을 구성하여 확장 분

[표 9] 주요 SPKI 클러스터와 분산 특성

여기서 중요한 점은 규모가 큰 클러스터와 분산도가 큰 클러스터를 구분해야 한다는 것이다. 단일 인프라 제공자에 집중된 클러스터는 서브넷 또는 제공자 단위 대응이 가능할 수 있지만, 여러 ASN과 국가로 분산된 캠페인은 IP 차단만으로 대응하기 어렵다. SPKI, ASN 이동, 포트, 활성 상태를 결합한 헌팅 신호로 운용해야 한다.​

[그림 12] SPKI 기반 캠페인 클러스터 분포

7.2. 전략 헌팅은 오래 남는 특징 값에서 시작

별첨 기준 전략적 헌팅 시그니처는 총 128건이며, 이 중 SPKI가 115건, ASN+포트가 13건이다. 우선순위는 medium 73건, high 46건, critical 9건으로 구성된다. critical 우선순위 SPKI 중 가장 주목할 항목은 ‘6691ce9450b4eb3d35709bbefaa63 e3819c8940e8a7db70e796070e3d 5cb5c93’이다. 이 SPKI는 101개 고유 IP, 111회 사용, 105.1일 지속 기간을 보였고, 주요 ASN은 Railnet LLC, AROSS-AS, Biil Ru Ltd 등으로 나타났다. 또 ‘9ef15a1ce89f8df6b8fed558a36547e5205501e6b21fe 5b00790e4716a3bd248’는 Kimsuky/Xworm/Remcos 관련 태그와 함께 22개 고유 IP, 31회 사용, 97.1일 지속 기간으로 critical 우선순위에 올랐다.

이 장의 결론은 단순하다. IP와 도메인은 빠르게 바뀌지만 SPKI와 배포 fingerprint는 반복된다. 따라서 전략적 헌팅 목록은 차단 목록보다 긴 수명으로 운영하고, TLS 검사 또는 CTI 플랫폼에서 재사용 fingerprint로 관리해야 한다.

8. Analyst's Pick: 북한 연계 행위자의 개발자 대상 JavaScript C2 운용 사례

8.1. 사례 개요와 선정 배경

Analyst's Pick으로 다룬 클러스터 2046은 북한 연계 행위자의 개발자 대상 JavaScript C2 운용 사례다. 전체 통계에서 가장 많은 IoC를 차지하는 대량 캠페인은 아니지만, 분석 가치는 크다. 분석 데이터의 참고 근거가 실제 JavaScript 샘플로 이어지고, 정적 복원을 통해 난독화된 문자열, Node.js 실행 구조, C2 제어 채널, 업로드/유출 채널까지 연결해 볼 수 있기 때문이다.

[표 10] 클러스터 2046 구조적 지표

분석가 관점에서 이 사례의 핵심은 단일 서버 주소가 아니다. 개발자 워크스테이션, GitHub/NPM/VSCode/Git hook, Vercel 기반 설정값 전달, 터미널/API 연결 구간 후보, Socket.IO/WebSocket 기반 제어 채널, 업로드/유출 경로가 하나의 공격 흐름으로 이어진다. 따라서 탐지도 단일 IOC 차단에 머물러서는 부족하다. 파일 흔적, C2 통신 규약, 헤더/필드 조합, Proxy/SIEM 기반 과거 로그 헌팅을 함께 설계해야 한다.

이 사례는 "북한 C2 서버 목록"이 아니라 "북한 연계 행위자의 개발자 대상 작전이 어떻게 정상 개발 업무 흐름을 악용해 C2 백엔드와 업로드/유출 경로로 연결되는가"를 보여주는 사례로 다뤄야 한다.

8.2. 역할별 인프라 구성

단순 IOC 묶음이 아니라 역할별 인프라로 나눠 봐야 한다.

[표 11] 클러스터 2046 역할별 인프라 구성

[그림 13] 북한 연계 행위자의 개발자 대상 JavaScript C2 역할 모델

이 그림은 개발자 실행 흐름에서 Vercel 설정값 전달 구간, lab99 터미널/API 후보, ROUTERHOSTING 기반 백엔드 후보, 그리고 샘플로 확인된 제어/업로드 채널이 어떻게 역할 분리되어 있는지를 보여준다. 하단의 증거 경계는 특히 중요하다. ‘216.126.225.243:8087’과 ‘8085/8086’은 샘플 기반으로 역할이 확인됐지만, Vercel 또는 lab99 응답이 해당 백엔드를 직접 내려준다는 연결성은 아직 추가 검증이 필요하다.

8.3. 샘플 실행 구조와 통신 구조

악성코드 분석 관점에서 이 사례의 강점은 인프라 그래프만으로 끝나지 않는다는 데 있다. 1순위 피벗 샘플은 난독화 된 JavaScript였고, 분석을 통해 실행 구조와 통신 구조를 분리해 볼 수 있었다.

[표 12] JavaScript 샘플의 정적 분석 관찰 지점

이 구조는 단순 스크립트형 다운로더보다 한 단계 더 운영화된 형태에 가깝다. 피해자 실행은 개발자 도구 체인 안에서 유도하고, 실제 샘플은 Node.js 런타임을 이용해 2단 페이로드를 분리 실행하며, 이후 제어 채널과 업로드/유출 채널을 별도로 사용한다. 그래서 이 절은 인프라 분석이면서 동시에 악성코드 정적 분석 결과로 읽혀야 한다.​​

8.4. C2 통신 규약과 채널 분리

분석 결과 기준으로 가장 중요한 발견은 216.126.225.243:8087이 단순한 연관 IoC가 아니라 실제 C2 제어 채널로 확인됐다는 점이다. 다만 샘플에 직접 하드코딩 된 값은 웹 소켓이 아니라 http://216.126.225.243:8087이며, 실행 흐름에서 이를 Socket.IO/WebSocket 통신으로 전환하거나 사용하는 구조다.

[표 13] C2 통신 요소와 채널 분리

이 구조는 명령 제어와 업로드/유출 기능이 분리되어 있음을 보여준다. 단일 IoC 차단보다 upload, validation, 호스트 메타데이터, Socket.IO/WebSocket 전환, Node.js 의존성 조합을 함께 보는 헌팅 조건이 더 유효하다.

8.5. 증거 범위와 해석 한계

이 사례에서 가장 중요한 것은 확정 증거와 후보 인프라를 별개의 범주로 해석하는 것이다.

# 확정

- 난독화된 JavaScript에서 정적 복원을 통해 C2 관련 평문 문자열과 실행 구조 확인

- 샘플은 Node.js 기반이며, 1단 로더와 2단 수집/제어 스크립트가 분리된 구조

- ‘http://216.126.225.243:8087’ 하드코딩 C2 제어 채널

- 실행 흐름에서 ‘ws://216.126.225.243:8087’ 형태의 Socket.IO/WebSocket 기반 제어 채널 사용

- ‘http://216.126.225.243:8085/upload’, ‘http://216.126.225.243:8086/upload’

- validation 헤더, 호스트 식별 필드, Node.js 의존성 조합

- 브라우저 인증정보, 지갑, .env, .ssh, API 토큰, 개인키 계열 수집 로직

# 후보 인프라

- lab99.sbs /api/terminal/*: 분석 데이터 기준 터미널/API 연결 구간 후보

- brezo.live, admin.brezo.live: 같은 분석 묶음에서 확인되는 서버 측 또는 관리 거점 후보

- Vercel 설정값 전달 구간과 216.126.225.243 C2 백엔드의 직접 응답 흐름 연결성

# 미확인

- lab99.sbs 응답이 실제로 216.126.225.243 C2 백엔드를 내려준다는 직접 증거

- Vercel 설정값 전달 엔드포인트와 216.126.225.243 C2 백엔드의 코드 수준 직접 연결성

- 시간대를 활용한 행위자 귀속

8.6. 파일/네트워크 헌팅 룰 적용 예시

이 Analyst's Pick은 분석에서 끝내기보다 실제 헌팅 조건으로 내려보낼 수 있는 가치가 높다. 룰은 두 갈래로 나누는 것이 좋다. 첫 번째는 정적 파일과 아티팩트 저장소에서 유사 JavaScript 샘플을 찾기 위한 YARA 룰이고, 두 번째는 Proxy/IDS/NDR에서 C2 통신 규약을 찾기 위한 네트워크 패킷 룰이다. 운용 우선순위는 다음과 같다.

[표 14] 헌팅 룰 운용 우선순위

파일 탐지 룰은 아래 두 가지로 나눈다. 첫 번째 룰은 확인된 백엔드와 업로드 경로를 포함하므로 정확도가 높다. 두 번째 룰은 서버 주소가 바뀐 변종을 찾기 위한 행위 기반 룰이다. 다만 이 YARA 룰은 평문 문자열이 남아 있는 파일, 정적 분석 산출물, 복호화/문자열 복원 결과 저장소에 적합하다. 원본 난독화 파일에서 문자열이 복원되지 않은 상태라면 미탐 가능성이 있다.

네트워크 패킷 탐지 룰은 Suricata 6/7 계열 문법을 기준으로 작성되었다. Snort 2.x 또는 일부 상용 IDS/IPS는 HTTP buffer keyword가 다를 수 있으므로 운영 전 제품별 파서에서 검증해야 한다. 직접 백엔드 룰은 정밀도가 높지만 수명이 짧을 수 있고, ‘/upload’와 ‘validation’ 조합은 서버가 바뀌어도 남을 수 있는 장기 헌팅 조건이다.

M365 Defender 또는 Sentinel에서는 아래 쿼리로 먼저 직접 백엔드 접속 여부를 확인할 수도 있다.

운영 시에는 ‘216.126.225.243’ 기반 룰을 즉시 차단 및 헌팅에 사용하고, /upload, validation, ukey/username/timestamp, Socket.IO/WebSocket 전환 조건은 장기 헌팅 후보로 유지하는 편이 적합하다. Vercel, lab99, brezo는 샘플에서 확인된 C2 백엔드가 아니므로 차단 룰보다 검토 및 연결성 확인용 축으로 관리해야 한다. ​

​9. 결론

지난 분기 보고서는 단일 IoC 차단의 한계를 짚고, 공격 인프라 뒤에 남는 메타데이터를 방어 논리로 전환하는 데 초점을 맞췄다. IP와 도메인은 빠르게 바뀌지만, 인증서, 포트, URI, 활성 시간대, 배포 방식 같은 흔적은 공격자가 인프라를 교체하거나 확장하는 과정에서도 반복될 수 있다는 문제가 있었다. 이번 보고서는 그 관점을 이어가되, 같은 질문에 조금 다른 결과를 보여준다.

2026년 3월 1일부터 6월 15일까지의 데이터에서 특정 공격 도구의 우세가 아니라, 공격자가 정상 서비스 환경과 공유 인프라를 어떻게 이용하는가였다. Cloudflare와 주요 클라우드/공유 호스팅은 ClearFake, ClickFix, Vidar 같은 캠페인이 정상 서비스 트래픽과 섞이는 구간으로 나타났고, Hetzner, Railnet, Hostinger, Namecheap 계열은 페이로드 전달과 활성 C2 백엔드 대응이 필요한 인프라로 구분됐다. Alibaba, Tencent, Yancy 계열 ASN에서는 C2/framework 성격의 태그가 특정 네트워크에 몰리는 양상도 확인됐다. 이 기간의 데이터가 말하는 답은 어떤 인프라를 일괄 차단할 것인가보다 무엇을 바로 차단하고, 무엇을 검토 대상으로 남기며, 무엇을 장기 헌팅 신호로 전환할 것인가에 가까웠다.

단일 IP나 도메인만 보면 Cloudflare 기반 캠페인은 과도한 차단 위험으로 이어지고, 중국계 클라우드 ASN의 C2 집중도는 단순 국가 통계로 희석되며, SPKI와 ASN+포트 조합은 짧게 쓰고 버리는 IOC 사이에 묻힌다. 방어 관점에서는 이들을 한 목록에 넣는 것이 아니라 차단, 검토, 전술 헌팅, 전략 헌팅으로 나눠 운용해야 한다.

Analyst's Pick으로 다룬 북한 연계 행위자의 개발자 대상 JavaScript C2 사례는 이 흐름을 샘플 수준에서 확인해 준다. 이 사례의 가치는 특정 IP 하나가 아니라, 개발자 업무 흐름에서 시작된 신뢰 체인이 설정 값 전달 구간, Git hook 설정, Socket.IO/ WebSocket 기반 제어 채널, ‘/upload’ 기반 업로드/유출 채널로 이어지는 구조에 있다. 정적 분석으로 확인된 백엔드 (216.126. 225.243)와 validation 헤더, ukey, host, os, username, timestamp 같은 호스트 메타데이터 필드는 단순 IoC보다 오래 남을 수 있는 C2 통신구조이다. 이 때문에 해당 사례는 파일 탐지 룰과 네트워크 패킷 탐지 룰로 전환 가능한 분석 근거가 된다.

이 인텔리전스 보고서의 목적은 수집된 위협 단서를 방어자가 바로 판단하고 운용할 수 있는 기준으로 바꾸는 데 있다. 즉시 차단할 대상은 좁히고, 정상 서비스와 섞인 대상은 검토 가능한 조건으로 관리하며, 공격자가 반복해서 남기는 인증서, 포트, URI, 헤더, 호스트 필드, ASN 조합은 다음 탐지를 위한 헌팅 신호로 남겨야 한다. 2분기 데이터는 이러한 기준이 공유 인프라 악용, 인프라 제공자별 역할 분화, 역할 분리형 C2 운영 모델을 중심으로 정리될 수 있음을 보여준다.

10. 대응 가이드 부록

본 보고서는 수집된 다채널 위협 텔레메트리의 신뢰도(Confidence Level)와 방어 메커니즘의 특성에 따라 총 5종의 별첨(Appendix) 지표를 제공한다. 각 데이터 세트는 보안 관제의 단계별(차단-관제-헌팅-전략-예측) 프로세스에 최적화되어 있으므로, 보안 담당자는 아래의 가이드를 기준 삼아 내부 보안 장비 및 SIEM 체계에 동적으로 적용할 것을 권고한다.

[별첨 1] 즉시 차단 리스트 (Blocklist)

분석 시점을 기준으로 C2 통신이 활성화(Alive)되어 있으며, 악성 행위의 신뢰도가 매우 높은 IoC만을 엄선한 목록이다. 특히 Cloudflare, Akamai 등 주요 CDN 및 클라우드 공유 인프라 대역을 자동 배제하여, 단발성 IP 차단 시 발생할 수 있는 정상 서비스 장애 가능성을 원천 차단했다. 보안 담당자는 해당 리스트의 IP 및 도메인을 방화벽(F/W), IPS 등 보안 장비의 차단 정책에 즉시 반영해야 한다. 정책 적용 후 내부망과 해당 지표 간의 In/Outbound 통신 시도 로그가 확인될 경우, 내부 단말의 감염을 강하게 의심하고 즉각적인 격리 및 포렌식을 수행해야 한다.

[별첨 2] 공유 인프라 점검 리스트 (Review_Shared_Infra)

악성 행위가 식별되었으나 즉시 차단할 경우 부수적 피해가 우려되거나, 추가적인 페이로드 검증이 선행되어야 하는 대상을 포괄한다. 본 분기 데이터 기준, 공격자가 실제 근원지를 은닉하기 위해 악용한 Cloudflare(AS13335) 및 Amazon(AS16509) 대역의 프록시 노드들이 다수 포함되어 있다. 보안 담당자는 이 리스트를 IP 단위로 단순 차단하는 것을 지양하고, 웹 방화벽이나 프록시 장비를 통해 도메인 및 URL 경로 기반의 정밀 차단 정책을 적용하는 우선 검토 대상으로 활용해야 한다.

[별첨 3] 전술적 헌팅 리스트 (Tactical_Hunting_Active_Campaign)

현재 가장 활발하게 유포되고 있는 최신 위협 캠페인들의 '실시간 탐지 패턴 및 침해지표(IoC) 모음'이다. 분기 별로 관측된 캠페인 등 최신 공격 전술 트렌드가 반영되어 있다. 보안 담당자는 제공된 패턴을 SIEM의 상관분석 탐지 규칙(Rule)에 반영하여 초기 침투 시도를 실시간으로 차단해야 하며, 나아가 최근 3개월 이내의 방화벽 및 DNS 로그를 대상으로 동일 패턴의 통신 이력이 있는지 추적하는 전수 검사(Retroactive Hunt) 용도로 활용해야 한다.

[별첨 4] 전략적 헌팅 리스트 (Strategic_Hunting_Signatures)

공격 그룹이 방어망을 피하고자 통신 단말(IP/Domain)을 지속적으로 교체하더라도 절대 변하지 않는 공격자만의 '인프라 고유 지문 시그니처 리스트'이다. 인증서 공개키 해시값(SPKI) 및 특정 호스팅과 비표준 포트의 결합(ASN+Port 조합) 등 인프라 설정 고유의 특징들을 시그니처화했다. 보안 담당자는 이 시그니처를 내/외부 위협 인텔리전스(CTI) 플랫폼 및 SSL Inspection 장비에 적용하여, 아직 표면적으로 드러나지 않은 숨겨진 예비 C2 서버까지 선제적으로 발굴하고 일괄 무력화하는 전략적 대응에 활용해야 한다.

[별첨 5] 인프라 전이 추적 지표 (Tactical to Strategic Promotions)

공격 그룹이 다음 대규모 작전을 위해 새롭게 구축하거나 호스팅 업체를 이동 중인 '예비 공격 거점의 장기 관찰 목록(Watchlist)'이다. 캠페인의 대규모 인프라 이동 패턴 사례가 대표적이며, 이 리스트는 단순한 차단 대상을 넘어, 위협 그룹의 다음 공격 징후를 예측하고 방어 체계를 선제적으로 고도화하기 위해 관찰해야 하는 전략적 지표로 관리되어야 한다.

※ 모든 데이터는 추출 시점 기준(2026.06.16)의 활성 상태를 반영하고 있다. 특히 [별첨 1]의 차단 리스트는 공격자의 인프라 폐기 속도에 따라 유효기간이 달라질 수 있으므로, 방화벽의 장비 부하를 막기 위해 주기적인 유효성 점검 및 동적 삭제를 권장한다.

사이버 위협은 언제 어디에서나 발생할 수 있습니다.

샌즈랩은 최신 악성코드 분석을 통해 획득한 위협 간 연관 정보 및 IoC를 리포트로 지속적으로 공유해 사이버 위협을 예방하고 안전한 사이버 사회를 만들고자 합니다.