Windows 이벤트 로그 기반 포렌식 분석

Windows 포렌식에서 결국 제일 먼저 보게 되는 건 이벤트 로그다.
처음에는 종류도 많고 꽤 복잡해 보여서 어디부터 봐야 할지 막막한데, 몇 번 흐름을 따라가다 보면 어느 순간부터는 “아 이건 여기서 끊어 보면 안 되고 뒤를 같이 봐야 하는구나” 하는 감이 생긴다.

나도 처음에는 Event ID를 많이 외우는 게 중요한 줄 알았는데, 실제로 계속 보다 보니까 그보다는 어떤 순서로 연결해서 볼 수 있느냐가 더 중요하다는 쪽으로 생각이 바뀌었다.
같은 4624라도 앞에 뭐가 있었는지, 뒤에 뭐가 붙는지에 따라 의미가 꽤 달라지기 때문이다.

무작정 이벤트 ID만 외우기보다,
로그인 → 권한 → 프로세스 → 네트워크로 이어지는 흐름을 먼저 잡아두면
분석할 때 훨씬 덜 흔들린다.

로그 위치부터 확인

기본 로그 위치는 여기다.

C:\Windows\System32\winevt\Logs\

여기 들어가면 .evtx 파일들이 쭉 있는데 실제 분석은 결국 이 파일들을 기반으로 시작하게 된다.

물론 실무에서는 Event Viewer, PowerShell, EDR, SIEM을 통해 보는 경우가 더 많지만 원본이 어디에 쌓이는지는 알고 있는 편이 좋다.
이걸 알고 있으면 다음 상황에서 꽤 도움이 된다.

• 오프라인 포렌식 이미지를 분석할 때
• 원격 수집이 안 된 장비에서 직접 확인해야 할 때
• 로그 유실 여부를 파일 기준으로 점검해야 할 때
• 특정 채널의 로그 보존 상태를 빠르게 확인해야 할 때

로그를 보기 전에 위치부터 확인하는 건 생각보다 단순한 습관 같아도 꽤 중요하다.

어떤 로그부터 보면 되는지

처음에는 Application, System, Security를 다 비슷한 비중으로 봐야 하나 싶었는데, 실제로 공격 흔적을 추적할 때는 Security 로그부터 보는 게 가장 자연스럽다.

대략 이렇게 정리할 수 있다.

• Security → 로그인 / 권한 / 인증 / 감사 흔적
• System → 시스템 상태 / 서비스 / 드라이버 / 재부팅
• Application → 프로그램 또는 애플리케이션별 로그

물론 세 로그가 서로 완전히 분리되어 있는 건 아니지만, 누가 들어왔고 어떤 권한으로 어떤 행위를 시작했는지를 보려면 대부분 Security에서 첫 단서를 잡게 된다.

특히 계정 오남용이나 침해사고 초동 분석에서는 Security 로그가 거의 시작점 역할을 한다.

로그인 이벤트부터 확인

로그인 관련해서는 처음부터 너무 많이 외우기보다 이 두 개부터 확실히 기억하는 편이 낫다.

이 두 개만 제대로 봐도 정상적인 로그인 흐름인지, 반복 실패 후 성공했는지, 혹은 특정 계정이 지속적으로 시도되고 있는지를 빠르게 볼 수 있다.

로그를 보다 보면 아래 같은 패턴이 자주 보인다.

4625 → 4625 → 4625 → 4624

이건 거의 brute force, password spraying, 또는 계정 크리덴셜 추측 시도의 결과처럼 보이는 경우가 많다.
물론 환경에 따라 사용자가 비밀번호를 여러 번 틀리고 결국 맞게 입력했을 수도 있지만, 반복 횟수, 시간 간격, 출발지 IP, 대상 계정까지 같이 보면 정상과 비정상을 구분할 수 있다.

여기서 중요한 건 4624 하나만 보고 “정상 로그인”이라고 판단하면 안 된다는 점이다.
앞뒤에 어떤 실패 로그가 있었는지, 이후에 관리자 권한이나 의심 프로세스가 이어졌는지까지 같이 붙여서 봐야 한다.

