Windows 보안 감사 정책과 이벤트 로그 조사 실무 ── 4625를 읽는 정보시스템 담당자가 되기

「어젯밤부터 어떤 계정이 잠금을 반복하고 있다. 원인을 조사해 달라」「퇴사자 계정으로 누군가 로그온을 시도하지 않았는지 확인하고 싶다」「이 서버, 언제 누가 무엇을 실행했는지 알 수 있나?」── 중소기업 정보시스템 담당자나, 고객사에 시스템을 납품하는 개발자가 어느 날 갑자기 받는 요청입니다. 그리고 의지할 곳이 Windows의 Security 이벤트 로그입니다.

그런데 실제로 이벤트 뷰어를 열면, 그곳에는 두 가지 현실이 기다립니다. 보고 싶은 이벤트가 기록되어 있지 않거나(감사 정책이 활성화되어 있지 않음), 대량 이벤트에 묻혀 읽을 수 없거나(노이즈로 비대해져 있음)입니다. 보안 감사는 「활성화하면 기록된다」는 기능이지만, 무엇을 어디까지 기록할지 설계하지 않으면 정작 필요할 때 도움이 되지 않습니다.

flowchart TB
    accTitle: 이벤트 뷰어에서 마주치는 두 가지 현실
    accDescr: 이벤트 뷰어를 열면, 감사 정책이 활성화되어 있지 않아 보고 싶은 이벤트가 기록되지 않았거나, 노이즈로 비대해져 대량 이벤트에 묻혀 읽을 수 없거나 둘 중 하나이며, 무엇을 어디까지 기록할지 설계해야 한다
    open["이벤트 뷰어를 연다"] --> real{"기다리는 현실은?"}
    real -->|기록되지 않음| none["보고 싶은 이벤트가 미기록"]
    real -->|묻혀 있음| noise["대량 이벤트에 읽을 수 없음"]
    none -.-> cause1["감사 정책이 비활성"]
    noise -.-> cause2["노이즈로 비대해짐"]
    none --> design["무엇을 어디까지 기록할지 설계"]
    noise --> design

그림 1: 「기록이 없다」 아니면 「묻혀서 읽을 수 없다」. 둘 다 기록 범위를 설계하지 않은 것이 원인입니다.

이 글에서는 감사 정책의 구조(기본과 고급 두 체계), 중소 규모 환경에서 최소한 활성화해야 할 하위 범주, 4624/4625/4740/4688 같은 대표 이벤트 ID를 읽는 법, Security 로그의 용량 설계, 그리고 PowerShell로 조사하는 방법까지를 2026년 8월 시점의 1차 자료를 바탕으로 정리합니다. 이 사이트에서 다뤄 온 NTLM 감사·SMB 서명·BitLocker·방화벽 각 글이 「방어를 단단히 하는」 이야기라면, 이 글은 「무슨 일이 일어났는지 나중에 확인할 수 있게 하는」 이야기이며, 그것들을 묶는 후속 글입니다.

1. 먼저 결론

• 감사 정책에는 「기본」과 「고급(Advanced Audit Policy)」 두 체계가 있으며, 섞으면 안 됩니다. 둘을 함께 쓰면 감사 결과가 예상과 다른 상태가 된다고 Microsoft가 명시합니다. 고급 쪽(하위 범주 40개 이상)으로 통일합니다.¹
• 현재 상태 확인은 auditpol /get /category:*입니다. GPO에서 왔든 로컬 설정에서 왔든, 지금 적용 중인 감사 설정을 목록으로 볼 수 있습니다.²
• 「전부 활성화」는 하면 안 됩니다. 이벤트를 대량으로 만드는 하위 범주를 활성화하면, 정작 중요한 이벤트가 노이즈에 묻히고 성능에도 영향을 줍니다. Microsoft의 베이스라인 권장을 출발점으로, 필요한 것만 더합니다.³⁴
• 로그온 성공은 4624, 실패는 4625입니다. 4624는 로그온 유형(2=대화형, 3=네트워크, 10=원격 데스크톱 등)으로 「어떤 로그온인지」를 구분합니다.⁵
• 4625는 Status/Sub Status 코드로 실패 이유를 알 수 있습니다. 0xC0000064=존재하지 않는 사용자 이름, 0xC000006A=비밀번호 오류, 0xC0000072=사용 안 함으로 설정된 계정, 0xC0000234=잠금 중, 이 대표적입니다.⁶
• 이벤트는 「어느 컴퓨터에 기록되는지」가 정해져 있습니다. 4624/4625는 접근된 쪽 컴퓨터, 자격 증명 유효성 검사(4776)나 Kerberos 사전 인증 실패(4771)는 도메인 컨트롤러입니다. 볼 컴퓨터를 잘못 고르면 「로그가 없다」고 오진합니다.⁶⁷⁸
• Security 로그는 용량 설계(최대 크기와 보존)가 절반입니다. 보존이 덮어쓰기 모드이면 오래된 이벤트부터 사라집니다. Get-WinEvent -ListLog Security로 최대 크기와 건수를 확인하고, 필요한 보존 일수에서 역산해 늘립니다.⁹¹⁰
• 프로세스 생성(4688)의 명령줄 기록은 강력하지만, 기밀이 로그에 평문으로 남는 위험을 감수하는 설정입니다. 활성화하기 전에 스크립트류를 점검하십시오.¹¹¹²

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 34건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 감사 정책의 기초 ── 「기본」과 「고급」을 섞지 않는다

Windows의 감사 정책은 두 체계가 있습니다.¹

• 기본 감사 정책: 「로컬 정책 > 감사 정책」에 있는 범주 설정 9개입니다. Windows Vista 이전부터 있던 오래된 체계입니다.
• 고급 감사 정책(Advanced Audit Policy Configuration): 「보안 설정 > 고급 감사 정책 구성」에 있는 하위 범주 설정 40개 이상입니다. 기본의 범주 하나를 여러 하위 범주로 나눈 것으로, 예를 들어 기본의 「계정 로그온 이벤트 감사」 하나에 대해 고급 쪽에는 하위 범주가 4개 있습니다. 기본 쪽에서 범주 하나를 활성화하는 것은 대응하는 하위 범주를 전부 활성화하는 것과 같아서, 관심 없는 이벤트까지 대량으로 기록됩니다.¹

