SecurityHeroblog

점검표 559줄을 다섯 번 — 두 사람은 나란히 읽었다

10월 13일, 텔넷으로 들어온 세 출발지가 똑같은 명령 559개를 다섯 번 되풀이했습니다. 매번 파일 22개를 받고 1분 반 안에 나갔고, 오후 4시 50분에는 두 곳이 0.9초 차이로 들어와 같은 작업을 나란히 했습니다. 설치 안내서를 내려준 주소는 같은 주소 대역에서 네 번째로 나온 곳입니다.

아파트에 정수기 점검 기사님이 오는 날을 떠올려 봅시다. 기사님 손에는 점검표가 한 장 있습니다. 필터 확인, 물 받아 보기, 부품 교체, 사인 받기. 어느 집에 가든 순서가 같습니다. 그래서 몇 분 걸릴지도 대충 정해져 있습니다.

점검표의 좋은 점은 누가 들고 가도 똑같이 일한다는 겁니다. 그런데 이걸 거꾸로 생각해 볼 수도 있습니다. 서로 다른 기사 세 명이 와서 한 줄도 다르지 않게, 거의 같은 시간 안에 일을 마쳤다면 어떨까요? 그 집에서 일한 건 사람이라기보다 점검표 쪽입니다.

어제 우리 서버에서 그런 일이 있었습니다. 차이가 있다면 이 점검표가 559줄이었다는 점입니다. 그리고 아무도 기사를 부르지 않았습니다.

먼저, 우리 집 이야기

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

사실 미끼 서버는 두 대입니다. 첫 번째(센서 01) 는 현관 비밀번호를 쉬운 숫자로 맞춰 둔 집입니다. 번호가 맞으면 실제로 들어올 수 있고, 안에서 한 일이 기록됩니다. 두 번째(센서 02) 는 문이 절대 안 열리는 집입니다. 누가 어느 문을 몇 번 만졌는지만 적습니다. 오늘 이야기는 대부분 첫 번째 집에서 나왔습니다.

사실 어제 들어온 기사들은 모두 텔넷으로 왔습니다. 텔넷은 멀리 있는 컴퓨터에 접속해 명령을 치는 아주 오래된 통로입니다. 오가는 말이 암호로 감싸지지 않습니다. 공유기나 CCTV 같은 작은 장비에 아직 남아 있는 경우가 많습니다. 우리 집에서는 2223번 문이 텔넷 문입니다. 여기서 ’문 번호’는 포트라고 부르는 것입니다.

다섯 번, 한 줄도 다르지 않았다

사실 어제 첫 번째 집에서 로그인에 성공한 세션 가운데 다섯 건이 눈에 띄었습니다. 세션은 ’한 번 들어와서 나갈 때까지’를 말합니다. 다섯 건의 숫자는 이렇습니다.

들어온 곳 (별칭) 가린 출발지 머문 시간 명령 받은 파일
ATK-00D1AA 103.40.x.x 88.23초 559개 22건
ATK-447569 (1회차) 181.233.x.x 104.73초 559개 22건
ATK-447569 (2회차) 181.233.x.x 89.29초 559개 22건
ATK-225FF4 180.190.x.x 87.40초 559개 22건
ATK-447569 (3회차) 181.233.x.x 79.27초 559개 22건

명령 칸과 파일 칸을 위에서 아래로 훑어보세요. 다섯 줄이 모두 같습니다.

사실 ATK-로 시작하는 이름은 우리가 출발지마다 붙이는 별칭입니다. 출발지 IP는 뒤쪽을 가려서 적었습니다. 출발지는 세 곳입니다. 그중 ATK-447569는 세 번 왔습니다.

사실 머문 시간은 79초에서 105초 사이입니다. 그 안에 명령 559개를 쳤습니다. 1초에 다섯에서 일곱 줄입니다. 파일 22개는 4초에 하나꼴로 받았습니다. 기록이 얼마나 촘촘한지 보여 주는 점수(completeness)는 다섯 건 모두 81로, 어제 이보다 높은 세션은 없었습니다.

