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

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

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

이 글에서는 감사 정책의 구조(기본과 고급 두 체계), 중소 규모 환경에서 최소한 활성화해야 할 하위 범주, 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는 상태/보조 상태 코드로 실패 이유를 알 수 있습니다. 0xC0000064=존재하지 않는 사용자 이름, 0xC000006A=비밀번호 오류, 0xC0000072=비활성화된 계정, 0xC0000234=잠금 중, 이 대표적입니다.⁶
• 이벤트는 「어느 머신에 기록되는가」가 정해져 있습니다. 4624/4625는 접근당한 쪽의 머신에, 자격 증명 유효성 검사(4776)나 Kerberos 사전 인증 실패(4771)는 도메인 컨트롤러에 기록됩니다. 볼 머신을 착각하면 「로그가 없다」고 오진하게 됩니다.⁶⁷⁸
• Security 로그는 그릇의 설계(최대 크기와 보존)가 절반입니다. 보존이 덮어쓰기 모드라면 오래된 이벤트부터 사라져 갑니다. Get-WinEvent -ListLog Security 로 최대 크기와 건수를 확인하고, 필요한 보존 일수에서 역산해 확장합니다.⁹¹⁰
• 프로세스 생성(4688)의 명령줄 기록은 강력하지만, 기밀이 로그에 평문으로 실리는 위험과 맞바꾸는 것입니다. 활성화하기 전에 스크립트류를 점검하십시오.¹¹¹²

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

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

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

중요한 것은 이 두 체계에 호환성이 없다는 점입니다. Microsoft는 「기본과 고급을 모두 사용하지 마라. 감사 결과가 예상치 못한 상태가 된다」고 명시하고 있습니다. 그룹 정책으로 고급 감사 정책을 적용하면 해당 컴퓨터의 기존 감사 설정이 일단 지워진 뒤 고급 쪽 설정이 적용되며, 이후에는 고급 쪽에서만 확실하게 제어할 수 있습니다. 고급 쪽을 사용하는 환경에서는 보안 옵션 「감사: 감사 정책 하위 범주 설정 강제(Audit: Force audit policy subcategory settings)」를 활성화하여, 기본 쪽 설정이 덮어쓰지 못하도록 해 둡니다(독립 실행형 머신에서는 기본으로 활성화되어 있습니다).¹⁴

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

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가 기록되므로, 「어느샌가 감사가 비활성화되어 있었다」도 나중에 추적할 수 있습니다.¹²

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

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

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

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

4. 대표적인 이벤트 ID 읽는 법

4.1. 4624 ── 로그온 성공은 로그온 유형으로 구분해서 읽는다

4624는 「계정이 로그온되었습니다(An account was successfully logged on)」로, 로그온 세션이 만들어진 머신(접근당한 쪽)에 기록됩니다.⁵ 대량으로 기록되는 이벤트이므로, 읽을 때는 먼저 로그온 유형(Logon Type) 으로 구분합니다.⁵

함께 확인해야 할 필드는 「새 로그온(New Logon)」의 계정 이름, 「네트워크 정보(Network Information)」의 원본 네트워크 주소(Source Network Address), 「인증 패키지(Authentication Package)」(NTLM인지 Kerberos인지), 그리고 「상승된 토큰(Elevated Token)」(관리자 권한 세션인지)입니다. 관리자 권한 로그온만 추적하고 싶다면, 같은 로그온 ID로 기록되는 4672(특수 권한이 새 로그온에 할당됨)도 사용할 수 있습니다.⁵

4.2. 4625 ── 실패 이유는 상태/보조 상태 코드로 확정한다

4625는 「계정이 로그온에 실패했습니다(An account failed to log on)」로, 로그온이 시도된 머신에 기록됩니다.⁶ 「실패 이유(Failure Reason)」란의 문구보다 상태(Status)/보조 상태(Sub Status)의 16진 코드로 읽는 편이 확실합니다. 대표적인 것은 다음과 같습니다.⁶

• 0xC0000064: 존재하지 않는 사용자 이름. 짧은 시간에 연속되고 있다면 계정 열거 공격의 조짐
• 0xC000006A: 비밀번호 오류. 특정 계정에 연속되고 있다면 비밀번호 추측 공격의 조짐
• 0xC000006D: 사용자 이름 또는 인증 정보가 잘못됨
• 0xC000006F: 허용된 시간대 밖
• 0xC0000070: 허용되지 않은 워크스테이션에서
• 0xC0000072: 관리자에 의해 비활성화된 계정(퇴사자 계정으로의 시도는 여기에 나타남)
• 0xC000015B: 이 머신에서 요청된 로그온 유형이 허용되지 않음
• 0xC0000193: 만료된 계정
• 0xC0000234: 잠금 중

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

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

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

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

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

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

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

