새로운 Linux 봇넷 B1txor20, Log4J를 악용하고 C2 통신에 DNS 터널링 사용

최근에 발견된 봇넷은 Linux 시스템을 대상으로 하여 중요 정보 탈취·루트킷 설치·리버스 셸을 생성하며, 웹 트래픽 프록시 역할을 합니다.

 

Qihoo 360의 Network Security Research Lab(360 NetLab) 연구원들에 의해 발견된 악성코드는 B1txor20으로 불리며, Linux ARM, X64 CPU 아키텍처 장치를 공격하는데 초점을 맞추고 있습니다.

 

봇넷은 Log4J 취약점을 표적으로 하는 익스플로잇을 악용하여 새로운 호스트를 감염시킵니다. 현재도 수십 개의 공급업체가 취약한 Apache Log4j 로깅 라이브러리를 사용하는 것을 볼 때, Log4J 취약점은 매우 매력적인 공격 벡터입니다.

 

연구원들은 2월 9일 허니팟에서 B1txor20 봇넷 샘플을 처음 발견했습니다. 백도어, SOCKS5 프록시, 악성코드 다운로드, 데이터 도용, 임의 명령 실행 및 루트킷 설치 기능을 포함한 총 4개의 멀웨어 샘플을 캡쳐했습니다.

 

봇넷에 의한 지속적인 Log4J 악용

Log4J 취약점이 공개된 이후 많은 위협 행위자가 Log4Shell 익스플로잇을 공격에 배포했으며, 여기에는 중국, 이란, 북한 및 터키 정부와 연결된 국가 지원 해킹 그룹과 랜섬웨어 그룹이 사용하는 액세스 브로커가 포함됩니다.

 

360 NetLab 연구원은 "Log4J의 취약점이 공개된 이후 점점 더 많은 악성코드가 등장하고 있습니다. Elknot, Gafgyt, Mirai는 모두 너무 친숙합니다"라고 덧붙였습니다. 예를 들어, 12월에는 취약한 Linux 장치를 Mirai 및 Muhstik Linux 악성코드로 감염시키기 위해 Log4J 보안 결함을 악용하는 위협 행위자를 발견했습니다.

 

이러한 봇넷은 IoT 장치와 서버를 장악한 후 크립토 마이너를 배포하고 대규모 DDoS 공격을 수행하는 것으로 나타났습니다.

 

B1txor20 Overview

B1txor20 악성코드의 특징은 C2(명령 및 제어) 서버와의 통신 채널에 DNS 터널링을 사용하는 것입니다. 이 기술은 공격자가 안티바이러스 소프트웨어에 탐지되지 않고 악성코드 및 데이터를 주고받을 때 사용합니다.

 

연구원들은 "봇은 훔친 민감한 정보, 명령어 실행 결과 등 전달해야 할 정보를 특정 인코딩 기술을 이용해 숨긴 뒤 DNS 요청으로 C2에 전송한다"고 설명했습니다. "요청을 받은 후 C2는 DNS 요청에 대한 응답으로 페이로드를 봇에 전송합니다. 이러한 방식으로 봇과 C2는 DNS 프로토콜을 이용해 통신합니다."

 

또한 360 NetLab 연구원은 악성 프로그램 개발자가 광범위한 악성 기능을 포함했지만 모든 기능이 활성화된 것은 아님을 발견했습니다. 이는 비활성화된 기능이 여전히 버그가 있는 상태이며, B1txor20 악성코드의 제작자가 여전히 기능을 개선하고 활성화하기 위해 노력하고 있다는 신호로 해석할 수 있습니다.

 

현재 B1txor20 악성코드에서 지원되는 기능은 다음과 같습니다.

1. SHELL
2. Proxy
3. Execute arbitrary commands (임의의 명령 실행)
4. Install Rootkit (루트킷 설치)
5. Upload sensitive information (민감한 정보 업로드)

[그림 1] flowchart (출처: 360 NetLab)

 

Reverse Analysis

360 NetLab은 2022년 2월 9일자 샘플을 주요 분석 대상으로 선정하였으며, 그 기본 정보는 다음과 같습니다.

MD5:0a0c43726fd256ad827f4108bdf5e772 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped Packer:None

[그림 2] B1txor20 샘플 기본 정보 (출처: 360 NetLab)

 

