Windows 이벤트 로그 기반 공격 흐름 분석 — Event ID 4624 중심

왜 하필 4624인가

Windows Security 로그에서 Event ID 4624는 "로그온 성공"을 의미한다. 표면적으로는 그냥 누군가가 로그인에 성공했다는 기록이다.

그런데 실제로 로그를 몇 번 들여다보면, 이 이벤트가 생각보다 많은 정보를 품고 있다는 걸 알게 된다. 누가 들어왔는지, 어디서 왔는지, 어떤 방식으로 인증했는지, 관리자 권한 세션인지까지 전부 4624 안에 들어 있다.

사실 처음에는 4624 하나만 보고 "정상 로그인이네" 하고 넘기기 쉽다. 그런데 계속 분석하다 보면, 이 이벤트는 "로그인 성공"이라는 사실보다 그 로그인이 만들어낸 세션의 성격을 읽는 출발점에 더 가깝다는 감이 생긴다.

같은 4624라도 앞에 반복된 4625(로그인 실패)가 쌓여 있으면 brute-force 시도 후 성공일 수 있고, 뒤에 4672(특권 부여)와 4688(프로세스 생성)이 이어지면 고권한 세션에서 뭔가 실행됐다는 뜻이 된다. 즉, 4624 하나만 떼어놓고 보면 거의 의미가 없고, 앞뒤 문맥과 엮어야 비로소 분석이 시작된다.

이 글에서는 4624의 구조를 먼저 잡고, 그 안에서 실무적으로 먼저 봐야 하는 필드를 정리한 다음, 공격 흐름에서 4624가 어떤 위치에 있는지를 시나리오 기반으로 따라가 본다.

4624의 핵심 필드 — 전부 읽지 말고 먼저 볼 것만 본다

4624를 처음 열면 필드가 꽤 많다. 전부 한 번에 읽으려 하면 오히려 흐름이 안 잡힌다. 처음에는 아래 순서대로만 보는 편이 좋다.

1. TargetUserName / TargetDomainName

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

예를 들면:

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

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

2. LogonType

이건 거의 핵심이다. 같은 4624라도 LogonType이 다르면 의미가 꽤 달라진다. 뒤에서 더 자세히 정리하겠지만, 처음에는 2(Interactive), 3(Network), 10(RDP)만 구분할 수 있으면 충분하다.

3. IpAddress / WorkstationName

어디서 왔는지를 본다. 외부 IP인지, 내부 점프서버인지, localhost(127.0.0.1)인지에 따라 해석이 전혀 달라진다.

4. ProcessName / ProcessId

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

5. ElevatedToken / VirtualAccount

관리자 권한 세션인지, 서비스 계정 문맥인지를 빠르게 판단할 때 쓴다. ElevatedToken이 Yes면 고권한 세션으로 보는 편이 자연스럽다.

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

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

<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>
      4624
    </EventID>
    <TimeCreated SystemTime="2026-03-25T00:12:34.000Z" />
    <Execution ProcessID="716" ThreadID="760" />
    <Channel>
      Security
    </Channel>
  </System>
  <EventData>
    <Data Name="TargetUserName">
      alice
    </Data>
    <Data Name="TargetDomainName">
      CORP
    </Data>
    <Data Name="TargetLogonId">
      0x123456
    </Data>
    <Data Name="LogonType">
      10
    </Data>
    <Data Name="LogonProcessName">
      User32
    </Data>
    <Data Name="AuthenticationPackageName">
      Negotiate
    </Data>
    <Data Name="WorkstationName">
      WORKSTATION01
    </Data>
    <Data Name="ProcessId">
      0x2cc
    </Data>
    <Data Name="ProcessName">
      C:\Windows\System32\svchost.exe
    </Data>
    <Data Name="IpAddress">
      203.0.113.45
    </Data>
    <Data Name="IpPort">
      49222
    </Data>
    <Data Name="ElevatedToken">
      Yes
    </Data>
    <Data Name="VirtualAccount">
      No
    </Data>
  </EventData>
</Event>

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

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

LogonType — 외우기보다 해석하는 게 낫다

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

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

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

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

예를 들어 Type 3이 보이면 자연스럽게 네트워크 접근, 공유 폴더, 원격 리소스 접근, 내부 이동 같은 쪽으로 생각이 간다. 반대로 Type 10이면 거의 바로 RDP 문맥을 떠올리게 된다.

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

4624 하나를 실제로 해석해 보면

아래 같은 조합의 4624가 보였다고 해보자.

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

이걸 그대로 풀어보면:

