일주일 늦게 온 '추가 데이터' — 받을 기기는 공유기였다

휴대폰에 새 게임을 깔던 날을 떠올려 봅시다. 스토어에서 받는 앱은 생각보다 작습니다. 그런데 처음 켜면 이런 문구가 뜹니다. “추가 데이터를 내려받습니다.” 진짜 게임은 그다음에 옵니다. 크기도 처음 받은 앱보다 훨씬 큽니다.

추가 데이터에는 규칙이 하나 있습니다. 내 기기에 맞는 버전이 내려온다는 겁니다. 기기마다 안에 든 칩이 다릅니다. 그래서 다른 기기용 파일은 받아 봐야 돌아가지 않습니다.

어제 우리 서버에서 이 두 단계가 보였습니다. 다만 두 단계 사이에 일주일이 끼어 있었습니다. 그리고 내려온 버전은 우리가 매일 쓰는 컴퓨터용이 아니었습니다.

먼저, 우리 집 이야기

사실 우리는 허니팟을 운영합니다. 허니팟은 일부러 허술하게 열어 둔 미끼 서버입니다. 누가 와서 무엇을 하는지 지켜보려고 둡니다. 아래 이야기는 실제 피해가 아닙니다. 관찰 기록입니다.

사실 미끼 서버는 두 대입니다. 센서 01은 비밀번호만 맞으면 실제로 들어올 수 있는 서버입니다. 안에서 친 명령과 받아 간 파일이 기록됩니다. 센서 02는 문이 열리지 않는 서버입니다. 누가 어느 문을 몇 번 두드렸는지만 적습니다. 오늘 이야기는 대부분 센서 01에서 나왔습니다.

사실 글에 나오는 ATK-로 시작하는 이름은 우리가 출발지마다 붙이는 별칭입니다. 출발지 IP는 뒷자리를 가려서 적습니다. 파일을 내려준 주소는 143[.]20[.]154[.]42처럼 점을 괄호로 감쌉니다. 실수로 눌러도 접속되지 않게 일부러 망가뜨린 표기입니다. 이걸 디팽(defang) 이라고 부릅니다.

일주일 전: 작은 설치 파일만 왔다

사실 10월 8일, 143[.]20[.]154[.]42라는 주소에서 wget.sh라는 파일이 15번 내려왔습니다. wget은 인터넷에서 파일을 받아 오는 명령입니다. .sh는 명령을 순서대로 적어 둔 메모(셸 스크립트)라는 뜻입니다. 크기는 1,670바이트였습니다. 받아 간 곳은 ATK-713362 한 곳이었습니다.

사실 그날 센서 01에 저장된 실행파일은 0개였습니다. 그날 일지에는 이렇게 적었습니다. “wget.sh 가 다음 단계로 무엇을 불러오려 했는지는 알 수 없다.”

게임으로 치면 설치 앱만 받아 두고 ‘추가 데이터’ 화면에서 멈춘 상태였습니다.

어제: 같은 주소에서 본편 세 벌

사실 일주일 뒤인 10월 15일. 같은 주소의 /bins/ 폴더에서 이번에는 실행파일이 내려왔습니다. 세 종류였습니다.

크기 칸을 일주일 전 숫자와 견줘 보세요. bot.arc 하나가 10월 8일 wget.sh의 약 60배입니다. 작은 설치 앱 다음에 큰 본편이 온 모양 그대로입니다.

사실 세 파일을 합치면 44번입니다. 44번을 받아 간 곳은 ATK-7E40FB 한 곳뿐입니다. 이 별칭과 세 파일의 지문(해시)은 지난 일지 37개 어디에도 없던 값입니다. 해시는 파일 내용으로 계산한 고유 번호입니다. 글자 하나만 달라도 완전히 다른 번호가 나옵니다. 그래서 파일의 지문처럼 씁니다.

사실 세 파일에는 공통점이 두 가지 더 있습니다. 첫째, 정적 링크입니다. 실행에 필요한 부품을 전부 한 파일에 묶어 놓았다는 뜻입니다. 받는 쪽 기기에 뭐가 깔려 있든 혼자 돌아갑니다. 둘째, 디버그 정보가 지워져(stripped) 있습니다. 만든 사람이 작업하며 남긴 이름표를 떼어 냈다는 뜻입니다. 그래서 안을 들여다봐도 무엇을 하는 부분인지 읽기 어렵습니다.