B1txor20의 샘플은 실행될 때 먼저 [netns] 프로세스로 위장하고 PID 파일 [/var/run/.netns.pid]을 통해 단일 인스턴스를 실행한 다음 [/etc/machine-id], [/tmp/.138171241], [/dev/urandom]을 사용하여 BotID를 생성합니다. 이후, DNS 터널에 사용되는 도메인 네임을 해독하고, DNS 서버의 접속 테스트에 사용되는 RC4 비밀키를 복호화합니다. 마지막으로 DNS 터널을 사용하여 등록 정보를 C2로 전송하고 C2의 명령어 실행을 기다립니다. 여기서는 일반 기능에 대한 자세한 내용은 설명하지 않고, B1txor20 악성코드의 DNS 터널 구현에 대해 살펴보겠습니다.

 

Bot ID 생성

B1txor20 악성코드는 [그림 3]과 같이 BotID를 생성하기 위해 [/etc/machine-id] 또는 [/tmp/.138171241]에서 32바이트를 읽습니다. BotID 생성에 실패하면 16바이트의 데이터가 [/dev/urandom]을 통해 생성되며 이전 2개의 파일에 기록됩니다.

[그림 3] Bot ID 생성 소스코드 (출처: 360 NetLab)

 

[그림 4] Bot ID 생성 프로세스 소스코드 (출처: 360 NetLab)

 

VM machine-id 값 [ab3b49d10ec42c38b1093b8ce9ad12af]을 예로 들면 다음과 같은 파이썬 코드를 사용하여 BotID의 값을 0x125d로 계산할 수 있습니다 .

import struct id='ab3b49d10ec42c38b1093b8ce9ad12af' values=struct.unpack("<16H",id) sum=0 for i in values:     sum ^= i print hex(sum) if sum&0xff <0xf:     sum+=0x10 if sum>>8 < 0xf:     sum+=0x1000 print hex(sum)   # sum=0x125d

[그림 5] Bot ID 생성 프로세스 예시 (출처: 360 NetLab)

 

복호화

B1txor20 악성코드 샘플은 저장된 도메인 네임과 RC4 비밀키를 다음 소스코드를 이용해 복호화합니다.

[그림 6] 복호화 소스코드 (출처: 360 NetLab)

 

원리는 간단하며, xor_key가 [49 D3 4F A7 A2 BC 4D FA 40 CF A6 32 31 E9 59 A1]인 단일 바이트 xor 연산입니다.

[그림 7] 복호화 소스코드 (출처: 360 NetLab)

 

복호화 프로세스는 [그림 8]의 CyberChef와 동일합니다. 도메인 네임은 [.dns.webserv.systems]이고, RC4 비밀키는 [EnLgLKHhy20f8A1dX85l] 입니다.

[그림 8] CyberChef를 이용한 복호화 (출처: 360 NetLab)

 

 

DNS 서버의 연결성 측정

B1txor20 악성코드는 다음 소스코드로로 3개의 DNS(8.8.8.8:53, 8.8.8.4:53, 194.165.16[.]24:443) 서버의 연결을 테스트합니다.

[그림 9] Measure the connectivity of DNS servers (출처: 360 NetLab)

 

B1txor20 악성코드는 [res_discuery] API를 사용하여 "google.com"의 DNS 요청 메시지를 작성한 후 [res_send]를 통해 요청을 보냅니다. 이 메시지가 정상적으로 전송되면 네트워크는 해당 DNS 서버에 연결되어 있는 것으로 간주되며 나중에 사용할 수 있도록 저장됩니다.

[그림 10] Measure the connectivity of DNS servers (출처: 360 NetLab)

 

Bot과 194.165.16[.]24에서 발생하는 실제 트래픽은 다음과 같습니다.

[그림 11] 194.165.16[.]24에서 발생한 트래픽 (출처: 360 NetLab)

 

C&C Communication

위의 준비가 완료되면 B1txor20 악성코드는 DNS 터널링을 이용하여 C2 통신을 설정하고 C2가 보낸 명령의 실행을 기다리는 최종 단계에 들어갑니다.

[그림 12] C2 통신 소스코드 (출처: 360 NetLab)

 

일반적으로 DNS 터널링을 이용한 악성코드의 시나리오는 다음과 같습니다.

“봇은 도난당한 민감한 정보, 명령 실행 결과 및 전달해야 할 기타 정보를 특정 인코딩 기술을 사용하여 숨긴 후 DNS 요청으로 C2에 보냅니다. 요청을 받은 후 C2는 DNS 요청에 대한 응답으로 페이로드를 봇 측에 보냅니다. 이러한 방식으로 Bot과 C2는 DNS 프로토콜의 도움으로 통신을 수행합니다.”

 

이러한 네트워크 구조에는 3가지 핵심 사항이 있습니다.

