月光愛靑狼

자세한 내용은 아래 교보문고 홈페이지를 참고바랍니다.
White Hat Python 화이트 해커를 위한 암호와 해킹

1. 개요

• 2026년 5월 18일 전후, CJ그룹 여성 임직원들의 개인정보가 텔레그램 채널에 무단 게시된 사실이 알려졌습니다. 
• 해당 채널은 2023년에 개설됐고, 유출 정보는 실제 재직 중인 임직원 정보와 일치하는 것으로 확인됐습니다.
• CJ그룹은 사안을 심각하게 보고 경위 조사와 수사 의뢰를 준비 중이라고 밝혔습니다.

2. 피해범위

• 현재까지 확인된 유출 규모는 약 330여 명 수준으로 확인됐습니다.
• 피해 대상은 대부분 여성 임직원으로 전해졌으며, 텔레그램 채널에는 이들의 식별 가능한 정보가 다수 포함된 것으로 알려졌습니다.
• 일부 여성 임직원의 얼굴 사진까지 다수 게시되어 2차 피해 우려도 제기했습니다.

3. 유출항목

• 유출 항목은 이름, 사진, 휴대전화 번호, 이메일, 소속 부서, 직급, 사내 전화번호입니다.
• 근무 지역과 내부 인트라넷 관련 정보도 포함됐다고 합니다.
• 또한 임직원 개인 SNS에 공개된 사진이 무단 게시된 정황이 있다고 합니다.

4. 원인

• CJ그룹은 현재까지 외부 해킹 정황은 발견되지 않았다고 설명했고, 내부자의 임직원 프로필 조회를 통한 유출 가능성을 주요 원인으로 보고 있습니다. 
• 내부 인트라넷에서 조회 가능한 정보가 유출된 점을 근거로 내부 소행 가능성있어 보입니다.
• 다만 정확한 사고 원인과 유출 경로는 아직 조사 중입니다.

5. 대응

• CJ그룹은 유출 사실 확인 후 경위 조사에 착수했고, 수사기관 및 관계기관 신고와 수사 의뢰를 준비 중이라고 밝혔습니다. 
• 회사는 추가 피해 방지를 위한 조치를 취하겠다고도 했습니다. 
• 허민회 CJ그룹 경영지원 대표는 사내 게시판을 통해 임직원들에게 사과의 뜻을 전한 것으로 보도됐습니다.

6. 문제점

• 가장 큰 문제는 휴대전화 번호와 사진처럼 직접 식별 가능한 정보가 함께 유출돼 2차 피해 가능성이 커졌다는 점입니다. 
• 또 여성 직원들에게 피해가 집중된 점은 사안의 민감성과 악의성을 더 키우는 요소로 지적됐습니다. 
• 내부 인트라넷 조회 가능 정보까지 포함된 정황은, 단순 외부 침해보다 내부 통제와 접근권한 관리의 취약성을 드러낸다는 점에서 문제가 큽니다.

1. 개요

• 브레이브모바일은 재능 거래 플랫폼 ‘숨고’를 운영하는 기업으로, 2026년 5월 11일 공식 홈페이지 공지를 통해 2026년 4월 27일 외부 해킹 공격으로 인한 개인정보 유출 사고가 발생했음을 밝혔습니다. 
• 해당 사고는 외부 공격자가 내부 시스템 일부에 접근하면서 발생한 것으로 확인되었습니다.

2. 피해 범위

• 숨고 플랫폼 이용자 중 일부 회원 정보가 유출된 것으로 확인되었습니다.
• 정확한 피해 인원은 공개되지 않았으나, 회사 측은 영향을 받은 사용자에게 개별 안내를 진행하고 있다고 밝혔습니다.
• 전문가(서비스 제공자)와 일반 이용자 모두 일부 포함된 것으로 알려졌습니다.

3. 유출 항목

 - 브레이브모바일 공지 및 관련 보도에 따르면 다음 정보가 유출된 것으로 확인되었습니다.

• 이름
• 휴대전화 번호
• 이메일 주소
• 서비스 이용 관련 일부 정보 (프로필 및 활동 정보 일부 포함 가능)

※ 주민등록번호, 비밀번호, 결제정보 등 민감정보는 유출되지 않았다고 밝혔습니다.

4. 원인

 - 외부 공격자가 취약점을 이용해 내부 시스템에 비정상적으로 접근한 것이 원인으로 분석되었습니다.

 - 구체적인 공격 방식은 공개되지 않았으나, 일반적으로 이러한 사례는

• 웹 애플리케이션 취약점
• 인증 우회 또는 계정 탈취
• API 또는 관리 인터페이스 노출

등과 관련될 가능성이 제기되고 있습니다.

5. 대응

 - 브레이브모바일은 사고 인지 후 다음과 같은 조치를 수행했다고 밝혔습니다.

• 침해 시스템 차단 및 추가 접근 차단 조치
• 보안 취약점 점검 및 보완
• 관계 기관 신고 및 조사 협조
• 영향 대상 사용자 개별 통지
• 추가 피해 방지를 위한 모니터링 강화

 - 또한 사용자에게 의심스러운 연락(피싱, 스미싱 등)에 대한 주의를 당부하였습니다.

