Azure AD Graph 활동 로그: 디렉터리 열거 감지

이제 AAD 그래프 활동 로그를 Elasticsearch로 가져와 SIEM/XDR 솔루션 내에서 위협 탐지에 사용할 수 있습니다. 저 문장은 흥미로워야 할 것 같지 않지만, 흥미롭다. 지난 10년 중 대부분의 기간 동안, 이러한 원격 측정 데이터는 고객이 접근할 수 있는 로그 스트림으로 존재하지 않았습니다. Microsoft Graph 활동 로그(최신 graph.microsoft.com 인터페이스)는 2024년 4월에 일반 출시되었습니다. 공격 도구가 실제로 공격하는 유일한 영역인 기존 graph.windows.net 인터페이스는 2026년 초까지 접근이 차단된 상태로 유지되었습니다.

이 글에서는 전체 과정을 처음부터 끝까지 살펴봅니다. 가시성이 중요한 이유, Elasticsearch에 로그를 수집하는 방법, ROADrecon을 사용하여 수동으로 현실적인 정찰을 생성하는 방법, 그리고 ES|QL에서 결과를 찾는 방법을 설명합니다. 아래 내용은 모두 실제 테넌트를 대상으로 검증되었습니다.

핵심 사항

AAD 그래프 활동 로그는 Azure 통합을 통해 Elastic으로 전송되어 전체 ECS 추출과 함께 logs-azure.aadgraphactivitylogs-* 에 저장됩니다.
ROADtools, AADInternals 및 관련 업체들은 수년간 정보 부족이라는 공백 속에서 활동해 왔습니다. 수비수들은 통화 내용을 녹음하지 못했습니다.
AAD 그래프는 "더 이상 사용되지 않음"으로 표시되어 있지만 대부분의 테넌트에서 여전히 쿼리할 수 있습니다. 1.61 내부 API 버전은 여전히 Microsoft Graph에서 제공하지 않는 데이터를 반환합니다.
ECS 필드는 토지 유형(event.action, event.outcome, http.request.method, source.ip, user.id, user_agent.original)으로 분류됩니다. 데이터셋 추가 정보는 azure.aadgraphactivitylogs.properties.* 아래에서 쿼리 가능합니다.
5가지 검색은 활동을 안정적으로 포착합니다. 도구 사용자 에이전트, 엔드포인트 범위, *-internal API 오용, FOCI 클라이언트 ID 불일치 및 4xx 급증.

수비수 가시성의 간략한 역사

보안 담당자들은 로그인, 조건부 액세스, 역할 할당 및 OAuth 동의 부여에 수년간 공을 들여왔습니다. 콘텐츠 중 상당수는 공격 도구가 실제로 접근하는 디렉터리 API에 대한 내용을 다루지 않습니다. 이유는 구조적인 문제입니다. 해당 API에 대한 고객이 접근할 수 있는 로그가 존재하지 않았기 때문입니다. Microsoft Graph 활동 로그가 먼저 출시되었습니다(미리 보기 2023년 10월, 정식 출시 2024년 4월). AzureADGraphActivityLogs는 마침내 2026년 초에 등장했습니다.

지난 10년 동안 대부분의 기간 동안 AAD 그래프 열거는 SOC(보안 운영 센터)에서 볼 수 없었는데, 이는 원격 측정 데이터가 숨겨져 있어서가 아니라 애초에 존재하지 않았기 때문입니다. ROADtools, AADInternals, MSOLSpray, 마이크로버스트. 그 어떤 것도 완벽한 로깅 설정을 하더라도 누구도 포착할 수 있는 데이터를 생성하지 못했습니다.

AzureADGraphActivityLogs가 플랫폼 로그 인덱스에 기록되기 시작하는 날부터 상황이 달라집니다.

AAD Graph는 "사용 중단"되었지만 여전히 활발하게 사용되고 있습니다.

간단히 복습해 봅시다. Azure AD Graph는 Entra ID 디렉터리 개체에 대한 기존 REST API이며 https://graph.windows.net/{tenantId}/{objecttype} 에서 호스팅되고 API 버전은 1.5, 1.6 및 1.61-internal 과 같습니다. 마이크로소프트는 2019년부터 모든 사용자에게 마이크로소프트 그래프로 마이그레이션할 것을 권장해 왔으며, 서비스 종료일은 여러 차례 연기되었습니다.

