Google SecOps (Chronicle) Curated Detections: 결함 분석 및 튜닝

이 저장소는 네이티브 Google SecOps (Chronicle) Curated Detections의 아키텍처 설계 결함, 로직 불일치, 튜닝 전략을 문서화합니다.

Google Threat Intelligence (GTIG)는 APT29/BRICKSTORM 캠페인 추적과 같은 개념적 위협 커버리지 측면에서 탁월하지만, 큐레이티드 규칙의 원시 YARA-L 구현은 그룹화 로직 모순이나 하드코딩된 임계값 변수와 같은 구현상의 실수를 종종 포함합니다. 실제 엔터프라이즈 환경에서 이는 대규모 알림 피로(alert fatigue)로 이어지는 경우가 잦습니다.

이 프로젝트는 네이티브 규칙이 왜 오작동하거나 SOC를 알림으로 범람시키는지 분석하고, 이러한 문제를 해결하기 위한 최적화된 Custom Rules 및 패치를 공유합니다.

📑 목차

BRICKSTORM / APT29에 대한 O365 제품군 알림 실패
UEBA: 비정상 인증 시도 총계
- 하드코딩 결함과 알림 피로
- UEBA 튜닝 권장사항

1. BRICKSTORM / APT29에 대한 O365 제품군 알림 실패

Google은 손상된 서비스 주체(Service Principal)가 Microsoft 365 Exchange Online에서 대량 이메일 반출을 수행하는 것을 탐지하기 위한 일련의 규칙을 공개했습니다 (APT29/Midnight Blizzard가 적극적으로 사용하는 기법).

영향을 받는 큐레이티드 규칙은 다음과 같습니다:

O365 Mailbox Access by Service Principal with Multiple User Agents
O365 Multiple Mailboxes Accessed by Service Principal
O365 Mailbox Access by Service Principal from Multiple ASNs
O365 Multiple Mailboxes Accessed via Microsoft Graph API

❌ Google 로직의 핵심 결함

이 규칙 모음은 명시된 목표와 YARA-L 구현 사이에 체계적인 로직 불일치를 포함하고 있습니다. 이는 규칙 팩 전반에 걸친 코드 재사용으로 인한 것으로 보입니다. 이 규칙들은 자동화된 서비스 주체와 일반적인 사용자 활동을 제대로 구분하지 못하여, 정상적인 직원 행동에서도 알림이 발생하게 됩니다.

결함 1: 그룹화 로직 모순

규칙 설명에는 *"단일 O365 세션 ID를 가진 서비스 주체를 탐지..."*라고 명시되어 있음에도 불구하고, "Multiple User Agents" 규칙의 YARA-L match 섹션은 세션 ID($session_id)가 아닌 $application_id로 그룹화합니다. 이는 규칙의 명시된 목적과 완전히 모순되며, 동일한 애플리케이션을 사용한다는 이유만으로 3시간 창 안의 무관한 인간 로그인을 모두 집계하게 됩니다.

결함 2: Outlook 모바일 공용 클라이언트 누락

이 규칙들은 특정 ClientAppId에 연결된 비정상적 행동 패턴(변경되는 IP, ASN, User-Agent)을 추적합니다. Google은 여러 네이티브 Microsoft 애플리케이션에 대한 제외 정규식을 포함하고 있지만, 가장 보편적인 인간 모바일 클라이언트인 Microsoft Outlook 모바일 앱(27922004-5251-4030-b22d-91ecd9a37ea4)은 설명할 수 없게 누락되었습니다.

영향: 이 공용 클라이언트를 필터링하지 않으면, 스마트폰에서 공유 사서함을 읽다가 네트워크를 전환하는(예: Wi-Fi에서 4G로 전환) 정상 직원은 본질적으로 Multiple ASNs 및 Multiple IPs 알림을 유발합니다. iOS와 Android를 사용하는 서로 다른 직원이 동일한 부서 사서함을 확인하는 경우 Multiple User Agents 알림이 발생합니다.