• LogonType 10 → RDP 접속이다. 누군가가 원격 데스크톱으로 들어왔다.
• 203.0.113.45 → 외부 IP다. 내부망 대역이 아닌 이상 외부에서 직접 RDP로 접속한 것으로 보인다.
• Administrator → 관리자 계정이다. 공격자가 가장 먼저 노리는 계정 중 하나다.
• ElevatedToken = Yes → 관리자 권한이 부여된 세션이다.

이 조합은 꽤 강한 신호다. 물론 VPN 게이트웨이를 통해 합법적으로 원격 접속하는 관리자일 수도 있다. 하지만 적어도 "외부 IP에서 RDP로 관리자 계정에 접속, 고권한 세션 생성"이라는 사실만으로도 후속 행위를 반드시 확인해야 하는 로그다.

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

• 이 로그인 직후 어떤 프로세스가 실행됐는가
• 같은 시점에 4672(특권 부여)가 붙는가
• PowerShell, cmd, mmc, regedit 같은 관리성 프로세스가 실행됐는가
• 이후 5156 같은 네트워크 허용 로그가 따라오는가
• 같은 IP에서 다른 시스템으로도 접속 시도가 있었는가

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

로그인 이후 — 권한 상승과 프로세스 실행을 붙여본다

4672: 특권 부여

4624 바로 뒤에 자주 보이는 이벤트가 4672다. 이 이벤트는 새로운 로그온 세션에 특별한 권한(SeDebugPrivilege, SeBackupPrivilege 등)이 할당됐다는 의미다. 쉽게 말하면 관리자 성격의 강한 권한이 붙은 세션이라고 보면 된다.

4624 → 4672

이 조합이 보이면 단순 로그인보다 민감하게 보는 편이 낫다. 물론 현업 기준으로 보면 관리자 권한 로그온 자체가 무조건 이상한 건 아니다. 문제는 "원래 그래야 하는 계정이, 원래 그래야 하는 시간에, 원래 그래야 하는 시스템에서" 그런 행위를 했느냐다.

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

4688: 프로세스 생성

로그인 다음에 자연스럽게 보는 이벤트는 4688이다. 이 이벤트는 "새로운 프로세스가 생성됐다"는 의미다.

{
  "NewProcessName": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
  "ParentProcessName": "C:\\Windows\\explorer.exe",
  "TargetUserName": "Administrator",
  "TokenElevationType": "%%1936"
}

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

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

이런 도구들은 정상 관리 행위에도 쓰일 수 있지만, 침해사고에서도 아주 자주 보이는 이름들이다. 그래서 중요한 건 "이 프로세스가 실행됐는가"보다 이 프로세스가 어떤 로그인 세션 직후, 어떤 권한으로, 어떤 부모 프로세스 아래에서 실행됐는가다.

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

Get-WinEvent -LogName Security |
  Where-Object { $_.Id -eq 4688 } |
  Select-Object TimeCreated,
    @{N='User';E={$_.Properties[1].Value}},
    @{N='Process';E={$_.Properties[5].Value}},
    @{N='Parent';E={$_.Properties[13].Value}} |
  Format-Table -AutoSize

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

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

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

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

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

로그인(4624) → 권한 상승(4672) → 프로세스 실행(4688) → 네트워크(5156)

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

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

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

실제 공격 시나리오 3가지

시나리오 1: 정상적 업무 흐름

[09:00] 4624 — LogonType 2, User: jinho, IP: 127.0.0.1
[09:01] 4688 — explorer.exe → outlook.exe
[09:15] 4624 — LogonType 3, User: jinho, IP: 192.168.1.100
         (파일서버 접근)

직원이 사무실 PC에서 콘솔 로그인(2) → 메일 클라이언트 실행 → 내부 파일 서버 접속(3). 이건 전형적인 정상 패턴이다. LogonType, 시간대, 대상 시스템 모두 평소와 일관되면 크게 신경 쓸 필요 없다.

시나리오 2: 외부 RDP 침입

[02:14] 4625 × 47회 — LogonType 10, User: Administrator, IP: 185.x.x.x
[02:31] 4624 — LogonType 10, User: Administrator, IP: 185.x.x.x
[02:31] 4672 — SeDebugPrivilege 할당
[02:32] 4688 — powershell.exe (encoded command)
[02:33] 5156 — outbound 443, dest: 91.x.x.x

새벽 2시, 외부 IP에서 47번 실패 후 성공. 성공 직후 특권 부여, PowerShell 실행, 외부 통신. 이건 거의 교과서적인 brute-force → 초기 침투 → C2 통신 패턴이다.