추정 사람이 키보드로 1초에 일곱 줄을 칠 수는 없습니다. 게다가 세 곳이 559줄을 한 줄도 다르지 않게 되풀이했습니다. 같은 점검표를 기계가 그대로 읽어 내려간 것으로 보는 게 자연스럽습니다. 이런 걸 자동화 스크립트라고 부릅니다.

점검표에 적혀 있던 일

사실 559줄의 원문은 우리 손에 없습니다. 대신 명령이 ‘무엇을 하려는 것인지’ 분류한 결과가 있습니다. 다섯 건 모두 네 가지로 같았습니다.

  • 파일 다운로드. 바깥 창고에서 부품을 들여오는 일입니다.
  • 실행 권한 부여. 리눅스에서는 받은 파일을 바로 실행할 수 없습니다. ’이 파일은 실행해도 된다’는 표시를 붙여야 합니다. 부품에 전원 스위치를 다는 일입니다.
  • 다운로드 후 실행. 들여온 부품의 스위치를 켜는 일입니다.
  • 흔적 삭제. 현관 방문 기록부에서 자기 줄을 지우는 일입니다.

추정 네 가지는 목록이지 순서가 아닙니다. “들여오고 → 스위치 달고 → 켜고 → 지웠다”는 순서는 그럴듯하지만, 기록이 순서까지 알려 주지는 않습니다. 그리고 하나 빠진 것이 있습니다. 다음에 또 들어오기 위한 장치(지속성) 가 이 다섯 건에는 없었습니다. 예를 들어 비밀번호 없이 들어올 수 있는 열쇠를 몰래 걸어 두는 일 같은 것입니다. 그래서 이번 점검표는 ’설치하고 치우고 나간다’에서 끝납니다.

오후 4시 50분, 기사 둘이 같은 집에

사실 첫 세션은 한국 시간 낮 12시 10분, ATK-00D1AA였습니다. 다음은 4시간 38분 뒤인 오후 4시 49분, ATK-447569입니다. 여기서부터 4분 34초 동안 일이 몰렸습니다.

사실 ATK-447569가 첫 작업을 마치고 나갔습니다. 0.397초 뒤 다시 들어왔습니다. 그리고 그 0.886초 뒤, 다른 출발지 ATK-225FF4가 들어왔습니다. 두 출발지는 IP 앞 두 자리부터 다릅니다(181.233 · 180.190). 이때부터 두 세션이 87~89초 동안 나란히 돌았습니다. 한 집에 기사 둘이 1초도 안 되는 차이로 들어와 같은 점검표를 동시에 읽은 셈입니다.

사실 ATK-225FF4가 먼저 나갔고, 1초쯤 뒤 ATK-447569도 나갔습니다. 그리고 0.405초 뒤 ATK-447569가 세 번째로 들어왔습니다. 이 별칭 하나가 4분 34초 동안 친 명령은 1,677개(559×3)입니다.

추정 나가자마자 다시 들어오고, 다른 곳과 동시에 같은 일을 했습니다. 사람보다는 자동 반복으로 보입니다. 하지만 두 출발지가 같은 운영자라는 근거는 없습니다. 같은 점검표는 여러 사람이 복사해 쓸 수 있습니다. 우리는 ’같은 도구’까지만 말합니다.

사실 같은 묶음인지 확인해 볼 단서도 없었습니다. SSH 접속에서는 접속 프로그램의 ’지문(hassh)’을 떠서 같은 도구끼리 묶을 수 있습니다. 하지만 텔넷에서는 그 지문이 생기지 않습니다. 세 출발지 모두 지문 칸이 비어 있습니다.

시간 순서로 늘어놓으면