6. 문제점

• 이번 사고와 관련하여 지적되는 주요 문제는 다음과 같습니다.
• 사고 발생(4월 27일) 이후 공식 공지(5월 11일)까지 약 2주 지연된 점
• 구체적인 공격 경로 및 기술적 원인에 대한 정보 공개 부족
• 유출 규모(정확한 인원 등)에 대한 투명성 부족
• 재능 거래 플랫폼 특성상 연락처 기반 연결이 많아 2차 피해(피싱, 사칭 등) 가능성 증가

이번 글에서는 지금까지 이어온 Sigma 연재 전체의 흐름을 한 번에 정리해드리겠습니다.

SigmaHQ 공식 문서와 Panther 자료를 보면, Sigma는 특정 SIEM에 종속되지 않는 표준 탐지 언어로서, 로그 소스별 룰을 YAML로 작성하고 다양한 백엔드로 변환하는 데 강점이 있습니다.

그래서 이 연재는 단순한 룰 예제 모음이 아니라, 기초 문법 → 플랫폼 변환 → 실전 탐지 → 운영 자동화 → 미래 확장으로 이어지는 실전형 로드맵으로 보는 편이 가장 정확합니다.

◎ 연재의 출발점

• 처음 연재는 Sigma가 왜 필요한지, 그리고 룰이 어떤 구조로 작성되는지로 시작되었습니다. 
• SigmaHQ 문서는 logsource, detection, condition이 룰의 핵심이며, 동일한 규칙을 Splunk, Elastic, Sentinel 등으로 변환할 수 있다고 설명합니다. 
• 이 단계에서는 탐지 언어를 이해하는 것이 가장 중요했고, 공격자 행위와 로그 필드를 연결하는 감각을 만드는 데 초점이 맞춰졌습니다.

◎ 기본기에서 실전으로

• 그다음 흐름은 보통 MITRE ATT&CK 매핑, 오탐 튜닝, 메타 룰, 룰 유지보수로 이어집니다. 
• Sigma는 단순 키워드 검색이 아니라, 공격자의 전술·기술과 로그 이벤트를 연결하는 방식이기 때문에 ATT&CK 매핑이 매우 중요합니다. 
• 또한 PicoSecurity와 Panther가 강조하듯, Sigma는 자동화와 상호운용성이 강점이므로, 룰을 쌓아두는 것보다 검증 가능한 파이프라인 안에 넣는 것이 더 중요합니다.

◎ DaC 단계

• 연재 중반부의 핵심은 Detection as Code(DaC)였습니다. 
• 여기서는 룰을 수동으로 편집하는 대신 Git으로 관리하고, CI/CD로 validate, convert, test, deploy하는 구조가 중심이 됩니다. 
• 즉, Sigma는 “작성 언어”에서 끝나지 않고, 버전 관리 가능한 탐지 엔지니어링 자산으로 바뀝니다. 
• 이 단계가 들어가면 연재 전체의 성격이 확 달라집니다. 
• 룰 문법 설명에서 벗어나, 실제 조직에서 탐지를 운영하는 방식으로 올라가기 때문입니다.

◎ EDR 통합

• 이후 자연스럽게 이어진 것이 Sigma + EDR 통합입니다. 
• HarfangLab과 Kaspersky 자료처럼, Sigma는 로그 기반 탐지를 EDR 텔레메트리와 결합할 때 특히 강합니다. 
• 이 단계에서는 프로세스 생성, 서비스 설치, 레지스트리 변경, PowerShell, WMI 같은 엔드포인트 행위를 Sigma로 정리하고, EDR에서 실시간 차단 또는 후속 대응으로 연결하는 흐름이 중심이었습니다.
• 여기서 이제 “SIEM 룰”에서 “엔드포인트 대응 설계”로 확장됩니다.

◎ 클라우드 확장

그다음 축은 Sigma + Cloud Security였습니다. 

Recorded Future와 SigmaHQ 문서가 보여주듯, 클라우드 탐지는 AWS CloudTrail, Azure Entra ID, GCP Audit Log 같은 관리 평면 로그가 핵심입니다.

이 단계에서는 플랫폼별로 다른 로그 구조를 Sigma로 추상화해서, 계정 탈취, 권한 상승, 로깅 무력화, 방화벽 변경 같은 행위를 공통 프레임으로 다루게 됩니다.

즉, 이제 단일 엔드포인트를 넘어 멀티클라우드 탐지 체계로 확장된 셈입니다.

◎ 개별 클라우드 편

 - 클라우드 통합 다음에는 개별 플랫폼을 깊게 파고드는 구성이 가장 자연스럽습니다.