결함 3: 공유 사서함 충돌

백엔드 서비스 계정을 식별하기 위해 Google의 로직은 다음 조건에 의존합니다: $e.principal.user.userid != $e.target.user.userid

영향: 이 조건은 단순히 행위자 ID가 대상 사서함 소유자와 다른지 여부만 확인합니다. 자동화된 서비스 주체에게는 해당하지만, 공유 또는 부서 사서함에 접근하는 인간 직원(예: 운영자가 [email protected]을 여는 경우)에게도 표준적인 동작입니다. 이 설계 결함은 정상적인 운영 인적 트래픽에서 엄청난 노이즈를 생성합니다.

✅ O365 규칙에 대한 튜닝된 YARA-L 솔루션

이 설계 결함을 해결하려면 운영 요구에 따라 두 가지 옵션이 있습니다:

옵션 1: 네이티브 SIEM 제외 (빠른 해결책) 반드시 규칙을 비활성화하거나 사용자 지정 코드를 작성할 필요는 없습니다. Google SecOps SIEM UI 내에서 직접 제외(Exclusion) 를 생성하면 됩니다. Outlook 모바일(27922004-5251-4030-b22d-91ecd9a37ea4)의 ClientAppId와 승인된 백업 애플리케이션(예: Keepit)을 대상으로 제외를 추가하기만 하면 Google의 큐레이티드 규칙을 활성 상태로 유지하면서 오탐 홍수를 즉시 차단할 수 있습니다.

옵션 2: Custom Rules 배포 (아키텍처 수정) 기본 그룹화 로직 결함(예: $application_id 불일치)을 완전히 수정하려면 Curated Detections를 비활성화하고 Custom Rules를 배포해야 합니다. 수정 내용은 다음과 같습니다:

Outlook 모바일(27922004-...)을 명시적으로 허용 목록에 추가합니다.
알려진 승인된 엔터프라이즈 백업 앱(예: Keepit)을 허용 목록에 추가합니다.
match 섹션을 수정하여 세션별로 올바르게 집계합니다.

튜닝된 규칙 1: Multiple User Agents

rule custom_ttp_o365_mailbox_access_by_service_principal_with_multiple_uas {
  meta:
    rule_name = "[CUSTOM] O365 Mailbox Access by Service Principal with Multiple User Agents"
    description = "Detects a Service Principal with a single O365 session ID accessing O365 mailboxes with multiple user agents. Tuned to fix grouping logic and exclude Outlook Mobile (Public Client) human traffic."
    severity = "Low"
    tactic = "TA0009"
    technique = "T1114.002"

  events:
    $e.metadata.log_type = "OFFICE_365"
    $e.metadata.product_event_type = "MailItemsAccessed" nocase
    $e.target.application = "Exchange"
    $e.security_result.detection_fields["RecordType"] = /^(2|50)$/
    
    // Extract actual Session ID and App ID
    $session_id = $e.network.session_id
    $application_id = $e.additional.fields["ClientAppId"]
    
    $e.principal.user.userid !=$e.target.user.userid
    
    ( 
      $e.network.http.user_agent = /AppId/ nocase or $e.additional.fields["ClientAppId"] = /./
    )
    
    // EXCLUSIONS: Added Outlook Mobile + Standard Google Exclusions
    $e.additional.fields["ClientAppId"] != /^(27922004-5251-4030-b22d-91ecd9a37ea4|bea75f7a-2505-46e8-9bf6-d3f7da9c9da7|b52893c8-bc2e-47fc-918b-77022b299bbc|...)$/ nocase

  match:
    // Group by both App AND Session to isolate the specific token lifecycle
    $application_id,$session_id over 3h

  outcome:
    $vendor_name = "Microsoft"
    $product_name = "Office 365"
    $source_ua_dc = count_distinct($e.network.http.user_agent)
    $client_app_id = array_distinct($e.additional.fields["ClientAppId"])

  condition:
    // Triggers if the SAME session rotates 2+ User Agents
    $e and $source_ua_dc >= 2
}

