MITRE ATT&CK: T1036.010 (Masquerade Account Name) | 전술: Defense Evasion | 플랫폼: Azure AD, Google Workspace, IaaS, Linux, Network, Office 365, SaaS, Windows, macOS
도입: 왜 이 공격이 중요한가
2016년 우크라이나 전력망이 마비됐을 때, 조사팀이 발견한 건 단순했습니다. 시스템에 "admin"과 "система(System)"라는 이름의 계정 두 개가 새로 만들어져 있었거든요. 언뜻 보면 정상적인 관리자 계정 같잖아요?
Masquerade Account Name 은 공격자가 정상적인 계정명과 유사하거나 일반적으로 신뢰받는 이름으로 계정을 생성하여 의심을 피하는 기법입니다. "backup", "help", "root", "service" 같은 이름들이 대표적이죠.
💡 쉬운 비유: 가짜 신분증을 만들 때 "김철수"보다 "관리자"라고 쓰면 더 의심받지 않는 것과 같습니다.
1. 공격자 관점
왜 이 기법을 사용하는가
- 관리자 착각 유도: "backup", "service" 같은 이름은 IT 담당자도 기존 서비스 계정으로 오인하기 쉬움
- 자동화 도구 우회: 많은 보안 솔루션이 계정명 패턴을 기반으로 이상 징후를 탐지하는데, 일반적인 이름은 필터링에서 제외됨
- 사회공학적 효과: 헬프데스크나 다른 직원들이 "admin" 계정의 활동을 의심하지 않음
동작 흐름
공격자는 보통 다음과 같은 단계로 계정명 위장을 진행합니다:
| 단계 | 설명 | 목적 |
|---|---|---|
| 1. 기존 계정 조사 | Account Discovery(T1087)로 현재 시스템의 계정 명명 규칙 파악 | 자연스러운 이름 선택 |
| 2. 계정 생성/변경 | Create Account(T1136) 또는 기존 계정 이름 변경 | 백도어 계정 확보 |
| 3. 권한 상승 | 생성한 계정에 관리자 권한 부여 | 시스템 완전 장악 |
| 4. 지속성 확보 | 정상 계정으로 위장하여 장기간 활동 | 탐지 회피 |
특히 교묘한 점은 기존 계정을 먼저 삭제하고 같은 이름으로 새 계정을 만드는 경우입니다. 로그상으로는 계정 삭제와 생성이 기록되지만, 관리자는 "기존 계정을 재생성한 것"으로 오해하기 쉽거든요.
2. 실제 공격 사례
📌 Sandworm Team - 2016 Ukraine Electric Power Attack (2016)
배경: 러시아 연계 APT 그룹 Sandworm Team이 우크라이나 전력 인프라를 겨냥한 사이버 공격에서 전력망을 실제로 차단시킨 사건입니다.
공격 과정:
- 초기 침입: 스피어 피싱으로 전력회사 직원 PC 감염
- 계정 위장: "admin"과 "система(System)" 두 개의 새 계정 생성
- 전력망 조작: 위장 계정으로 SCADA 시스템에 접근하여 변전소 차단
피해 규모: 우크라이나 서부 지역 약 23만 명이 수 시간 동안 정전
출처: Anatomy of an Attack: Detecting and Defeating CRASHOVERRIDE
📌 Dragonfly - 미국 에너지 인프라 침투 (2018)
배경: 러시아 연계 APT 그룹 Dragonfly(Energetic Bear)가 미국 전력회사와 에너지 기업들을 대상으로 한 장기간 스파이 활동입니다.
공격 과정:
- 수급망 침해: 에너지 업계 소프트웨어 벤더를 통한 초기 침입
- 계정 위장: "backup", "service", "email_admin" 등 서비스 계정으로 위장한 새 계정들 생성
- 네트워크 확산: 위장 계정으로 내부 네트워크를 탐색하며 중요 시스템 접근
피해 규모: 미국 에너지 부문 수십 개 기업의 운영 기술(OT) 네트워크까지 침투
출처: Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors
📌 Magic Hound - ProxyShell 자동화 공격 (2022)
배경: 이란 연계 APT 그룹 Magic Hound가 Microsoft Exchange ProxyShell 취약점을 자동화하여 대량 침투를 시도한 캠페인입니다.
공격 과정:
- ProxyShell 익스플로잇: Exchange 서버의 인증 우회 취약점 악용
- 계정 위장: 침해한 시스템마다 "help", "DefaultAccount" 로컬 계정 생성
- 백도어 설치: 위장 계정을 통해 웹셸과 원격 접근 도구 배포
피해 규모: 전 세계 수백 개 조직의 Exchange 서버가 동시에 침해됨
출처: APT35 Automates Initial Access Using ProxyShell
3. 왜 탐지가 어려운가?
공식 탐지 방법
DET0383 Detection Strategy for Masquerading via Account Name Similarity - AN1077: 새로 생성되거나 이름이 변경된 사용자 계정이 기존 서비스나 관리자 계정과 유사한 패턴을 보이는 경우를 탐지합니다. 'admin1', 'adm1n', 'backup_help' 같은 접두사/접미사 변형이나 동형 문자 사용을 모니터링합니다.
공격자가 이 기법을 선호하는 이유
인간의 인지적 한계 악용: 시스템 관리자들은 하루에 수십 개의 알림을 받는데, "admin" 계정 생성 로그는 "당연한 관리 작업"으로 넘어가기 쉽습니다. 특히 대기업에서는 여러 팀이 각자 관리 계정을 만들어서 누가 만든 건지 확인하기 어려워요.
명명 규칙의 맹점: 대부분 조직이 "서비스 계정은 service_로 시작", "관리자 계정은 admin_으로 시작" 같은 규칙을 가지고 있는데, 공격자는 이런 규칙을 역이용합니다. 오히려 규칙을 따르는 계정이 더 의심받지 않거든요.
자동화 도구의 화이트리스트: 많은 SIEM과 EDR 솔루션이 "admin", "backup", "service" 같은 일반적인 이름을 기본 화이트리스트에 포함시킵니다. 이런 계정의 활동은 알림 임계값이 높게 설정되어 있어서 웬만한 행동으로는 경보가 발생하지 않아요.
탐지의 현실적 한계
False Positive 문제: 정상적인 관리 작업과 구분하기가 정말 어렵습니다. 새로운 IT 담당자가 들어와서 "admin_newguy" 계정을 만드는 것과 공격자가 만든 "admin_backup" 계정을 어떻게 구분할 수 있을까요?
계정 생성 권한의 분산: 대기업에서는 여러 부서가 각자 서비스 계정을 만들 권한을 가지고 있어서, 중앙에서 모든 계정 생성을 추적하기 어렵습니다. 특히 클라우드 환경에서는 개발팀, 운영팀, 보안팀이 각자 다른 도구로 계정을 관리하거든요.
로그 보관 기간의 한계: 공격자가 몇 달 후에 계정을 활성화하면, 계정 생성 당시의 컨텍스트를 파악하기 어려워집니다. "이 계정을 누가 언제 왜 만들었는지" 추적하려면 여러 시스템의 로그를 교차 분석해야 하는데, 실무에서는 시간과 인력이 부족해서 쉽지 않아요.
4. 나도 위험할까? 자가 진단
이 공격이 나와 관련 있는지 확인해보세요.
이런 환경이라면 주의가 필요합니다
- 회사에서 여러 부서가 각자 서비스 계정을 만들 수 있는 권한을 가지고 있다
- Active Directory나 클라우드 계정 관리에서 계정 생성 승인 프로세스가 없거나 형식적이다
- 시스템에 "admin", "backup", "service" 같은 이름의 계정이 여러 개 존재한다
- 계정 생성 로그를 정기적으로 검토하지 않거나, 누가 언제 만들었는지 추적하기 어렵다
공식 대응 방안
M1047 Audit (감사): 각 사용자 계정이 명확한 목적을 가지고 있는지 정기적으로 감사하세요.
M1018 User Account Management (사용자 계정 관리): 사용자 계정의 명명 규칙을 정의하고 시행하여 일반적인 계정명 스키마에 맞지 않는 계정을 쉽게 발견할 수 있도록 하세요.
당장 할 수 있는 것
- 개인 PC나 홈 서버에서 "admin", "guest", "user" 같은 기본 계정명 대신 고유한 이름 사용하기
- 회사 시스템에서 의심스러운 새 계정(특히 관리자 권한을 가진)을 발견하면 IT 팀에 즉시 문의하기
- 🏢 보안 담당자: 계정 생성 시 승인자, 목적, 만료일을 필수로 기록하는 워크플로우 구축하고, 주기적으로 "orphan accounts" 점검하기
5. 관련 기술
| 기법 | 설명 | 링크 |
|---|---|---|
| T1136 Create Account | 계정명 위장의 전제 조건이 되는 새 계정 생성 기법으로, 공격자가 시스템 접근 권한을 확보한 후 지속성을 위해 사용 | MITRE 참고 |
| T1087 Account Discovery | 기존 계정 명명 규칙을 파악하여 자연스러운 위장 계정명을 선택하기 위한 정찰 기법 | MITRE 참고 |
| T1531 Account Access Removal | 기존 계정을 삭제한 후 같은 이름으로 새 계정을 만들어 더욱 교묘하게 위장하는 기법 | MITRE 참고 |
참고 자료
- [MITRE ATT&CK - T1036.010](https://attack.mitre.org/techniques/T1036/010/)
관련 글 더 보기
- EDR 우회 공격: 보안 도구를 무력화하는 첫 번째 단계 | T1562.001
- MITRE T1562 Impair Defenses 12가지 보안 무력화 기법 분석 | T1562
- Linux auditd 무력화로 흔적 남기지 않는 해킹 기법 | T1562.012
- 가짜 보안 알림 스푸핑: BlackBasta가 보안팀을 속이는 방법 | T1562.011
- 안전 모드 부팅으로 EDR 우회: 공격자가 보안 솔루션을 무력화하는 방법 | T1562.009
- 방화벽 무력화 공격의 실체: APT28·APT38 사례로 본 침투 전술 | T1562.004
- 프로세스 인수 덮어쓰기: 공격자가 정상 데몬으로 위장하는 원리 | T1036.011
- 브라우저 핑거프린트 위조: 공격자가 네트워크 탐지를 우회하는 원리 | T1036.012
- Kerberos 티켓 탈취·위조: 도메인 인증을 우회하는 5가지 기법 | T1558
- Golden Ticket 공격: 도메인 전체를 영구 지배하는 Kerberos 위조 원리 | T1558.001
안내 및 법적 고지
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었으며, MITRE ATT&CK (최신 버전) 기준 정보를 포함합니다. 기술적 내용은 MITRE ATT&CK 공식 데이터를 기반으로 하며, 보안 교육 목적으로 제공됩니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.
COMMENTS (0)
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.