버전 목록에 ’컴퓨터’가 없었다

사실 CPU는 기계의 두뇌 칩입니다. 칩 종류마다 알아듣는 말이 다릅니다. 그래서 프로그램은 칩 종류별로 따로 만들어야 합니다. 파일 이름 뒤의 arc, arm4, arm5가 바로 그 칩 종류입니다. 게임의 ’기종별 버전’과 같은 자리입니다.

사실 ARC용 실행파일은 지난 기록에서 딱 한 번 나왔습니다. 9월 8일, 다른 주소가 내려준 아홉 종 묶음 가운데 하나였습니다.

추정 ARC는 데스크톱이나 서버에는 거의 들어가지 않는 칩입니다. 그래서 이 파일은 공유기·셋톱박스 같은 작은 장비를 노리고 만들었다고 보는 편이 자연스럽습니다. 버전 목록에 우리 책상 위 컴퓨터는 처음부터 없었던 셈입니다.

추정 일주일 전 비어 있던 ‘다음 단계’ 자리에 같은 주소의 실행파일이 나타났습니다. 설치 앱이 있었고, 일주일 뒤 본편이 왔습니다. 그래서 오늘은 이 주소가 이어지는 모습을 중심에 놓았습니다.

사실 다만 조심할 점이 있습니다. 어제 이 주소에서 wget.sh는 한 번도 내려오지 않았습니다. 10월 8일의 wget.sh가 정말 오늘의 bot.* 파일을 부르는 스크립트였는지는 모릅니다. 스크립트 내용이 우리 기록에 없기 때문입니다. 설치 앱과 본편이 같은 게임인지 확인하지 못했다는 뜻입니다.

’내려받기’를 누른 사람이 보이지 않는다

사실 여기서 빈칸이 하나 생깁니다. ATK-7E40FB는 다운로드 기록에만 이름이 있습니다. 그날의 주요 세션 목록에는 없습니다. 세션은 ’한 번 들어와서 나갈 때까지’를 말합니다. 그래서 이 출발지에 대해 다음을 모릅니다.

• 출발지 IP (가린 형태조차 기록에 없습니다)
• 언제 들어왔는지, 어느 문(포트)으로 왔는지
• 로그인에 성공했는지
• 명령을 몇 개 쳤고 무엇을 하려 했는지
• 44번의 다운로드가 한 번의 방문에서 일어났는지, 여러 번에 걸쳤는지

사실 어제 파일을 배달한 기록이 있는 SSH 접속 프로그램 지문은 하나 있었습니다(98ddc560…, SSH-2.0-Go, 4곳). 하지만 이 지문이 ATK-7E40FB와 같은 출발지인지는 기록에 없습니다. 그래서 둘을 잇지 않습니다.

게임 화면에 ‘다운로드 완료’ 기록은 남았습니다. 그런데 버튼을 누른 사람의 얼굴은 화면에 없습니다. 오늘 이야기는 사람이 아니라 다운로드 기록에서 출발합니다.

압축을 풀자 보인 세 번째 주소

사실 어제 겉으로 드러난 유포지(파일이 놓여 있던 주소)는 두 곳입니다. 143[.]20[.]154[.]42(bot.*)와 176[.]65[.]139[.]40(wget.sh)입니다.

사실 그런데 하나가 더 있었습니다. UPX는 실행파일을 압축해 크기를 줄이는 도구입니다. 압축된 파일은 겉에서 안쪽 글자가 보이지 않습니다. 이 압축을 풀었더니 유포 주소 12개가 나왔습니다. 전부 hxxp://31[.]77[.]227[.]121/bins/ 아래였습니다. 파일 이름은 parm·parm5·parm6·parm64·parm7·pm68k·pmips·pmpsl·pppc·psh4·pspc·x86_64였습니다. 칩 종류로 12가지입니다.