• AWS CloudTrail 전용 Sigma 룰 작성법: DeleteTrail, StopLogging, CreateAccessKey, AuthorizeSecurityGroupIngress 같은 핵심 이벤트를 CloudTrail 기준으로 다룹니다.
• Azure Sentinel + Entra ID Sigma 탐지: 고위험 로그인, 역할 할당, 서비스 주체 생성, 조건부 액세스 우회를 다룹니다.
• GCP Cloud Audit Log Sigma 룰: IAM 정책 변경, 서비스 계정 키 생성, 방화벽 수정, 감사 로그 조작을 다룹니다.

 - 이 세 편은 사실상 클라우드 파트의 “개별 심화편”이며, 이전의 통합편을 실제 운영 가능한 룰로 쪼개는 역할을 합니다.

◎ 랜섬웨어 프로젝트

• 그다음 마지막 실전 축은 최신 랜섬웨어 공격 시나리오로 구현하는 실전 Sigma 프로젝트입니다. 
• DFIR Report, SOC Prime, Picus의 자료를 보면 최근 랜섬웨어는 초기 침투, Cobalt Strike, PsExec, WMI, 서비스 생성, 암호화 실행까지 매우 빠르게 이어집니다.
• 그래서 이 파트는 단일 IOC가 아니라 공격 체인 전체를 Sigma 룰과 상관분석으로 묶는 프로젝트로 보는 게 맞습니다.

◎ AI/ML 확장

• 마지막 보너스 축이 Sigma + AI/ML 탐지입니다.
• SigmaHQ와 Picus가 보여주는 것처럼 Sigma는 구조화된 룰 언어이므로, ML 이상 점수와 결합하거나 LLM으로 룰 초안을 생성하는 데 잘 맞습니다.
• 이 단계에서는 룰이 AI를 대체하는 것이 아니라, AI가 발견한 이상을 Sigma로 설명 가능하게 만드는 구조가 핵심입니다. 즉, 미래 지향적인 보강편으로 두기 좋습니다.

◎ 전체 로드맵

 - 지금까지의 흐름을 한 줄로 정리하면 아래처럼 볼 수 있습니다.

• Sigma 기본 문법 이해
• ATT&CK 매핑과 오탐 튜닝
• Meta Rule과 상관분석
• Detection as Code 파이프라인
• Sigma + EDR 통합
• Sigma + Cloud Security 통합
• AWS / Azure / GCP 개별 심화
• 랜섬웨어 실전 프로젝트
• AI/ML 기반 확장.

◎ 마무리

• 지금까지의 내용은 단순히 “Sigma 룰을 몇 개 썼다”가 아니라, 탐지 엔지니어링이 실제 운영 체계로 어떻게 발전하는지를 보여준다는 점입니다. 
• SigmaHQ의 표준 문법 위에 DaC, EDR, Cloud, 랜섬웨어, AI/ML을 차례로 얹으면, 결국 하나의 일관된 탐지 운영 프레임이 완성됩니다.

이번 글에서는 Sigma를 AI/ML 기반 탐지와 어떻게 결합할 수 있는지 실전 관점에서 정리해드리겠습니다.

Sigma는 원래 로그 기반 탐지를 표준화하기 위한 YAML 포맷이지만, SigmaHQ 공식 문서와 Picus 자료를 보면 이 포맷이 단순한 룰 저장 형식을 넘어 CI/CD, 대규모 룰 재사용, 플랫폼 간 변환에 적합하다는 점이 분명합니다.

여기에 AI/ML을 더하면, 단순 룰 탐지를 넘어 이상 징후 발견, 룰 초안 생성, 오탐 분류, 튜닝 자동화까지 확장할 수 있습니다.

◎ AI/ML을 붙이는 이유

• 전통적인 Sigma 룰은 강력하지만, 이미 알고 있는 TTP를 빠르게 탐지하는 데 더 강합니다. 
• 반면 AI/ML은 정상 행위의 패턴을 학습한 뒤 벗어나는 행동을 찾는 데 유리합니다. 
• 즉, Sigma는 “무엇을 볼지”를 명확히 하고, AI/ML은 “무엇이 이상한지”를 넓게 보는 식으로 역할이 나뉩니다.
• 실무에서는 이 둘을 경쟁시키기보다 전처리와 후처리로 엮는 방식이 가장 효과적입니다.

◎ Sigma와 AI/ML의 분업

 - 구조를 단순화하면 다음과 같습니다.

• Sigma: 정형 로그에서 알려진 공격 패턴 탐지.
• ML 이상탐지: 계정, 프로세스, 네트워크의 비정상 변화 탐지.
• LLM 보조: 룰 초안 작성, 필드 추정, 설명 자동 생성.

 - SigmaHQ 문서도 Sigma가 기본적으로 행위 기반 탐지에 맞고, 룰은 YAML과 간단한 조건 조합으로 구성된다고 설명합니다.

 - 그렇기 때문에 AI/ML이 계산한 스코어를 바로 Sigma 조건에 넣거나, 반대로 Sigma hit을 학습 데이터로 쓰는 방식이 자연스럽습니다.

◎ 가장 실용적인 적용 지점

 - AI/ML과 Sigma를 섞을 때 가장 먼저 효과가 나는 영역은 다음 세 가지입니다.

1. 이상치 점수로 Sigma 트리거

