Linux Audit System을 무력화하는 T1562.012 공격 기법의 동작 원리와 SkidMap 사례 분석. auditd 중지부터 로그 조작까지 은밀한 흔적 제거 방법의 상세한 메커니즘을 해부합니다.
Linux Audit System은 Linux 환경에서 시스템 활동을 추적하는 핵심 보안 메커니즘이다. 하지만 공격자들은 이 감시 체계를 무력화하여 자신들의 흔적을 지우려 한다.
2019년 SkidMap 악성코드가 Redis 서버를 대상으로 한 공격에서 Linux Audit System을 완전히 비활성화한 사례가 발견되었다. 공격자는 단순히 auditctl -D 명령어 하나로 모든 감사 규칙을 제거하고, systemctl stop auditd로 감사 데몬을 중지시켜 완전한 은밀성을 확보했다.
이 글에서는 MITRE ATT&CK T1562.012 기법의 동작 원리와 공격자가 Linux 감사 시스템을 무력화하는 구체적 방법을 분석한다.
T1562.012는 공격자가 Linux 시스템의 감사(Audit) 시스템을 비활성화하거나 수정하여 자신의 활동을 은폐하는 공격 기법이다.
Disable or Modify Linux Audit System: Adversaries may disable or modify the Linux audit system to hide malicious activity and avoid detection. — MITRE ATT&CK T1562.012
이 기법은 Defense Evasion 전술에 속하며, 공격자가 시스템에서 수행하는 악의적 활동의 로그 생성을 방지하거나 기존 로그를 조작하는 것을 목표로 한다.
| 용어 | 역할 | 차이점 |
|---|---|---|
| auditd | 사용자 영역 감사 데몬 | 커널 감사 이벤트를 수집하고 로그 파일에 기록 |
| auditctl | 감사 규칙 관리 도구 | 실시간으로 감사 규칙을 추가/삭제/조회 |
| ausearch | 감사 로그 검색 도구 | 기록된 감사 로그에서 특정 이벤트 검색 |
| aureport | 감사 보고서 생성 도구 | 감사 로그를 분석하여 요약 보고서 생성 |
| audit.rules | 감사 규칙 설정 파일 | /etc/audit/rules.d/에 위치한 영구 규칙 정의 |
Linux Audit System은 커널 레벨과 사용자 레벨로 나뉘어 동작하는 포괄적인 감시 체계이다.
Linux Audit System의 전체 동작 흐름
Linux 커널의 감사 서브시스템은 시스템 호출 인터셉트 지점에서 동작한다. 사용자가 파일을 열거나, 프로세스를 생성하거나, 네트워크 연결을 시도할 때마다 커널은 미리 정의된 감사 규칙과 비교하여 로깅 여부를 결정한다.
# 감사 규칙 예시 - /etc/passwd 파일 접근 모니터링
-w /etc/passwd -p wa -k passwd_changes
# -w: 감시 대상 파일
# -p wa: write/attribute 변경 감시
# -k: 키워드 태그
auditd는 커널에서 생성된 감사 이벤트를 netlink 소켓을 통해 수신하고, 이를 구조화된 로그 형태로 변환하여 파일에 저장한다.
# auditd 설정 파일 - /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL_ASYNC
실제 감사 로그는 다음과 같은 구조화된 형태로 저장된다:
type=SYSCALL msg=audit(1640995200.123:456): arch=c000003e syscall=2 success=yes exit=3 a0=7fff12345678 a1=241 a2=1a4 a3=0 items=1 ppid=1234 pid=5678 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="cat" exe="/bin/cat" key="passwd_changes"
type=PATH msg=audit(1640995200.123:456): item=0 name="/etc/passwd" inode=12345 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
이 로그에서 syscall=2는 open() 시스템 호출을, name="/etc/passwd"는 접근된 파일을, comm="cat"은 실행된 명령어를 나타냅니다.
공격자가 가장 먼저 시도하는 방법은 auditd 서비스 자체를 중지시키는 것이다.
# systemd 기반 시스템
systemctl stop auditd
systemctl disable auditd
# SysV init 기반 시스템
service auditd stop
chkconfig auditd off
이 방법의 위험성은 즉각적인 완전 차단에 있다. auditd가 중지되면 모든 감사 이벤트가 /dev/null로 사라지며, 관리자가 서비스 상태를 확인하기 전까지 공격자의 모든 활동이 기록되지 않다.
더 정교한 공격자들은 모든 규칙을 제거하는 대신, 자신의 활동과 관련된 특정 규칙만 제거한다.
# 현재 활성 규칙 확인
auditctl -l
# 특정 파일 감시 규칙 제거
auditctl -W /etc/passwd -p wa -k passwd_changes
# 모든 규칙 일괄 삭제
auditctl -D
# 감사 시스템 완전 비활성화
auditctl -e 0
auditctl -e 0 명령어는 특히 치명적인데, 이는 커널 레벨에서 감사 기능 자체를 비활성화하여 auditd를 재시작해도 로깅이 재개되지 않다.
공격자의 로그 조작 흐름
공격자는 단순히 로그를 삭제하는 것이 아니라, 선별적으로 자신의 흔적만 제거한다:
# 특정 시간대 로그 제거
sed -i '/1640995200/d' /var/log/audit/audit.log
# 특정 사용자 활동 로그 제거
grep -v "uid=1000" /var/log/audit/audit.log > /tmp/cleaned.log
mv /tmp/cleaned.log /var/log/audit/audit.log
# 로그 파일 완전 삭제 후 빈 파일 생성
rm /var/log/audit/audit.log
touch /var/log/audit/audit.log
chown root:root /var/log/audit/audit.log
chmod 600 /var/log/audit/audit.log
가장 지속적인 공격은 부팅 시 로드되는 감사 규칙을 수정하는 것이다:
# 영구 규칙 파일 수정
echo "# Disabled by maintenance" > /etc/audit/rules.d/audit.rules
# 또는 특정 규칙만 주석 처리
sed -i 's/^-w \/etc\/passwd/#-w \/etc\/passwd/' /etc/audit/rules.d/audit.rules
이 방법은 시스템 재부팅 후에도 감사 기능이 제대로 작동하지 않게 만들어, 공격자의 지속적인 접근을 보장한다.
SkidMap은 Redis 서버를 대상으로 한 암호화폐 채굴 악성코드로, 감사 시스템 무력화에 다단계 접근법을 사용했다:
auditctl -D && systemctl stop auditd 실행/etc/audit/rules.d/ 디렉터리 내 모든 파일 삭제이 공격에서 주목할 점은 공격자가 감사 로그를 삭제하기 전에 먼저 새로운 로그 생성을 차단했다는 것이다. 이는 삭제 과정에서 발생하는 로그마저 남지 않게 하려는 치밀한 계획이었다.
Linux/Ebury는 SSH 데몬을 감염시키는 백도어로, 감사 시스템에 대해 더욱 정교한 접근을 보여줍니다:
# Ebury가 사용한 선별적 규칙 제거
auditctl -W /usr/sbin/sshd -p x
auditctl -W /etc/ssh/sshd_config -p wa
Ebury는 SSH 관련 감사 규칙만 제거하여 전체 감사 시스템이 정상 작동하는 것처럼 보이게 만들었다. 이로 인해 관리자들은 감사 시스템이 작동 중이라고 착각했고, SSH 백도어 활동은 수년간 탐지되지 않았다.
#!/bin/bash
# 감사 시스템 상태 점검 스크립트
check_audit_status() {
# auditd 서비스 상태 확인
if ! systemctl is-active --quiet auditd; then
echo "ALERT: auditd service is not running"
logger "SECURITY: auditd service stopped"
fi
# 감사 규칙 수량 확인
rule_count=$(auditctl -l | wc -l)
if [ $rule_count -lt 10 ]; then
echo "ALERT: Too few audit rules ($rule_count)"
logger "SECURITY: Audit rules reduced to $rule_count"
fi
# 로그 파일 무결성 확인
if [ ! -s /var/log/audit/audit.log ]; then
echo "ALERT: Audit log file is empty or missing"
logger "SECURITY: Audit log file compromised"
fi
}
# 감사 규칙을 불변(immutable) 모드로 설정
auditctl -e 2
# 또는 규칙 파일에 추가
echo "-e 2" >> /etc/audit/rules.d/99-finalize.rules
-e 2 설정은 감사 설정을 잠금 상태로 만들어, 시스템 재부팅 없이는 규칙 변경이 불가능하게 만듭니다.
# audisp-remote 플러그인 설정
echo "active = yes
direction = out
path = /sbin/audisp-remote
type = always
format = string" > /etc/audisp/plugins.d/au-remote.conf
# 원격 서버 설정
echo "remote_server = 192.168.1.100
port = 514
local_port = any
transport = tcp" > /etc/audisp/audisp-remote.conf
| 항목 | 설정 방법 | 중요도 |
|---|---|---|
| 서비스 자동 시작 | systemctl enable auditd | 핵심 |
| 불변 모드 활성화 | auditctl -e 2 | 핵심 |
| 원격 로그 전송 | audisp-remote 설정 | 권장 |
| 로그 파일 보호 | chattr +a /var/log/audit/audit.log | 권장 |
| 정기 상태 점검 | cron으로 스크립트 실행 | 핵심 |
T1562.012는 보안 무력화 공격(T1562) 기법군의 일부로, 플랫폼별 특화된 접근법을 보여줍니다. Windows 이벤트 로그 비활성화(T1562.002)와 비교하면, Linux 환경의 감사 시스템이 더 세밀한 제어와 영구적 설정 변경이 가능하다는 특징이 있다.
또한 명령 히스토리 삭제(T1562.003)와 함께 사용될 때 더욱 철저한 흔적 제거가 가능한다. 공격자들은 종종 이 두 기법을 연계하여 시스템 레벨 감사와 사용자 레벨 히스토리를 동시에 제거한다.
Linux Audit System은 시스템 보안의 핵심 구성 요소이지만, 공격자들의 표적이 되기 쉬운 단일 장애 지점이기도 한다. 다층 보안 접근법과 지속적인 모니터링이 필요하다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.