사실 겉면 주소만 봤다면 이 주소는 어제 목록에 한 줄도 없었을 겁니다. 이름 짓는 방식도 다릅니다. 겉에 드러난 쪽은 bot.칩종류, 풀어서 나온 쪽은 p+칩종류입니다.

추정 이름 규칙이 다르다는 것만으로 두 주소가 같은 운영자인지, 다른 운영자인지 판단할 수 없습니다. 둘 다 ’기종별 버전’을 여러 벌 준비해 둔 모양이라는 점만 같습니다.

같은 날, 이미 본 얼굴들

사실 어제 센서 01에서 기록이 가장 촘촘했던 세션 다섯 건은 모두 텔넷으로 들어와 로그인에 성공했습니다. 텔넷은 멀리 있는 기계에 접속해 명령을 치는 오래된 통로입니다. 오가는 말이 암호로 감싸지지 않습니다. 우리 서버에서는 2223번 문이 텔넷 문입니다.

명령 칸을 보세요. 559개짜리 둘, 61개짜리 셋. 두 가지 모양뿐입니다.

사실 559개짜리는 이틀 전 일지에서 다섯 번 본 모양입니다. 그때도 명령 559개, 파일 22건이었습니다. 61개짜리는 10월 11일의 ATK-8FB338과 모양이 같습니다. 출발지 별칭만 새것입니다. 559개짜리 두 세션은 176[.]65[.]139[.]40의 wget.sh(1,487바이트)와 Renesas SH 칩용 실행파일(1,196바이트)을 받아 갔습니다. 이 두 파일도 이틀 전에 처음 기록한 지문입니다.

추정 출발지가 바뀌어도 559개 명령 묶음이 이틀 사이 일곱 번 실행됐습니다. 사람이 아니라 같은 자동화 도구가 이미 감염된 여러 장비에서 돌고 있는 모양에 가깝습니다.

사실 다섯 세션 모두가 받아 간 파일도 두 개 있습니다. 하나는 202바이트짜리 셸 스크립트입니다. 8월 21일부터 거의 매일 보던 파일입니다. 다른 하나는 1바이트짜리 파일입니다. 글자 딱 한 개 크기입니다. 어제 하루에만 181번 내려왔습니다.

시간 순서로 늘어놓으면 이렇게 됩니다. 첫 줄과 ‘시각 미상’ 줄 사이가 일주일이라는 점을 눈여겨보세요.

1. 2026-10-08 (아카이브)
   사실 143[.]20[.]154[.]42/bins/wget.sh(81a7cdbb…, 1,670바이트)가 15번 내려왔고, 받아 간 곳은 ATK-713362 하나다. 그날 01 에 저장된 실행파일은 0개다.
2. 2026-10-15T01:11:36.827Z ~ 01:13:21.076Z (10:11 KST)
   사실 ATK-5F31BC(133.232.x.x)가 텔넷으로 로그인에 성공했다. 104.25초 동안 명령 559개, 다운로드 22건이 있었다. intents 는 다운로드 후 실행·실행 권한 부여·파일 다운로드·흔적 삭제 4종이고 completeness 81, TTY 기록 있음.
3. 2026-10-15T01:52:26.484Z ~ 01:54:14.170Z (10:52 KST)
   사실 ATK-A600B8(123.216.x.x)가 앞 세션 시작 40분 49.66초 뒤에 들어왔다. 107.69초 동안 명령 559개, 다운로드 22건, intents 4종이 같았다. 두 세션 모두 wget.sh(7b8cd695…, 1,487바이트, 176[.]65[.]139[.]40)와 Renesas SH 실행파일(7c34c76b…, 1,196바이트)의 delivered_by 에 있다.
4. 10/13 대조
   사실 10/13 에는 다른 별칭 세 곳이 같은 559개 명령 묶음을 다섯 번 실행했다(79~105초). 오늘 107.69초는 그 범위보다 2.7초 길다. 별칭 ATK-5F31BC·ATK-A600B8 은 아카이브에 없다.
5. 10/13 대조
   추정 출발지가 바뀌어도 같은 559개 명령 묶음이 이틀 사이 일곱 번 실행됐다. 사람이 아니라 같은 자동화 도구가 감염된 다른 장비에서 돌고 있는 모양에 가깝다.