시각은 세계 표준시(UTC)입니다. 한국 시간은 9시간을 더하면 됩니다. 07:50 부근의 소수점 아래 숫자를 보세요. 한 세션이 끝나고 다음이 시작되기까지 1초가 걸리지 않습니다.

  1. 사실 ATK-00D1AA(103.40.x.x) 텔넷 세션 시작, 로그인 성공
  2. 사실 ATK-00D1AA 세션 종료. 88.23초 동안 명령 559개, 다운로드 22건. 의도 4종, 입력 기록(TTY) 있음
  3. 사실 ATK-447569(181.233.x.x) 첫 번째 세션 시작. ATK-00D1AA 시작 4시간 38분 12.65초 뒤다
  4. 사실 ATK-447569 첫 번째 세션 종료(104.73초, 명령 559개, 다운로드 22건)
  5. 사실 0.397초 뒤 ATK-447569 두 번째 세션 시작
  6. 사실 그 0.886초 뒤 다른 출발지 ATK-225FF4(180.190.x.x)가 세션 시작. 이때부터 두 세션이 동시에 진행됐다
  7. 사실 ATK-225FF4 종료(87.40초, 명령 559개, 다운로드 22건)
  8. 사실 ATK-447569 두 번째 세션 종료(89.29초)
  9. 사실 0.405초 뒤 ATK-447569 세 번째 세션 시작
  10. 사실 ATK-447569 세 번째 세션 종료(79.27초). 이 별칭은 4분 34초 동안 세 번 들어와 명령 1,677개를 쳤다(559×3)
  11. 사실 다섯 세션의 명령을 합하면 2,795개로, 어제 센서 01 전체 명령 41,776개의 6.7%다
  12. 추정 0.4초 간격 재접속과 다른 출발지의 동시 실행으로 보아, 사람이 치는 것이 아니라 자동화된 반복으로 보인다. 다만 두 출발지가 같은 운영 주체라는 근거는 없다

사실 아래에서 두 번째 줄도 봐 주세요. 어제 하루 첫 번째 집에서 친 명령 15개 중 1개가 이 다섯 세션에서 나왔습니다. 하루 4,180세션 가운데 다섯 건이 그만큼을 차지했습니다.

부품은 어디서 왔나 — 같은 거리, 네 번째 창고

사실 기사들이 받아 간 파일 중에 wget.sh라는 설치 안내서가 있습니다. 1,487바이트입니다. 영어 글자로 1,487자, 원고지로 치면 일곱 장 남짓입니다. 이 안내서를 내려준 주소는 hxxp://176[.]65[.]139[.]40/wget.sh 입니다. 어제 이 주소에서 60회 내려왔습니다.

사실 인터넷 주소는 앞 세 덩어리가 같으면 같은 ’대역’으로 묶입니다. 같은 거리의 번지수 같은 겁니다. 176.65.139 거리에서 파일을 내준 주소는 이번이 네 번째입니다.

주소 끝자리 이전 브리프에 나온 날
.196 8/21 · 8/23 · 9/22 · 9/27
.202 8/23 ~ 8/25
.206 9/17
.40 10/13 (어제, 처음)

사실 창고 하나를 차단 목록에 올리면, 같은 거리의 다른 창고가 문을 엽니다. 우리 기록이 그 모습을 두 달째 적고 있습니다.

추정 그래서 주소 한 개씩 막는 것보다 거리(대역) 단위로 지켜보는 것을 검토할 근거가 됩니다. 다만 같은 거리에 있다고 같은 주인이라고 단정할 근거는 없습니다.

사실 새로 나온 이 주소는 C-TAS로 신고했습니다. C-TAS는 한국인터넷진흥원(KISA)의 위협 정보 공유 체계입니다. 우리 쪽에서 확인된 건 ’전송 성공’까지입니다. KISA에 실제로 등록됐는지는 따로 확인해야 합니다.

서버용이 아닌 부품

사실 함께 들어온 파일 가운데 실행파일 두 개가 눈에 띕니다. 하나는 Renesas SH라는 CPU용입니다. 1,196바이트로 원고지 여섯 장 정도입니다. 다른 하나는 MIPS라는 CPU용이고 160바이트입니다. 원고지 한 장도 못 채우는 크기입니다. MIPS 파일은 ATK-447569만 보냈습니다.