4624를 왜 더 깊게 봐야 하는지

표면적으로만 보면 4624는 그냥 “로그인 성공”이다.
그런데 실제로는 이 이벤트 안에 생각보다 많은 정보가 들어 있다.

예를 들면 이런 것들이다.

• 누가 로그인했는지
• 어떤 방식으로 로그인했는지
• 어떤 프로세스가 관여했는지
• 어느 시스템 또는 어느 주소에서 들어왔는지
• 관리자 권한 세션인지
• 가상 계정 또는 서비스 성격인지

즉, 4624는 단순한 성공 로그라기보다 로그온 세션이 새로 만들어졌다는 사실과 그 문맥을 같이 보여주는 이벤트에 가깝다.

그래서 이 글에서는 기존 흐름 위에 4624를 조금 더 깊게 붙여서 보려고 한다.

실제 이벤트 화면을 보면

아래 예시는 Event Viewer에서 본 4624 이벤트 화면이다.

이 화면에서 바로 눈에 들어오는 값은 몇 가지가 있다.

Logon Type: 2
Account Name: Administrator
Process Name: C:\Windows\System32\svchost.exe
Source Network Address: 127.0.0.1
Elevated Token: Yes

이 조합만 보면 외부에서 원격으로 들어온 흔적이라기보다는 로컬에서 관리자 계정 세션이 생성된 사례에 더 가깝다.

특히 127.0.0.1은 localhost이고, Logon Type 2는 Interactive이기 때문에 직접적인 로컬 로그인 문맥으로 해석하는 쪽이 자연스럽다.

물론 실제 분석에서는 여기서 끝나지 않고, 바로 이어서 해당 세션과 연결되는 다른 이벤트를 찾아보는 게 좋다.

프로세스 관점도 같이 봐야 한다

이벤트만 보면 “로그인 성공” 정도로 끝나기 쉬운데, 실제로는 그 세션에서 어떤 프로세스가 움직였는지도 같이 봐야 한다.

아래 이미지는 Task Manager 관점에서 PID를 확인하는 예시다.

처음 이 화면을 보면 그냥 작업 관리자 캡처처럼 보이는데, 실제로는 여기서 확인한 PID나 프로세스 이름을 이벤트 로그와 맞물려 보는 순간부터 의미가 생긴다.
예를 들어 Security 로그 쪽에서 특정 세션과 연결된 Process ID, Process Name이 보이고, 다른 타임라인이나 도구에서 비슷한 시점의 프로세스 흔적이 보이면 그때부터는 단순히 “로그인이 있었다”가 아니라 “로그인 이후 이 세션에서 어떤 행위가 이어졌다”로 시야가 넓어진다.

4624에는 Process ID와 Process Name이 들어갈 수 있고, 이 값은 나중에 4688 같은 프로세스 생성 이벤트와 연결해서 볼 때 꽤 유용하다.

예를 들어:

• 4624에서 세션 생성
• 4672에서 특권 부여
• 4688에서 PowerShell 또는 cmd 실행
• 5156에서 외부 통신 허용

이런 식으로 이어지면 단순 로그인보다 훨씬 더 강한 행위 기반 흐름이 된다.

즉, 이벤트는 따로따로 보기보다 같은 세션, 같은 계정, 같은 시간대, 같은 PID 축으로 엮어서 보는 편이 훨씬 낫다.

Raw XML을 같이 보면 이해가 빨라진다

Event Viewer 화면으로만 보면 필드가 예쁘게 정리돼 보여서 편하긴 하다.
그런데 실제로 어떤 값이 어떤 이름으로 저장되는지 보려면 XML 구조를 같이 보는 게 더 명확하다.

아래는 4624 예시 XML이다.

