MITRE ATT&CK: T1562.012 (Disable or Modify Linux Audit System) | 전술: Defense Evasion | 플랫폼: Linux
도입: 왜 이 공격이 중요한가
리눅스 서버에서 해커가 가장 먼저 꺼버리고 싶어하는 것이 뭘까요? 바로 auditd라는 감사 시스템입니다. 이 시스템은 서버에서 일어나는 모든 중요한 활동들 - 누가 로그인했는지, 어떤 파일에 접근했는지, 어떤 명령어를 실행했는지 - 을 빠짐없이 기록하거든요.
해커 입장에서는 자신의 행적이 다 기록되는 게 부담스럽죠. 그래서 root 권한을 얻자마자 auditd를 꺼버리거나 설정을 조작해서 자신의 활동만 기록되지 않도록 만드는 겁니다.
💡 쉬운 비유: 은행에 침입한 도둑이 CCTV 녹화 장치를 꺼버리거나 자신이 찍힌 부분만 삭제하는 것과 같아요.
1. 공격자 관점
왜 이 기법을 사용하는가
- 완벽한 은밀성: 자신의 활동이 로그에 남지 않아 나중에 포렌식 조사를 받아도 추적이 어려워짐
- 지속성 확보: 백도어나 악성 파일 설치 과정이 기록되지 않아 오랫동안 숨어있을 수 있음
- 간단한 실행: root 권한만 있으면 몇 개 명령어로 쉽게 무력화 가능
동작 흐름
해커는 먼저 auditd가 실행 중인지 확인하고, systemctl 명령어로 서비스를 중단하거나 kill 명령어로 프로세스를 직접 종료합니다. 더 교묘한 경우에는 /etc/audit/audit.rules 파일을 수정해서 특정 활동만 기록되지 않도록 만들기도 해요.
💡 쉬운 비유: 경비원을 잠재우거나 아예 보초실에서 내보낸 다음, 마음껏 건물을 뒤지는 것과 같습니다.
2. 실제 공격 사례
📌 Ebury 백도어 - OpenSSH 타겟팅 캠페인 (2009-2024)
배경: Ebury는 15년 넘게 활동해온 정교한 리눅스 백도어로, 주로 웹 서버와 호스팅 업체를 타겟으로 삼았습니다. 이 백도어의 가장 무서운 점은 탐지를 피하기 위해 시스템의 로깅 기능을 완전히 무력화시킨다는 거예요.
공격 과정:
- SSH 서버의 취약점을 악용하거나 탈취한 자격증명으로 시스템에 침투
- Ebury 백도어가 활성화되면 즉시 OpenSSH, systemd, 그리고 auditd 로그를 모두 비활성화
- 시스템에서 일어나는 모든 악성 활동이 기록되지 않은 채로 크리덴셜 스틸링, 트래픽 프록싱, 스팸 발송 등을 수행
피해 규모: 전 세계 40만 대 이상의 리눅스 서버가 감염되었으며, 특히 호스팅 업체들이 대거 피해를 입었습니다.
3. 왜 탐지가 어려운가?
공식 탐지 방법
DET0062 리눅스 감사 시스템 비활성화/수정 탐지 전략 - AN0171: 프로세스 종료(auditd 종료), 서비스 관리(systemctl stop auditd), 또는 규칙/설정 파일(/etc/audit/audit.rules, audit.conf) 변조를 통한 리눅스 감사 시스템 비활성화나 수정을 탐지. 방어자 관점에서는 auditctl/systemctl 명령어의 의심스러운 실행, 감사 규칙 파일 수정, 또는 권한 있는 실행과 연관된 감사 로그의 갑작스러운 부재를 모니터링해야 함.
공격자가 이 기법을 선호하는 이유
- 자기 파괴적 특성: auditd를 끄는 순간부터 그 이후의 모든 활동이 기록되지 않아서, 공격 자체의 흔적이 사라짐
- 정당한 관리 작업으로 위장: systemctl이나 kill 명령어는 시스템 관리자가 일상적으로 사용하는 명령어라서 의심받지 않음
- 복구의 어려움: 로그가 없으면 무엇이 해킹당했는지, 언제부터 침투가 시작되었는지 파악하기 거의 불가능
탐지의 현실적 한계
위의 공식 탐지 방법들이 있다고 해도, 실제로는 탐지가 매우 어려워요. auditd가 꺼지는 순간 그 이후의 모든 활동이 기록되지 않기 때문에, 공격이 진행되고 있다는 것 자체를 알기 어렵거든요. 게다가 많은 기업에서 auditd 로그를 실시간으로 모니터링하지 않고, 설령 모니터링을 한다고 해도 시스템 재부팅이나 정당한 유지보수로 인한 서비스 중단과 구분하기 쉽지 않습니다.
4. 나도 위험할까? 자가 진단
이 공격이 나와 관련 있는지 확인해보세요.
이런 환경이라면 주의가 필요합니다
- 리눅스 서버를 운영하고 있지만 auditd 로그를 정기적으로 확인하지 않는 경우
- SSH 접속을 허용하는 서버가 있는데 강력한 인증 방식(MFA 등)을 사용하지 않는 경우
- 시스템 관리자 계정이 여러 명에게 공유되어 누가 언제 접속했는지 추적이 어려운 경우
- 웹 서버나 호스팅 서비스를 운영하면서 보안 업데이트가 늦어지는 경우
공식 대응 방안
M1047 감사: 로깅 설정을 수정할 권한이 예상되는 사용자와 역할에게만 있는지 계정 역할 권한을 정기적으로 확인. 감사 규칙이 런타임에 수정되지 않도록 하려면 audit.rules 파일의 마지막 명령으로 auditctl -e 2를 추가. 시작된 후에는 이 모드에서 설정을 변경하려는 모든 시도가 감사되고 거부됨. 설정은 시스템을 재부팅해야만 변경 가능.
M1018 사용자 계정 관리: 공격자가 이 기법을 완전히 활용하려면 이미 로컬 시스템에서 root 수준의 접근 권한을 가지고 있어야 함. 사용자와 계정을 필요한 최소 권한으로 제한해야 함.
당장 할 수 있는 것
- 리눅스 서버를 운영한다면 auditd 서비스가 정상 실행 중인지 주기적으로 확인하기 (
systemctl status auditd) - 서버 접속 시 평소와 다른 점(로그인 기록이 없어진다든지)을 발견하면 즉시 전문가에게 문의하기
- 🏢 보안 담당자: auditd 설정에서
auditctl -e 2옵션을 활성화해 런타임 설정 변경을 차단하고, 중앙 로그 서버로 실시간 전송 설정
5. 관련 기술
| 기법 | 어떤 상황에서 함께 사용되나 |
|---|---|
| T1070.002 Clear Linux or Mac System Logs | auditd를 끈 후에도 이전에 남겨진 로그 파일들을 완전히 삭제해서 흔적을 없애고 싶을 때 |
| T1222 File and Directory Permissions Modification | 백도어 파일의 권한을 변경하거나 시스템 파일에 접근할 때, 이런 권한 변경 활동이 auditd에 기록되지 않도록 미리 무력화할 때 |
참고 자료
📌 이 글은 AI(Claude) 를 활용하여 작성되었으며, MITRE ATT&CK v18.0 기준 (2025-10-28) 을 기준으로 합니다. 본 콘텐츠는 보안 교육 및 방어 목적으로만 제공되며, 이를 악용한 불법 행위에 대한 책임은 전적으로 행위자 본인에게 있습니다.
?뱛 ??湲? [蹂댁븞 臾대젰??T1562) ?쒕━利?(/blog/t1562-impair-defenses)???쇰??낅땲??
COMMENTS (0)
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.