튜닝된 규칙 2: Multiple Mailboxes Accessed

(동일한 로직이지만, 제외 항목에 Outlook 모바일과 함께 승인된 백업 솔루션(예: Keepit(a7cd46df...))을 허용 목록에 반드시 추가하십시오.)

튜닝된 규칙 3: Multiple ASNs

(User Agents 규칙과 달리 Google은 이 규칙에서는 실제로 $session_id로 올바르게 그룹화했습니다. 다만 여전히 Outlook 모바일 제외가 빠져 있습니다. 위와 동일한 제외 로직을 적용하고 $source_asn_dc >= 2 조건은 유지하십시오.)

튜닝된 규칙 4: Multiple Mailboxes Accessed via Microsoft Graph API

(동일한 로직입니다. events 블록 끝의 제외 정규식에 Keepit(a7cd46df...)과 같은 승인된 백업 애플리케이션을 추가해야 합니다.)

2. UEBA: 비정상 인증 시도 총계

규칙: Anomalous Auth Attempts Total by Principal Hostname and Target User ID

(참고: UEBA는 "User and Entity Behavior Analytics(사용자 및 엔티티 행동 분석)"를 의미합니다. 이러한 규칙은 정적 서명을 사용하지 않고, 수학적 알고리즘을 통해 "정상" 행동을 기준선으로 삼아 통계적 편차에 대해 알림을 발생시킵니다.)

❌ 하드코딩 결함과 알림 피로

이 UEBA 규칙은 30일 동안의 기록 평균과 표준편차를 계산하여 비정상적인 인증 급증을 탐지하려고 시도합니다.

알림 피로: 프로덕션 환경에서 이 큐레이티드 규칙은 매우 낮은 True Positive 비율(~0.08%, 2324개의 알림 중 2건의 조치 가능한 티켓)을 생성했습니다. 사실상 순수한 노이즈입니다.
코드 결함: Google은 outcome 블록 시작 부분에 $num_stddevs_away = max(2) 변수를 선언합니다. 그러나 $historical_threshold 계산에서 Google 개발자는 변수 대신 값 2를 하드코딩했습니다. 이 프로그래밍 오류로 인해 분석가가 YARA-L 로직을 완전히 복제하고 다시 작성하지 않고는 UI나 상속 변수를 통해 민감도를 쉽게 재정의할 수 없습니다.

✅ UEBA 튜닝 권장사항

실제 테스트 결과 통계적 임계값을 단순히 조정하는 것(예: $num_stddevs_away를 3 또는 4로 높이기, $coefficient_of_variation_threshold를 0.1에서 0.05로 낮추기, $observation_threshold를 15로 증가시키기)으로는 충분하지 않습니다. 주간 알림 수가 710건에서 111건으로 줄어들 뿐이며, 분석가 팀에게는 여전히 과도한 노이즈입니다.

권장 접근 방식: SecOps 엔터프라이즈 테넌트의 경우 "Failed Authentications by Device"에 대한 Broad 규칙셋 알림을 비활성화하고 Precise 알림 채널에만 엄격하게 의존하십시오. 이 구조적 완화 조치만이 알림 홍수를 막을 수 있는 유일한 효과적인 방법입니다.
대안적 사용자 지정 접근 방식: 규칙을 계속 유지해야 한다면 규칙을 Custom Rule로 복제하고, $historical_threshold 내부의 하드코딩된 2를 사용자 정의 $num_stddevs_away 변수와 일치하도록 수정한 다음, 더 엄격한 기준 계수를 적용하십시오.

고지 사항: 이 튜닝은 실제 침해 대응 및 SIEM 엔지니어링 경험에 기반합니다. 프로덕션에 배포하기 전에 항상 특정 환경에서 YARA-L 규칙을 테스트하십시오.

인기

fixing-google-secops-detections