중요한 점은 이 두 체계가 호환되지 않는다는 것입니다. Microsoft는 「기본과 고급을 함께 쓰지 마십시오. 감사 결과가 예상과 다른 상태가 됩니다」라고 명시합니다. 그룹 정책으로 고급 감사 정책을 적용하면 그 컴퓨터의 기존 감사 설정이 한 번 지워진 뒤 고급 쪽 설정이 적용되며, 이후에는 고급 쪽에서만 확실히 제어할 수 있습니다. 고급 쪽을 쓰는 환경에서는 보안 옵션 「감사: 감사 정책 하위 범주 설정을 강제로 적용」을 활성화해 두어, 기본 쪽 설정이 덮어쓰지 못하게 합니다(독립 실행형 컴퓨터에서는 기본으로 활성화되어 있습니다).¹⁴

flowchart TB
    accTitle: 기본 감사 정책과 고급 감사 정책의 관계
    accDescr: 기본 감사 정책과 고급 감사 정책은 호환되지 않으며, 둘을 함께 쓰면 감사 결과가 예상과 다른 상태가 되므로, 고급 쪽으로 통일하고 하위 범주 설정 강제를 활성화해 기본 쪽의 덮어쓰기를 막는다
    basic["기본 감사 정책（범주 9개）"] --> both{"둘을 함께 쓰는가?"}
    adv["고급 감사 정책（하위 범주 40개 초과）"] --> both
    both -->|예| bad["감사 결과가 예상과 다른 상태"]
    both -->|아니요| unify["고급 쪽으로 통일"]
    unify --> force["하위 범주 설정을 강제로 적용을 활성화"]
    force -.-> guard["기본 쪽 설정에 의한 덮어쓰기를 막음"]

그림 2: 두 체계는 호환되지 않습니다. 고급 쪽으로 통일하고, 「강제로 적용」 설정으로 기본 쪽의 덮어쓰기를 막습니다.

현재 상태 확인은 명령 한 줄입니다. 관리자 권한의 명령 프롬프트에서 실행합니다.²

rem 지금 적용 중인 감사 설정을 하위 범주 단위로 목록 표시
auditpol /get /category:*

rem 변경 전 백업(CSV)과 복원
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

auditpol 출력은 GPO에서 왔든 로컬 설정에서 왔든 「결과적으로 적용 중인 정책」입니다. GPO로 배포했을 설정이 적용되지 않을 때의 대조에도 쓸 수 있습니다. 참고로 감사 설정 자체가 바뀌면 이벤트 4719가 기록되므로, 「어느새 감사가 비활성화되어 있었다」는 일도 나중에 추적할 수 있습니다.¹²

flowchart TB
    accTitle: auditpol로 보이는 것은 결과 정책
    accDescr: auditpol 출력은 GPO에서 왔든 로컬 설정에서 왔든 결과적으로 적용 중인 감사 정책이며, GPO 설정이 적용되지 않을 때의 대조에 쓸 수 있고, 감사 설정 자체의 변경은 이벤트 4719로 나중에 추적할 수 있다
    gpo["GPO로 배포한 설정"] --> eff["결과적으로 적용 중인 정책"]
    local["로컬 설정"] --> eff
    eff --> get["auditpol /get 으로 목록"]
    get -.-> diff["GPO 미적용 시 대조에 쓸 수 있음"]
    change["감사 설정 자체의 변경"] -.-> e4719["4719가 기록되어 나중에 추적 가능"]

그림 3: auditpol은 출처를 가리지 않고 「적용 중인 설정」을 반환합니다. 감사 설정 변경 자체는 4719에 남습니다.

3. 최소한 활성화해야 할 하위 범주 판단표

「일단 전부 활성화」가 나쁜 선택인 이유는 분명합니다. 예를 들어 권한 사용 계열 하위 범주를 성공까지 감사하면 이벤트 양이 방대해져 다른 항목을 찾기 어려워지고, 성능에도 영향이 난다고 Microsoft가 경고합니다.⁴ 로그 용량(5장)은 유한하므로, 노이즈를 기록할수록 정작 필요한 이벤트의 보존 일수가 줄어듭니다. 감사 설계란 「무엇을 기록하지 않을지」를 정하는 일입니다.

flowchart TB
    accTitle: 전부 활성화가 나쁜 선택인 이유
    accDescr: 모든 하위 범주를 활성화하면 대량 이벤트가 발생하고, 정작 중요한 이벤트가 노이즈에 묻혀 성능에도 영향을 주며, 유한한 로그 용량에서는 필요한 이벤트의 보존 일수도 줄어든다
    all["모든 하위 범주를 활성화"] --> flood["대량 이벤트가 발생"]
    flood --> noise["정작 중요한 이벤트가 묻힘"]
    flood --> perf["성능에 영향"]
    flood --> keep["보존 일수가 줄어듦"]
    noise --> lesson["무엇을 기록하지 않을지를 정하는 것이 감사 설계"]
    perf --> lesson
    keep --> lesson

그림 4: 「전부 활성화」는 정작 중요한 이벤트를 묻히게 합니다. 기록하지 않을 것을 정하는 일이 감사 설계입니다.

Microsoft는 워크스테이션/서버별로 베이스라인 권장과 강화 권장을 공개하며, 이것이 출발점이 됩니다.³ 그다음 중소 규모 환경의 「사고 발생 시 최소한 이것만은 읽고 싶다」는 관점으로 정리한 것이 다음 표입니다.

반대로 파일 시스템이나 레지스트리의 개체 액세스 감사, 권한 사용, 패킷 필터 계열(5152 등)은 기본으로는 손대지 않는 편이 무난합니다. 이들은 대상을 좁힌 SACL 설정이나 원인 분리 기간 한정에서야 도움이 되며, 상시 전면 활성화하면 로그를 잠식합니다.⁴