<?xml version="1.0"?>
<Event
    xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider
            Name="Microsoft-Windows-Security-Auditing"
            Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>
    </EventID>
    <Version>
    </Version>
    <Level>
    </Level>
    <Task>
    </Task>
    <Opcode>
    </Opcode>
    <Keywords>
    </Keywords>
    <TimeCreated SystemTime="2015-11-12T00:24:35.079785200Z" />
    <EventRecordID>
    </EventRecordID>
    <Correlation ActivityID="{00D66690-1CDF-0000-AC66-D600DF1CD101}" />
    <Execution ProcessID="716" ThreadID="760" />
    <Channel>
    </Channel>
    <Computer>
    </Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">
    </Data>
    <Data Name="SubjectUserName">
    </Data>
    <Data Name="SubjectDomainName">
    </Data>
    <Data Name="SubjectLogonId">
    </Data>
    <Data Name="TargetUserSid">
    </Data>
    <Data Name="TargetUserName">
    </Data>
    <Data Name="TargetDomainName">
    </Data>
    <Data Name="TargetLogonId">
    </Data>
    <Data Name="LogonType">
    </Data>
    <Data Name="LogonProcessName">
    </Data>
    <Data Name="AuthenticationPackageName">
    </Data>
    <Data Name="WorkstationName">
    </Data>
    <Data Name="LogonGuid">
    </Data>
    <Data Name="TransmittedServices">
    </Data>
    <Data Name="LmPackageName">
    </Data>
    <Data Name="KeyLength">
    </Data>
    <Data Name="ProcessId">
    </Data>
    <Data Name="ProcessName">
    </Data>
    <Data Name="IpAddress">
    </Data>
    <Data Name="IpPort">
    </Data>
    <Data Name="ImpersonationLevel">
    </Data>
    <Data Name="RestrictedAdminMode">
    </Data>
    <Data Name="TargetOutboundUserName">
    </Data>
    <Data Name="TargetOutboundDomainName">
    </Data>
    <Data Name="VirtualAccount">
    </Data>
    <Data Name="TargetLinkedLogonId">
    </Data>
    <Data Name="ElevatedToken">
    </Data>
  </EventData>
</Event>

이 XML을 기준으로 보면 Event Viewer에서 보던 항목들이 실제로는 어떤 필드명으로 저장되는지 바로 보인다.

특히 실전에서는 아래 값들이 자주 중요해진다.

• TargetUserName
• TargetDomainName
• TargetLogonId
• LogonType
• AuthenticationPackageName
• ProcessName
• IpAddress
• ElevatedToken

즉, 화면으로 볼 때는 예쁘게 정리된 설명을 보고, 자동화나 탐지 룰을 만들 때는 XML 필드명을 기준으로 잡는 게 편하다.

그리고 개인적으로는 XML을 한 번 눈에 익혀두면 나중에 SIEM에서 필드 매핑이 좀 다르게 들어오거나 EDR 쪽에서 이름이 살짝 바뀌어 보여도 훨씬 덜 당황하게 되는 느낌이 있다.
결국 원형이 어떻게 생겼는지를 알고 있으면, 다른 도구에서 보여주는 표현이 달라도 중심을 잡기가 쉬워진다.

4624에서 먼저 보는 필드

4624를 볼 때는 전부 한 번에 읽으려 하면 오히려 흐름이 안 잡힌다.
처음에는 아래 순서대로 보는 편이 좋다.

1. TargetUserName / TargetDomainName

누가 로그인했는지를 본다.
여기서 가장 먼저 해야 할 건 “이 계정이 원래 이 시스템에서 이런 방식으로 로그인하는 계정인가?”를 생각해보는 것이다.

예를 들면:

• 일반 사용자 계정이 새벽 시간대에 관리자 세션으로 로그인
• 서비스 계정이 Interactive 로그인
• 외부 도메인 계정이 예상치 못한 서버에서 로그인

이런 건 그 자체로 바로 눈에 들어와야 한다.

2. LogonType

이건 거의 핵심이다.
같은 4624라도 Logon Type이 다르면 의미가 꽤 달라진다.

3. IpAddress / WorkstationName