6. 2026-10-15T08:10:15Z ~ 08:10:43Z (17:10 KST)
   사실 ATK-B34D3D(171.113.x.x)가 텔넷으로 로그인에 성공했다. 28.54초 동안 명령 61개, 다운로드 20건이 있었다. intents 는 흔적 삭제 하나, completeness 69.
7. 2026-10-15T11:45:18Z ~ 11:45:38Z (20:45 KST)
   사실 ATK-BBC079(201.145.x.x)가 텔넷으로 로그인에 성공했다. 20.00초 동안 명령 61개, 다운로드 20건이 있었고 intents 는 흔적 삭제 하나다.
8. 2026-10-15T11:58:42Z ~ 12:00:07Z (20:58 KST)
   사실 ATK-74E36B(116.72.x.x)가 텔넷으로 로그인에 성공했다. 84.84초 동안 명령 61개, 다운로드 20건이 있었고 intents 는 흔적 삭제 하나다. 같은 모양이 10/11 에 ATK-8FB338 로 기록돼 있다.
9. 하루 전체
   사실 주요 세션 5건 모두 202바이트 셸 스크립트(0c99433c…, 아카이브 8/21 부터 반복 기록)와 1바이트 파일(01ba4719…, 오늘 181번)의 delivered_by 에 들어 있다.
10. 하루 전체 (시각 미상)
    사실 hxxp://143[.]20[.]154[.]42/bins/bot.arc(ARC700 32비트, 100,156바이트)가 16번, bot.arm4(ARM 32비트, 66,756바이트)가 16번, bot.arm5(ARM 32비트, 63,468바이트)가 12번 내려왔다. 셋 다 정적 링크에 디버그 정보가 지워졌고(stripped), delivered_by 는 세 파일 모두 ATK-7E40FB 하나다.
11. 하루 전체
    사실 오늘 143[.]20[.]154[.]42 에서 wget.sh 는 내려오지 않았다. 10/8 의 wget.sh 가 오늘의 bot.* 를 부르는 스크립트였는지는 스크립트 내용이 브리프에 없어 확인할 수 없다.
12. 하루 전체
    추정 ARC 실행파일은 아카이브에서 9/8 에 한 번 기록됐다(다른 유포지의 아홉 종 세트 중 하나). 데스크톱·서버에는 거의 없는 CPU 라서, 이 파일은 공유기·셋톱박스 같은 임베디드 장비를 겨냥했다고 보는 편이 자연스럽다.
13. 하루 전체
    사실 같은 389바이트 SSH 공개키(a8460f44…)가 서로 다른 21곳에서 21번 심겼다. 같은 날 자격증명 345gs5662d34:345gs5662d34 도 21곳, libssh_0.9.6 지문(f555226d…)도 오늘 21곳이다.
14. 하루 전체
    추정 세 값이 모두 21곳이라 같은 무리일 가능성이 있다. 다만 출발지 목록끼리 대조한 값이 JSON 에 없어 숫자가 같다는 것 말고는 근거가 없다.

시각이 찍힌 줄은 모두 이미 본 모양의 세션입니다. 정작 새로 나타난 bot.* 세 파일에는 시각이 없습니다. 앞에서 말한 빈칸이 표에서도 그대로 보입니다.

숫자 21이 세 번

사실 어제 같은 SSH 공개키 하나가 서로 다른 21곳에서 21번 심겼습니다. SSH는 텔넷과 비슷한 원격 접속 통로입니다. 차이는 내용을 암호로 감싼다는 점입니다. 공개키는 비밀번호 대신 쓰는 열쇠입니다. 이 열쇠를 서버의 authorized_keys(허용된 열쇠 목록) 파일에 적어 두면, 그 열쇠 주인은 비밀번호 없이 들어올 수 있습니다. 이 열쇠의 크기는 389바이트입니다. 영문 389자, 짧은 문단 하나 길이입니다.

사실 같은 날 아이디·비밀번호가 둘 다 345gs5662d34인 조합도 21곳에서 나왔습니다. libssh_0.9.6이라는 접속 프로그램 지문도 21곳입니다.