여기서 포인트:

• 반복 실패 후 성공 = 크리덴셜 추측 성공 가능성
• LogonType 10 + 외부 IP = RDP 직접 노출
• 성공 직후 바로 powershell.exe = 자동화된 공격 도구 가능성
• 외부 통신 = C2(Command & Control) 의심

시나리오 3: Lateral Movement

[14:00] 4624 — LogonType 3, User: svc_backup, IP: 10.0.1.50
         (초기 침투된 서버에서 다른 서버로 이동)
[14:00] 4672 — 특권 부여
[14:01] 4688 — wmic.exe /node:10.0.1.60 process call create ...
[14:01] 4624 — LogonType 3, User: svc_backup, IP: 10.0.1.50
         (10.0.1.60 서버에서 같은 계정으로 다시 로그인)

이미 탈취한 서비스 계정으로 내부 이동. 같은 계정이 여러 서버에서 LogonType 3으로 연속 접속하면서 wmic, psexec, WinRM 등으로 명령을 전파한다.

여기서 핵심은 LogonID 연속성이다. 동일한 LogonID(또는 TargetLogonId)가 여러 중요 이벤트에서 재사용되면, 한 세션의 연속 활동으로 판단할 근거가 된다.

탐지 룰의 기본 골격

위 시나리오를 기반으로 간단한 탐지 룰을 만들면 대략 이런 모양이 된다.

RULE: Suspicious RDP followed by privilege escalation
 
WHEN EventID == 4624
  AND LogonType == 10
  AND IpAddress NOT IN (known_vpn_ranges)
THEN
  FOR next 300 seconds, same LogonID:
    IF EventID IN (4672, 4688)
      ALERT "External RDP session with privilege escalation"
      PRIORITY = HIGH

RULE: Lateral movement via service account
 
WHEN EventID == 4624
  AND LogonType == 3
  AND TargetUserName MATCHES "svc_*"
  AND count(distinct TargetComputer) >= 3 within 600 seconds
THEN
  ALERT "Service account accessing multiple hosts rapidly"
  PRIORITY = CRITICAL

이런 룰은 SIEM이든 스크립트든 형태는 달라도 핵심 로직은 같다. 4624를 기준으로 세션을 잡고, 같은 세션(LogonID) 안에서 후속 이벤트를 찾는 구조다.

실무에서 자주 빠지는 함정

False Positive 관리

VPN 게이트웨이나 점프서버를 통해 합법적 원격 접속이 이루어질 수 있다. IP의 ASN/지리정보와 사용자 평소 패턴을 같이 보지 않으면 오탐이 쏟아진다.

운영팀의 정기 작업이 새벽에 실행되는 경우도 꽤 흔하다. 겉보기에는 수상해 보이지만 알고 보면 스케줄된 배치 작업인 경우. 그래서 결국 중요한 건 **"수상한 모양" 하나보다 "정상적인 운영 흐름과 얼마나 어긋나 있느냐"**를 보는 쪽이다.

로그 신뢰도

• 일부 로그 전송 과정에서 LogonID가 누락되거나 변경되는 경우가 있다
• 시간 동기화 문제(clock skew)로 이벤트 순서가 뒤집힐 수 있다
• 로그 삭제(1102: Security 로그 지움) 여부도 항상 체크해야 한다
• 계정 공유 환경에서는 TargetUserName만으로 개인을 특정하기 어렵다

정상 vs 악성 PowerShell 구분

PowerShell이 실행됐다는 사실 자체는 이상한 게 아니다. 문제는 어떤 세션에서, 어떤 인자로, 어떤 시간에 실행됐느냐다. -enc (encoded command)가 붙어 있거나, 다운로드 행위(IEX, Invoke-WebRequest)가 포함되면 우선순위를 올려야 한다.

Script Block Logging(Event ID 4104)이 켜져 있으면 실제 실행된 스크립트 내용까지 볼 수 있다. 이걸 4688과 같이 보면 "무엇이 실행됐는지"가 훨씬 선명해진다.

의심 포인트 체크리스트

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

• 비정상 시간대 로그인 (새벽, 휴일)
• 동일 IP에서 반복 실패 후 성공
• 관리자 권한 세션 생성 (ElevatedToken = Yes)
• 로그인 직후 PowerShell / cmd / rundll32 실행
• 서비스 계정의 Interactive 로그인 (Type 2)
• 외부 계정 또는 낯선 도메인 계정 사용
• 같은 계정이 짧은 시간 내 여러 서버에 접속
• Authentication Package가 평소와 다른 경우 (예: Kerberos 환경에서 NTLM 반복)

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