• ML 모델이 risk_score를 만들고, 그 점수가 특정 임계치를 넘으면 Sigma 룰이 작동하도록 합니다.
• 예를 들어, 평소엔 보이지 않던 국가에서 로그인했고, 짧은 시간에 여러 호스트에서 PowerShell이 실행되면 점수가 급상승합니다. 
• 이 값을 risk_score > 80 같은 조건으로 묶으면 Sigma의 정교함과 ML의 넓은 시야를 함께 가져갈 수 있습니다.

2. Sigma hit을 학습 라벨로 사용

• 이미 잘 만들어진 Sigma 룰은 정답 라벨로 쓰기 좋습니다.
• 예를 들어, Azure Sentinel의 Entra ID 룰이나 AWS CloudTrail 룰에서 잡힌 이벤트를 정상/비정상 라벨로 분류하면, 이후 ML 모델 학습 데이터로 활용할 수 있습니다.
• 이 방식은 초기 데이터셋이 부족한 SOC 환경에서 특히 유용합니다.

3. LLM으로 룰 초안 생성

• SigmaHQ는 15,000개 이상의 룰 생태계를 가진 만큼, 비슷한 공격 패턴을 참고해 새 룰을 빠르게 확장할 수 있습니다.
• LLM은 여기서 초안 생성기 역할을 하기에 좋습니다. 예를 들어, “CloudTrail에서 IAM 권한 상승 탐지” 같은 설명을 입력하면 eventName, userIdentity, requestParameters 기반 초안을 뽑아낼 수 있습니다.
• 다만 최종 검증은 반드시 사람이 하셔야 합니다.

◎ 실전 아키텍처

• 가장 현실적인 구조는 아래와 같습니다.

• 이 구조에서 Sigma는 “결정 규칙”을 담당하고, ML은 “우선순위 재조정”을 담당합니다.
• Picus도 Sigma를 포함한 탐지 콘텐츠가 플랫폼에 종속되지 않고 변환 가능해야 운영 효율이 높다고 설명합니다.
• 즉, AI/ML은 단독 운영보다 Sigma 파이프라인의 앞단과 뒷단에 붙일 때 가장 실용적입니다.

◎ 예시 시나리오

예시 1. 랜섬웨어 전조
 - 모델이 다음 특징을 감지합니다.

• 새로 생성된 서비스 계정.
• 짧은 시간 내 다수 호스트 접속.
• PsExec, WMI, PowerShell 실행 증가.

- 이때 Sigma는 알려진 패턴을 직접 잡고, ML은 그 조합의 비정상성을 점수화합니다.

 - 결과적으로 단일 IOC가 없어도 공격 전개를 놓치지 않게 됩니다.

예시 2. 클라우드 계정 탈취

• AWS CloudTrail이나 Entra ID에서 평소와 다른 지역, 다른 User-Agent, 이상한 토큰 발급이 연속으로 발생하면, Sigma는 특정 API 호출을 잡고 ML은 행위 시퀀스 전체를 이상치로 판정합니다.
• 이 방식은 공격자가 정상 사용자처럼 보이도록 위장할수록 더 유리해집니다.

◎ 운영 시 주의점

 - AI/ML을 붙인다고 자동으로 좋아지지는 않습니다. 오히려 아래 세 가지가 중요합니다.

• Feature drift 관리가 필요합니다.
• 학습 데이터 편향을 확인하셔야 합니다.
• 설명 가능성을 반드시 확보해야 합니다.

 - 특히 보안관제에서는 “왜 울렸는가”가 명확해야 하므로, ML 결과는 그대로 쓰기보다 Sigma 룰이나 상관분석으로 설명 가능한 형태로 바꾸는 편이 좋습니다.

 - 또한 Picus가 말하듯 Sigma는 CI/CD에 잘 맞기 때문에, 모델 변경과 룰 변경을 같은 파이프라인에서 검증하면 운영 안정성이 높아집니다.

◎ 도입 순서

 - 실무에서는 아래 순서가 가장 무난합니다.

• 기존 Sigma 룰을 먼저 정리합니다.
• 룰 히트 데이터를 라벨로 저장합니다.
• 간단한 이상치 탐지 모델부터 붙입니다.
• ML 점수를 Sigma 조건 또는 상관분석에 연결합니다.
• 오탐 사례를 다시 룰과 모델 양쪽에 반영합니다.

 - 이 순서를 따르면 AI/ML이 갑자기 독립 시스템이 되지 않고, 기존 SOC 흐름 안에 자연스럽게 녹아듭니다.

◎ 마무리

• Sigma와 AI/ML의 결합은 “룰 탐지 vs 머신러닝 탐지”의 대결이 아닙니다. 
• 오히려 명확한 탐지 규칙과 유연한 이상탐지의 협업에 가깝습니다.
• Sigma가 공격자의 알려진 행동을 빠르게 잡고, AI/ML이 그 주변의 이상한 흐름을 넓게 보완하면, SOC는 훨씬 촘촘한 탐지 체계를 갖출 수 있습니다.
• 특히 랜섬웨어, 계정 탈취, 클라우드 권한 오용처럼 패턴은 같지만 변형이 많은 공격에서는 이 조합이 매우 강합니다.