사실 CPU는 컴퓨터의 두뇌입니다. 실행파일은 CPU 종류에 맞아야 돌아갑니다. Renesas SH와 MIPS는 일반 서버나 PC보다 공유기·셋톱박스 같은 작은 장비에 들어가는 계열입니다. 정수기 기사가 정수기가 아니라 보일러용 부품을 들고 온 것과 비슷합니다.

추정 이 집이 무슨 기계인지 확인하지 않고, 여러 기계용 부품을 일단 다 들고 온 것으로 보입니다. 하지만 이것도 해석일 뿐입니다. 559줄 안에서 무슨 일이 있었는지는 원문이 없어 모릅니다.

사실 배경으로 하나만 덧붙입니다. 8월 16일부터 반복해서 나온 압축 파일이 있습니다. 이 파일은 풀어야만 안에 적힌 주소가 보입니다. 풀면 hxxp://31[.]77[.]227[.]121/bins/ 아래로 CPU 이름이 붙은 파일 12개가 나옵니다. 거기에 Renesas SH 계열(psh4)과 MIPS 계열(pmips·pmpsl)이 들어 있습니다. 어제 들어온 실행파일과 CPU 종류가 겹친다는 것까지만 사실입니다. 어제 파일이 그 목록에서 왔다는 근거는 없습니다.

받아 적을 값

방어에 쓰실 수 있게 그대로 옮깁니다. 이런 값을 IOC(침해 지표)라고 부릅니다. “이 값이 보이면 의심하라”는 표지입니다. sha256은 파일 내용 전체로 계산한 고유 번호입니다. 한 글자만 달라도 완전히 다른 값이 나옵니다. 값을 누르면 복사됩니다. 설명 끝의 ’처음/반복’을 보세요.

url
hxxp://176[.]65[.]139[.]40/wget.sh설치 스크립트 유포지 · 60회 · 176.65.139 대역의 네 번째 주소 · 처음 나온 주소 · C-TAS 신고(전송 성공까지 확인)
sha256
7b8cd695424f9b004b459ce886d92e9a24f38957dc9071510ab669a7cb89c417wget.sh · 1,487바이트 · 보낸 곳 ATK-00D1AA, ATK-225FF4, ATK-447569, ATK-F3C363, ATK-706401, ATK-A72B17 · 처음 나온 해시
sha256
7c34c76b8d831eb3c3b8585a96f763690956aadbc0a00f37146317ca8d54548dELF 32비트 Renesas SH · 정적 링크 · 스트립됨 · 1,196바이트 · 58회 · URL 미기록 · 보낸 곳 ATK-00D1AA, ATK-225FF4, ATK-447569, ATK-F3C363, ATK-706401 · 처음 나온 해시
sha256
48f9b3ea45b544d0acd75ff962aa19f7b688c6c4c81b709196791126408f4212ELF 32비트 MIPS(MSB) · 160바이트 · URL 미기록 · 보낸 곳 ATK-447569 · 섹션 헤더 위치(1960)가 파일 크기를 넘는다 · 처음 나온 해시
sha256
0c99433c7d433d65ab890dcee20b330f262379d532bc76f91e18f09ecfa5fb54202바이트 POSIX 셸 스크립트 · 62회 · URL 미기록 · 보낸 곳 8곳 · 반복(8/21·8/23·9/6·10/4·10/11)
sha256
01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b1바이트 빈 파일 · 1,190회 · URL 미기록 · 보낸 곳 10곳 · 반복

사실 위쪽 네 줄은 어제 처음 나온 값이고, 아래 두 줄은 전에도 본 값입니다. 보낸 곳 목록에는 오늘의 다섯 세션 말고 ATK-F3C363·ATK-706401·ATK-A72B17 같은 별칭도 있습니다. 같은 부품을 받아 간 집이 다섯 세션보다 넓다는 뜻입니다.

어제 하루 전체

시야를 넓혀 첫 번째 집의 하루를 봅니다. 오른쪽 ‘견줄 것’ 칸이 숫자를 손에 잡히게 해 줍니다.