어디서 왔는지를 본다.
특히 외부 IP, 내부 점프서버, localhost, 미지의 워크스테이션 이름은 모두 해석이 달라진다.

4. ProcessName / ProcessId

이 로그온이 어떤 프로세스 문맥에서 생성됐는지를 본다.
뒤쪽 프로세스 이벤트와 붙여볼 때 중요하다.

5. ElevatedToken / VirtualAccount / RestrictedAdminMode

관리자 권한 세션인지, 서비스 계정 문맥인지, RDP Restricted Admin이 사용됐는지 등을 판단할 때 중요하다.

Logon Type은 외우기보다 해석하는 게 낫다

Microsoft 문서를 보면 Logon Type은 여러 개가 있다.
실무에서 전부를 매번 다 쓰는 건 아니지만, 한 번 표로 정리해 두면 나중에 훨씬 편하다.

여기서 많이 보게 되는 건 사실 몇 개 안 된다.

• 2 → 사용자가 직접 로그인
• 3 → 네트워크 로그온, SMB나 내부 이동 문맥에서 자주 봄
• 5 → 서비스 시작
• 10 → RDP
• 7 → 잠금 해제

즉, 전부 외우려 하기보다 2, 3, 5, 10이 어떤 상황에서 나오는지 먼저 익히는 게 훨씬 낫다.

개인적으로는 Logon Type 표를 볼 때 “암기표”처럼 보기보다 “문맥표”처럼 보는 쪽이 더 맞는 것 같다.
같은 로그인 성공이어도 Type 2와 Type 10은 해석이 전혀 다르고, Type 3과 Type 5도 의심 포인트가 완전히 다르기 때문이다.

예를 들어 Type 3이 보이면 자연스럽게 네트워크 접근, 공유 폴더, 원격 리소스 접근, 내부 이동 같은 쪽으로 생각이 간다.
반대로 Type 10이면 거의 바로 RDP 문맥을 떠올리게 된다.
Type 5는 서비스 계정과 서비스 시작 흐름을 먼저 의심하게 되고, Type 2는 로컬 사용자 행위 쪽으로 보는 편이 자연스럽다.

결국 중요한 건 “이 값이 뭐더라”가 아니라 “이 값이면 어디까지 따라가 봐야 하지”에 더 가까운 것 같다.

지금 예시 로그를 해석하면

앞서 본 실제 예시 로그는 다음 특징을 갖고 있다.

TargetUserName = Administrator
LogonType = 2
ProcessName = C:\Windows\System32\svchost.exe
IpAddress = 127.0.0.1
ElevatedToken = Yes

이걸 그대로 풀어보면:

• Interactive 로그인이다.
  즉, 네트워크를 통한 원격 인증보다 로컬 사용자 로그인 쪽 해석이 자연스럽다.

• 127.0.0.1이다.
  외부 또는 다른 내부 호스트에서 들어온 흔적이라기보다 localhost 문맥이다.

• Administrator 계정이다.
  관리자 세션이므로 이후 이벤트와 붙이면 민감도가 올라간다.

• ElevatedToken = Yes다.
  단순 계정 로그인보다 관리자 권한 세션으로 보는 편이 맞다.

이 조합만 놓고 보면 바로 “침해”라고 단정할 만한 상황은 아니지만, 적어도 고권한 로컬 세션이 시작됐다는 점에서 후속 행위를 꼭 봐야 하는 로그다.

여기서 내가 보통 바로 이어서 생각하는 건 이런 쪽이다.

• 이 로그인 직후 어떤 프로세스가 실행됐는가
• 같은 시점에 4672가 붙는가
• PowerShell, cmd, mmc, regedit 같은 관리성 프로세스가 실행됐는가
• 이후 5156 같은 네트워크 허용 로그가 따라오는가
• 같은 계정으로 추가 인증이나 자격증명 사용 흔적이 있는가

즉, 4624를 끝점으로 보지 않고 시작점으로 보는 습관이 더 중요한 것 같다.

