[SERVER] (XMRig)를 이용한 리눅스 서버 악성마이닝코드 대응

1. XMRig 악성채굴코드. (사건의 발단)

• 특정 서버에서 $ top명령어로 조회된 CPU 사용률이 비정상적임을 발견.
  
• 프로세스의 실행 명령어인 ld-linux-x86-64를 검색해보니 XMRig를 이용한 악성 마이닝(채굴) 코드가 성행함을 확인할 수 있었음.
  
• 국내외로 여러 연구실 및 학교, 서버 클러스터들이 당한것으로 보임.

  해당 내용 및 출처는 학교 채굴 프로그램 대응 보고서를 기반으로 작성되었으며, 추가적으로 확인된 내용과 여러 웹페이지 조사내용을 덧붙여 작성함.

---

2. 확인 및 조사

2.1 실행되고있는 프로세서 조사

-$ top으로 검색된 의심 프로세스의 아이디(PID)확인할 수 있음.

• 아래와 같은 과정으로 XMRig 프로세서를 확인.

$ su
$ cd proc/{PID}
$ cat cmdline
$ cat comm
$ ll exe

• 그리고 PID를 이용하여 호출 위치를 다음 명령어로 확인해볼 수 있음.

sudo pwdx {PID}

• 호출 위치로/usr/local/games/.cache로를 확인할 수 있었음.
• 해당 경로에 주로 설치되는 경로중 하나이고, 여기뿐만 아니라 아래 경로에도 설치되는 경우도 많다고 함.출처