항목 10월 13일 견줄 것
세션 4,180건 약 21초에 한 번 문이 열리고 닫힘
고유 출발지 209곳 한 곳이 평균 20번꼴
로그인 시도 3,278회 약 26초에 한 번 비밀번호를 눌러 봄
친 명령 41,776개 약 2초에 한 줄
포트 2222 (SSH) 2,911세션 약 70%
포트 2223 (텔넷) 1,266세션 약 30% · 1분 남짓에 한 번

사실 명령 41,776개 가운데 2,795개가 오늘 본 다섯 세션입니다. 포트별 합과 통신 방식별 합은 둘 다 4,177인데, 전체 세션은 4,180입니다. 3건이 어긋납니다. 이유는 아래 ’우리가 모르는 것’에 적었습니다.

안 열리는 집 — 화면공유 문이 기록을 새로 썼다

사실 두 번째 집은 문이 안 열립니다. 그래서 누가 몇 번 만졌는지만 남습니다. 어제는 VNC 문이 눈에 띄었습니다. VNC는 멀리 있는 컴퓨터 화면을 내 화면에 띄워 조작하는 화면공유 기능입니다. ‘한 곳당’ 칸을 견줘 보세요.

문 무엇을 하는 문인가 포트 접촉 출발지
VNC 화면 공유 5900 74,372번 438곳
RDP 윈도우 원격 데스크톱 3389 3,323번 125곳
SMB 윈도우 파일 공유 445 250번 46곳
LDAP 회사 계정 목록 조회 389 134번 20곳
MSSQL 마이크로소프트 데이터베이스 1433 61번 41곳
ADB 안드로이드 기기 연결 통로 기록 없음 441번 기록 없음

사실 VNC 접촉 74,372번은 1.2초에 한 번꼴입니다. 출발지 438곳도, 접촉 횟수도 8월 26일 이후 브리프 26개에서 가장 큰 값입니다. 종전 최대는 접촉 65,487번(9/10), 출발지 416곳(9/8)이었습니다. 한 곳당 평균은 169.8번입니다.

사실 VNC에 접속할 때 내미는 버전 표기도 달라졌습니다. 003.008이 61,601번, 003.003이 12,478번입니다. 003.008 비중은 83.2%로, 10월 11일의 98.7%에서 내려왔습니다. 003.003만 보면 이틀 사이 19.0배가 됐습니다.

사실 원격 데스크톱(RDP) 문에 붙어 온 꼬리표(쿠키)는 ‘hello’ 2,747번, '<ip>' 412번, ‘zgrab’ 1번입니다. 꼬리표는 보내는 쪽이 아무 글자나 써 넣을 수 있어서, 이것만으로 누구인지 묶지 않습니다. SMB 문에서는 아주 오래된 방식(SMB1) 시절의 이름만 들어왔습니다.

추정 이 기록은 침입 이야기가 아닙니다. 문을 만진 규모와 모양까지만 말할 수 있습니다. 왜 늘었는지는 모릅니다.

이 번호 쓰고 계신가요

사실 어제 첫 번째 집 현관에 눌러 본 아이디·비밀번호 가운데 이 글에 그대로 옮기는 건 10종입니다. 기준은 하나입니다. 서로 다른 출발지 세 곳 이상에서 똑같이 눌러 본 조합만 적습니다. 여러 곳이 똑같이 들고 다니는 번호라면 누구의 것도 아닌 공장 기본값일 가능성이 높습니다. 세 번째 칸을 보세요.

아이디 비밀번호 서로 다른 출발지
admin admin 45곳
345gs5662d34 345gs5662d34 12곳
root 12345 7곳
root admin 7곳
user user 5곳
root 123456 5곳
admin 12345 5곳
root root123 5곳
root vizxv 3곳
root (빈 칸) 3곳

사실 admin/admin은 45곳에서 모두 311번 들어왔습니다. 한 곳당 7번꼴입니다. 맨 아래 줄은 비밀번호를 아예 비워 둔 채 눌러 본 경우입니다.