로그인 이후에는 프로세스 실행을 붙여본다

로그인 다음에 자연스럽게 보는 이벤트는 4688이다.

Event ID: 4688

이 이벤트는 “새로운 프로세스 생성”을 의미한다.

예를 들면 이런 식이다.

{
  "NewProcessName": "powershell.exe",
  "ParentProcessName": "explorer.exe"
}

겉으로 보면 단순해 보이지만, 실제로는 여기서 의심 포인트가 꽤 많이 나온다.

• powershell.exe
• cmd.exe
• rundll32.exe
• mshta.exe
• wmic.exe
• regsvr32.exe

이런 도구들은 정상 관리 행위에도 쓰일 수 있지만, 침해사고에서도 아주 자주 보이는 이름들이다.

그래서 중요한 건 “이 프로세스가 실행됐는가”보다 이 프로세스가 어떤 로그인 세션 직후, 어떤 권한으로, 어떤 부모 프로세스 아래에서 실행됐는가다.

직접 확인할 때는 이렇게 볼 수 있다.

Get-WinEvent -LogName Security | Where-Object { $_.Id -eq 4688 }

이렇게 보면 로그가 꽤 많이 나온다.
그래서 결국 중요한 건 필터링 기준이다.

예를 들어:

• 고권한 계정 세션 직후의 4688만 보기
• PowerShell, cmd, rundll32 같은 프로세스만 보기
• 야간 시간대 실행만 보기
• 특정 서버에서만 보기
• 특정 사용자 또는 서비스 계정만 보기

이런 식으로 범위를 줄여가야 의미 있는 분석이 된다.

그리고 여기서도 결국 독립 이벤트로 보기보다 앞의 4624와 뒤의 네트워크 흔적까지 연결했을 때 훨씬 그림이 선명해진다.
세션 생성 → 특권 부여 → 의심 프로세스 실행 → 외부 통신 허용, 이 흐름이 잡히기 시작하면 그때부터는 단순한 시스템 사용 흔적과는 결이 달라진다.

권한 상승 이벤트도 붙여본다

여기서 같이 봐야 하는 대표적인 이벤트가 4672다.

4672

이 이벤트는 새로운 로그온 세션에 특별한 권한이 할당됐다는 의미다.
쉽게 말하면 관리자 성격의 강한 권한이 붙은 세션이라고 보면 된다.

그래서 아래 흐름은 꽤 중요하다.

4624 → 4672

이 조합이 보이면 단순 로그인보다 민감하게 보는 편이 낫다.

특히 그 뒤에 4688이 붙어서 PowerShell이나 cmd가 실행되면 실제 관리 작업인지, 스크립트 실행인지, 공격 행위인지 더 깊게 볼 필요가 있다.

현업 기준으로 보면 사실 관리자 권한 로그온 자체가 무조건 이상한 건 아니다.
문제는 “원래 그래야 하는 계정이, 원래 그래야 하는 시간에, 원래 그래야 하는 시스템에서” 그런 행위를 했느냐는 쪽이다.

결국 4672는 단독으로 확정 증거가 되기보다, 4624와 4688 사이에서 민감도를 높여주는 이벤트에 가깝다.
그래서 나는 이걸 볼 때 “이상하다”보다는 “주의 깊게 이어서 봐야 한다”는 신호로 받아들이는 편이다.

전체 흐름으로 보면 더 잘 보인다

지금까지 본 흐름을 한 줄로 정리하면 거의 이렇다.

로그인 → 권한 상승 → 프로세스 실행 → 네트워크

이걸 이벤트 기준으로 표현하면 대략 이런 식이다.

4624 → 4672 → 4688 → 5156

이 패턴이 보이면 그냥 단순 로그인 한 줄을 본 게 아니라, 하나의 세션이 실제로 어떤 행위를 이어갔는지까지 본 셈이 된다.

그래서 포렌식에서 중요한 건 로그를 많이 쌓아두는 것보다 결국 이 흐름을 연결할 수 있는지인 것 같다.