추정 세 숫자가 모두 21이라 한 무리일 가능성은 있습니다. 하지만 근거는 숫자가 같다는 것 하나뿐입니다. 21곳의 출발지 목록을 서로 맞춰 본 값이 없습니다. 게다가 libssh_0.9.6은 같은 프로그램을 쓰는 무관한 사람도 같은 값을 갖습니다.

받아 적을 값

방어하는 쪽이 차단 목록에 넣을 값입니다. 값을 누르면 복사됩니다. 주소는 디팽 상태 그대로 두었습니다.

위쪽 여섯 줄이 오늘의 새 값입니다. 아래 네 줄은 이미 차단 목록에 있어야 할 값입니다. 이틀 전에도, 8월에도 나왔습니다.

어제 하루 전체

사실 센서 01의 하루 숫자입니다.

사실 명령을 ’무엇을 하려는 것인지’로 나눈 하루 합계도 있습니다. 실행 권한 부여 2,298, 파일 다운로드 291, 다운로드 후 실행 291, 시스템 정찰 92, 흔적 삭제 32, SSH 열쇠 심기 22, 방어 무력화 1입니다. ’실행 권한 부여’는 받은 파일에 ’실행해도 된다’는 표시를 붙이는 일입니다. 리눅스에서는 이 표시가 없으면 파일을 켤 수 없습니다.

문이 안 열리는 집: 화면공유 문이 또 기록을 넘었다

사실 센서 02에서는 VNC 접촉이 8만 4,222번이었습니다. VNC는 다른 컴퓨터의 화면을 그대로 보고 조작하는 화면공유 통로입니다. 하루가 8만 6,400초이니 거의 1초에 한 번 누가 이 문을 두드린 셈입니다. 이틀 전(10월 13일) 세운 최대치 7만 4,372번보다 9,850번 많습니다.

사실 출발지는 436곳으로 이틀 전(438곳)보다 2곳 적었습니다. 대신 한 곳당 두드린 횟수가 평균 169.8번에서 193.2번으로 늘었습니다. 센서 02 전체 접촉 8만 5,729번 가운데 VNC가 98.2% 입니다.

사실 VNC 접속 때 서로 맞추는 버전 번호도 달라졌습니다. 003.008이 6만 2,224번, 003.003이 2만 1,746번입니다. 003.008의 비율은 이틀 전 83.2%에서 74.1% 로 내려갔습니다.

사실 원격 데스크톱 통로인 RDP는 반대로 줄었습니다. 611번·111곳입니다. 이틀 전 3,323번의 5분의 1도 안 됩니다. RDP 접속 첫 요청에 붙는 이름표 칸(쿠키)에 hello라고 적어 온 경우가 이틀 전 2,747번에서 16번으로 거의 사라졌습니다. 반면 <ip>라고 적어 온 경우는 413번으로 이틀 전(412번)과 거의 같습니다.

사실 SMB 쪽에서 상대가 내민 규격 이름은 대부분 아주 옛날 버전(SMB1 시대)이었습니다. 새 버전 이름은 2번뿐이었습니다. 이 서버는 문이 열리지 않습니다. 그래서 로그인 성공·명령·비밀번호 기록은 처음부터 없습니다.

이 비밀번호, 쓰고 계신가요

사실 어제 센서 01에 들어온 아이디·비밀번호 조합 가운데 서로 다른 출발지 3곳 이상에서 나온 것만 옮깁니다.

사실 admin / admin은 22곳에서 330번 나왔습니다. 한 곳이 평균 15번씩 같은 조합을 넣어 본 셈입니다. 반대로 345gs5662d34 조합은 21곳에서 21번입니다. 한 곳당 딱 한 번입니다.

사실 3곳 미만에서만 나온 조합은 197종입니다. 실제로 유출된 계정일 수 있어서 값은 싣지 않고 개수만 밝힙니다. 지난 최대치(10월 8일, 3,212종)의 6.1% 수준입니다.

수법을 국제 분류표에 대응시키면