4688은 「새 프로세스가 생성되었습니다(A new process has been created)」로, 프로세스가 생성될 때마다 생성한 계정, 새 프로세스의 실행 파일 경로, 부모 프로세스, 토큰 상승 유형이 기록됩니다.¹¹ 「이 서버에서 누가 무엇을 실행했는가」에 답할 수 있는, 조사 가치가 매우 높은 이벤트입니다.

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

4.6. 4698 ── 예약 작업 생성

4698은 「예약 작업이 생성되었습니다(A scheduled task was created)」로, 작업 이름과 작업 정의 XML 전문(실행 명령을 포함)이 기록됩니다. 악성코드가 재시작 후에도 살아남기 위한 상투적인 수단이 작업 등록이기 때문에, Microsoft는 작업 생성 이벤트의 모니터링을 권장하고 있습니다.¹⁵ 업무에서 작업을 많이 사용하는 환경이라도, 생성 자체는 일상적으로 일어나는 일이 아니므로 노이즈는 비교적 적습니다.

하나 더 기억해 두어야 할 것이 1102 「감사 로그가 지워졌습니다(The audit log was cleared)」 입니다. Security 로그의 삭제는 반드시 이 이벤트를 남기므로, 「로그가 비어 있다」는 상황이 사고인지 조작인지를 구분할 수 있습니다.¹⁸

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:<바이트 수> 또는 그룹 정책으로 배포할 수 있습니다.¹⁰

참고로 보안 옵션에는 「감사: 보안 감사를 기록할 수 없는 경우 즉시 시스템 종료(Audit: Shut down system immediately if unable to log security audits)」(이른바 CrashOnAuditFail)라는 설정이 있습니다. 활성화되어 있을 때 감사를 기록할 수 없게 되면 STOP 오류 C0000244 로 시스템이 정지합니다. 감사 기록을 절대로 놓칠 수 없는 인증 요건을 위한 설정으로, 기본값은 비활성화입니다. 공격자가 대량의 이벤트를 발생시켜 의도적으로 서버를 멈추는 DoS로 전용될 수 있다고 Microsoft 스스로 주의를 주고 있으며, 일반적인 중소 규모 환경에서 섣불리 활성화해서는 안 됩니다.¹⁹

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

6.1. 이벤트 뷰어에서 좁혀 보기

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

6.2. Get-WinEvent로 추출하기

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

# 최근 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로 이벤트 로그를 실무적으로 조사하기」에서 자세히 다루고 있습니다.

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 크래시 덤프 수집 입문」 참고).

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

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

(2) 로그가 가득 찼을 때의 동작을 모른 채 운영하고 있다. 덮어쓰기 모드라면 오래된 흔적이 조용히 사라지고, 덮어쓰지 않는 설정이라면 새 이벤트가 폐기되며, CrashOnAuditFail이 활성화되어 있으면 시스템째로 정지합니다(5장).¹⁰¹⁹ 어느 동작을 선택하고 있는지를 파악하고, 「사라지기 전에 모은다」는 체계(정기 내보내기나 로그 수집 기반)를 마련해 두는 것이 본질입니다.

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

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

8. 정리

• 감사 정책은 「기본」과 「고급」이라는 두 체계가 있으며, 섞으면 예상치 못한 결과가 됩니다. 고급 쪽으로 통일하고, auditpol /get /category:* 로 현재 상태를 확인한 뒤 설계합니다.
• 「전부 활성화」는 노이즈와 비대화로 조사를 죽입니다. Microsoft의 기준선 권장을 출발점으로, 로그온·계정 관리·프로세스 생성을 축으로 한 3장의 판단표부터 시작하십시오.
• 4624는 로그온 유형, 4625는 상태/보조 상태 코드, 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에는 기본으로 활성화되어 있는 감사 하위 범주가 있기 때문입니다. 예를 들어 '로그온(Logon)' 하위 범주는 Windows 10 버전 1809 이후 성공·실패가 모두 기본으로 활성화되어 있으므로, 아무것도 설정하지 않아도 4624(성공)와 4625(실패)는 기록됩니다. 다만 기본 상태 그대로는 자격 증명 유효성 검사(4776)나 프로세스 생성(4688) 등, 조사에서 필요해지는 이벤트의 상당수는 기록되지 않습니다. 자신의 환경에서 무엇이 활성화되어 있는지는 auditpol /get /category:* 로 확인할 수 있습니다. 그런 다음 부족한 하위 범주를 고급 감사 정책 쪽에서 명시적으로 활성화하는 것이 실무의 정석입니다.

로그온 실패를 조사하고 싶은데, 대상 서버의 Security 로그에서 4625를 찾을 수 없습니다. 어디를 봐야 하나요?

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

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

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

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

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

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

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

저자 프로필

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

Go Komura

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

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