사용 중단 예정 기능은 사라지지 않았습니다. 2026년에도 AAD Graph는 기존 액세스 경로가 여전히 사용 가능한 환경이나 애플리케이션이 명시적으로 사용이 차단되지 않은 환경에서 요청에 응답할 수 있습니다. 이 시스템이 공격 대상으로 계속 남아 있는 데에는 몇 가지 이유가 있습니다.

공격 도구는 이식되지 않았습니다. ROADrecon은 여전히 gather 에 그것을 사용합니다. AADInternals는 이를 감싸는 수십 개의 cmdlet을 가지고 있습니다.
*-internal API 버전은 더 많은 데이터를 반환합니다. 1.61-internal 일반 디렉터리 탐색 중에 사용자 객체에 strongAuthenticationDetail 인라인으로 노출합니다. Microsoft Graph와 동등한 기능은 UserAuthenticationMethod.Read.All 에 의해 차단되는 별도의 /authentication/methods 엔드포인트 뒤에 있습니다. 그러한 비대칭성이 바로 대량 열거 도구가 악용하는 부분입니다.
해당 블록은 단일 토글 버튼이 아닙니다. blockAzureADGraphAccess 제어는 application.authenticationBehaviors 의 앱별로 존재하므로 테넌트 전체를 차단하려면 모든 앱 등록을 반복해야 합니다. 대부분의 환경에서는 기존 자동화 시스템이 여전히 API에 의존하기 때문에 그렇게 하지 않았습니다. 마이크로소프트의 단계적 서비스 종료 시행은 마이크로소프트의 일정에 따라 진행되며, 방어자의 일정과는 무관합니다.
가시성이 없었기 때문에 레드팀과 공격자들은 관련 정보를 얻기 위해 API 엔드포인트를 무차별적으로 공격할 수 있었습니다.

정상적인 AAD 그래프 트래픽은 소수의 마이크로소프트 자체 발신자가 대부분을 차지합니다. 테스트 테넌트에서 볼륨 순서는 Microsoft.OData.Client, Microsoft Azure Graph Client Library, 자사 AppId의 빈 UA 테일, Microsoft ADO.NET Data Services, Azure 포털(포털 앱 ID에 대한 Chrome UA) 순이었습니다. 식별 가능한 범주 외의 모든 것은 내부 도구이거나 승인되지 않은 활동입니다. 따라서 이는 견고한 위협 탐지/탐지 데이터 세트가 됩니다. 만약 당신이 그것을 포착하고 있다면요.

데이터 수집 파이프라인 설정

이미 진단 설정을 이벤트 허브로 전달하는 Elastic Azure 통합을 실행 중인 경우 이 섹션을 건너뛰세요. 아마 로그 범주를 하나 더 활성화하기만 하면 될 겁니다. 맨 앞에서부터 시작하면 약 20분 정도 걸리는 길입니다.

1단계: 로그를 수신할 스택

모든 Elastic 배포 방식이 작동합니다. Elastic Cloud 체험판은 프로토타이핑을 위한 가장 간편한 옵션입니다. 또 다른 옵션으로는 Elastic Container Project를 활용하여 시작하는 것입니다. Azure 통합은 활성화되면 AzureADGraphActivityLogs를 자동으로 처리합니다.

2단계: Azure 통합 추가

Kibana에서 통합 > Azure Logs > Azure Logs 추가를 선택합니다. 테넌트와 동일한 구독에 있는 이벤트 허브에 이벤트 허브 연결 문자열, 이벤트 허브 이름 및 오프셋 체크포인팅용 스토리지 계정을 입력하세요.

Azure Logs v2 데이터 스트림을 특별히 활성화하십시오. 그것이 바로 AAD 그래프 활동 로그의 진입점입니다. 이벤트 라우터는 category == "AzureADGraphActivityLogs" 과 일치하고 문서를 logs-azure.aadgraphactivitylogs-* 로 재라우팅하며, 여기서 데이터셋 파이프라인은 전체 ECS 추출을 적용합니다.