공격자가 쓴 방법을 MITRE ATT&CK라는 국제 분류표의 번호에 맞춰 보면 이렇습니다. ID를 누르면 원문 설명을 볼 수 있습니다.

• T1110.001Brute Force: Password Guessing추정
• T1078Valid Accounts추정
• T1105Ingress Tool Transfer추정
• T1222.002File and Directory Permissions Modification: Linux and Mac추정
• T1059.004Command and Scripting Interpreter: Unix Shell추정
• T1070Indicator Removal추정
• T1098.004Account Manipulation: SSH Authorized Keys추정
• T1027.002Obfuscated Files or Information: Software Packing추정

오늘의 주인공은 T1105(외부에서 도구 들여오기) 입니다. 설치 앱과 본편이 내려온 일이 모두 여기에 들어갑니다. 마지막 줄 T1027.002가 앞에서 본 UPX 압축입니다. 전부 ’추정’인 이유가 있습니다. 명령을 분류한 결과를 우리가 표에 이어 붙였기 때문입니다.

전에 이런 모양이 있었다

추정 2016년 Mirai 봇넷이 비슷한 모양이었습니다. 봇넷은 감염된 기기 여러 대를 한 사람이 한꺼번에 부리는 무리를 말합니다. Mirai는 텔넷의 공장 기본 비밀번호로 IoT 장비(인터넷에 연결된 작은 기기)에 들어갔습니다. 그리고 여러 칩 종류별 실행파일을 내려보냈습니다. 텔넷 로그인 → 파일 들여오기 → 실행 표시 붙이기 → 실행. 그리고 서버용이 아닌 ARC·ARM·Renesas SH 칩용 파일이 칩마다 준비된 점까지 구조가 같습니다. 위 표의 root / xc3511은 공개된 Mirai 소스의 기본 비밀번호 목록에 있는 조합으로 알려져 있습니다.

추정 그렇다고 Mirai 계열이라고 단정하지 않습니다. 소스가 공개된 뒤 변형이 아주 많이 나왔습니다. 어제 파일들의 악성코드 분류 태그도 우리 기록에 없습니다. (참고: 미국 CISA 경보 TA16-288A, USENIX Security 2017 논문 ‘Understanding the Mirai Botnet’)

그래서 뭘 해야 하나

게임 본편은 기기가 ’내려받기’를 허락해야 깔립니다. 공유기도 같습니다. 아래 여섯 가지는 그 허락을 어디서 끊을지에 대한 이야기입니다. 침해 가능성은 브리프의 판단을 그대로 옮겼습니다.

1. 공장 출하 계정·쉬운 비밀번호를 그대로 쓴다 · 침해 가능성 높음 추정 admin / admin이 22곳에서 330번 나왔습니다. 어제 주요 세션 다섯 건은 모두 로그인에 성공했습니다. 공장 계정이 그대로라면 첫 시도 묶음 안에서 문이 열립니다. 그다음은 장비용 실행파일이 내려와 봇넷의 한 대가 되는 순서입니다.

2. 비밀번호 로그인만 쓰고 열쇠 방식을 안 쓴다 · 침해 가능성 높음 추정 ’SSH 열쇠 심기’가 22번, 같은 공개키가 21곳에서 나왔습니다. 비밀번호로 들어와 자기 열쇠를 심어 두면, 비밀번호를 바꿔도 열쇠로 다시 들어옵니다. authorized_keys 파일을 직접 열어 보지 않으면 모르고 지나갑니다.

3. 관리용 문을 인터넷에 직접 열어 뒀다 · 침해 가능성 높음 추정 하루 동안 센서 01에 175곳, 센서 02에 695곳이 찾아왔습니다. 열려 있는 관리용 문은 하루 안에 발견된다는 뜻입니다. 텔넷처럼 내용을 암호로 감싸지 않는 통로라면 비밀번호가 새어 나갈 위험도 함께 커집니다.

4. 재접속 제한(fail2ban·rate limit)이 없다 · 침해 가능성 중간 추정 admin / admin처럼 한 곳이 15번씩 두드리는 방식은 횟수 제한으로 막힙니다. 하지만 345gs5662d34처럼 한 곳이 딱 한 번씩만 두드리는 방식은 출발지별 제한에 걸리지 않습니다. 그래서 ’중간’입니다. 공장 계정 지우기와 함께 써야 효과가 있습니다.