이번 글에서는 최신 랜섬웨어 공격 흐름을 가정해 Sigma 룰을 어떻게 설계하고 묶어낼지 실전 관점에서 정리해드리겠습니다.

랜섬웨어는 이제 단일 악성코드보다 초기 침투, 자격증명 탈취, 수평 이동, 배포 자동화가 결합된 공격 체인으로 움직이며, DFIR Report와 SOC Prime 사례도 이런 다단계 전개를 강조합니다.

SigmaHQ 공식 문서는 Sigma가 YAML 기반 탐지 언어이며, 로그 소스별로 행동 패턴을 표준화해 SIEM으로 변환할 수 있다고 설명합니다.

◎ 왜 시나리오형 프로젝트인가

• 랜섬웨어 탐지는 개별 IOC만으로는 부족합니다. 
• 최근 공격은 피싱으로 초기 진입을 만든 뒤, Cobalt Strike 같은 원격 제어 도구를 올리고, LSASS에서 자격증명을 빼낸 후, PsExec와 WMI로 암호화 페이로드를 퍼뜨리는 식으로 이어집니다. 
• DFIR Report가 분석한 Quantum 사례는 초기 감염에서 도메인 전체 암호화까지 4시간도 채 걸리지 않았다고 설명합니다.
• 그래서 실전 Sigma 프로젝트는 단일 룰 모음이 아니라 공격 단계별 탐지 체인으로 설계하시는 편이 훨씬 강합니다.

◎ 프로젝트 목표

 - 이번 프로젝트의 목표는 다음 네 단계를 하나의 탐지 흐름으로 연결하는 것입니다.

• 초기 침투: 악성 ISO, 문서 매크로, 취약점 악용.
• 포스트 익스플로잇: Cobalt Strike, 계정 탐색, LSASS 접근.
• 수평 이동: PsExec, WMI, RDP.
• 랜섬웨어 실행: 서비스 생성, 배포 스크립트, 대량 암호화.

 - 이 흐름을 Sigma로 쪼개면, 각 단계에서 경고를 만들고 이후 상관분석으로 하나의 인시던트로 묶을 수 있습니다.

◎ 1단계 초기 침투

• 공격의 시작은 보통 피싱 이메일, 악성 ISO, Office 문서입니다. 
• Picus Security는 DarkSide 초기 단계에서 Word가 Filter Loader를 호출하는 비정상적인 프로세스 관계를 Sigma로 탐지하는 예시를 제시합니다.

 - 같은 원리로 다음과 같은 규칙을 먼저 둘 수 있습니다.

• 이 규칙은 Office 문서가 스크립트 인터프리터를 호출하는 장면을 잡는 기본형입니다.

◎ 2단계 포스트 익스플로잇

• Quantum 사례에서는 IcedID 감염 이후 Cobalt Strike Beacon이 올라오고, 이후 LSASS 접근과 도메인 탐색이 이어졌습니다. 
• SOC Prime은 Quantum 관련 Sigma 세트에 Cobalt Strike pipe 이벤트, 의심스러운 프로세스 생성, 예약 작업 생성 같은 탐지를 포함한다고 설명합니다.

 - 이 구간에서는 아래처럼 프로세스 생성과 파이프 이벤트, 예약 작업을 함께 보는 것이 좋습니다.

• 이후에는 LSASS 접근 이벤트, 새 서비스 생성, 의심스러운 named pipe를 추가해서 체인을 넓히시면 됩니다.

◎ 3단계 수평 이동

• 랜섬웨어 조직은 흔히 PsExec와 WMI를 이용해 감염을 확산합니다. 
• DFIR Report와 SOC Prime 사례 모두 Quantum 공격에서 WMI, PsExec, RDP가 수평 이동의 핵심이었다고 밝힙니다.

 - 실전에서는 아래 두 축이 매우 중요합니다.

• 그리고 서비스 생성 이벤트를 따로 두어야 합니다.
• FortiSIEM이 Sigma에서 차용한 Cobalt Strike 서비스 설치 룰도 ADMIN$와 COMSPEC, powershell 패턴을 강조합니다.

• 이런 룰은 단독 탐지보다 연결 탐지가 더 중요합니다.
• 예를 들어 “Cobalt Strike 의심 프로세스 → PsExec 서비스 생성 → 원격 실행” 순서를 30분 이내로 묶으면 경보 품질이 훨씬 높아집니다.

◎ 4단계 랜섬웨어 실행

• 마지막은 암호화 페이로드 배포입니다. 
• LockBit과 Quantum 사례 모두 WMI 또는 PsExec로 다수 호스트에 페이로드를 복사하고 실행하는 방식이었습니다. 
• SOC Prime의 LockBit 탐지 자료도 서비스 설치, 레지스트리 변경, 명령행 패턴 같은 실행 흔적을 별도로 다룹니다.

 - 이 단계에서는 다음과 같은 규칙이 유효합니다.

