클라우드 인증 로그의 사각지대
클라우드 제공업체의 인증 로그에는 공격자가 악용하는 치명적 허점이 있습니다. Azure 로그인 우회 사례로 보는 탐지 엔지니어링의 교훈.
Priya Sharma
TrustedSec 보안 팀이 최근 Azure 로그인 기록을 우회하는 세 번째와 네 번째 방법을 공개했습니다. 보안 팀이 탐지에 의존하는 로그에 남지 않으면서 Microsoft 클라우드 서비스에 인증하는 독립적인 기법이 네 가지나 된다는 뜻입니다. 로그인은 실제로 일어났지만 로그에는 기록되지 않았습니다. 이 로그에서 의심스러운 활동을 모니터링하던 사람들은 아무것도 보지 못한 것입니다.
이건 이론적인 문제가 아닙니다. 공격자가 자격 증명을 훔쳐 Azure 환경에 접근하면, 보안 팀이 가장 먼저 확인하는 것이 로그인 로그입니다. 그 로그가 불완전하다면, 즉 특정 유형의 인증이 아예 로그를 남기지 않는다면 탐지 능력에 여러분이 모르던 구멍이 있는 것입니다. 그리고 여러분은 로그가 완벽하다는 전제 아래 보안 결정을 내려왔을 것입니다.
인증 로그에 공백이 생기는 이유
흔히 인증 로깅은 단순하다고 생각합니다. 누군가 인증하면 기록하면 된다는 것이죠. 하지만 실제로 클라우드 인증은 수십 가지 프로토콜, 엔드포인트, 토큰 유형이 얽힌 복잡한 시스템이고, 로깅 범위도 그때그때 다릅니다.
Azure Active Directory(현재 Entra ID)는 Microsoft 365, Azure 리소스, SAML/OIDC 기반 서드파티 앱, App Proxy를 통한 온프레미스 레거시 앱, 서비스 프린시펄, 관리 ID 등의 인증을 처리합니다. 각 인증 경로마다 자체 백엔드, 로깅 파이프라인, 예외 케이스가 있습니다. 로그인 로그는 인증 서비스가 생성하지만, 일부 인증 흐름은 표준 서비스를 거치지 않거나 현재 로깅 인프라보다 먼저 만들어진 레거시 경로를 사용합니다.
레거시 프로토콜의 공백
Microsoft는 2000년대 초반 프로토콜과의 하위 호환성을 유지하고 있습니다. 이 프로토콜들은 현대적인 로깅 인프라보다 앞서 만들어졌습니다. 일부 SMTP, IMAP, POP3 인증 경로는 표준 Azure AD 토큰 엔드포인트가 아니라 메일 전송 계층에서 인증하는 'Basic Auth' 흐름을 사용합니다. 이런 인증은 최신 OAuth/OIDC 흐름과 같은 로그인 로그 항목을 남기지 않을 수 있습니다.
Microsoft는 몇 년째 Basic Auth를 폐기하고 있지만, 기업 환경에서는 폐기가 느립니다. 레거시 메일 클라이언트, 문서를 이메일로 보내는 스캐너, 오래된 업무용 애플리케이션을 쓰는 조직은 여전히 Basic Auth를 켜 두고 있을 수 있습니다. 레거시 경로 하나하나가 잠재적인 로깅 공백입니다.
서비스 프린시펄 인증
애플리케이션과 자동화가 사용하는 사람이 아닌 ID인 서비스 프린시펄은 사용자와 다른 방식으로 인증합니다. 이들의 로그인 이벤트는 별도의 로그 스트림(서비스 프린시펄 로그인, 대화형 로그인, 비대화형 로그인)에 나타납니다. 대화형 로그인 로그만 모니터링하는 보안 팀은 서비스 프린시펄 활동을 완전히 놓치게 됩니다.
탈취된 서비스 프린시펄은 흔한 공격 벡터이기 때문에 이 점이 중요합니다. 서비스 프린시펄의 자격 증명이나 인증서를 얻은 공격자는 그 애플리케이션으로 인증해서 권한이 있는 모든 리소스에 접근할 수 있습니다. 보안 팀이 사용자 로그인만 지켜보고 있다면 이런 활동은 절대 보이지 않습니다.
토큰 재사용과 갱신
모든 접근이 새로운 인증을 거치는 것은 아닙니다. OAuth 리프레시 토큰은 재인증 없이 접근을 계속 허용합니다. 공격자가 유효한 리프레시 토큰을 훔치면(감염된 기기, 가로챈 트래픽, 악성코드 등을 통해) 비밀번호 기반 인증에서 생기는 것과 같은 로그인 로그를 남기지 않고 새 액세스 토큰으로 교환할 수 있습니다. 최초 로그인은 기록되었더라도 이후 토큰 갱신은 비대화형 로그인으로 나타날 수 있는데, 많은 탐지 규칙은 이를 모니터링하지 않습니다.
탐지 엔지니어링의 문제
인증 로깅의 공백은 클라우드 보안의 더 큰 문제를 드러냅니다. 우리는 완전하다고 가정한 로그 위에 탐지 시스템을 구축하고, 공격자가 로그를 남기지 않는 경로를 찾아내면 그제서야 놀랍니다.
클라우드 환경의 표준 보안 구조는 이렇습니다. 클라우드 서비스가 로그를 생성하고, 로그가 SIEM(Security Information and Event Management, 보안 정보 및 이벤트 관리 시스템)으로 전송되고, 탐지 규칙이 로그에서 의심스러운 패턴을 분석하고, 경보가 발생해 조사가 시작됩니다. 이 구조는 로그가 관련 활동을 모두 포착할 때만 제대로 작동합니다. 그렇지 않다면 SIEM은 불완전한 그림을 비싸게 모니터링하는 도구에 불과합니다.
Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.실제로 할 수 있는 일
클라우드 제공업체의 로깅 공백은 여러분이 고칠 수 없습니다. 그건 Microsoft(또는 AWS, Google)의 몫입니다. 하지만 인증 로그가 완전하다는 가정에만 기대지 않는 탐지 전략은 만들 수 있습니다.
여러 로그 소스 모니터링하기
인증 로그는 신호 중 하나일 뿐입니다. 활동 로그는 또 다른 신호입니다. 공격자의 로그인이 인증 로그에 나타나지 않더라도, 이후 행위(이메일 읽기, 파일 접근, 데이터베이스 조회, 설정 변경)는 각각 로그 항목을 남깁니다. 활동 로그와 인증 로그를 교차 상관분석하면 불일치가 드러납니다. 최근 로그인 기록이 없는 ID에서 발생한 활동은 로그인이 왜 기록되지 않았든 의심스럽습니다.
-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5 // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass레거시 인증 비활성화하기
SMTP, IMAP, POP3용 Basic Auth 같은 레거시 프로토콜을 사용하지 않는다면 비활성화하세요. 최신 로깅을 우회하는 인증 경로 자체를 쓸 수 없게 되므로 로깅 공백 범주 전체가 사라집니다. Azure의 조건부 액세스 정책으로 사용자별, 그룹별, 또는 테넌트 전체에서 레거시 인증을 차단할 수 있습니다.
비활성화하기 전에 현재 사용 현황부터 점검하세요. 아이러니하게도 Azure 로그인 로그에는 일부 레거시 인증 시도가 나타나며, 레거시 인증용 Entra ID 워크북으로 여전히 오래된 프로토콜을 쓰는 애플리케이션을 찾을 수 있습니다. 해당 애플리케이션을 먼저 고친 뒤 레거시 인증을 차단하세요.
토큰 활동 모니터링하기
환경이 지원한다면 CAE(Continuous Access Evaluation, 지속적 액세스 평가)를 구현하세요. CAE를 사용하면 상황이 바뀔 때(사용자 비활성화, 고위험 로그인 탐지, IP 위치 변경 등) Azure AD가 거의 실시간으로 토큰을 취소할 수 있습니다. CAE가 없으면 훔친 액세스 토큰은 보안 팀이 무엇을 하든 보통 1시간인 만료 시점까지 유효합니다.
토큰 수명과 갱신 패턴도 함께 모니터링하세요. 리프레시 토큰이 새로운 IP 주소나 새로운 기기에서 쓰이거나 비정상적인 시간대에 쓰인다면 플래그를 세워야 합니다. 이것이 토큰 탈취를 알 수 있는 유일한 신호인 경우가 많습니다.
자체 로깅 테스트하기
가장 효과가 큰 조치는 로깅이 실제로 여러분이 생각하는 것을 포착하는지 정기적으로 테스트하는 것입니다. 환경에서 지원하는 방식(대화형, 비대화형, 서비스 프린시펄, 레거시 프로토콜)으로 각각 인증해 보고 기대한 로그 항목이 생기는지 확인하세요. 생기지 않는다면 공격자보다 먼저 공백을 찾은 것입니다.
체계적으로 수행하는 조직이 거의 없는 탐지 엔지니어링 테스트입니다. 대부분의 팀은 탐지 규칙을 작성하고 제대로 동작할 거라고 가정합니다. 규칙이 의존하는 이벤트가 실제로 로그에 남는지 확인하는 기반 데이터 품질 검증이 규칙 자체보다 더 중요하다고 해도 과언이 아닙니다.
더 넓은 교훈
Azure 로그인 로그 우회 사례가 Microsoft만의 문제는 아닙니다. 모든 클라우드 제공업체에는 로깅이 불완전한 인증 경로가 있습니다. AWS CloudTrail에도 일부 리전의 특정 컨트롤 플레인 작업, 특정 서비스 연결 역할 가정, 원래 ID를 가릴 수 있는 교차 계정 역할 체이닝 같은 알려진 공백이 있습니다. Google Cloud 감사 로그에도 비슷한 예외 케이스가 있습니다.
교훈은 “Azure 로깅이 고장 났다”가 아닙니다. 모든 로깅은 불완전하며, 그렇지 않다고 가정하는 보안 구조는 실패한다는 것입니다. 심층 방어는 보안 통제를 여러 개 두는 것만이 아니라 독립적인 가시성 소스를 여러 개 확보하는 것입니다. 탐지가 하나의 로그 소스가 완전하다는 전제에 전적으로 기대고 있다면, 보안 태세에 단일 장애점이 있는 셈입니다.
어떤 개별 로그 소스든 불완전하거나 우회될 수 있다고 가정하고 탐지를 설계하세요. 인증 로그, 활동 로그, 네트워크 로그, 엔드포인트 텔레메트리를 교차 상관분석하고, 소스 간 불일치를 찾으세요. 그 불일치가 바로 공격자가 악용하는 공백을 가리키는 경우가 많습니다. 그리고 로깅을 정기적으로 테스트하세요. 여러분이 모르는 공백이 결국 여러분에게 불리하게 쓰일 공백입니다.