개별 이벤트를 많이 보는 것만으로는 어느 시점부터 한계가 온다.
오히려 이벤트를 많이 보다 보면 더 헷갈릴 때도 있다.
그런데 세션 단위로, 계정 단위로, 시간대 단위로, 프로세스와 네트워크까지 엮어서 보기 시작하면 흩어진 조각들이 조금씩 하나의 문장처럼 읽히는 느낌이 든다.

나도 이 부분이 처음에는 잘 안 잡혔는데, 몇 번 반복하다 보니까 4624를 보면 그냥 “로그인 성공”으로 안 보이고 “이제부터 이어서 볼 게 많아졌다”는 신호처럼 보이기 시작했다.
아마 이 감각이 생기는 순간부터 이벤트 로그 분석이 훨씬 덜 막막해지는 것 같다.

지금 기준에서 의심 포인트

실제로 로그를 보면서 개인적으로 먼저 체크하게 되는 건 이 정도다.

• 비정상 시간대 로그인
• 동일 IP 또는 동일 워크스테이션에서 반복 실패
• 관리자 권한 세션 생성
• 로그인 직후 PowerShell / cmd / rundll32 실행
• 서비스 계정의 Interactive 로그인
• 외부 계정 또는 낯선 도메인 계정 사용
• 원래 쓰이지 않던 시스템에서의 관리자 로그인

이 중 2~3개 이상이 같이 보이면 그건 그냥 “이상하네” 정도로 넘기기보다는 다음 이벤트까지 반드시 더 따라가 보는 편이 좋다.

이런 기준은 완벽하게 딱 떨어지는 룰이라기보다, 분석할 때 시선을 어디에 먼저 둘지 정하는 체크리스트에 가깝다.
실제로는 조직 환경마다 정상 패턴이 다르기 때문에 무엇이 이상한지도 결국 맥락에 따라 달라진다.
하지만 적어도 위 같은 항목들은 대부분 환경에서 기본적인 경고 신호 역할은 해주는 편이다.

4624에서 특히 주의해서 볼 만한 값들

Microsoft 문서를 따라가 보면 4624에는 꽤 많은 필드가 있다.
그중 실제 운영에서 유용한 것들을 조금 더 정리해보면 이렇다.

Elevated Token

이 값이 Yes면 관리자 권한 세션으로 해석할 수 있다.
고권한 계정 사용 여부를 빠르게 거르는 데 도움이 된다.

Virtual Account

Managed Service Account 같은 가상 계정 문맥을 식별할 때 유용하다.
서비스 계정 모니터링을 할 때 꽤 중요해진다.

Restricted Admin Mode

주로 Logon Type 10인 RemoteInteractive에서 의미가 있다.
RDP Restricted Admin 사용 여부를 확인할 수 있다.

Authentication Package

NTLM, Kerberos, Negotiate 같은 값이 들어간다.
환경에서 원래 Kerberos가 주로 나와야 하는데 NTLM이 반복적으로 보인다면 그 자체로 점검 포인트가 될 수 있다.

Logon ID / Linked Logon ID / Logon GUID

이 값들은 이벤트를 서로 엮을 때 유용하다.
특히 4672나 4648 같은 이벤트와 연결해볼 때 도움이 된다.

개인적으로는 4624를 볼 때 처음부터 모든 필드를 다 읽으려 하지 않고, 의미가 큰 것부터 먼저 훑은 뒤 나머지를 문맥 보강용으로 보는 쪽이 더 잘 맞았다.
어차피 실무에서는 이벤트가 한두 개만 나오는 게 아니라 꽤 많이 쏟아지기 때문에, 처음부터 모든 필드를 균등하게 읽으려 하면 오히려 중요한 걸 놓치기 쉽다.

실무적으로는 이런 식으로 보면 좋다

4624를 볼 때 “로그인 성공”이라는 한 문장만 보지 말고 아래 질문들을 같이 붙여서 보면 흐름이 많이 잡힌다.