사실 이 기준에 못 미친 조합은 개수만 셉니다. 어제는 2,633종이었습니다. 누군가의 진짜 계정에서 새어 나온 것일 수 있어서 값은 적지 않습니다. 표에 적은 조합 하나마다 적지 않은 조합이 260개쯤 있는 셈입니다. 기록상 가장 많았던 날은 10월 8일 3,212종입니다.

사실 오늘의 다섯 세션이 어떤 조합으로 문을 열었는지는 모릅니다. 접속과 비밀번호를 이어 주는 정보가 기록에 없습니다.

공격자가 쓴 수법을 국제 분류표에 대응시키면

MITRE ATT&CK은 공격 수법마다 번호를 붙여 둔 국제 목록입니다. 어제 본 행동을 그 번호에 맞추면 이렇습니다. ID를 누르면 원문 설명으로 갑니다.

  • T1078Valid Accounts — 텔넷 로그인 성공 5건추정
  • T1110.001Brute Force: Password Guessing — 센서 01 로그인 시도 3,278회, admin/admin 이 45곳에서 시도됨추정
  • T1105Ingress Tool Transfer — 세션마다 다운로드 22건, wget.sh 반입추정
  • T1222.002File and Directory Permissions Modification: Linux — 의도 '실행 권한 부여'추정
  • T1059.004Command and Scripting Interpreter: Unix Shell — 의도 '다운로드 후 실행', 셸 스크립트 반입추정
  • T1070Indicator Removal — 의도 '흔적 삭제'(세부 기법은 명령 원문이 없어 특정 불가)추정

사실 여섯 줄 모두 [추정] 입니다. 우리 손에 있는 건 행동 분류와 횟수까지이고, 명령 원문은 없습니다. 가운데 세 줄(T1105·T1222.002·T1059.004)이 점검표의 부품 들여오기 → 스위치 달기 → 켜기에 해당합니다. 맨 아래 T1070이 방문 기록부 지우기입니다.

전에 이런 모양이 있었다

사실 Mirai 봇넷 (2016). 텔넷 기본 비밀번호로 IoT 장비에 들어가 여러 CPU용 실행파일을 뿌린 무리입니다. IoT 장비는 공유기·CCTV처럼 인터넷에 연결된 작은 기기를 말합니다. 봇넷은 감염된 기기 여러 대를 한꺼번에 조종하는 무리입니다. 오늘 표에 있는 root/vizxv는 Mirai 공개 소스의 기본 비밀번호 목록에 있는 조합으로 알려져 있습니다. (출처 유형: 정부 경보 US-CERT/CISA Alert TA16-288A · 학술 논문 USENIX Security 2017 ‘Understanding the Mirai Botnet’)

추정 텔넷 로그인 성공 → 바깥에서 파일 반입 → 실행 권한 부여 → 실행. 그리고 서버가 아니라 작은 장비용 CPU(Renesas SH·MIPS) 실행파일. 이 뼈대가 같습니다. 하지만 Mirai 계열이라고 판정하지 않습니다. 소스가 공개된 뒤 파생본이 많습니다. 어제 파일의 악성코드 분류 태그(MalwareBazaar)도 우리 브리프에 없습니다.

그래서 뭘 해야 하나

점검표 이야기로 돌아가면 할 일은 간단합니다. 부르지 않은 기사가 들어오지 못하게. 들어와도 부품을 못 들여오게. 그리고 기록부는 집 밖에도 한 부. 브리프가 꼽은 여섯 가지를 차례로 봅니다.

사실 1. 기본 계정·쉬운 비밀번호를 그대로 쓴다 · 침해 가능성 높음 오늘의 다섯 세션은 모두 로그인에 성공했습니다. 같은 날 admin/admin이 45곳에서 311번, root/12345가 7곳, root/vizxv가 3곳에서 들어왔습니다.

추정 로그인되는 순간 1분 30초 안에 바깥 파일 22개가 들어오고, 스위치가 달리고, 켜집니다. 그 장비는 남의 명령을 받는 상태가 됩니다. 다만 다섯 세션이 어느 조합으로 들어왔는지는 모릅니다. 위 조합과의 연결은 정황뿐입니다.