• 또는 서비스 생성 후 바로 실행되는 패턴을 붙여서, 실제 암호화 직전의 행위를 포착하시면 좋습니다.

◎ 프로젝트 구성 방법

 - 이 프로젝트는 단일 룰 1개보다 룰 세트 + 상관분석으로 구성하시는 것이 좋습니다.

• Rule 1: Office/ISO 초기 실행 탐지.
• Rule 2: Cobalt Strike 의심 행위.
• Rule 3: PsExec/WMI 수평 이동.
• Rule 4: 서비스 생성 및 랜섬웨어 실행.
• Correlation: 1→2→3→4를 시간순으로 묶기.

 - SigmaHQ의 규칙 구조 문서도 logsource, detection, metadata를 분리해 유지보수성을 높이라고 권장합니다. 즉, 룰을 길게 한 줄로 쓰기보다 단계별로 잘라두는 것이 실무적입니다.

◎ 오탐을 줄이는 법

 - 랜섬웨어 시나리오형 탐지에서 가장 큰 문제는 관리 도구와의 혼동입니다. 

 - PsExec, WMI, PowerShell, RDP는 모두 관리자도 쓰기 때문입니다.

 - 따라서 다음 기준이 필요합니다.

• 배포 서버, 점프 서버, 운영 계정은 화이트리스트로 두십시오.
• 야간 시간대와 비정상 작업 시간을 구분하십시오.
• 한 호스트에서 끝나는 단발성 이벤트보다 다수 호스트 연쇄를 더 높게 평가하십시오.

 - SOC Prime과 Picus 사례도 결국 TTP 조합이 있어야 오탐을 줄일 수 있다고 말합니다.

◎ 마무리

• 최신 랜섬웨어는 단순 악성 파일이 아니라 초기 침투부터 배포까지 자동화된 공격 체인입니다. 
• 그래서 Sigma 프로젝트도 IOC 중심이 아니라 행위 중심, 단계 중심, 상관분석 중심으로 설계하셔야 합니다.

이번 글에서는 GCP Cloud Audit Log를 기반으로 Sigma 룰을 작성하는 방법을 실전 관점에서 정리해드리겠습니다. 

Sigma는 벤더 중립적인 탐지 규칙 포맷이라서, GCP 감사 로그처럼 구조화된 클라우드 로그와 궁합이 좋습니다. 

Panther와 SigmaHQ 문서에서도 Sigma는 YAML 기반으로 탐지 로직을 기술하고, 백엔드를 통해 SIEM별 쿼리로 변환되는 표준이라고 설명합니다.

◎ 왜 GCP Audit Log인가

• GCP Cloud Audit Logs는 관리자 활동, 데이터 액세스, 시스템 이벤트, 정책 거부를 기록하며, 누가 언제 어디서 무엇을 했는지 추적하는 데 핵심이 됩니다. 
• 특히 공격자는 IAM 정책을 바꾸거나, 서비스 계정을 악용하거나, 방화벽과 로깅 설정을 바꾸는 식으로 움직이기 때문에, 감사 로그가 있으면 초반 행위를 빠르게 잡아낼 수 있습니다.
• SigmaHQ의 logsource 문서도 이런 식으로 product와 service를 조합해 특정 로그 소스를 좁히는 방식을 권장합니다.

◎ 먼저 봐야 할 이벤트

 - GCP에서는 처음부터 모든 로그를 다 보려 하기보다, 관리 평면 이벤트부터 잡는 편이 좋습니다. 

 - 실무에서 우선순위가 높은 항목은 다음과 같습니다.

• IAM 정책 변경입니다.
• 서비스 계정 키 생성입니다.
• 방화벽 규칙 수정/삭제입니다.
• Cloud Logging 비활성화 또는 변경입니다.
• 데이터 액세스 권한 변화입니다.

 - Panther의 Sigma 예시도 GCP 방화벽 생성·삭제·수정 이벤트를 탐지하는 규칙을 보여주며, gcp.audit.method_name 기반으로 매칭하는 구조를 사용합니다.

◎ 기본 규칙 구조

• GCP Audit Log용 Sigma는 보통 아래 형태로 시작하면 됩니다.

• 이 규칙은 방화벽 변경 행위 자체를 잡는 가장 기본적인 패턴입니다.
• 실제 운영에서는 이 규칙에 프로젝트 ID, 사용자 이메일, 호출 IP를 함께 넣어야 오탐 줄이기가 훨씬 쉬워집니다.

◎ 실전 탐지 포인트

• 가장 먼저 추천드리는 탐지 포인트는 IAM 정책 변경입니다. 
• GCP에서는 서비스 계정 가장이 공격의 핵심이기 때문에, SetIamPolicy 계열 이벤트와 serviceAccountTokenCreator, serviceAccountUser 같은 역할 추가를 같이 보는 것이 좋습니다.
• A13e의 GCP Audit Log 룰 라이브러리도 이런 식으로 서비스 계정 권한 상승을 별도 탐지 항목으로 다루고 있습니다.
• 예를 들면 다음과 같이 작성할 수 있습니다.