• 이 계정은 원래 이 시스템에서 로그인하는 계정인가?
• 이 시간대 로그인이 평소와 맞는가?
• 이 Logon Type이 계정 성격과 맞는가?
• Source IP / Workstation Name이 낯설지는 않은가?
• Elevated Token이 붙어 있는가?
• 직후에 4672, 4688, 5156이 이어지는가?
• PowerShell, cmd, rundll32 같은 프로세스가 바로 실행됐는가?

결국 포렌식에서 중요한 건 정답 하나를 빨리 맞히는 것보다 정상 흐름과 어긋나는 지점을 계속 좁혀가는 것 같다.

이 질문들을 계속 던지다 보면 이벤트가 하나씩 점처럼 보이던 상태에서 선으로 이어지기 시작한다.
어떤 계정이 들어왔고, 어떤 권한을 얻었고, 어떤 프로세스를 실행했고, 그 뒤 어떤 통신을 했는지가 한 세션의 흐름처럼 정리되기 시작하면 그때부터는 단순 조회가 아니라 분석에 가까워진다.

아직 애매한 부분도 있다

물론 이벤트 로그만으로 모든 걸 단정하기는 어렵다.

예를 들면 이런 부분들은 항상 조금 더 봐야 한다.

• 정상 PowerShell과 악성 PowerShell 구분
• 로그 삭제 또는 누락 여부
• 시간 동기화 문제(clock skew)
• 계정 공유 사용 환경
• 점프서버 / 운영도구 때문에 생기는 정상 원격 흔적
• 서비스 계정의 예외적인 사용 패턴

즉, 이벤트 로그는 굉장히 많은 걸 말해주지만 동시에 맥락이 없으면 오해도 만들 수 있다.

그래서 한 줄짜리 이벤트를 확정 증거처럼 보기보다 주변 이벤트와 시스템 성격까지 같이 보는 게 훨씬 안정적이다.

이 부분은 실제로 몇 번 겪어보면 더 체감된다.
겉보기에는 꽤 수상해 보였는데 알고 보면 운영팀의 정기 작업이거나, 반대로 얼핏 정상처럼 보였는데 자세히 파보니 계정 오남용이었던 경우도 있다.
그래서 결국 중요한 건 “수상한 모양” 하나보다 “정상적인 운영 흐름과 얼마나 어긋나 있느냐”를 보는 쪽인 것 같다.

메모

로그는 생각보다 많은 걸 말해준다.
그런데 동시에 “보여주지 않는 것도 있다”는 느낌도 분명 있다.

그래서 개인적으로는 이벤트 하나를 길게 보는 것보다 여러 이벤트를 짧게 이어서 보는 방식이 더 잘 맞는 것 같다.

특히 4624는 그냥 로그인 성공 로그가 아니라, 그 다음 분석을 어디로 이어갈지를 정하게 해주는 꽤 좋은 출발점처럼 보인다.

한 줄만 보면 너무 평범한데, 그 뒤에 붙는 것들을 같이 보기 시작하면 꽤 많은 이야기를 해준다.
그 점이 이벤트 로그가 재미있는 부분이기도 하고, 동시에 어려운 부분이기도 하다.

다음에 같이 보면 좋은 것

여기까지가 Windows Security 로그 기준의 기본 흐름이라면, 다음에는 아래를 붙여보면 더 재미있다.

• Sysmon 로그 같이 보기
• PowerShell Script Block Logging 분석
• 4648, 4672, 4688, 5156 연계
• Sigma rule 기준 탐지 패턴 정리
• 계정 유형별 정상 / 비정상 로그인 베이스라인 만들기

이쪽까지 붙기 시작하면 단순히 “로그를 읽는다”에서 끝나는 게 아니라 실제로 탐지나 헌팅으로도 이어질 수 있다.
4624 하나만 깊게 봐도 출발점으로는 충분하고, 거기에 후속 이벤트와 보조 로그가 붙으면 훨씬 더 입체적으로 보이게 된다.

일단 여기까지.