5. 장비가 밖으로 나가는 연결을 막지 않는다 · 침해 가능성 높음 추정 로그인 다음 단계는 전부 장비가 바깥 주소로 파일을 받으러 나가는 동작이었습니다. 오늘의 ’추가 데이터 내려받기’가 바로 그것입니다. 장비가 아무 바깥 주소로나 나가지 못했다면, 어제 본 실행파일 반입은 실패했을 겁니다.

6. 기록을 바깥에 모으지 않는다(로그 수집·EDR 없음) · 침해 가능성 높음 추정 흔적 삭제 명령이 하루 32번 나왔습니다. 주요 세션 다섯 건 모두에 들어 있었습니다. 기록이 장비 안에만 있으면, 지운 뒤에는 누가 언제 무엇을 받아 갔는지 되살릴 수 없습니다. EDR은 기기 안의 수상한 동작을 감시해 따로 보고하는 보안 프로그램입니다.

우리가 모르는 것

이 섹션은 이 일지에서 가장 중요한 부분입니다. 위에서 한 이야기의 경계선이기 때문입니다.

본편을 받아 간 쪽에 대해

• [확인 불가] ATK-7E40FB는 주요 세션 목록에 없습니다. 그래서 접속 시각·통로·문 번호·로그인 성공 여부·의도 분류·명령 수를 모릅니다. 44번의 다운로드가 한 번의 방문이었는지, 여러 번에 걸쳤는지도 모릅니다.
• [확인 불가] 어제 파일 배달 기록이 있는 유일한 SSH 지문(98ddc560…, SSH-2.0-Go, 어제 4곳·누적 16곳)이 어떤 파일을 배달했는지 기록에 없습니다. 주요 세션 다섯 건은 텔넷이라 지문 칸이 비어 있습니다.

설치 앱과 본편의 관계에 대해

• [확인 불가] 10월 8일의 wget.sh(같은 주소, 81a7cdbb…)가 오늘의 bot.* 파일을 부르는 스크립트였는지 모릅니다. 스크립트 내용이 브리프에 없습니다. 10월 8일의 ATK-713362와 어제의 ATK-7E40FB가 어떤 관계인지도 모릅니다.
• [확인 불가] bot.arc·bot.arm4·bot.arm5가 어떤 악성코드 계열인지 모릅니다. MalwareBazaar 분류 태그가 기록에 없습니다.
• [확인 불가] 143[.]20[.]154[.]42(bot.*), 31[.]77[.]227[.]121(압축 속 p+칩종류), 176[.]65[.]139[.]40(wget.sh)이 같은 운영자인지 판단할 근거가 없습니다.

이미 본 세션들에 대해

• [확인 불가] 주요 세션 다섯 건의 화면 기록(TTY)은 있다는 것만 확인했습니다. 내용은 브리프에 없습니다. 의도 분류 목록에는 실행 순서가 담기지 않습니다.
• [확인 불가] 공개키·345gs5662d34 계정·libssh 지문이 모두 21곳인 것은 숫자가 같다는 사실일 뿐입니다. 출발지 목록이 같은지는 대조할 수 없습니다.

주소와 신고에 대해

• [확인 불가] 기록 속 주소 목록에 디스코드 웹훅 주소가 1건 있습니다. 웹훅은 메신저 방에 자동으로 메시지를 보내는 주소입니다. 어떤 파일·세션에서 나왔는지, 무엇에 쓰였는지 모릅니다. 주소 안에 비밀 토큰이 들어 있어 원문은 싣지 않습니다.
• [확인 불가] 어제 본 유포지는 C-TAS(한국인터넷진흥원 위협 정보 공유 시스템)로 신고했습니다. 다만 전송 성공까지만 확인됐습니다. KISA에 실제로 등록됐는지는 따로 확인해야 합니다.
• [참고] 브리프에 실린 취약점 통계(CVE 7,689건·실제 악용 확인 KEV 414건·랜섬웨어 확인 101건. 상위 5건: FortiOS CVE-2018-13379·Confluence CVE-2022-26134·Log4j2 CVE-2021-44228·NetScaler CVE-2023-4966·PAN-OS CVE-2024-3400)는 KISA 보안공지의 배경 정보입니다. 어제 허니팟 관측과 직접 연결된 것이 아닙니다.