이런 기준은 완벽하게 딱 떨어지는 룰이라기보다, 분석할 때 시선을 어디에 먼저 둘지 정하는 체크리스트에 가깝다. 실제로는 조직 환경마다 정상 패턴이 다르기 때문에 무엇이 이상한지도 결국 맥락에 따라 달라진다.

4624에서 조금 더 보면 좋은 필드들

여기까지 핵심 필드를 봤다면, 아래는 상황에 따라 추가로 확인하면 좋은 필드들이다.

AuthenticationPackageName

NTLM, Kerberos, Negotiate 같은 값이 들어간다. 환경에서 원래 Kerberos가 주로 나와야 하는데 NTLM이 반복적으로 보인다면 그 자체로 점검 포인트가 될 수 있다. Pass-the-Hash 공격은 NTLM 인증을 악용하는 경우가 많다.

RestrictedAdminMode

주로 LogonType 10(RDP)에서 의미가 있다. RDP Restricted Admin 모드가 사용됐는지를 확인할 수 있다. 이 모드는 크리덴셜이 원격 시스템에 캐시되지 않아 보안상 유리하지만, 동시에 Pass-the-Hash로 RDP 접속이 가능해지는 양면이 있다.

VirtualAccount

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

LogonGuid / TargetLinkedLogonId

이 값들은 이벤트를 서로 엮을 때 유용하다. 특히 4672, 4648 같은 이벤트와 연결해볼 때, 그리고 도메인 환경에서 여러 시스템 간 로그온 연쇄를 추적할 때 도움이 된다.

운영 관점에서의 권장 사항

4624는 분석의 출발점이다. 자동화의 핵심은 "4624 → 같은 LogonID의 4672/4688 연계"를 신속히 찾아내는 룰을 구현하는 것이다.

운영팀에게 권하고 싶은 건 이 정도다.

1. LogonID 기반 연계 탐색 자동화: 4624 발생 시 동일 LogonID로 후속 이벤트(4672, 4688, 5156)를 자동으로 묶어 보여주는 뷰를 만들어라.

2. 베이스라인 구축: 계정별, 시스템별, 시간대별 정상 로그인 패턴을 먼저 파악하라. 이상 탐지는 정상을 알아야 가능하다.

3. Script Block Logging 활성화: PowerShell 실행 내용을 4104로 기록하도록 설정하라. 4688만으로는 "무엇이 실행됐는지"를 알기 어렵다.

4. 로그 보존 기간 확보: Security 로그의 기본 크기는 작다. 최소 90일 이상 보존할 수 있도록 로그 크기를 늘리거나 중앙 수집 체계를 갖춰라.

5. 1102 감시: Security 로그가 삭제되면 Event ID 1102가 남는다. 이 이벤트 자체를 모니터링 대상에 넣어라. 로그를 지우는 행위는 그 자체로 강한 의심 신호다.

다음에 같이 보면 좋은 것

여기까지가 Windows Security 로그 기준의 기본 흐름이라면, 다음에는 아래를 붙여보면 더 입체적으로 보인다.

• Sysmon 로그: 프로세스 생성(Event 1), 네트워크 연결(Event 3), 파일 생성(Event 11) 등을 훨씬 상세하게 기록한다. 기본 Security 로그로는 부족한 부분을 채워준다.
• PowerShell Script Block Logging (4104): 실제 실행된 스크립트 내용까지 기록한다.
• 4648 (Explicit Credential 사용): RunAs나 네트워크 드라이브 매핑 시 다른 크리덴셜을 명시적으로 사용한 경우. Lateral movement에서 자주 보인다.
• Sigma rule 기반 탐지 패턴: 오픈소스 탐지 규칙으로 위의 이벤트 조합을 자동으로 매칭할 수 있다.
• 계정 유형별 베이스라인: 서비스 계정 / 관리자 계정 / 일반 사용자별로 정상 로그인 패턴을 분리해서 관리하면 이상 탐지 정확도가 올라간다.

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

References

• Microsoft Docs — Event ID 4624
• Ultimate Windows Security — Event 4624 Encyclopedia
• MITRE ATT&CK — Valid Accounts (T1078), Remote Desktop Protocol (T1021.001)
• Hero image: U.S. Air Force / Tech. Sgt. R.J. Biermann — Public domain, via Wikimedia Commons
• Thumbnail image: UK Ministry of Defence — OGL v1.0, via Wikimedia Commons
• Flow diagram: Cyberattack chain — Public domain, via Wikimedia Commons
• Body image: CC BY 2.0, via Wikimedia Commons