• 이 규칙은 서비스 계정 가장을 위한 핵심 권한 추가를 탐지하는 데 유용합니다.

◎ 서비스 계정과 방화벽

• GCP에서는 서비스 계정 키 생성이 매우 중요합니다. 
• 공격자가 키를 만들면 장기적으로 재사용 가능한 자격 증명을 확보하게 되므로, CreateServiceAccountKey 계열 이벤트는 반드시 보셔야 합니다.
• 방화벽 쪽에서는 Compute.Firewalls.Delete, Patch, Update 같은 메서드를 기준으로 보면 되고, 필요하면 포트·대상 범위까지 좁혀서 외부 노출 행위를 잡을 수 있습니다.

◎ 로그 비활성화와 은폐

• 공격자는 흔히 감사 로그 자체를 약화시키려고 합니다. 
• GCP에서는 감사 로그를 직접 끄는 것이 어렵더라도, 로그 라우팅, 싱크, 권한, 보관 정책을 바꾸는 방식으로 탐지를 회피할 수 있습니다.
• 그래서 Disable, Delete, Update 계열의 관리 작업과 함께, 로깅 설정 변경 이벤트를 따로 묶어 보는 것이 중요합니다.
• 이 부분은 AWS CloudTrail의 StopLogging과 같은 사고 모델로 이해하시면 편합니다.

◎ 오탐 줄이는 방법

• GCP Audit Log는 자동화 시스템이 많이 호출하기 때문에, 오탐 튜닝이 정말 중요합니다.
• Terraform, Deployment Manager, CI/CD principal을 화이트리스트로 두십시오.
• 프로젝트별로 예상되는 서비스 계정 메일을 필터링하십시오.
• 정기 배포 시간대와 관리 작업 시간을 구분하십시오.
• A13e 라이브러리도 실전 배포 전에 automation principal과 IP allowlist를 튜닝하라고 안내합니다.
• 이 부분을 빼면 초기 운영에서 알람 피로도가 매우 높아집니다.

◎ 운영 순서

 - 실무에서는 아래 순서로 가시면 가장 안정적입니다.

• Audit Logs 수집 활성화부터 확인합니다.
• IAM 정책 변경, 서비스 계정 키 생성, 방화벽 수정 세 가지를 먼저 탐지합니다.
• Sigma로 작성한 뒤 SIEM dialect로 변환합니다.
• CI/CD에서 테스트용 GCP 로그로 검증합니다.
• 오탐 필터를 추가하고 운영에 투입합니다.

◎ 마무리

• GCP Cloud Audit Log는 단순한 감사 기록이 아니라, 공격자가 클라우드에서 무엇을 바꾸고 어떻게 은폐하는지 보여주는 핵심 증거입니다. 
• Sigma로 이 로그를 표준화하면, GCP 전용 탐지를 만들면서도 다른 클라우드와 같은 문법으로 운영할 수 있습니다.
• 특히 IAM 정책 변경, 서비스 계정 권한 상승, 방화벽 수정, 로깅 무력화는 반드시 우선순위로 잡는 것이 좋습니다.

이번 글에서는 Azure Sentinel과 Entra ID(구 Azure AD) 로그를 활용한 Sigma 탐지를 실전 중심으로 정리해드리겠습니다.

Microsoft 문서는 Sentinel이 Entra ID Sign-in Logs와 Audit Logs를 기본 지원하며, KQL로 탐지 규칙을 작성한다고 설명합니다.

SigmaHQ 파이프라인을 통해 Sigma 규칙을 KQL로 변환하면, 커뮤니티 3,700+ 규칙을 바로 활용할 수 있습니다.

◎ Azure Sentinel + Entra ID가 중요한 이유

• Azure Sentinel은 클라우드 네이티브 SIEM으로, Entra ID의 Sign-in Logs, Audit Logs, Provisioning Logs를 기본으로 수집합니다. 
• 이 로그들은 비정상 로그인, 역할 변경, 앱 등록 같은 Azure 공격의 핵심을 잡아줍니다. 
• Sigma를 쓰면 이런 로그를 플랫폼 독립적으로 표준화해, AWS나 GCP 규칙과도 공유할 수 있습니다.

 - 탐지 우선순위

• 고위험 로그인 (위치, 디바이스 불일치).
• 역할 할당/권한 상승.
• 앱 등록/서비스 주체 생성.
• 조건부 액세스 우회 시도.

◎ Entra ID 로그 필드 구조

 - Sign-in Logs (SigninLogs 테이블)

• ResultType: 0(성공), 50053(조건부 액세스 블록).
• Location: IP, 국가, ISP.
• RiskLevelDuringSignIn: high, medium.
• ConditionalAccessStatus: success, failure.

 - Audit Logs (AuditLogs 테이블)

• Category: UserManagement, ApplicationManagement.
• ActivityDisplayName: Add member to role.
• TargetResources: 대상 객체.

 - Sigma 매핑

◎ 기본 Entra ID Sigma 규칙

