보안 업체 CloudSEK과 Gambit Security는 2026년 8월 27일 랜섬웨어 Aurora 운영자의 노출된 공격 인프라를 분석한 보고서를 각각 공개했다. Gambit에 따르면 운영자는 4월 8일부터 5월 21일까지 10개 대상 조직에서 AI 코드 편집기의 에이전트 기능에 VPN 접속, 내부 스캔, 권한 수집, NTLM 릴레이, 인증서 공격 명령을 맡겼고, CloudSEK은 러시아어를 쓰는 Aurora 제휴 공격자(affiliate)가 4~7월 9개국 20개 넘는 조직을 침해해 17곳에서 도메인 수준 또는 대화형 접근을 얻었으며 그중 4곳이 유출 사이트에 올랐다고 밝혔다.
두 보고서가 공개한 인프라 IP 6개와 암호화 도구 해시, 협상 사이트 주소가 겹쳐 같은 운영자의 활동으로 보인다(분석). 다만 두 회사가 같은 서버를 봤는지는 밝혀지지 않았고 집계 기준과 기간이 달라 숫자를 합치면 안 된다. 다른 AI 해킹 사고는 AI 해킹 사고 사례 2026에 모았다.
AI가 새 공격 기법을 만든 사건은 아니다. 에이전트는 NetExec, ntlmrelayx, Certipy 같은 공개 도구로 오래 알려진 Active Directory(AD)·인증서 서비스(AD CS)·ESXi 약점을 노렸다. 그래서 먼저 2026년 4월 이후 VPN 로그인 출발지를 공개 IP와 대조하고, 설명되지 않는 인증서 발급을 찾고, ESXi·리눅스 서버에 /etc/ssh/sshd-banner 파일이 생겼는지 본다.
한눈에 보기
| 항목 | 내용 |
|---|---|
| 언제 | 침해 활동 2026년 4~7월(CloudSEK), AI 에이전트 세션 4월 8일~5월 21일(Gambit), 보고서 공개 8월 27일 |
| 누가 | 러시아어를 쓰는 Aurora 제휴 공격자. CloudSEK은 접근 브로커가 아니라 암호화까지 직접 한다고 '높은 신뢰도'로 평가 |
| 무엇이 뚫렸나 | VPN(확보한 자격 증명이나 기존 경로), AD 도메인, 백업 시스템 자격 증명. AD CS 템플릿·웹 등록과 ESXi는 공격 대상 |
| AI가 한 일 | 공격 순서와 러시아어 AD CS 공격 계획 작성(CloudSEK). 에이전트 기능이 VPN 접속부터 인증서 공격까지 명령 실행, 대부분 첫 시도는 실패(Gambit) |
| 사람이 한 일 | 자격 증명·접속 경로 제공, 목표·도구·계획 지정과 후보 번호 선택, 'DCSync·계정 잠금·컴퓨터 추가 금지' 제약, 암호화 도구 반입 |
| 피해·영향 | 일부 조직의 도메인 장악(krbtgt 추출 포함), 와일드카드 TLS 인증서 개인키 탈취, 50GB 단위 유출, 4곳 유출 사이트 게시, 결제 지갑 잔액 7 BTC(분석 시점) |
| 지금 상태 | 알려진 결함·설정 문제라 MS17-010·KB5008380·KB5005413 조치와 CloudSEK 완화책 7개로 막을 수 있다(분석). CloudSEK은 공개 전 국가 CERT·피해 조직 통보를 시작했다. AI 도구 제공사의 대응은 두 보고서에 없다 |
| 출처 신뢰도 | 두 회사의 공격자 인프라 직접 분석(1차 자료). 피해 조직명, 몸값 총액, 자격 증명 획득 경로는 비공개 |
무슨 일이 있었나: 타임라인
- 2026년 4~7월: CloudSEK이 찾은 노출 디렉터리의 기록 범위. 피해 국가 중 미국 비중이 가장 컸다.
- 2026-04-08~05-21: Gambit이 AI 코드 편집기 에이전트 세션을 관찰한 기간(대상 조직 10곳).
- 날짜 미공개: 피해 조직 4곳이 유출 사이트에 올랐다. 기록된 접근부터 게시까지 최단 약 2주, 길어도 두어 달이었다(CloudSEK).
- 2026-08-27: CloudSEK이 'Caught in 4K: The Aurora Files'를 공개했다. 같은 날 Gambit Security도 보고서를 냈다.
공격 흐름 단계별 분석
ATT&CK 번호는 원문에 없어 이 글에서 붙였다(분석). Gambit의 2차 클러스터(8개 조직, SQL Server xp_cmdshell·GodPotato·DCSync·s5cmd 유출)는 귀속이 중간 신뢰도이고 다른 운영자일 수 있어 단계에 섞지 않았다.
1단계 진입: 확보한 자격 증명으로 VPN·SOCKS 터널 접속
- 무엇을: 에이전트는 운영자가 넘긴 자격 증명이나 기존 접속 경로로 VPN 클라이언트나 proxychains를 설정해 접속했다(Gambit). 피해자를 향한 행위는 모두 임차 SOCKS 피벗(주로 독일·미국 VPS)을 거쳤고, 전문·금융 서비스 업종에서는 SSL-VPN 자격 증명을 확인한 기록이 나왔다(CloudSEK).
- 기법: 유효 계정(T1078), 외부 원격 서비스(T1133), 프록시(T1090).
- 흔적: VPN 인증 로그의 IOC IP·처음 보는 VPS 대역 로그인 성공, 그 세션에 할당된 내부 IP에서 시작된 스캔(일반 점검).
2단계 내부 정찰: 서브넷 스캔, LDAP·SMB 열거, ESXi 찾기
- 무엇을: 운영자는 매번 같은 순서로 NetExec 기반 LDAP·SMB 탐색, 비밀번호 정책 조회, AS-REP Roasting, Kerberoasting을 돌렸다(CloudSEK). 에이전트는 Nmap·NetExec로 서브넷을 스캔하고 BloodHound 수집기로 받은 계정의 권한을 보고했다. 자체 모듈 esxi_finder.py는 LDAP로 알아낸 서브넷의 443·902 포트를 스캔하고 TLS 인증서와
/sdk·/ui/응답으로 ESXi·vCenter 빌드를 식별한다(Gambit). - 기법: 네트워크 서비스·도메인 계정·그룹 탐색(T1046, T1087.002, T1069.002).
- 흔적: 내부 방화벽·NDR의 포트 스윕, ESXi·vCenter 접근 로그의
/sdk·/ui/요청.
3단계 자격 증명 탈취: 로스팅, 브라우저 저장 비밀번호, SAM·LSA
- 무엇을: Kerberoasting과 AS-REP Roasting은 모든 작전에서 돌렸다. 7개 브라우저를 노리는 자체 모듈도 썼다. 노출 디렉터리에는 SAM·LSA 덤프와 Kerberos 티켓이 있었고, 제조 업종 피해 조직에서는 Azure AD Connect 동기화 계정 해시도 나왔다(CloudSEK).
- 기법: Kerberoasting(T1558.003), AS-REP Roasting(T1558.004), 브라우저 자격 증명(T1555.003), OS 자격 증명 덤프(T1003).
- 흔적: DC 보안 로그 4769·4768(일반 점검), EDR의 브라우저 프로필 대량 읽기.
4단계 권한 상승: NTLM 릴레이, AD CS 악용, noPac
- 무엇을: CloudSEK이 정리한 경로는 셋이다. 직접 짠 noPac 스크립트(머신 계정 이름 변경, TGT, S4U2self), AD CS ESC1·ESC6·ESC8 악용, PetitPotam·PrinterBug·DFSCoerce로 인증을 강제한 NTLM 릴레이(DCSync에 해당하는 변형 포함)다. 에이전트도 PetitPotam·Coerce Plus·PrinterBug와 Impacket ntlmrelayx로 릴레이하고 Certipy로 인증서 공격을 했다(Gambit). 도메인 관리자 인증서를 받을 수 있는 템플릿 오류를 찾아 실제로 시도한 조직도 있었고, 한 대상에서는 EternalBlue(MS17-010)로 계정을 직접 만들었다.
- 기법: 강제 인증(T1187), NTLM 릴레이(T1557.001), 인증서 악용(T1649), 취약점 악용(noPac T1068, EternalBlue T1210). noPac은 KB5008380이 고친 CVE-2021-42287과 관련된 공격으로 알려져 있다(원문에는 CVE 표기 없음).
- 흔적: AD CS 서버의 4624·IIS 로그, CA 감사 로그 4886·4887, DC의 4768·4781(일반 점검), DC System 로그의 KDC 이벤트 35~38(KB5008380).
5단계 도메인 장악과 수집·유출
- 무엇을: evil-winrm·chisel·proxychains로 이동하고 Metasploit 핸들러를 C2로 썼다. 일부 조직은 krbtgt 추출까지 도메인이 넘어갔고 RDP 세션, 그룹 정책·SYSVOL 유출, 와일드카드 TLS 인증서 개인키 탈취도 나왔다. 데이터는 PowerShell로 7-Zip을 돌려 50GB 단위로 압축·스테이징한 뒤 가져갔고 목적지는 원문에 없다(CloudSEK).
- 기법: WinRM(T1021.006), RDP(T1021.001), 터널링(T1572), 아카이브 압축(T1560.001).
- 흔적: 지정 관리 호스트 밖에서 온 WinRM(5985·5986) 접속, 명령줄의 7z 분할 압축, 도메인 정책보다 수명이 긴 Kerberos 티켓(CloudSEK 권고 3).
6단계 백업·ESXi 겨냥과 암호화
- 무엇을: CloudSEK은 백업 시스템 자격 증명 확인을 '전형적인 암호화 직전 지표'로 봤다. 암호화 도구는 Zig로 만든 Windows용 sap.exe와 Linux·ESXi용 encrypt.out이고, 공개 Cloudflare R2 버킷에서 받아 scp로 스테이징 호스트에 보냈다(CloudSEK). encrypt.out의
-esxi모드는esxcli vm process list로 VM의 World ID를 모아esxcli vm process kill --type=force --world-id=<id>로 강제 종료한 뒤 VM 파일(vmdk·vmx·vmem 등)만 암호화하고 시스템 볼륨은 건너뛴다. 협박문은/etc/ssh/sshd-banner에 써서 SSH 로그인 전에 보이게 한다(Gambit). Windows 변종은 섀도 복사본을 지우고 레지스트리로 시스템 복원을 끈다(CloudSEK). - 기법: 도구 반입(T1105), 서비스 중지(T1489), 복구 방해(T1490), 데이터 암호화(T1486).
- 흔적:
*.r2.dev다운로드, 백업 콘솔 관리자 로그인, 여러 VM 연쇄 강제 종료,sshd_config변경과 SSH 재시작(CloudSEK Sigma 룰). 섀도 복사본 삭제 같은 공통 행위는 AI 랜섬웨어 행위 기반 탐지·복구 점검 9가지에 정리했다.
7단계 협박과 결제
- 무엇을: Gambit은 암호화 도구에 박힌 Tor 협상 사이트와 유출 사이트 exposedrecords[.]io를 공개했다. CloudSEK은 암호화 도구에서 나온 키로 합의까지 끝난 협상 기록을 봤고, 결제 지갑에는 분석 시점 7 BTC가 있었다.
- 흔적: SSH 배너·랜섬노트에 적힌 onion 주소, 프록시·DNS의 exposedrecords[.]io 조회(일반 점검).
AI는 정확히 무엇을 했나
AI가 한 일
- 계획(CloudSEK): 관찰 기간 마지막 몇 주의 기록에서 AI 코드 편집기는 공격 순서를 작성하고 따져 보는 데 쓰였고, 러시아어 AD CS 공격 계획 전체도 이 도구로 썼다. CloudSEK은 운영자가 새 작전마다 계획을 AI에 점점 더 기댔다고 평가했다.
- 실행(Gambit): 에이전트 기능(앤트로픽의 AI 모델로 구동)은 10개 대상 조직의 세션에서 1·2·4단계 명령을 실행했다. 총 명령 수는 공개되지 않았다.
- 시행착오: 명령 대부분은 첫 시도에 실패해 여러 번 고쳐졌고 일부는 결국 성공했다(Gambit). 방어 쪽에서는 조금씩 바뀌며 반복되는 실패가 단서다(분석).
사람이 한 일
- 접근 수단: 자격 증명이나 기존 접속 경로를 에이전트에 넘겼다.
- 지휘: 목표만 주거나('이 사용자의 권한을 알려 줘'), 쓸 도구를 정하거나, '이전에 생성된 공격 계획'을 따르게 했다. 에이전트가 다음 단계 후보를 내놓으면 번호 하나로 답하기도 했다.
- 제약: 모든 피해 조직에서 러시아어로 'DCSync는 절대 하지 마라'(최소 다섯 번, 대신 DC 머신 해시 요구), '계정을 잠그면 안 된다'(모든 스프레이·추측 요청), '도메인에 컴퓨터를 추가하지 마라'를 반복했다. 이유는 원문에 없다.
- 암호화와 도구: 암호화 도구 반입·배포와 비공개 GitLab의 자체 NetExec 모듈 운영은 운영자 몫이다. 모듈을 AI로 만들었는지는 원문에 없다.
과장된 해석 바로잡기
- 'AI가 만든 랜섬웨어'가 아니다. 암호화 도구를 AI가 썼다는 서술은 없다.
- 'AI가 혼자 뚫었다'가 아니다. 접속 수단은 사람이 줬고 유출·협상·결제에 AI를 썼다는 근거도 없다. 10개 대상 중 실제 침해된 곳의 수도 Gambit 보고서에 없다.
- 'AI 흔적을 찾으면 된다'도 아니다. 에이전트는 VPN·SOCKS 터널 너머에서 공개 도구를 돌렸고, 피해 시스템에 AI 도구 고유의 흔적이 남았다는 보고는 없다. 행위로 탐지한다.
왜 뚫렸나: 원인
기술 원인
- 릴레이를 받아 주는 인증 경로: CloudSEK 권고 1은 LLMNR·NBT-NS 활성, SMB 서명과 인증 확장 보호(EPA) 미적용을 겨냥한다. 마이크로소프트는 PetitPotam을 '전형적인 NTLM 릴레이 공격'으로 보고 릴레이 보호가 없는 AD CS 웹 등록(CA Web Enrollment·CES)을 표적으로 든다(KB5005413).
- 인증서 템플릿·CA 설정: 운영자는 요청자가 주체·SAN을 넣을 수 있는 구성(ESC1·ESC6)으로 도메인 관리자 인증서를 노렸다(CloudSEK).
- 특권 계정의 SPN과 지원 종료 OS: 특권 계정, 특히 기본 Administrator에 SPN이 있으면 로스팅으로 깬 비밀번호가 곧 특권이 된다(CloudSEK 권고 4, 분석). 운영자는 서명 없이 null 세션 SMBv1로 닿는 지원 종료 호스트를 반복해 찾아 썼다(CloudSEK).
- 내부망에서 닿는 ESXi 관리 포트(443·902): 관리망을 나눴다면 2단계의 ESXi 탐색이 막힌다(분석).
운영 원인
- 유효한 VPN 자격 증명이나 기존 접속 경로가 공격자 손에 있었다. 획득 경로와 피해 조직의 MFA 적용 여부는 밝혀지지 않았다.
- 백업이 운영 AD와 가까웠던 것으로 보인다. 백업 자격 증명이 확인됐고 CloudSEK 권고 6은 다른 자격 증명·네트워크 구간으로의 분리를 요구한다(분석).
- 흔한 경보만 믿기 어렵다. 운영자는 에이전트에 DCSync·계정 잠금·컴퓨터 추가를 금지했고(Gambit, 실제로 다 지켜졌는지는 보고서에 없다), 접근부터 유출 사이트 게시까지 최단 약 2주였다(CloudSEK). 경보부터 격리까지 목표를 시간 단위로 잡는다(분석).
우리 조직에서 찾아볼 흔적
IOC와 명령 문자열은 두 보고서 원문에서 옮겼고 이벤트 ID와 조건은 일반 점검이다. 임차 VPS 주소는 재할당될 수 있어 2026년 4월 이후 기록의 소급 헌팅에 쓰고, 조건은 1주일 치 기록으로 오탐을 거른 뒤 경보로 올린다.
| 확인할 곳 | 볼 내용 | 예시 조건 |
|---|---|---|
| VPN 게이트웨이 인증 로그(원격지 IP·사용자·할당 내부 IP) | 로그인 성공 원격지 | 2026-04-01 이후 아래 IOC IP와 일치, 또는 처음 보는 호스팅·VPS 대역에서 성공 |
| 프록시·DNS·방화벽 | 도구 다운로드·C2 | 아래 R2 주소 접속, 서버 대역의 *.r2.dev 실행 파일 다운로드, IOC IP로의 송신 |
| DC 보안 로그 4769·4768·4771·4776 | 로스팅·스프레이 | 한 계정의 여러 SPN RC4(0x17) 티켓 요청, 사전 인증 유형 0, 한 출발지가 여러 계정에 1~2회씩 실패(잠금 이벤트 4740만 보면 놓친다) |
| AD CS 서버 4624·IIS 로그 | ESC8 릴레이 | DC 컴퓨터 계정이 DC가 아닌 IP에서 NTLM 로그온, 직후 /certsrv/ 요청 |
| CA 감사 로그 4886·4887 | 이상 발급 | DC·관리자 명의 인증서, 요청자가 주체를 넣는 템플릿(ENROLLEE_SUPPLIES_SUBJECT) 요청 |
| DC 4768·4781·4662, System 로그의 KDC 이벤트 35~38 | 인증서 로그온·noPac·DCSync | 인증서 정보 칸이 채워진 DC·관리자 TGT(4768), 컴퓨터 계정 이름이 DC 이름($ 없이)으로 바뀜(4781), 복제 권한 접근(4662)을 4624 로그온 ID로 이어 허용된 DC·동기화 서버 밖 출발지 확인(DC 계정 포함, SACL 감사 필요) |
| EDR(Sysmon 1·4688 명령줄, 파일 접근) | 압축·브라우저 비밀번호·SQL | powershell.exe → 7z 분할 압축(-v), 브라우저가 아닌 프로세스의 프로필 폴더 연속 읽기(CloudSEK 권고 5), 2차 클러스터의 sqlservr.exe → cmd.exe·powershell.exe와 s5cmd 실행 |
| 백업 콘솔 감사 로그 | 백업 관리자 계정 | 업무 시간 외, 비관리 단말, VPN 출발지 로그인 |
내부 방화벽, ESXi /var/log/shell.log·hostd.log, vCenter 이벤트 |
ESXi 탐색과 VM 종료 | 관리망 밖 443·902 스윕과 /sdk·/ui/ 요청, esxcli vm process kill --type=force, 한 호스트의 여러 VM이 몇 분 안에 꺼짐(도구 내부 명령은 셸 기록에 없을 수 있다) |
| ESXi·리눅스 파일과 auditd | SSH 배너 협박문 | /etc/ssh/sshd-banner 존재, sshd_config의 Banner 줄, /etc/init.d/SSH restart. CloudSEK의 실험 단계 Sigma 룰은 리눅스 auditd의 한 CommandLine에 /etc/ssh/sshd_config, sshd-banner, init.d·SSH·restart가 모두 있어야 맞는다. ESXi는 설정 변경과 SSH 재시작을 같은 호스트·시간대로 묶어 본다(일반 점검) |
공개 IOC는 아래와 같다.
- 운영자 VPS·C2: 172.86.113.245, 172.86.90.75(두 보고서 공통), 144.172.116.150(CloudSEK).
- SOCKS 피벗: 104.194.134.167(CloudSEK: 운영자 VPS 겸 SOCKS 중계), 89.106.83.49, 45.61.148.166(포트 21056), 167.88.167.37(포트 50167, CloudSEK: C2 이그레스 확인용), 23.234.108.48(CloudSEK), 68.210.224.231(Gambit).
- SOCKS 피벗(Gambit 중간 신뢰도): 45.61.134.62, 45.59.113.63, 144.172.95.50, 77.110.125.143, 81.177.215.15, 45.142.31.17, 45.32.186.198, 217.69.8.54.
- 2차 클러스터(Gambit, 귀속 중간 신뢰도): C2 146.19.125.36, S3 유출 노드 157.173.29.133, 93.157.139.115, 93.157.139.123, 152.236.4.14, 23.246.128.3.
- 해시: sap.exe(Windows) SHA-256
eb0aab1e892d7e09e2c7bcf1d21fd83c1743ed9196b3efac6c78482fb0d99207, encrypt.out(Linux·ESXi) SHA-256a4af136d159a8eb96b54924fa80355ca52874913301300f55af7d67ae97edcfe, MD5a607384ce68144f2061a8b30cc65a6b8. - 주소·파일명: 다운로드 URL
pub-c057b7d0b24944a29e381ce9ea22a2f1.r2[.]dev/xu4gid0t8er3.out, 협상 사이트ijexszhscln27nl263lmcd7tx3jttkhm4wjhd4e3y6r4csdbfyeprvid[.]onion, 유출 사이트exposedrecords[.]io. 랜섬노트 이름은 README 앞뒤에 느낌표가 3개씩 붙고 DO_NOT_DELETE.txt로 끝난다(검색 예:*README*DO_NOT_DELETE.txt).
대응 순서
오늘
- 보안관제: 2026-04-01 이후 VPN·프록시·DNS·EDR 기록에서 위 IOC를 찾고, ESXi·리눅스 서버의
/etc/ssh/sshd-banner와 Banner 줄을 확인한다. - 계정·네트워크 담당: 일치하는 VPN 로그인이 있으면 계정을 비활성화하고 세션을 끊고 출발지를 차단한 뒤 MFA 등록 기기와 최근 로그인 이력을 본다(일반 점검).
- 침해 대응 담당: 의심 호스트는 전원을 끄지 말고 네트워크에서 격리한 뒤 메모리·디스크 이미지를 확보하고, DC·CA·VPN·ESXi·백업 콘솔 로그를 덮어쓰기 전에 보관한다. 침해가 확인되면 인증서 폐기와 계정 복구를 이번 주로 미루지 않는다. 첫 1시간의 결정은 침해사고 1시간 골든타임 액션북에 있다.
- 인프라 담당: 백업 관리 계정 비밀번호를 바꾸고 오프라인·불변 사본을 확인한다. ESXi는 호스트 클라이언트나 vCenter에서 SSH·ESXi Shell 서비스를 멈추고 443·902 접근을 관리망으로 제한한다(일반 점검).
- AD 담당: AD CS 웹 등록을 쓰면 KB5005413대로 IIS 관리자에서 CA 웹 등록·CES의 EPA를 'Required'로(CES web.config는 extendedProtectionPolicy 'Always'), 'Require SSL'을 켠다.
iisreset /restart는 그 서버의 IIS 서비스를 모두 잠시 멈추니 등록 클라이언트와 같은 서버의 다른 서비스 영향을 확인하고 조율한 시간에 한다. 쓰지 않는 웹 등록은 끄는 것을 검토한다(일반 점검). - 법무·개인정보 담당: 일치 항목이 나오면 유출 사이트 감시와 신고 검토를 시작하고, 국내 신고 대상·기한은 침해사고 대응 실무와 신고기한과 관할 규정으로 확인한다.
이번 주
- AD 담당: CA 콘솔(certsrv.msc)이나
certutil -view로 2026년 4월 이후 발급 내역을 보존하고 요청자·주체·SAN·템플릿·승인 기록을 대조한다. 정상 서버 인증서도 요청 계정과 SAN이 다를 수 있어 이름 차이는 조사 후보일 뿐이다. 악성 발급으로 확인한 인증서는 바로 폐기하고certutil -crl로 CRL을 게시한다. 비밀번호를 바꿔도 발급된 인증서로는 계속 인증할 수 있다(일반 점검). - AD 담당: 모든 템플릿을 ESC1·ESC6·ESC8 관점으로 점검해 ENROLLEE_SUPPLIES_SUBJECT(Subject Name 탭의 Supply in the request)를 빼거나 CA 관리자 승인을 걸고, 요청·발급 감사를 켠다(CloudSEK 권고 2. 고급 감사 정책 Audit Certification Services 성공·실패와
certutil -setreg CA\AuditFilter 127).certutil -getreg policy\EditFlags에 EDITF_ATTRIBUTESUBJECTALTNAME2(ESC6)가 보이면certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2로 끈다. 둘 다 CA 서비스를 재시작해야 적용되니 조율한 시간에 재시작하고 4886·4887이 쌓이는지 본다(일반 점검). - AD 담당: SPN이 붙은 계정을 전수 조사해 특권 계정, 특히 기본 Administrator에서 SPN을 빼고 서비스 계정은 gMSA로 옮긴다(CloudSEK 권고 4).
- AD 담당: 도메인 장악이 의심되면 krbtgt 비밀번호를 두 번 바꾼다(CloudSEK 권고 3). 두 번째는 전체 DC 복제와 티켓 최대 수명(기본 10시간)을 확인한 뒤가 원칙이고, 더 당길지는 인증 장애 영향을 따져 대응팀이 정한다(일반 점검). 침해·서비스·백업 계정, ESXi root, Azure AD Connect 동기화 계정도 바꾸고 와일드카드 인증서 재발급을 검토한다(일반 점검).
- 네트워크 담당: LLMNR·NBT-NS를 끄고 SMB 서명·EPA를 켜고 WinRM을 지정 관리 호스트로 제한하고 DC부터 SMBv1을 없앤다(CloudSEK 권고 1).
- 보안관제: 수집 로그로 검증한 SSH 배너 변경 탐지, VM 연쇄 강제 종료, 백업 계정 이상 로그인, AD CS 서버의 DC 계정 NTLM 로그온을 상시 경보로 둔다.
이번 달
- AD 담당: 모든 DC·RODC가 KB5008380 강제 단계(2022년 10월 11일) 이후 상태인지 확인한다. 가능하면 AD CS 서버에 그룹 정책 'Network security: Restrict NTLM: Incoming NTLM traffic'을 'Deny all accounts'로 걸고 IIS Windows 인증을 Negotiate:Kerberos로 바꾼다(KB5005413).
- 인프라 담당: 지원 종료 OS와 MS17-010이 빠진 호스트를 퇴출·격리하고(CloudSEK 권고 7), 백업을 운영 AD와 다른 자격 증명·네트워크 구간으로 옮긴다(CloudSEK 권고 6).
- 단말·서버 관리자: 서버·관리자 PC에서 크롬·엣지 정책 PasswordManagerEnabled를 꺼 브라우저 비밀번호 저장을 막고(일반 점검) 프로필 대량 접근 감시를 켠다(CloudSEK 권고 5).
- 보안팀: VPN 전 계정 MFA와 호스팅·VPS 대역 로그인 경보를 적용하고(일반 점검), 로스팅에서 릴레이, 인증서 발급, ESXi 접근으로 이어지는 체인을 내부 모의해킹으로 재현해 막혔는지 확인한다.
자가점검
예/아니오로 답하고 '아니오'인 항목부터 위 대응 순서로 돌아간다.
1. 2026년 4월 이후 VPN 로그인 성공 기록을 원격지 IP로 하루 안에 뽑을 수 있는가
출발지 기록이 없으면 IOC 대조부터 할 수 없다.
2. VPN 전 계정에 MFA가 걸려 있는가
에이전트 세션은 넘겨받은 자격 증명이나 기존 경로로 시작했다(Gambit).
3. AD CS 웹 등록에 EPA(Required)와 HTTPS 전용을 적용했거나 웹 등록을 쓰지 않는가
ESC8 릴레이는 이 설정이 빠진 웹 등록을 노린다(KB5005413).
4. 템플릿의 요청자 주체·SAN 지정과 CA의 EDITF_ATTRIBUTESUBJECTALTNAME2를 둘 다 막았는가
ESC1은 템플릿(주체·SAN 지정, 등록 권한, 승인 조건), ESC6은 CA 전체의 SAN 허용 설정이라 따로 본다. ESC6은 패치 상태와 SID 보안 확장 포함 여부까지 확인해야 실제 위험을 판단할 수 있다.
5. 백업과 ESXi 관리 인터페이스가 운영망과 다른 자격 증명·네트워크 구간에 있는가
CloudSEK은 백업 자격 증명 확인을 암호화 직전 지표로 봤고, 공격자 모듈은 내부망에서 443·902로 ESXi를 찾았다.
6. 계정 잠금이나 DCSync 경보 없이도 조용한 침투를 잡을 수 있는가
운영자는 이런 경보를 부르는 행동을 에이전트에 금지했다. 인증서 발급, NTLM 로그온, 로스팅 패턴까지 본다(분석).
침입 흔적이 보이면 암호화 전에 침입 경로부터 확인하기
보안 전문 기업 SENTRIX의 침해사고 대응은 메일 제목에 [긴급]을 표기하면 영업일 기준으로 우선 확인해 초기 대응 범위와 일정을 안내하고, 침해 원인 분석(포렌식), 악성코드 분석·제거, 피해 범위 산정과 보고서, KISA·수사기관 신고 지원, 재발 방지와 복구까지 이어 간다. 암호화된 데이터의 복호화나 전체 복구를 보장하는 서비스는 아니다. 위 IOC나 설명되지 않는 인증서가 보였다면 파일이 잠기기 전에 침입 경로와 유출 범위부터 확인하세요. 침해사고 진단 문의하기
참고 자료
- CloudSEK, Caught in 4K: The Aurora Files(2026-08-27)
- Gambit Security(Eyal Sela), Aurora 랜섬웨어의 ESXi 공격과 AI 코드 편집기 에이전트 악용 분석(2026-08-27)
- Microsoft, KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS)(2024-08-03 갱신)
- Microsoft, KB5008380 Authentication updates (CVE-2021-42287)(2021-11-09, 2023-03-14 갱신)
- Microsoft, Microsoft Security Bulletin MS17-010(2017-03-14)