flowchart TB
    accTitle: 대량 이벤트 계열 하위 범주 다루기
    accDescr: 파일 시스템이나 레지스트리의 개체 액세스 감사, 권한 사용, 패킷 필터 계열은 상시 전면 활성화하면 로그를 잠식하므로, 대상을 좁힌 SACL 설정이나 원인 분리 기간 한정에서야 도움이 된다
    heavy["대량 이벤트 계열 하위 범주"] --> use{"어떻게 활성화하는가?"}
    heavy -.-> ex1["개체 액세스 감사"]
    heavy -.-> ex2["권한 사용·패킷 필터 계열"]
    use -->|상시 전면| eat["로그를 잠식함"]
    use -->|대상을 좁힌 SACL| ok1["도움이 됨"]
    use -->|원인 분리 기간 한정| ok2["도움이 됨"]

그림 5: 개체 액세스나 권한 사용은 상시 전면 활성화하지 않습니다. 대상과 기간을 좁혀야 도움이 됩니다.

4. 대표 이벤트 ID 읽는 법

4.1. 4624 ── 로그온 성공은 로그온 유형으로 구분한다

4624는 「계정이 로그온되었습니다」이며, 로그온 세션이 만들어진 컴퓨터(접근된 쪽)에 기록됩니다.⁵ 대량으로 기록되는 이벤트이므로, 읽을 때는 먼저 로그온 유형으로 가릅니다.⁵

함께 볼 필드는 「새 로그온」의 계정 이름, 「네트워크 정보」의 원본 주소, 「인증 패키지」(NTLM인지 Kerberos인지), 그리고 「상승된 토큰」(관리자 권한 세션인지)입니다. 관리자 권한 로그온만 추적하고 싶다면, 같은 로그온 ID로 기록되는 4672(특수 권한 할당)도 쓸 수 있습니다.⁵

flowchart TB
    accTitle: 4624를 구분해서 읽는 절차
    accDescr: 대량으로 기록되는 4624는 먼저 로그온 유형으로 가른 뒤 계정 이름과 원본·인증 패키지·상승된 토큰을 확인하고, 관리자 권한 로그온은 같은 로그온 ID의 4672와 대조한다
    ev["4624 로그온 성공"] --> type["로그온 유형으로 가름"]
    type --> fields["주요 필드를 확인"]
    fields -.-> f1["계정 이름과 원본"]
    fields -.-> f2["인증 패키지"]
    fields -.-> f3["상승된 토큰"]
    fields --> admin["관리자 권한 추적"]
    admin -.-> e4672["같은 로그온 ID의 4672"]

그림 6: 4624는 로그온 유형으로 가른 뒤에 필드를 읽습니다. 권한 로그온은 4672와 상관시킵니다.

4.2. 4625 ── 실패 이유는 Status/Sub Status 코드로 확정한다

4625는 「계정이 로그온에 실패했습니다」이며, 로그온이 시도된 컴퓨터에 기록됩니다.⁶ 「실패 이유」란의 문구보다 Status/Sub Status의 16진 코드로 읽는 편이 확실합니다. 대표적인 것은 다음과 같습니다.⁶

• 0xC0000064: 존재하지 않는 사용자 이름. 짧은 시간에 연속되면 계정 열거 공격의 징후
• 0xC000006A: 비밀번호 오류. 특정 계정에 연속되면 비밀번호 추측 공격의 징후
• 0xC000006D: 사용자 이름 또는 인증 정보가 잘못됨
• 0xC000006F: 허용된 시간대 밖
• 0xC0000070: 허용되지 않은 워크스테이션에서
• 0xC0000072: 관리자가 사용 안 함으로 설정한 계정(퇴사자 계정으로의 시도는 여기에 나옴)
• 0xC000015B: 이 컴퓨터에서 요청된 로그온 유형이 허용되지 않음
• 0xC0000193: 만료된 계정
• 0xC0000234: 잠금 중

「누가·어디서·왜 실패했는지」는 대상 계정+원본(워크스테이션 이름/IP 주소)+이 코드의 세 가지 조합으로 확정합니다. 6장에서 이 세 가지를 한 번에 추출하는 PowerShell을 실었습니다.