사실 2. 관리용 문(텔넷)을 인터넷에 직접 열어 뒀다 · 침해 가능성 높음 어제 텔넷 문(2223)에 1,266세션이 왔습니다. 오늘의 다섯 건도 전부 텔넷입니다.

추정 텔넷은 암호화도 없고 열쇠 방식 인증도 없습니다. 비밀번호 하나만 맞으면 안으로 들어옵니다. 그러면 오늘 본 네 단계가 그대로 다시 일어납니다. 공유기·카메라 설정 화면에 ‘텔넷’ 항목이 있다면 꺼 두는 게 좋습니다.

사실 3. 비밀번호 로그인만 쓰고 열쇠 방식을 안 쓴다 (SSH 쪽) · 침해 가능성 중간 오늘 다섯 세션과는 별개로, SSH 문 쪽 기록입니다. SSH 세션 2,911건, ’SSH 키 심기’로 분류된 행동 17건이 있었습니다. 같은 공개키 파일(a8460f44…)이 별칭 15곳에서 15번 내려왔습니다.

추정 SSH 키 심기는 비밀번호 없이 들어올 수 있는 열쇠를 현관에 몰래 하나 걸어 두는 일입니다. 서버는 authorized_keys(허용된 열쇠 목록)에 적힌 열쇠면 그냥 들여보냅니다. 이렇게 되면 나중에 비밀번호를 바꿔도 다시 들어올 수 있습니다.

사실 4. 재접속 제한(fail2ban·rate limit)이 없다 · 침해 가능성 높음 ATK-447569는 0.397초, 0.405초 간격으로 4분 34초 동안 세 번 다시 들어왔습니다. ATK-225FF4는 0.886초 뒤에 함께 들어왔습니다. 아무 제한도 걸리지 않았습니다.

추정 fail2ban은 짧은 시간에 너무 자주 오는 출발지를 잠시 막는 도구입니다. 이런 장치가 없으면 같은 집에 같은 설치가 몇 번이고 반복됩니다. 점검표로 치면 “방금 다녀간 기사가 1초 만에 또 벨을 누르면 문을 열지 않는다” 는 규칙입니다.

사실 5. 장비가 밖으로 나가는 연결을 막지 않는다 · 침해 가능성 높음 다섯 세션이 각각 22건씩 받았습니다. wget.sh 주소에서만 60회가 내려왔습니다. 하루 전체로는 ‘파일 다운로드’ 110건, ‘다운로드 후 실행’ 96건이 분류됐습니다.

추정 장비가 바깥 창고에서 부품을 직접 받아 왔습니다. 정해 둔 납품처하고만 연결되게 해 뒀다면(허용 목록) 부품 들여오기 단계에서 흐름이 끊겼을 겁니다. 점검표가 아무리 길어도 부품이 없으면 설치를 못 합니다.

사실 6. 기록을 바깥에 모으지 않는다(로그 수집·EDR 없음) · 침해 가능성 중간 다섯 세션 모두 ’흔적 삭제’가 있었습니다. 하루 전체로는 78건입니다. 우리는 미끼 서버라서 입력 기록(TTY)이 따로 남았습니다.

추정 EDR은 컴퓨터 안의 수상한 움직임을 기록하고 알려 주는 감시 프로그램입니다. 방문 기록부가 집 안에만 있으면 지워지는 순간 끝입니다. 언제 누가 무엇을 들였는지 되짚을 수 없습니다. 기록은 장비 밖으로 실시간으로 보내야 남습니다.

같은 날 이야기를 60초 영상으로도 만들었습니다. 영상은 ATK-447569가 나가자마자 다시 들어온 0.4초에 집중했습니다. 이 글은 그 다섯 세션이 왜 같은 점검표로 보이는지, 부품이 어디서 왔는지까지 펼쳤습니다.

우리가 모르는 것

이 블로그가 다른 곳과 다른 지점입니다. 아는 것만큼 모르는 것도 적습니다.