1. 고위험 로그인 탐지

 - KQL 변환 결과

2. 역할 할당 탐지

3. 서비스 주체 생성 (백도어)

◎ 고급 탐지 패턴

1. 조건부 액세스 우회

• 위치 기반 CA 우회 시도.

2. 다중 계정 동시 로그인

• 한 IP에서 5개 이상 계정 로그인.

3. 앱 등록 + 권한 부여 체인

◎ Sentinel 파이프라인 설정

 - Entra ID 커넥터 활성화

 - KQL 테이블

 - Sigma CLI 변환

 - 변환 결과 예시

◎ 오탐 튜닝 전략

 - Whitelist

 - 위험도 필터

 - 시간 기반

◎ 실전 워크플로

1. 데이터 온보딩

2. Sigma 규칙 배포

3. 인시던트 대응

4. 자동화

◎ 운영 팁

1. P1/P2 차이

• P1: 기본 Risk Detection.
• P2: Adaptive Access Control 추가.

2. 워크북 활용

3. MITRE 매핑:

◎ 마무리

• Azure Sentinel + Entra ID는 클라우드 인증 공격의 첫 번째 방어선입니다. 
• Sigma로 고위험 로그인, 역할 할당, 서비스 주체 생성을 표준화하면, AWS CloudTrail과 함께 클라우드 보안의 양 날개를 갖추게 됩니다.

자세한 내용은 아래 교보문고 홈페이지를 참고바랍니다.

오픈소스 툴킷을 이용한 실전해킹 절대내공

이번 글에서는 AWS CloudTrail 로그에 특화된 Sigma 규칙 작성법을 실전 중심으로 정리해드리겠습니다.

SigmaHQ 저장소에는 aws_cloudtrail_disable_logging.yml, aws_cloudtrail_bucket_deleted.yml 같은 CloudTrail 전용 규칙이 이미 존재하며, Invictus-IR의 Athena 기반 Sigma 프로젝트도 CloudTrail 탐지의 실전 사례를 보여줍니다.

Recorded Future 연구도 CloudTrail에서 Stratus Red Team, Pacu 같은 공격 도구의 행위를 탐지하는 데 Sigma를 활용했다고 설명합니다.

◎ CloudTrail이 왜 중요한가

• AWS CloudTrail은 관리 이벤트와 데이터 이벤트를 기록하는 핵심 감사 로그입니다.
• AWS 공식 문서에 따르면, IAM, S3, EC2, VPC 등 모든 서비스의 API 호출을 추적하며, 공격자의 계정 조작, 로깅 무력화, 권한 상승을 가장 먼저 잡을 수 있습니다.
• SigmaHQ 규칙도 logsource: product: aws, service: cloudtrail로 표준화되어 있어, SIEM 변환도 간단합니다.

 - 탐지 우선순위:

• 로깅 무력화: DeleteTrail, StopLogging, UpdateTrail.
• 권한 상승: CreateAccessKey, AttachUserPolicy.
• 보안 그룹 개방: AuthorizeSecurityGroupIngress.
• S3 버킷 조작: DeleteBucket.

◎ CloudTrail 필드 구조 이해

 - CloudTrail JSON 로그의 핵심 필드는 다음과 같습니다.

• eventName: API 호출명 (CreateAccessKey, DeleteTrail).
• eventSource: 서비스명 (iahttp://m.amazonaws.com, cloudtrail.amazonaws.com).
• userIdentity.type: 사용자 타입 (Root, AssumedRole).
• requestParameters: 요청 파라미터 (중첩 JSON).
• responseElements: 응답 결과.
• errorCode, errorMessage: 실패 시 에러.

 - Sigma에서 중첩 필드는 requestParameters.* 또는 responseElements.*로 표현하거나, 파이프라인에서 평탄화합니다.

◎ 기본 CloudTrail Sigma 규칙

1. CloudTrail 로깅 무력화 탐지 (SigmaHQ 공식)

 - Splunk 변환 결과

2. 루트 계정 액세스 키 생성

3. 보안 그룹 SSH 개방

◎ 고급 탐지 기법

1. 요청 파라미터 중첩 해석

• requestParameters.bucketName처럼 중첩 필드 접근.

2. 실패 이벤트 포함 (Gist 예시)

• 실패한 VM Export도 탐지.

3. Meta Rule로 상관분석

• 루트 키 생성 → SSH 개방 흐름 탐지.

◎ CloudTrail 로그 온보딩

 - S3 → Athena 변환 (Invictus-IR 방식)

 - SIEM 연동

◎ 실전 운영 워크플로

1. CloudTrail 활성화

2. 필수 이벤트 로깅

3. Sigma 규칙 배포

4. Athena 쿼리 예시

 - Whitelist 필터

 - 시간 기반

◎ 마무리

AWS CloudTrail은 클라우드 공격의 첫 번째 전선입니다. 

Sigma로 DeleteTrail, CreateAccessKey, AuthorizeSecurityGroupIngress 같은 핵심 이벤트를 표준화하면, 공격자의 초반 행보를 놓치지 않을 수 있습니다.