1. C2는 DNS 프로토콜을 지원해야 합니다.
2. 특정 인코딩 기술
3. DNS 요청이 전송되는 방식

 

다음 섹션에서는 B1txor20 악성코드가 실제로 생성하는 트래픽과 함께 C2 통신에 대한 기술적인 세부 사항을 분석합니다.

[그림 13] C2 통신 (출처: 360 NetLab)

0x01:C2 찾기

[그림 14]의 트래픽을 통해 B1txor20에서 사용되는 SLD가 [webserv.systems]임을 알 수 있습니다. DIG 명령어를 사용하면 이 SLD가 IP 194.165.16[.]24를 가리키고 있는 것을 알 수 있습니다. 또, 이 IP 194에서 DNS 확인 서비스가 켜져있기 때문에, B201xor의 C2는 정확히 194.165.16[.]24임을 확인할 수 있습니다.

[그림 14] C2 찾기 (출처: 360 NetLab)

 

0x02: 터널 도메인 네임 생성

B1txor20의 터널 도메인 이름 형식은 [Base64-Like String+.dns.websrv.systems]입니다. 앞의 Base64 문자열은 Bot에서 C2로 전송되는 정보입니다. 

 

첫 번째로 B1txor20 패킷은 사전 구성 프로세스를 가지고 있습니다. 이 프로세스는 [0xFF + BotId + 0xFF + Stage + 0xFF + TaskInfo] 형식으로 표시됩니다. 0xFF는 여러 항목을 구분하는 데 사용되며, 구성이 완료되면 Stage 값에 따라 다른 태스크가 [TaskInfo] 섹션을 채웁니다.

[그림 15] B1txor20 패킷 (출처: 360 NetLab)

 

[그림 16]을 예로 들면, Stage 값은 1입니다. [gather_info] 함수를 통해 [TaskInfo] 섹션에 "sysinfo_uptime,uid,hostname"의 정보가 채워 지고 0x0a에 의해 구분됩니다.

[그림 16] B1txor20 소스코드 (출처: 360 NetLab)

 

필요한 정보가 준비되면 B1txor20은 [process_query] 함수를 사용하여 [그림 17]의 정보를 추가로 처리합니다. 이 정보에는 ZLIB 압축, RC4 암호화 및 Base64 인코딩의 3가지 프로세스가 포함됩니다.

[그림 17] B1txor20 소스코드 (출처: 360 NetLab)

 

RC4 암호화에 사용되는 비밀키는 이전 복호화 섹션에서 설명한 문자열 "EnLgLKHy20f8A1dX85l"이며, Base64에서 사용되는 알파벳 문자열은 [ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789^_]입니다.

 

마지막으로 B1txor20은 위에서 생성한 Base64 문자열 앞에 상태 1바이트와 임의 문자열 4바이트를 추가한 후 도메인(쿼리되는 최종 도메인 네임)과 연결합니다. status 값은 ['0', '1', '2']이며, 0은 현재 쿼리가 삭제되어 후속 쿼리와 현재의 철자가 동일해야 함을 의미합니다. 1은 쿼리가 완료되었음을 의미합니다.

[그림 18] B1txor20 소스코드 (출처: 360 NetLab)

 

생성된 실제 쿼리 [1HQoOKPvBKs8yqO1tTUQkCqGWN9anB4RAGWhnJy8A.dns.webserv.systems]에 대해 살펴보겠습니다. [.dns.webserv.systems]에서 [KPvBKs8yqO1tTUQkCqGWN9anB4RAGWhnJy8A]를 가져온 뒤, 첫 번째 5바이트를 제거합니다. 그런 다음 Base64 디코딩, RC4 디코딩, ZLIB 압축해제를 사용하면 다음과 같은 raw 데이터를 얻을 수 있습니다.

[그림 19] B1txor20에서 생성된 쿼리로부터 얻은 raw 데이터(출처: 360 NetLab)

 

데이터 내용 및 형식에서 이전 설명과 하나씩 일치할 수 있으므로 이전 분석이 정확하다는 것을 알 수 있습니다.

Botid =0x125d Stage=1 sysinfo.uptime = 34 uid=30 hostname=debian

[그림 20] B1txor20 쿼리의 데이터 내용 (출처: 360 NetLab)

 

0x3: DNS 요청 보내기

도메인 네임 구성이 완료되면, B1txor20은 RES 시리즈 API를 사용하여 DNS 요청을 생성하고 전송합니다.

[그림 21] DNS 요청을 생성 및 전송 (출처: 360 NetLab)

 