또한 Azure AD Graph 활동 로그를 별도의 통합 항목으로 분리했으므로 "Azure AD Graph 활동 로그"를 검색하여 정책 템플릿을 통해 직접 설치할 수 있습니다.

3단계: Entra ID에서 진단 설정을 활성화합니다.

이것이 바로 수비수들이 가장 많이 놓치는 부분입니다. AzureADGraphActivityLogs는 진단 설정 범주로 새로 추가되었습니다. Entra ID 진단 설정이 이미 한동안 구성되어 있더라도 새 카테고리는 다시 선택해야 합니다. 그렇지 않으면 데이터는 마이크로소프트 테넌트 경계 내에서 생성되고 소멸됩니다.

Azure 포털에서:

Entra ID > 모니터링 > 진단 설정 > + 진단 설정 추가.
이름을 대보세요.
로그에서 AzureADGraphActivityLogs를 확인하세요. 그곳에 있는 동안 MicrosoftGraphActivityLogs, SignInLogs 및 AuditLogs가 아직 활성화되어 있지 않다면 활성화하는 것이 좋습니다. 통합 기능이 이 모든 것을 처리합니다.
대상 세부 정보에서 이벤트 허브(2단계에서 선택한 것과 동일한 허브)로 스트림을 전송합니다.
구하다.

4단계: 데이터 흐름 확인

몇 분 안에 이벤트가 표시되기 시작할 것입니다. 가장 빠른 타당성 검토:

FROM logs-azure.aadgraphactivitylogs-*
| LIMIT 20

문서에 event.action, http.request.method, zure.aadgraphactivitylogs.properties.* 필드가 모두 채워진 상태로 반환되면 문제가 없습니다. 아무것도 표시되지 않으면 일반적으로 이벤트 허브 권한을 잊어버렸거나 연결 문자열에 오타가 있거나 AAD 그래프 범주가 선택되어 있지 않은 경우를 의심해 볼 수 있습니다.

몇 가지 이벤트를 강제로 발생시키려면 Azure 포털에 로그인한 다음 사용자 또는 애플리케이션을 클릭하세요. 포털은 여전히 일부 개체 세부 정보를 얻기 위해 내부적으로 AAD Graph를 호출합니다. 만약 그것으로 아무것도 생성되지 않으면, 다음 curl 루프가 실행될 것입니다:

TOKEN=$(az account get-access-token --resource https://graph.windows.net --query accessToken -o tsv)
TID=$(az account show --query tenantId -o tsv)
for obj in users groups servicePrincipals applications tenantDetails; do
  curl -sS -o /dev/null -H "Authorization: Bearer $TOKEN" \
    "https://graph.windows.net/$TID/$obj?api-version=1.6&\$top=5"
done

필드 형상

데이터 흐름이 시작되면 속성은 유형이 지정된 최상위 필드로 표시됩니다. 사냥에 중요한 요소들은 다음과 같습니다.

ECS는 직접 채워집니다. event.action (방법 + 컬렉션에서 파생된 의미 동사, 예: users-read, batch-execute), event.outcome, event.duration, http.request.method, http.response.status_code, source.ip 및 source.geo.*, user.id, user_agent.original (구문 분석된 하위 필드 포함), url.path, azure.tenant_id, cloud.service.name = "Azure AD Graph".
zure.aadgraphactivitylogs.properties.*: app_id,, app_id, api_version, actor_type, roles, scopes, wids, identity_provider, client_auth_method, sign_in_activity_id, token_issued_at 아래의 데이터 세트별.
related.user user.id 과 properties.app_id 모두 가져오므로 OAuth 클라이언트 차원의 피벗은 사용자 피벗과 함께 작동합니다.

분석 및 재현을 위해 원본 JSON 데이터는 event.original 에 저장됩니다. 일반적인 사냥에서는 그 안에 손을 넣을 필요가 없을 겁니다. 그렇다면 ES|QL의 JSON_EXTRACT() 함수가 핵심입니다.

ROADrecon을 사용한 AAD 그래프 열거

무엇을 사냥해야 할지 알기 위해서는 그 활동이 어떤 모습인지 알아야 합니다. 아래 두 가지 툴킷은 레드팀 및 보안 연구 워크플로에서 AAD 그래프 트래픽이 가장 흔하게 발생하는 소스입니다. 저희 테스트 테넌트에서 두 가지 모두 실행해 봤습니다.

주의: 이 코드의 오용에 대해서는 어떠한 책임도 지지 않습니다. 이러한 도구는 본인이 소유하거나 테스트에 대한 명시적인 서면 승인을 받은 테넌트에 대해서만 실행하십시오.

ROADrecon: 대량 열거 테스트

ROADrecon은 Dirk-jan Mollema의 Entra ID 연구 프레임워크인 ROADtools 의 데이터 수집 모듈입니다. 아직 사용해보지 않으셨다면 강력 추천합니다. gather 명령은 디렉터리에 있는 모든 관심 있는 객체 유형(사용자, 그룹, 서비스 주체, 애플리케이션, 장치, 디렉터리 역할, 역할 할당, 적격 역할 할당, OAuth2 권한 부여, 관리 단위)을 순회하며 결과를 SQLite에 기록합니다.

설정은 표준 워크플로입니다.

pip install roadrecon
roadrecon auth --device-code -c 04b07795-8ddb-461a-bbee-02f9e1bf7b46 -r https://graph.windows.net

기기 코드 흐름을 통해 URL과 코드가 제공됩니다. 저희는 기본적으로 Microsoft Azure CLI(1b730954-1685-4b74-9bfd-dac224a7b894 - AAD PowerShell )를 사용하는데, 저희 테넌트에서 403 오류가 반환되었습니다. 로그인 후:

roadrecon gather

roadrecon gather 실행이 완료되었고, 생성된 토큰도 문제없이 처리되었습니다. 테넌트 관점에서 보면, 실행 과정에서 약 1 분 동안 약 2,000건 이상의 AAD Graph 호출과 로그가 생성되었습니다. ROADrecon이 알고 있는 모든 객체 유형에 대한 일괄 열거.

이를 통해 초기 탐지를 수행하여 이러한 이상 징후를 표시하기 시작할 수 있습니다.

AAD Graph 위협 탐지를 위한 주요 필드

본격적인 탐색에 앞서, 이상 징후를 탐지하는 데 유용한 몇 가지 주요 분야를 소개합니다.

필드	설명	찾을 수 있는 것
`event.action`	의미 동사 (HTTP 메서드 + 컬렉션, 예: `users-read`, `batch-execute`)	의도를 기준으로 AAD 그래프 활동을 분리하는 저렴한 필터
`http.request.method`	GET, POST, PATCH, DELETE	읽기(정찰) vs 쓰기(수정, 자격 증명 주입, 지속성 유지)
`http.response.status_code`	HTTP 상태 반환됨	정찰 성공 여부 vs. 차단 여부; 4xx 오류의 급증은 권한 요청 또는 무차별 대입 공격을 나타냅니다.
`user.id`	사용자 디렉터리 객체 ID를 호출합니다.	신원 확인; 로그인 로그/감사 로그에서 해당 사용자의 다른 활동으로 전환
`user_agent.original`	발신자의 전체 UA 문자열	호출자가 마이크로소프트 자체 라이브러리이든, 개발자 도구(curl, Python aiohttp)이든, 또는 악의적인 도구로 알려진 것이든 상관없이
`url.path`	리소스 경로(/users, /policies, /servicePrincipals 등)	어떤 디렉터리 객체 유형이 영향을 받고 있는지, 서로 다른 경로에 걸친 범위는 대량 열거를 나타냅니다.
`azure.aadgraphactivitylogs.properties.app_id`	토큰을 발급한 OAuth 클라이언트 ID	트래픽이 합법적인 자사 고객으로부터 발생하든 FOCI 스왑 방식의 악용 경로를 통해 발생하든 상관없이
`azure.aadgraphactivitylogs.properties.api_version`	1.5, 1.6, 1.61 내부 등	발신자가 공격 도구가 특별히 표적으로 삼는 내부 전용 필드(strongAuthenticationDetail, 전체 CAP 세트)를 요청하는지 여부
`azure.aadgraphactivitylogs.properties.actor_type`	사용자, 애플리케이션, 서비스 주체	사람 발신자 vs 서비스 제공자/앱 전용 흐름
`azure.aadgraphactivitylogs.properties.roles` / `wids`	발신자가 보유한 디렉터리 역할 표시 이름과 잘 알려진 역할 템플릿 GUID	호출 시점에 권한 있는 역할(전역 관리자, 애플리케이션 관리자 등)이 실행 중인지 여부
`azure.aadgraphactivitylogs.properties.scopes`	호출 토큰의 OAuth 스코프	토큰이 실제로 호출자에게 부여하는 디렉터리 권한은 무엇입니까?
`azure.aadgraphactivitylogs.properties.client_auth_method`	클라이언트 인증 방식(PRT, 인증서, 비밀 키 등)	PRT 악용, 장치 PRT 악용 또는 도난당한 클라이언트 자격 증명 사용을 위한 지문
`azure.aadgraphactivitylogs.properties.sign_in_activity_id`	최초 로그인과의 상관관계 ID	AAD 그래프 호출에서 호출 토큰을 생성한 로그인 이벤트로 피벗합니다.
`azure.aadgraphactivitylogs.properties.token_issued_at`	토큰이 발행된 타임스탬프	토큰 사용 기간 분석: 며칠 전에 발급된 토큰을 사용하는 호출은 만료된 토큰/갱신 토큰 남용을 나타낼 수 있습니다.

탐지 및 예방

탐지

AAD 그래프 감지를 위해서는 우선 로그 파일이 있어야 합니다. Entra ID에서 AzureADGraphActivityLogs 진단 범주를 활성화하고 쿼리 가능한 대상(최소한 Log Analytics 작업 영역, 이상적으로는 위 설정 섹션에 설명된 대로 Elastic 수집을 위해 이벤트 허브로도 전달)으로 라우팅해야 합니다. 그 작업이 완료될 때까지 이 게시물에 설명된 호출은 전적으로 카메라에 담기지 않으며, 아래의 사냥 계획은 실행되지 않습니다.

지금 당장 Elasticsearch로 데이터를 수집할 수 없더라도 진단 설정을 활성화하고 Log Analytics로 전송하세요. 아래 검색에 해당하는 KQL 쿼리는 간단하며, 추가 처리가 없더라도 데이터는 보존 기간 동안 누적됩니다.

예방

포털에는 테넌트 전체에 적용되는 단일 AAD Graph 비활성화 스위치가 없습니다. 실제 애플리케이션 계층 제어는 다음과 같습니다.

application.authenticationBehaviors.blockAzureADGraphAccess

애플리케이션 리소스에 대한 앱별 부울 값입니다(Microsoft Graph 베타, 문서 참조). 대규모 차단은 모든 앱 등록을 일일이 확인하고 수동 또는 프로그래밍 방식으로 차단 여부를 결정하는 것을 의미합니다. 마이크로소프트의 단계적 서비스 종료는 자체 일정에 따라 진행되고 있습니다. 그 과정이 진행될수록 방어해야 할 표면적은 줄어듭니다.

수비수들은 그동안 같은 축을 따라 움직일 수 있습니다.

테넌트에서 graph.windows.net 토큰을 여전히 보유하고 있는 애플리케이션을 감사하십시오. 필요 없는 항목에는 blockAzureADGraphAccess = true 설정하세요. AAD Graph에 의존하는 모든 기능은 심각한 오류를 일으키며, 이로 인해 이전에는 알지 못했던 기존 자동화 기능이 드러나게 됩니다.
Azure AD Graph를 대상 리소스로 사용하여 조건부 액세스를 적용합니다. Azure AD Graph 서비스 주체(00000002-0000-0000-c000-000000000000)는 표준 CA 앱 선택기에 표시되지 않지만 모든 리소스 정책의 적용을 받으며 사용자 지정 보안 속성 필터 방식을 통해 개별적으로 대상으로 지정할 수 있습니다. Microsoft의 3월 2026 시행 변경으로 이것이 더욱 실용적이 되었습니다. 이전에는 CA 시행에서 자동으로 제외되었던 낮은 권한 범위(User.Read, People.Read 등)가 이제 AAD 그래프 액세스로 처리되므로 모든 리소스 정책이 실제로 이를 차단합니다. CA는 토큰 발급 시점에 평가를 수행하므로 이미 유효한 토큰은 만료일까지 계속 작동합니다.
공격 도구가 사용되는 FOCI 클라이언트(Microsoft Teams, Microsoft Office, OneDrive, Azure PowerShell 등)에 CA를 적용합니다. 관리되고 규정을 준수하는 장치가 필요합니다. 기본 클라이언트가 로그인할 수 없으면 스왑 경로가 중단됩니다.
서비스 주체 호출자의 경우 Workload Identities Premium은 서비스 주체에 CA 범위가 추가됩니다. 조건은 위치, 신원 보호 위험 및 인증 컨텍스트로 제한되며, 권한 부여 제어는 차단만 가능합니다. 외부 및 위험 컨텍스트 경로를 통합하는 데 유용하며, 사용자 CA처럼 SP를 특정 클라우드 앱으로 범위 지정하는 데는 적합하지 않습니다.
기기 코드 흐름이 필요하지 않은 사용자에게는 해당 기능을 비활성화하세요. roadrecon auth --device-code 은 위의 전체 파이프라인으로 들어가는 가장 쉬운 경로이며 OAuth 피싱에서 매우 흔하게 사용됩니다.

행동 감지

저희는 위에 설명된 AAD 그래프 재구성 형태를 포괄하는 탐지 규칙을 배포했습니다. 각각은 Elastic detection-rules 저장소에 있으며 구문 분석된 logs-azure.aadgraphactivitylogs-* 데이터 스트림에 대해 기본적으로 실행됩니다.

의심스러운 사용자 에이전트를 사용한 Azure AD 그래프 액세스 - KQL 일치 규칙. AAD Graph가 공격 도구 계열(Python, aiohttp, curl, Go-http-client, axios, AzureHound, BloodHound, AADIntenals 등)과 일치하는 사용자 에이전트 문자열로부터 트래픽을 수신할 때 트리거됩니다. 마이크로소프트 자체 구성 요소 중 어느 것도 이러한 범주에 속하지 않는 반면 기본 도구는 속하기 때문에 확실한 기준 신호입니다.

Azure AD 그래프에서 사용자 - ES|QL 집계로 인한 4xx 오류 발생률이 높습니다 . 단일 발신자가 짧은 시간 내에 AAD 그래프에서 비정상적으로 높은 비율의 4xx 응답을 생성할 때 트리거됩니다. 정찰 및 무차별 대입 토큰 사용은 도구가 권한이 없는 엔드포인트에 접근하거나, 보유하지 않은 객체 ID를 요청하거나, AAD Graph에 대해 승인되지 않은 클라이언트 ID를 사용하는 등의 이유로 403 및 404 오류를 남깁니다.

비정상적인 클라이언트 및 사용자로 Azure AD 그래프 액세스 - KQL new_terms 규칙, 중간 심각도. (호출하는 OAuth 클라이언트, 로그인한 사용자) 쌍이 이전 14 일 동안 AAD 그래프에 처음으로 나타날 때 발생합니다. FOCI 스왑, 사용자가 일반적으로 사용하지 않는 클라이언트에 사용된 피싱된 새로 고침 토큰, 그리고 익숙하지 않은 클라이언트에서 사용된 도난 토큰을 포착합니다. 일반적으로 Azure AD와 상호 작용하는 것으로 관찰된 Microsoft가 소유한 백엔드 애플리케이션은 무시합니다.

비정상적인 사용자 및 ASN을 사용한 Azure AD 그래프 액세스 - KQL 일치 규칙. 일반적인 Microsoft/AWS/GCP/Akamai/Cloudflare ASN 조직을 제외하고 해당 집합 외부에서 발생하는 AAD Graph 트래픽에 플래그를 지정합니다. 공격 도구는 일반적으로 합법적인 발신자와는 다른 ASN 분포를 생성하는 주거용 ISP, VPS 제공업체 또는 익명화 네트워크를 이용합니다. 제외할 ASN 목록을 조정하여 테넌트별로 설정할 수 있습니다.

Azure AD 그래프 잠재력 열거(ROADrecon) - ES|QL 집계, 심각도 높음. aiohttp 사용자 에이전트와 단일 ID에서 발생하는 500개 이상의 AAD Graph 요청이 모두 필요합니다. ROADrecon의 gather 명령어는 기본적으로 aiohttp를 사용하며 모든 디렉터리 객체 유형을 탐색하므로, 이 조합은 사실상 도구의 고유한 특징입니다. 일반적인 비 Microsoft UA 규칙보다 심각도가 높습니다. 추가적인 버스트 요구 사항으로 인해 개발자 프로토타입 오탐 클래스가 제거되기 때문입니다.

Entra ID OAuth 장치 코드 Azure AD 그래프 열거에 로그인 - EQL 시퀀스, 심각도 높음. 동일한 사용자가 5분 이내에 graph.windows.net 에 대한 디렉터리 열거를 통해 관리되지 않는 장치에서 레거시 AAD Graph 대상(00000002-0000-0000-c000-000000000000)에 성공적으로 장치 코드 로그인을 연결합니다. 디바이스 코드 피싱은 사용자의 암호나 MFA를 건드리지 않고 OAuth 토큰을 획득하므로, 해당 토큰을 통해 사용자, 서비스 주체, 애플리케이션, 역할 할당, 정책 또는 테넌트 세부 정보에 대한 그래프 읽기가 즉시 발생하여 공격자가 탈취한 ID를 이용하게 됩니다. 교차 데이터 스트림 시퀀스는 다른 AAD 그래프 규칙에 있는 단일 이벤트 오탐 클래스를 제거합니다.

AAD 그래프 가시성: 다음 단계는 무엇일까요?

지난 10년 동안 대부분의 기간 동안 AAD 그래프 활동은 암흑 물질에 대한 원격 측정과 같은 역할을 했습니다. 공격 도구가 계속해서 해당 위치를 지적했기 때문에 우리는 그 위치가 있다는 것을 알고 있었지만, 고객은 구독할 수 있는 진단 스트림도 없고 조회할 로그도 없었습니다. Microsoft Graph 활동 로그는 2024년 4월 정식 출시되면서 격차를 절반으로 줄였습니다. AzureADGraphActivityLogs는 마침내 2026년 초에 나머지 절반의 개발을 완료했습니다.

이제 데이터는 확보되었으니, 나머지는 우리에게 달려 있습니다. 새로운 진단 설정을 추가하고, 이벤트 허브를 지정하고, 스택에 데이터를 수집하고, 감지 기능을 활성화(또는 자체 감지 기능 생성)한 다음 모니터링을 시작하세요.

이 게시물에 나온 탐지 결과는 시작점에 불과합니다. 일단 AAD 그래프 트래픽이 스택에 유입되고 테넌트에서 정상적인 상황이 어떤지 기준선을 설정하게 되면, 동일한 패턴이 일반화됩니다. 마이크로소프트에서 공식적으로 제공하는 전화는 소수의 잘 알려진 발신자 그룹에 속하며, 그 외의 발신자는 면밀히 살펴볼 필요가 있습니다.

그 활동은 항상 존재했습니다. 결국 가시성도 마찬가지입니다.

즐거운 사냥 되세요!

참고 자료

위의 조사에서 참조한 내용은 다음과 같습니다:

Elastic 보안 연구소 소개

Elastic Security Labs는 위협 환경에 긍정적인 변화를 가져오기 위해 노력하는 Elastic Security의 위협 인텔리전스 부서입니다. Elastic Security Labs는 전략적, 운영적, 전술적 공격자 목표에 대한 분석을 통해 새롭게 떠오르는 위협에 대한 공개 연구 자료를 제공하고, 이를 Elastic Security의 내장 탐지 및 대응 기능과 통합합니다. Elastic Security Labs의 트위터 계정 @elasticseclabs를 팔로우하고, www.elastic.co/security-labs/ 에서 연구 자료를 확인하세요.

Azure AD Graph 활동 로그: 가시성 격차 해소를 위한 데이터 수집 및 위협 탐지