/usr/local/games/*
/usr/bin/disk1
/usr/bin/dpkg-driver
/usr/bin/expect_timed
/home/계정/.난수/xinetd
/root/.난수/xinetd
+추가로 /dev/shm/.cache에서도 발견되었다고함.

2.2 XMRig가 실행된 디렉토리 조사

• 확인된 경로에가보면 확장자가 없는 (a, s, run)이름의 파일이 존재함.
  

2.2.1 a파일

• 또한 해당 파일(a)안에는upd스크립트를 crontab(작업 계획)이용하여 주기적으로 실행시키는 스크립트가 작성되어있음.

2.2.2 upd파일

• upd파일 내부에는 bash.pid파일에 적혀있는 프로세스를 찾아서 종료함. (해당 서버에서는 조사시에 확인되지 않음)
• 그후 /run스크립트를 실행함.
  

2.2.3 run파일

• 심지어 운영체제에 따라 구분까지 하였음.
• h64혹은 h32바이너리를 실행하는 구조.
  

2.2.4 bash & bash3

• 해당 서버에는 확인되지 않았으나 외부자료에서 확인 되었으므로 내용을 남김.
• stack* 디렉토리 속의 ld-linux-x86-64(해당경로에서 채굴 프로그램임)를 실행함.
• 하지만 해당 이름은 원래시스템 라이브러리이므로, find로 찾아낸 ld-linux-x86-64라이브러리들을 날려버리는 불상사는 발생시켜서는 안됨.

2.2.5 잠재적 트로이 프로세스 검사

• 해당 출처의 내용에서 언급하듯이 이러한 트로이 목마들은 잠재적으로 존재하다가 파일이 삭제되면 다운로드 및 압축해제를 진행하기 때문에 잠재 프로세스 확인이 필요함.

$ ps -aux |grep cache 
또는
$ ps -aux |grep games

• games키워드를 포함하는 프로세스를 찾은 결과 있었음.
• 또한 프로세스 이름은 감염된 서버마다 다른것으로 확인됨.
• 조치가 끝나고 주기적으로 확인해야할 부분임.
  
• 위의 프로세스는 하나의 커맨드라인으로 실행됨.
• 커맨드는 공백을 가지고 아래와 같이 출력됨.
• 스크립트는 파일의 존재여부를 확인 후 존재하지 않으면 다운로드를 시도함.
• 4시간 간격으로 동작을 반복함.

#!/bin/bash 
loop=2 
if [ -z "$2" ]; then
	VERSION="universal" 
else VERSION="$2" 
fi 
if [ -z "$5" ]; then
	LOCATION="/usr/local/games/" 
else LOCATION="$5" 
fi

while [ $loop -  le 10 ] do
	DIR="$LOCATION.cache/run"   
if [ -f "$DIR" ]; then
	echo "exec ok"
    PID=`cat "$3".bash.pid `
############################################################
# 경로에 파일이 존재하는지 확인하고
# 없다면 wget으로 다운로드하는 트로이목마 코드
# 172.105.21x.xx를 검색하면 멀웨이 조회 결과를 확인할 수 있음
#...위험하므로 생략함....
#############################################################
ubuntunew /tmp/

• 관련된 멀웨어 조회 내용은 해당 페이지를참조하면 보다 자세하고 확인 가능함.

3. 대응

• 우선 ld-linux-x86-64이름의 프로세스를 모두 강제 종료시키도록 해당 PID를 죽이는 시그널을 날림.

$ sudo kill -9 [XMRig Malware PID]

• 의심되었던 트로이목마 프로세스 삭제

$ sudo rm -rf /usr/bin/4d13086f

• pstree를 이용하여 프로세스구조 파악 및 연결된 프로세스 모두 확인 및 삭제

$ pstree -p [위의 트로이목마 프로세스(4d13086f)PID]
$ sudo kill -9 [pstree로 조회된 PID들]

• 리눅스 시스템 데몬리스트 조회

$ systemctl list-units —type=service

• 조회결과 아래그림처럼 kernel.service실행이 failed됨.
• 일반적으로 시스템 데몬 이름으로 kernel를 사용하지 않는다고 함.
  
• 중단된 커널상태를 자세히 살펴보면 아래와 같이 /usr/bin/4d13086f스크립트를 실행했던것을 확인할 수 있음.
• 채굴 바이러스 데몬이 확정되므로 삭제해야함.
• 혹시나 하는 마음으로 .. 강조하지만..
• 절대절대절대 kerneloops 커널웁스를 삭제하는 불상사는 일어나서는 안됨. (무엇이든 두번 세번 확인하는 습관을 갖도록 합시다.)

$ systemctl status kernel

• 데몬 서비스들을 확인하기 위해서는 /etc/init.d로 가면됨.
• 본인은 삭제하고자 했던 kernel(악성데몬)서비스는 보이지 않았음.
• 다시한번 강조하지만 kerneloops 커널웁스를 삭제해선 안됨.
• 만일 존재한다면 kernel이 존재한다면 cat을 통해 스크립트 내용을 확인해보면 좋을것 같음.
• 학교 채굴프로그램 대응 보고서에 따르면 아래와 같다고 함.

  • 악성코드가 설치된 날짜와 동일하게 생성된 파일
  • /etc/ppp/ 하위의 바이너리 파일을 실행
  • /etc/ssh/ 하위의 바이너리 파일을 실행
  • rc.local에서 ppp, ssh, kde, virtuoso 하위의 파일을 실행하는 구조로 동작함.

• 만일 위의 언급내용과 동일한 파일이 보인다면 /etc위치에서 아래와 같이 rc파일들을 확인하고 관련된 내용을 제거해야함.
• 해당내용은 여기서 생략하도록 하겠음.

$ ls rc*

---

4. 조치

4.1 모니터링 스크립트

• 위의 트로이목마 프로세스는 긴 공백문자를 가지는 특징과 높은 cpu점유율을 가지고 있음.
• 해당 특징을 이용하여 모니터링 및 대응 스크립트를 작성함.
• 악성코드가 crontab을 이용하여 주기적으로 접근하므로 crontab이 아닌 다른 방법으로 주기적으로 관리하는 방법은 추후 작성하도록 하겠음.

#!/bin/bash
PID=`ps aux|grep '                          '| head -1|awk '{ print $2}'`;
#또는 
#PID=`ps aux|grep 'ld-linux-x86-64'| head -1|awk '{ print $2}'`;
sudo kill -9 $PID;
crontab -r
systemctl restart crond

• 제안된 방법은 학교대응 보고서를 출처로함.
• 긴 공백 문자를 가진 PID kill
• crontab 삭제 및 재시작

4.2 계정 관리

• 오래된 장기 미접속 계정을 삭제해야함.
• root권한을 가진 계정들은 특히 사용안하면 삭제해야함.
• /bin/false, /bin/nologin와 같이 로그인이 필요없는 계정의 경우도 필요가 없는경우 삭제하는것도 방법임.

4.3 ssh 보안설정

• /etc/ssh/sshd_config파일에서 아래와 같은 관련 보안을 설정할 수 있음.
• 설정이 모두 끝나고 난뒤 재시작 필요함

$ sudo service ssh restart

4.3.1 ssh PermitRootLogin

• PermitRootLogin설정을 no로 변경.

4.3.2 ssh 포트 변경

• ssh포트는 일반적으로 22번 포트이므로 외부에서 22번 포트로의 접근이 일어남.
• ssh포트를 바꿔 접근하는것도 방법임. 물론, 웹서버를 운용하는 경우 관련 내용들을 모두 바꿔줄 필요는 있음.
• 해당 내용은 서버를 내부적으로 함께 사용하는 경우 회의를 통해 결정해야할듯함.

4.3.3 ssh 접속 실패시 제한 설정

• MaxAuthTries 제한 값을 설정함.
• 10번으로 조정했음.

4.6 최신버전유지

• 커널버전이 낮은경우 보안에 취약함.