flowchart TB
    accTitle: 4625의 실패 이유를 확정하는 흐름
    accDescr: 4625의 실패 이유는 Status/Sub Status의 16진 코드로 확정하고, 코드 경향에서 공격 징후를 읽은 뒤, 대상 계정과 원본을 맞춘 세 가지 조합으로 특정한다
    ev["4625 로그온 실패"] --> code["Sub Status 코드를 확인"]
    code --> sign{"코드의 경향은?"}
    sign -->|0xC0000064의 연속| enum["계정 열거의 징후"]
    sign -->|0xC000006A의 연속| guess["비밀번호 추측의 징후"]
    sign -->|0xC0000072| disabled["퇴사자 계정 시도"]
    enum --> triple["세 가지 조합으로 확정"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["대상 계정+원본+코드"]

그림 7: 실패 이유는 코드로 확정하고, 대상 계정·원본과 맞춘 세 가지 조합으로 읽습니다.

4.3. 4740 ── 잠금의 발생원은 「호출자 컴퓨터 이름」

4740은 「사용자 계정이 잠겼습니다」입니다(하위 범주는 사용자 계정 관리). 이 이벤트의 주역은 「호출자 컴퓨터 이름(Caller Computer Name)」 필드이며, 잠금의 트리거가 된 로그온 시도가 어느 컴퓨터에서 왔는지가 기록되어 있습니다.¹⁶ 여기서 발생원 PC를 특정하고, 그 PC에 남아 있는 오래된 자격 증명을 점검하는 것이 정석입니다. 원인은 비밀번호 변경 후에도 오래된 자격 증명을 계속 쓰는 무언가(저장된 자격 증명, 연결이 끊긴 채로 남은 RDP 세션, 오래된 비밀번호의 서비스나 작업)인 경우가 대부분입니다.

flowchart TB
    accTitle: 계정 잠금 조사의 정석
    accDescr: 4740의 호출자 컴퓨터 이름으로 발생원 PC를 특정하고, 그 PC에 남은 저장된 자격 증명, 연결이 끊긴 채로 남은 RDP 세션, 오래된 비밀번호의 서비스나 작업을 점검한다
    ev["4740 잠금 발생"] --> caller["호출자 컴퓨터 이름을 확인"]
    caller --> src["발생원 PC를 특정"]
    src --> sweep["오래된 자격 증명을 점검"]
    sweep -.-> c1["저장된 자격 증명"]
    sweep -.-> c2["연결이 끊긴 채로 남은 RDP 세션"]
    sweep -.-> c3["오래된 비밀번호의 서비스나 작업"]

그림 8: 4740의 「호출자 컴퓨터 이름」으로 발생원을 특정하고, 그 PC의 오래된 자격 증명을 점검합니다.

주의할 점이 하나 있습니다. 4625가 기록되는 것은 로그온 시도를 받은 쪽 컴퓨터입니다. 발생원 PC에서 파일 서버 등으로의 네트워크 로그온이 원인인 경우, 발생원 PC 자신의 Security 로그에는 4625가 남지 않고, 접근 대상 서버의 4625나, 도메인 계정이라면 DC 쪽의 4776(NTLM)/4771(Kerberos 사전 인증 실패)에 증거가 남습니다.⁷⁸ 「발생원 PC의 로그에 아무것도 없다」면, 받은 쪽을 보러 가십시오.

flowchart TB
    accTitle: 실패 증거가 남는 컴퓨터
    accDescr: 네트워크 로그온 실패는 발생원 PC 자신에는 남지 않고, 로그온 시도를 받은 접근 대상 서버의 4625에 기록되며, 도메인 계정이라면 DC 쪽의 4776이나 4771에도 증거가 남는다
    src["발생원 PC（자신에는 4625가 남지 않음）"] -->|네트워크 로그온| target["접근 대상 서버"]
    target -.-> e4625["4625가 기록됨"]
    src -->|도메인 계정의 인증| dc["도메인 컨트롤러"]
    dc -.-> e4776["4776（NTLM）/4771（Kerberos）"]

그림 9: 4625는 받은 쪽에 남습니다. 발생원 PC에 아무것도 없으면, 접근 대상 서버와 DC 쪽을 봅니다.

4.4. 4720 계열 ── 계정의 생성·변경·그룹 추가

계정 관리 계열은 번호가 이어집니다. 4720(사용자 계정 생성)¹⁷, 4726(삭제), 4738(변경), 그리고 그룹 쪽의 멤버 추가/삭제입니다. 그룹 멤버 변경은 그룹 종류에 따라 이벤트 ID가 갈린다는 점에 주의하십시오. 로컬 그룹이 4732/4733, 전역 그룹이 4728/4729, 유니버설 그룹이 4756/4757입니다.¹⁴ Domain Admins는 전역 그룹이므로, 그곳으로의 추가는 4728에 기록됩니다 ── 4732만 알림 조건으로 두면, 가장 보고 싶은 사건을 놓칩니다. 일상적으로는 헬프데스크 작업의 기록이지만, 「표준 사용자가 관리자 그룹에 갑자기 추가되었다」「아무도 모르는 계정이 만들어졌다」는 단 한 건이라도 즉시 조사 대상입니다. Microsoft도 특권 그룹에 대한 예기치 않은 멤버 추가를 단건 알림의 예로 듭니다.³

flowchart TB
    accTitle: 그룹 종류와 멤버 추가 이벤트
    accDescr: 그룹에 대한 멤버 추가는 그룹 종류에 따라 이벤트 ID가 갈리며, 로컬은 4732, 전역은 4728, 유니버설은 4756에 기록되므로, 전역 그룹 Domain Admins로의 추가는 4728을 본다
    add["그룹에 대한 멤버 추가"] --> kind{"그룹의 종류는?"}
    kind -->|로컬| lg["4732에 기록"]
    kind -->|전역| gg["4728에 기록"]
    kind -->|유니버설| ug["4756에 기록"]
    gg -.-> da["Domain Admins로의 추가는 여기"]
    lg -.-> miss["4732만의 감시는 놓친다"]

그림 10: 멤버 추가의 이벤트 ID는 그룹 종류에 따라 갈립니다. Domain Admins로의 추가는 4728입니다.

4.5. 4688 ── 프로세스 생성. 명령줄 기록은 별도 스위치

4688은 「새 프로세스가 만들어졌습니다」이며, 프로세스 생성마다 만든 계정, 새 프로세스의 실행 파일 경로, 부모 프로세스, 토큰 상승 유형이 기록됩니다.¹¹ 「이 서버에서 누가 무엇을 실행했는지」에 답할 수 있는, 조사 가치가 높은 이벤트입니다.

다만 기본에서는 명령줄 인수가 기록되지 않습니다. 「프로세스 생성 이벤트에 명령줄 포함」이라는 그룹 정책(관리 템플릿 > 시스템 > 프로세스 생성 감사)을 따로 활성화해야 비로소 4688의 「프로세스 명령줄」 필드에 인수가 들어갑니다.¹¹¹² powershell -EncodedCommand ... 같은 수상한 실행을 추적하려면 사실상 필수 설정이지만, 7장에서 말하는 기밀 혼입 위험을 이해한 뒤에 활성화하십시오.

flowchart TB
    accTitle: 4688과 명령줄 기록의 관계
    accDescr: 프로세스 생성 감사를 활성화하면 4688에 계정·실행 파일 경로·부모 프로세스가 기록되지만, 명령줄 인수는 별도의 그룹 정책을 활성화해야 비로소 기록되며, 기밀이 평문으로 남는 위험이 있다
    audit["프로세스 생성 감사를 활성화"] --> ev["4688이 기록됨"]
    ev -.-> base["계정·경로·부모 프로세스"]
    ev --> args{"인수도 보고 싶은가?"}
    args -->|기본 그대로| none["명령줄은 비어 있음"]
    args -->|GPO를 추가 활성화| cmd["인수가 기록됨"]
    cmd -.-> risk["기밀이 평문으로 남는 위험"]

그림 11: 4688의 명령줄 기록은 별도 스위치입니다. 활성화 전에 기밀 혼입 위험 점검이 먼저입니다.

4.6. 4698 ── 예약된 작업의 생성

4698은 「예약된 작업이 만들어졌습니다」이며, 작업 이름과 작업 정의 XML 전문(실행 명령을 포함)이 기록됩니다. 맬웨어가 재시작 후에도 살아남기 위한 상투 수단이 작업 등록이므로, Microsoft는 작업 생성 이벤트 모니터링을 권장합니다.¹⁵ 업무에서 작업을 많이 쓰는 환경에서도, 생성 자체는 일상적으로 일어나지 않으므로 노이즈는 작은 편입니다.

flowchart TB
    accTitle: 작업 등록에 의한 지속성과 4698
    accDescr: 맬웨어는 재시작 후에도 살아남기 위해 예약된 작업 등록을 상투 수단으로 쓰므로, 작업 생성에서 기록되는 4698을 모니터링하면 실행 명령을 포함한 작업 정의까지 추적할 수 있다
    mal["맬웨어의 지속성"] --> task["작업을 등록해 살아남음"]
    task --> ev["4698이 기록됨"]
    ev -.-> xml["실행 명령을 포함한 XML 전문"]
    ev --> watch["작업 생성 모니터링으로 탐지"]
    watch -.-> low["생성은 일상적이지 않아 노이즈가 작음"]

그림 12: 지속성의 상투 수단인 작업 등록은 4698에 남습니다. 정의 XML 전문에서 실행 명령까지 추적할 수 있습니다.

하나 더 기억해 둘 것이 1102 「감사 로그가 지워졌습니다」입니다. Security 로그의 지우기는 반드시 이 이벤트를 남기므로, 「로그가 비어 있다」일 때 사고인지 조작인지 원인을 가를 수 있습니다.¹⁸

flowchart TB
    accTitle: 1102로 로그 삭제 원인 분리
    accDescr: Security 로그의 지우기는 반드시 1102를 남기므로, 로그가 비어 있을 때는 1102의 유무를 확인해 삭제 조작이었는지 사고인지를 가를 수 있다
    empty["로그가 비어 있다"] --> rule["지우기는 반드시 1102를 남김"]
    rule --> check{"1102가 있는가?"}
    check -->|있음| op["삭제 조작이 있었다"]
    check -->|없음| acc["사고 가능성을 의심"]

그림 13: Security 로그의 지우기는 반드시 1102를 남깁니다. 빈 로그는 1102의 유무로 사고인지 조작인지를 가릅니다.

5. 로그 용량 설계 ── 최대 크기와 보존

감사 정책을 늘리기 전에 받을 용량을 확인합니다. Security 로그에는 최대 크기와 보존 모드가 있으며, 덮어쓰기 모드(일반적인 구성)에서는 최대 크기에 도달하면 새 이벤트가 가장 오래된 이벤트를 덮어씁니다. 반대로 보존 모드(덮어쓰지 않음)에서는 로그가 가득 차면 새 이벤트 쪽이 버려집니다.¹⁰ 어느 동작이든 「알아챘을 때는 로그가 없다」의 원인이 되므로, 현재 상태 파악이 먼저입니다.

# Security 로그의 용량을 확인: 보존 모드·최대 크기·현재 건수
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# 지금 실제로 며칠치가 남아 있는지(가장 오래된 이벤트의 일시)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog는 로그 구성과 건수를 한 번에 반환합니다.⁹ 「가장 오래된 이벤트의 일시」와 현재의 차이가 실제 보존 일수이며, 이것이 자사 요건(사고 조사에서 거슬러 가고 싶은 일수)에 모자라면 최대 크기를 늘립니다. 설정은 wevtutil sl Security /ms:<바이트 수> 또는 그룹 정책으로 배포할 수 있습니다.¹⁰

flowchart TB
    accTitle: 보존 일수에서 역산하는 용량 설계
    accDescr: Get-WinEvent의 ListLog로 구성과 건수를 확인하고, 가장 오래된 이벤트의 일시에서 실제 보존 일수를 구해, 사고 조사에서 거슬러 가고 싶은 일수에 모자라면 최대 크기를 늘린다
    check["ListLog로 구성과 건수를 확인"] --> oldest["가장 오래된 이벤트의 일시를 확인"]
    oldest --> days["실제 보존 일수를 산출"]
    days --> enough{"요건에 충분한가?"}
    enough -->|충분| keep["현재 크기를 유지"]
    enough -->|모자람| grow["최대 크기를 늘림"]
    grow -.-> how["wevtutil sl 또는 GPO로 설정"]

그림 14: 실제로 남아 있는 일수를 확인하고, 거슬러 가고 싶은 일수에서 역산해 최대 크기를 정합니다.

참고로 보안 옵션에는 「감사: 보안 감사를 기록할 수 없으면 즉시 시스템을 종료」(이른바 CrashOnAuditFail)라는 설정이 있습니다. 활성화된 상태에서 감사를 기록할 수 없게 되면 STOP 오류 C0000244로 시스템이 멈춥니다. 감사 증거를 절대 빠뜨릴 수 없는 인증 요건을 위한 설정이며, 기본값은 비활성입니다. 공격자가 대량 이벤트를 일으켜 의도적으로 서버를 멈추는 DoS로 바뀔 수 있다고 Microsoft 스스로 주의하며, 일반적인 중소 규모 환경에서 쉽게 활성화할 설정이 아닙니다.¹⁹

flowchart TB
    accTitle: 로그가 가득 찼을 때의 동작
    accDescr: 보존 구성은 덮어쓰기 모드와 덮어쓰지 않는 모드 두 가지이며, 덮어쓰지 않는 모드에서 감사를 기록할 수 없게 되었을 때, 별도 설정인 CrashOnAuditFail이 활성화되어 있으면 STOP 오류 C0000244로 시스템이 멈춘다
    full["Security 로그가 최대 크기에 도달"] --> mode{"보존 구성은?"}
    mode -->|덮어쓰기 모드| ow["가장 오래된 이벤트가 덮어써짐"]
    mode -->|덮어쓰지 않음| drop["새 이벤트가 버려짐"]
    ow -.-> lost["어느 쪽이든 알아챘을 때 로그가 없는 원인"]
    drop -.-> lost
    drop --> caf{"CrashOnAuditFail도 활성인가?"}
    caf -->|예| crash["STOP 오류 C0000244로 정지"]

그림 15: 보존 구성은 덮어쓰기 또는 폐기 두 가지입니다. CrashOnAuditFail은 별도 설정이며, 기록할 수 없을 때 멈추게 합니다.

6. 조사 실무 ── 필터, Get-WinEvent, 내보내기

6.1. 이벤트 뷰어에서 좁히기

단건 조사라면 이벤트 뷰어로 충분합니다. Security 로그를 열고 「현재 로그 필터」에서 이벤트 ID(예: 4625)와 기간을 지정합니다. 반복해서 볼 조건은 「사용자 지정 보기 만들기」로 저장해 두면, 다음부터는 클릭 한 번입니다. 이벤트 ID뿐 아니라 특정 계정 등으로 좁히고 싶다면, 필터 대화 상자의 XML 탭에서 XPath 쿼리를 직접 편집할 수 있습니다.

6.2. Get-WinEvent로 추출하기

건수가 많은 조사·여러 조건·정기 실행은 PowerShell의 Get-WinEvent로 바꿉니다. 핵심은 필터를 서버 쪽에서 적용하는 -FilterHashtable을 쓰는 것입니다.⁹

flowchart TB
    accTitle: 조사 수단 구분
    accDescr: 단건 조사는 이벤트 뷰어의 필터로 충분하고, 반복해서 볼 조건은 사용자 지정 보기에 저장하며, 건수가 많은 조사나 여러 조건·정기 실행은 Get-WinEvent로 바꾼다
    q{"어떤 조사인가?"}
    q -->|단건| viewer["이벤트 뷰어로 좁힘"]
    q -->|반복해서 볼 조건| view["사용자 지정 보기에 저장"]
    q -->|대량·여러 조건·정기| ps["Get-WinEvent로 전환"]
    ps -.-> hash["FilterHashtable로 좁힘"]

그림 16: 단건은 이벤트 뷰어, 반복이면 사용자 지정 보기, 건수가 많으면 Get-WinEvent입니다.

# 최근 24시간의 로그온 실패(4625)를 가져오기
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# 「누가·어디서·왜」를 표로 정리하기
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

이벤트의 XML 표현에서 EventData를 뽑아내는 이 패턴을 하나 갖고 있으면, 4624든 4688이든 같은 요령으로 재사용할 수 있습니다. Get-WinEvent의 필터 설계(FilterHashtable과 XPath의 구분, 느린 쿼리를 고치는 법)는 「Get-WinEvent로 이벤트 로그를 실무적으로 조사하기」에서 자세히 다룹니다.

flowchart TB
    accTitle: EventData를 뽑아내는 정리 패턴
    accDescr: Get-WinEvent로 가져온 이벤트를 XML 표현으로 변환하고, EventData의 각 필드를 뽑아 표로 정리하는 이 패턴은 4625에 한정되지 않고 4624나 4688에서도 같은 요령으로 재사용할 수 있다
    get["Get-WinEvent로 가져오기"] --> xml["이벤트를 XML 표현으로 변환"]
    xml --> pull["EventData를 뽑아내기"]
    pull --> shape["표로 정리해 집계"]
    shape -.-> reuse["4624나 4688에서도 같은 요령"]

그림 17: XML 표현에서 EventData를 뽑아 표로 만드는 패턴은, 이벤트 ID가 바뀌어도 재사용할 수 있습니다.

6.3. wevtutil로 내보내기

조사 대상 컴퓨터의 로그는, 덮어쓰기로 사라지기 전에 먼저 내보내 확보하는 것이 원칙입니다.¹⁰

rem Security 로그를 통째로 evtx로 확보
wevtutil epl Security C:\logs\security-20260801.evtx

rem 4625만 XPath로 좁혀 내보내기
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

내보낸 .evtx는 다른 컴퓨터에서 Get-WinEvent -Path C:\logs\security-20260801.evtx로 같은 방식으로 분석할 수 있습니다.⁹ 확보한 뒤에 분석하는 습관은, 크래시 조사에서 「먼저 덤프를 확보한다」와 같은 발상입니다(「Windows 크래시 덤프 수집 입문」 참조).

flowchart TB
    accTitle: 확보한 뒤에 분석하는 흐름
    accDescr: 조사 대상 컴퓨터의 Security 로그를 wevtutil epl로 evtx 파일에 내보내 확보하고, 다른 컴퓨터에서 Get-WinEvent의 Path 지정으로 같은 방식으로 분석한다
    target["조사 대상 컴퓨터"] --> export["wevtutil epl로 evtx에 확보"]
    export --> copy["다른 컴퓨터로 가져감"]
    copy --> analyze["Get-WinEvent -Path로 분석"]
    export -.-> note["덮어쓰기로 사라지기 전에 확보"]

그림 18: 먼저 확보, 그다음 분석. evtx로 확보하면 다른 컴퓨터에서도 같은 방식으로 조사할 수 있습니다.

7. 함정 ── 현장에서 밟기 쉬운 네 가지

(1) 4688의 명령줄에 기밀이 실린다. 명령줄 기록을 활성화하면 모든 프로세스의 인수가 Security 로그에 평문으로 들어갑니다. Microsoft는 「보안 이벤트의 읽기 액세스 권한이 있는 모든 사용자가, 모든 프로세스의 명령줄 인수를 읽을 수 있다. 인수에는 비밀번호 등의 기밀이 포함될 수 있다」고 명시합니다.¹² myapp.exe /user:admin /password:P@ssw0rd 같은 실행을 하는 업무 앱·스크립트가 하나라도 있으면, 그것은 로그 열람자 전원에게 기밀을 공개하는 일입니다. 활성화하기 전에 기밀을 인수로 넘기는 곳을 찾아내 고치십시오. 로그의 확보·전송처에서도 같은 취급 수준이 필요합니다.

flowchart TB
    accTitle: 명령줄 기록을 활성화하는 순서
    accDescr: 4688의 명령줄 기록은 활성화 전에 기밀을 인수로 넘기는 업무 앱이나 스크립트를 찾아내고, 해당 지점을 고친 뒤에 활성화하는 순서를 지키며, 로그의 확보·전송처에도 같은 취급 수준을 요구한다
    audit["기밀의 인수 전달을 찾아내기"] --> found{"해당하는가?"}
    found -->|있음| fix["넘기는 곳을 고침"]
    found -->|없음| on["명령줄 기록을 활성화"]
    fix --> on
    on -.-> dest["확보·전송처도 같은 취급 수준"]

그림 19: 명령줄 기록은 「찾아내 고친 뒤에 활성화」입니다. 순서를 뒤집으면 기밀 공개가 됩니다.

(2) 로그가 가득 찼을 때의 동작을 모른 채 운영한다. 덮어쓰기 모드라면 오래된 증거가 소리 없이 사라지고, 덮어쓰지 않는 설정이라면 새 이벤트가 버려지며, CrashOnAuditFail이 활성화되어 있으면 시스템째 멈춥니다(5장).¹⁰¹⁹ 어느 동작을 고르고 있는지를 파악하고, 「사라지기 전에 모은다」는 체계(정기 내보내기나 로그 수집 기반)를 마련하는 것이 본류입니다.

(3) 도메인 컨트롤러와 PC에서 봐야 할 로그가 다르다. 4624/4625는 접근된 컴퓨터에 기록됩니다.⁵⁶ 한편 도메인 계정의 자격 증명 유효성 검사(NTLM의 4776)는 자격 증명에 대해 권위가 있는 컴퓨터, 즉 도메인 계정이라면 DC에 기록되고⁷, Kerberos의 사전 인증 실패(4771)는 DC에만 기록됩니다.⁸ 「파일 서버에 4625가 없다=공격이 없었다」가 아니라, DC 쪽의 4776/4771도 대조해야 비로소 전체가 보입니다. 어떤 인증 프로토콜이 어떻게 흐르는지는 「그림으로 이해하는 NTLM과 Kerberos」를 참조하십시오.

(4) 시간 동기화가 어긋나면 대조할 수 없다. 여러 컴퓨터의 로그를 나란히 놓고 「이 4740 직전에 어느 PC에서 4625가 나왔는지」를 추적하는 작업은, 각 컴퓨터의 시계가 맞아 있다는 것이 전제입니다. 도메인 환경에서는 Kerberos 자체가 시계 어긋남에 상한(기본 5분)을 두며, 그것을 넘으면 인증 자체가 실패하기 시작합니다.²⁰ 조사 관점에서는 5분은커녕 몇 초의 어긋남만으로도 전후 관계를 오독하므로, w32time의 동기화 상태 확인을 조사 절차의 맨 앞에 넣으십시오. 또한 이벤트의 기록 시각은 UTC로 저장되고, 표시는 열람 컴퓨터의 표준 시간대를 따르므로, 해외 거점이나 UTC 설정 서버에서 가져온 evtx를 읽을 때는 표준 시간대 환산을 잊지 마십시오.

flowchart TB
    accTitle: 시간 동기화와 대조 조사의 전제
    accDescr: 여러 컴퓨터의 로그를 시간 순으로 대조하는 조사는 각 컴퓨터의 시계가 맞아 있다는 것이 전제이며, 몇 초의 어긋남만으로도 전후 관계를 오독하고, 기본 5분을 넘는 어긋남에서는 Kerberos 인증 자체가 실패하므로, w32time 동기화 확인을 조사 절차의 맨 앞에 넣는다
    merge["여러 컴퓨터의 로그를 대조"] --> pre["시계가 맞아 있다는 것이 전제"]
    pre --> skew{"시계의 어긋남은?"}
    skew -->|맞음| ok["시간 순으로 추적 가능"]
    skew -->|몇 초의 어긋남| misread["전후 관계를 오독"]
    skew -->|기본 5분을 넘음| kerb["Kerberos 인증이 실패"]
    pre -.-> first["w32time 확인을 절차의 맨 앞에"]

그림 20: 여러 컴퓨터의 대조는 시계 맞춤이 전제입니다. 몇 초의 어긋남만으로도 전후 관계 오독으로 이어집니다.

8. 정리

• 감사 정책은 「기본」과 「고급」 두 체계가 있으며, 섞으면 예상과 다른 결과가 됩니다. 고급 쪽으로 통일하고, auditpol /get /category:*로 현재 상태를 확인한 뒤에 설계합니다.
• 「전부 활성화」는 노이즈와 비대화로 조사를 죽입니다. Microsoft의 베이스라인 권장을 출발점으로, 로그온·계정 관리·프로세스 생성을 축으로 한 3장의 판단표부터 시작하십시오.
• 4624는 로그온 유형, 4625는 Status/Sub Status 코드, 4740은 호출자 컴퓨터 이름, 4688은 부모 프로세스와 명령줄 ── 각 이벤트에는 「여기를 본다」는 핵심이 있습니다.
• 로그 용량(최대 크기·보존 모드)은 감사 설계의 절반입니다. 실제로 남아 있는 일수를 확인하고, 요건에서 역산해 크기를 정하고, 사라지기 전에 내보내거나 모읍니다.
• 4688의 명령줄 기록은 기밀 혼입 위험을 점검한 뒤에. 컴퓨터마다 기록 위치가 다르다는 점과 시간 동기화는 대조 조사의 전제 조건입니다.
• 조사는 이벤트 뷰어의 필터로 시작하고, 반복이면 Get-WinEvent -FilterHashtable, 확보는 wevtutil epl. 「먼저 확보, 그다음 분석」의 순서를 깨지 마십시오.

관련 글

• Get-WinEvent로 이벤트 로그를 실무적으로 조사하기 ── 좁히는 속도가 조사 시간을 정한다
• NTLM 폐지로 업무 앱은 멈추는가 ── 감사 로그를 잡는 법과, 의존을 없애는 순서
• 그림으로 이해하는 NTLM과 Kerberos ── 왜 인증은 NTLM으로 「떨어지는가」
• SMB 서명과 LDAP 채널 바인딩 ── NTLM 대책의 「나머지 절반」을 실무에서 마무리하기
• Windows 이벤트 로그·ETW 입문 ── 업무 앱의 로그를 OS 표준 체계에 올리기
• Windows 크래시 덤프 수집 입문 - WER/ProcDump/WinDbg

관련 상담 영역

합동회사 코무라소프트에서는 Windows 환경의 감사 정책·로그 설계 상담, 이벤트 로그에 근거한 「언제·누가·무엇을 했는지」의 조사, 업무 앱이 인증·감사 주변에서 일으키는 문제의 원인 분석을 다룹니다. 「로그를 봐 달라고 했는데, 어디서부터 손대야 할지」라는 단계부터여도 괜찮습니다.

• 장애 조사·원인 분석
• 기술 상담·설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

감사 정책을 아무것도 설정하지 않았는데 Security 로그에 4624나 4625가 기록되는 이유는 무엇인가요?

Windows에는 기본으로 활성화되어 있는 감사 하위 범주가 있기 때문입니다. 예를 들어 「로그온」 하위 범주는 Windows 10 버전 1809 이후 성공·실패가 모두 기본으로 활성화되어 있어, 따로 설정하지 않아도 4624(성공)와 4625(실패)는 기록됩니다. 다만 기본값만으로는 자격 증명 유효성 검사(4776)나 프로세스 생성(4688)처럼 조사에서 필요해지는 이벤트 상당수가 기록되지 않습니다. 자기 환경에서 무엇이 활성화되어 있는지는 auditpol /get /category:* 로 확인할 수 있습니다. 그다음 부족한 하위 범주를 고급 감사 정책 쪽에서 명시적으로 활성화하는 것이 실무의 기본입니다.

로그온 실패를 조사하고 싶은데, 대상 서버의 Security 로그에서 4625가 보이지 않습니다. 어디를 보면 되나요?

먼저 4625는 「로그온이 시도된 컴퓨터」에 기록된다는 원칙을 확인하십시오. 사용자 PC에서의 로그온 실패라면 그 PC 쪽, 파일 서버 접근 실패라면 파일 서버 쪽입니다. 다음으로 auditpol /get /category:* 로 「로그온」 하위 범주의 실패 감사가 활성화되어 있는지 확인합니다. 도메인 계정이라면 도메인 컨트롤러 쪽의 자격 증명 유효성 검사(4776)나 Kerberos 사전 인증 실패(4771)에 기록이 남아 있는 경우가 많고, PC를 특정할 수 없을 때는 오히려 DC 쪽부터 조사하는 편이 빠릅니다. 그래도 찾을 수 없다면 로그 덮어쓰기로 과거분이 사라지지 않았는지(로그 최대 크기와 가장 오래된 이벤트의 일시)를 확인하십시오.

프로세스 생성(4688)의 명령줄 기록은 활성화해야 하나요?

조사 가치는 매우 높은 반면, 위험을 이해한 뒤에 활성화해야 하는 설정입니다. 활성화하면 모든 프로세스의 명령줄 인수가 Security 로그에 평문으로 기록됩니다. 명령줄에 비밀번호나 API 키를 넘기는 스크립트나 업무 앱이 하나라도 있으면, 그 기밀은 Security 로그를 읽을 수 있는 모든 사람에게 보이는 상태가 됩니다. Microsoft 스스로 이 주의점을 명시하고 있습니다. 먼저 자사 스크립트류가 기밀을 명령줄 인수로 넘기지 않는지 점검하고, 넘기는 곳을 고친 뒤에 활성화하는 순서를 권합니다.

Security 로그의 최대 크기는 어느 정도로 해야 하나요?

「며칠치를 직접 남겨 두고 싶은가」에서 역산하는 것이 정석이며, 만능 수치는 없습니다. 현재 설정과 실적은 Get-WinEvent -ListLog Security 로 확인할 수 있고, 가장 오래된 이벤트의 일시와 현재 일시의 차이가 「지금 실제로 남아 있는 일수」입니다. 감사 하위 범주를 늘리면 이벤트 양도 늘어나므로, 설정 변경 후에는 반드시 이 실제 보존 일수를 다시 확인하십시오. 사고 대응에서는 몇 주에서 몇 달 전의 로그가 필요해지는 일이 드물지 않으므로, 덮어쓰기로 사라지기 전에 정기적으로 내보내거나 로그 수집 체계로 다른 컴퓨터에 모아 두면 안심입니다.

계정 잠금(4740)의 원인은 어떻게 조사하나요?

4740 이벤트의 「호출자 컴퓨터 이름(Caller Computer Name)」 필드가 첫 단서입니다. 여기에 잠금의 트리거가 된 로그온 실패가 발생한 컴퓨터가 기록되어 있습니다. 다만 실패 기록 자체(4625)는 발생원이 아니라 로그온 시도를 받은 쪽에 남는다는 점에 주의하십시오. 네트워크 로그온이 원인이라면 접근 대상 서버의 4625나, 도메인 계정이라면 도메인 컨트롤러의 4776/4771을 시간 순으로 추적합니다. 그다음 발생원으로 특정한 PC 쪽에서는 비밀번호 변경 후에도 오래된 자격 증명을 계속 가지고 있는 것, 즉 저장된 자격 증명, 연결이 끊긴 채로 남은 원격 데스크톱 세션, 오래된 비밀번호로 구성된 서비스나 예약된 작업을 점검합니다. 잠금이 반복되면 시간 동기화가 어긋나지 않았는지도 함께 확인하십시오.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.