다섯 세션에 대해

  • [확인 불가] 다섯 세션이 어떤 아이디·비밀번호로 들어왔는지 모릅니다. admin/admin 같은 조합과의 연결은 정황뿐입니다.
  • [확인 불가] 559줄의 실제 내용이 없습니다. 행동 분류 4종만 있습니다. 559개 중 몇 개가 분류됐는지도 모릅니다.
  • [확인 불가] 세션마다 받은 22건이 어느 파일들로 이루어졌는지 나눌 수 없습니다. ‘보낸 곳’ 목록에는 다른 별칭의 몫(1바이트 파일 1,190회 등)이 섞여 있습니다.
  • [확인 불가] ATK-447569와 ATK-225FF4가 왜 동시에 같은 일을 했는지 모릅니다. 같은 도구라는 정황은 있지만 같은 조직이라는 근거는 없습니다.

들어온 부품에 대해

  • [확인 불가] wget.sh(1,487바이트)가 다음 단계로 무엇을 받아 오는지 내용이 없어 확인할 수 없습니다.
  • [추정] Renesas SH 실행파일(7c34c76b…)은 1,196바이트로 작습니다. 다른 파일을 받아 오는 작은 단계로 보이지만 검증하지 않았습니다.
  • [추정] MIPS 160바이트 파일(48f9b3ea…)은 섹션 헤더 위치(1960)가 파일 크기를 넘습니다. 전송 중에 잘린 파일일 수 있지만 확인하지 않았습니다.
  • [확인 불가] 파일의 MalwareBazaar 태그가 브리프에 없어 악성코드 계열 이름을 붙이지 않았습니다.

주소와 신고에 대해

  • [확인 불가] 176[.]65[.]139[.]40과 앞서 나온 .196·.202·.206이 같은 운영자인지 모릅니다. 대역만 같습니다.
  • [확인 불가] C-TAS 신고는 전송 성공까지만 확인됐습니다. KISA에 실제로 등록됐는지는 아직 모릅니다.
  • [확인 불가] ’처음 나온 값’은 지난 브리프에서 해시·별칭·주소를 글자로 검색한 결과입니다. 브리프가 없는 날(9/9·9/11 등)과는 비교하지 못했습니다.

숫자의 성격에 대해

  • [데이터 불일치] 포트별 합(4,177)과 통신 방식별 합(4,177)이 전체 세션(4,180)과 3건 어긋납니다. 원인을 모릅니다.
  • [확인 불가] VNC 접촉이 최대치를 찍은 이유, 003.003 표기가 다시 늘어난 이유를 모릅니다. 상대 도구가 바뀐 건지, 우리 센서 쪽이 바뀐 건지 가릴 수 없습니다.
  • [확인 불가] 출발지 상위 목록의 접촉 수와 전체 세션 수가 같은 단위인지 명시돼 있지 않아 비율을 내지 않았습니다.
  • [확인 불가] ADB 문의 441건은 무엇이 들어왔는지 상세 기록이 없어 오늘은 다루지 않았습니다.

아예 판단하지 않는 것

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

어제 우리 집에는 부르지 않은 기사가 다섯 번 다녀갔습니다. 출발지는 세 곳이었습니다. 그런데 점검표는 하나였습니다. 559줄을 한 줄도 바꾸지 않고 읽었습니다. 부품 22개를 들여와 스위치를 달고, 켜고, 방문 기록부를 지우고 1분 반 만에 나갔습니다. 오후 4시 50분에는 기사 둘이 1초도 안 되는 차이로 들어와 같은 점검표를 나란히 읽었습니다. 부품을 내준 창고는 같은 거리에서 네 번째로 문을 연 곳이었습니다.

점검표를 든 쪽은 집주인이 누구인지 묻지 않습니다. 현관 번호가 공장 설정 그대로인지만 봅니다. 그래서 막는 방법도 점검표처럼 단순합니다. 쓰지 않는 텔넷 문은 닫기. 공장 비밀번호는 바꾸기. 장비가 아무 데서나 부품을 받아 오지 못하게 하기. 그리고 기록부는 집 밖에도 한 부 두기입니다.


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