숫자의 성격에 대해

• [확인 불가] 두 센서의 출발지를 합친 870곳은 최대치입니다. 두 센서에 모두 온 출발지가 몇 곳인지 몰라서, 실제로는 이보다 적을 수 있습니다.
• [확인 불가] 센서 02의 출발지 상위 목록에는 어느 문을 두드렸는지 구분이 없습니다. 그래서 상위 12곳이 VNC를 두드렸다고 확정할 수 없습니다. 상위 목록의 접촉 수와 전체 접촉 수가 같은 단위인지도 명시돼 있지 않습니다.
• [확인 불가] 한 출발지가 여러 문을 돌아다녔는지는 출발지별 기록이 없어 계산하지 않았습니다. ADB 문의 446건은 무엇이 들어왔는지 상세 기록이 없습니다. 거기서 저장된 파일은 0개입니다.

아예 판단하지 않는 것

• 통신사·조직(ASN·ISP): 관련 데이터베이스가 없습니다. 추정하지 않습니다.
• 지리 위치: 같은 이유로 모릅니다. IP의 지리 정보는 애초에 누가 했는지 가리는 근거도 되지 못합니다. 이 글은 어떤 국가·기업·개인도 공격자로 지목하지 않습니다.
• VPN·Tor·클라우드 여부: 판별할 수단이 없습니다.
• VirusTotal: 연동돼 있지 않습니다. 파일 분류는 MalwareBazaar 태그를 씁니다.
• 접속 프로그램 문자열(User-Agent): 두 센서 모두 웹(HTTP) 서버가 아닙니다. 센서 01은 SSH·텔넷, 센서 02는 SMB·RDP·VNC·MSSQL·LDAP·ADB입니다.
• 취약점 번호(CVE) 연결: SSH·텔넷 공격은 대부분 특정 취약점을 참조하지 않습니다. 센서 02도 접속 규칙을 맞추는 단계라 마찬가지입니다.

일주일 전 우리 서버에는 작은 설치 파일 하나가 들어왔습니다. 그날은 거기서 멈췄습니다. 어제 같은 주소에서 본편이 내려왔습니다. 크기는 60배였고, 버전은 세 벌이었습니다. 그런데 세 벌 모두 우리 책상 위 컴퓨터용이 아니었습니다. 공유기나 셋톱박스처럼 거실 구석에 켜져 있는 작은 장비용이었습니다.

게임이라면 ’추가 데이터 내려받기’는 내가 누르는 버튼입니다. 공유기에서는 다릅니다. 공장 비밀번호가 그대로이고 바깥으로 나가는 길이 열려 있으면, 그 버튼은 남이 누릅니다. 그래서 할 일은 두 가지입니다. 공유기 관리자 비밀번호를 오늘 바꾸기. 그리고 쓰지 않는 원격 관리 기능을 끄기.

관측일은 2026년 10월 15일(UTC 기준 하루)이고, 이 글은 다음 날 정리했습니다. 비교 대상은 10월 8일·10월 11일·10월 13일 일지입니다. 출발지 IP는 브리프에 가림 처리된 형태(133.232.x.x, 123.216.x.x, 171.113.x.x, 201.145.x.x, 116.72.x.x) 그대로 옮겼고 복원하지 않았습니다. ATK-7E40FB는 가린 IP조차 기록에 없어 적지 않았습니다. 주소는 실수로 접속되지 않도록 디팽(hxxp://, [.]) 상태를 유지했습니다. 자격증명은 서로 다른 IP 3곳 이상에서 관측된 조합 11개만 원문 인용했습니다. 나머지 197종은 개수만 밝히고 값은 적지 않았습니다. 통신사·국적·VPN 여부처럼 우리에게 계측 수단이 없는 항목은 추정하지 않고 “모른다”로 남겨 뒀습니다.