이전 테스트에 따라 DNS 요청을 보내는 방법에는 3가지가 있습니다. 이러한 방법은 빠르지만 탐지 및 추적이 쉽습니다. 첫 번째와 세 번째 방법은 탐지가 어렵지만 조금 더 느립니다.

1. 공개 dns로 보내기(8.8.8.8, 8.8.4.4) 
2. C2로 직접 보내기(194.165.16[.]24)
3. 로컬 dns로 보내기(/etc/resolv.conf의 네임서버)

0x4: 프로세스 C2 페이로드

봇은 위의 방법으로 DNS 요청을 전송한 후 C2 명령 실행을 기다립니다. C2 명령어는 [Status(1 byte):Body] 형식으로 DNS 요청 응답 메시지에 저장됩니다. 이때 Body 부분에서도 "ZLIB 압축, RC4 암호화, BASE64 인코딩"을 사용합니다.

[그림 22] C2 페이로드 (출처: 360 NetLab)

 

예를 들어, 다음 그림에서 실제 명령 "1VSE6NZwczNMm2zgaXeLkZro="가 수신됩니다.

[그림 23] 수신된 C2 페이로드 (출처: 360 NetLab)

 

Body 부분의 "VSE6NZwczNMm2zgaXeLkZro=" 데이터를 Base64, RC4로 복호화한 후 다음과 같은 형식을 얻을 수 있으며, 압축을 풀면, 빨간 부분의 최종 명령 데이터[FF 02 FF 0A FF]를 얻을 수 있습니다. 해당 형식과 위에서 생성한 형식이 일치함을 알 수 있습니다. 이 시점에서 Bot은 0x02 기능을 수행하기 위해 이동하여 C2와 bot의 상호 작용 라운드가 완료되도록 합니다.

[그림 24] 복호화한 C2 페이로드 (출처: 360 NetLab)

 

C&C 지침

B1txor20은 총 14개의 명령어를 지원하며 명령어 번호와 기능은 다음 표와 같습니다.

명령 ID	함수
0x1	Beacon/Heartbeat
0x2	시스템 정보 업로드
0x3	쉘을 얻을 수 있는 "/dev/pamd"(유닉스 도메인 소켓) 생성
0x4	popen을 통한 임의 시스템 cmd 실행
0x5	트래픽 포워딩
0x6	파일 쓰기
0x7	파일 읽기
0x8	"/var/tmp/.unetns"(유닉스 도메인 소켓)를 통해 정보 전달, 사용되지 않음
0x9	특정 정보 업로드, 사용하지 않음
0x10	프록시 서비스 중지
0x11	프록시 서비스 시작
0x1a	프록시 서비스 생성
0x21	리버스 쉘
0x50	"/boot/conf- XXX" 정보 업로드, 사용되지 않음
0x51	"M3T4M0RPH1N3.ko" 루트킷 설치

[표 1] B1txor20 명령어 및 기능 (출처: 360 NetLab)

 

[표 1]에서 "사용되지 않음"은 샘플에서 함수가 해당 처리 코드를 가지고 있지만 호출되지는 않는다는 의미입니다. 이러한 코드가 디버깅에 사용되는지 아니면 다른 시나리오에 사용되는지 확실하지 않습니다.

 

도메인 소켓을 바인드한 후 제거 기능을 사용하여 소켓 파일을 삭제하는 0x3과 같은 일부 함수는 버그가 있어 소켓을 연결할 수 없으므로 기능 전체를 사용할 수 없습니다.

[그림 25] 버그가 있는 0x3 함수 (출처: 360 NetLab)

 

침해 지표(IOC)

C2

webserv[.]systems 194.165.16[.]24:53 194.165.16[.]24:443

 

Downloader

hxxp://179.60.150.23:8000/xExportObject.class ldap://179.60.150.23:1389/o=tomcat hxxp://194.165.16.24:8229/b1t_1t.sh hxxp://194.165.16.24:8228/b1t hxxp://194.165.16.24:8228/b1t hxxp://194.165.16.24:8228/_run.sh hxxp://194.165.16.24:8228/run.sh hxxp://194.165.16.24:8228/share.sh hxxp://194.165.16.24:8228/b1t hxxp://194.165.16.24:8228/run.sh hxxp://194.165.16.24:8228/run.sh hxxp://194.165.16.24:8229/b4d4b1t.elf

 

(출처 : 

https://blog.netlab.360.com/b1txor20-use-of-dns-tunneling_en/ 

https://www.bleepingcomputer.com/news/security/new-linux-botnet-exploits-log4j-uses-dns-tunneling-for-comms/)

 

보안관제센터 MIR Team