Windows 서비스와 이벤트 감사

1. Windows 서비스는 ‘백그라운드 프로그램’ 이상의 보안 객체다

Windows 서비스는 일반적으로 Service Control Manager(SCM, 서비스 제어 관리자) 의 관리 아래 실행되는 백그라운드 프로그램이다. SCM은 설치된 서비스 정보를 관리하고, 서비스를 시작·중지하며, 현재 상태를 추적하고, 서비스 제어 요청을 전달한다.

서비스를 보안 관점에서 볼 때는 최소한 다음 네 가지를 함께 확인해야 한다.

1. 무엇을 실행하는가: 서비스가 시작할 실행 파일과 인수
2. 누구의 권한으로 실행하는가: 서비스 로그온 계정
3. 언제 실행하는가: 자동·수동·사용 안 함 등의 시작 설정
4. 누가 설정을 바꿀 수 있는가: 서비스 객체와 관련 파일의 접근 권한

예를 들어 BackupAgent라는 서비스가 정상 백업 프로그램이라고 하더라도 다음 상태라면 위험이 커진다.

서비스 이름 : BackupAgent
실행 파일   : C:\Program Files\BackupAgent\agent.exe
실행 계정   : LocalSystem
시작 방식   : Automatic

여기서 LocalSystem처럼 강한 권한으로 실행된다는 사실만으로 취약한 것은 아니다. 그러나 일반 사용자가 agent.exe를 바꾸거나 서비스의 실행 경로를 변경할 수 있다면, 다음 서비스 시작 때 강한 서비스 권한으로 바뀐 코드가 실행될 위험이 생긴다.

따라서 서비스 보안은 “서비스를 켜거나 끄는 문제”가 아니라 실행 코드·보안 주체·구성 변경 권한을 함께 보호하는 문제다.

2. 서비스 계정은 서비스가 사용할 수 있는 자원의 범위를 결정한다

서비스도 프로세스이므로 실행될 때 보안 컨텍스트(Security Context) 가 필요하다. 이 보안 컨텍스트는 서비스가 어떤 로컬 파일·레지스트리·네트워크 자원 등에 접근할 수 있는지를 결정한다.

Windows에는 서비스에 사용할 수 있는 여러 종류의 계정이 있다. 시험 학습에서는 모든 유형의 세부 설정법보다 권한 범위가 서로 다르며 최소권한이 중요하다는 점을 이해해야 한다.

중요한 것은 “LocalSystem은 항상 나쁘다”가 아니다. 운영체제 핵심 서비스처럼 높은 권한이 필요한 서비스도 있다. 판단은 다음과 같이 해야 한다.

서비스가 필요한 작업
       ↓
그 작업에 필요한 최소 권한
       ↓
그 권한을 가진 서비스 계정 선택

불필요하게 강한 계정으로 서비스를 실행하면 서비스 코드의 오류나 침해가 발생했을 때 피해 범위가 커질 수 있다.

3. 서비스의 ‘시작 유형’과 ‘실행 권한’은 서로 다른 개념이다

서비스 관리 화면에서는 다음과 같은 실행 방식을 볼 수 있다.

• 자동 시작 계열
• 수동 또는 요청 시 시작 계열
• 사용 안 함(Disabled)

이 값은 서비스의 생명주기, 즉 언제 시작할지를 정한다. 서비스가 어떤 권한으로 동작하는지는 서비스 계정이 결정한다.

따라서 다음 두 문장은 서로 다른 질문이다.

“부팅할 때 자동으로 시작하는가?”  → 시작 방식
“시작되면 어떤 자원에 접근 가능한가?” → 서비스 계정·권한

사용하지 않는 서비스를 모두 삭제하면 되는가?

그렇게 단순하게 판단하면 안 된다. 어떤 Windows 서비스는 다른 기능과 종속 관계를 가지며, 필요하지 않아 보인다고 임의로 제거하거나 비활성화하면 운영체제나 업무 기능이 중단될 수 있다.

보안 강화에서는 다음 순서가 더 안전하다.

1. 서비스의 업무·시스템 필요성을 확인한다.
2. 종속 서비스와 영향 범위를 확인한다.
3. 불필요하다고 검증된 경우 비활성화 또는 제거를 검토한다.
4. 변경 후 기능과 로그를 확인한다.

즉 “서비스 수를 무조건 최소화”하는 것이 아니라 불필요한 공격 표면을 줄이되 필요한 기능을 깨뜨리지 않는 것이 목표다.

4. 이벤트 로그와 감사 정책은 같은 것이 아니다

Windows 보안 학습에서 가장 많이 혼동하는 것이 이벤트 로그(Event Log) 와 감사 정책(Audit Policy) 이다.

이벤트 로그

운영체제와 응용 프로그램이 생성한 이벤트를 저장하고 조회하는 기록 체계다. Windows 이벤트 뷰어(Event Viewer)에서 대표적으로 다음 영역을 볼 수 있다.

• Application: 응용 프로그램이 기록한 주요 이벤트
• Security: 보안 감사 이벤트
• System: Windows 시스템 구성요소·서비스·드라이버 관련 이벤트
• Setup: 설치·설정 과정 관련 이벤트
• Forwarded Events: 다른 컴퓨터에서 전달받은 이벤트
• Applications and Services Logs: 특정 Windows 구성요소나 응용 프로그램의 세부 채널

감사 정책

어떤 보안 행위를 감사 이벤트로 남길지 결정하는 정책이다. 예를 들어 로그온 성공과 실패를 기록할지, 프로세스 생성을 기록할지 등을 범주·하위범주 단위로 설정할 수 있다.

즉 관계는 다음과 같다.

감사 정책
  ↓ 어떤 보안 행위를 기록할지 선택
보안 행위 발생
  ↓ 조건이 충족되면 감사 이벤트 생성
Security 이벤트 로그 등에 저장
  ↓
Event Viewer / Get-WinEvent 등으로 조회·분석

감사 정책을 켰다고 모든 Windows 이벤트가 그 정책에 의해 생성되는 것은 아니다. System이나 Application 로그의 많은 이벤트는 각 이벤트 공급자(provider)의 동작에 따라 생성된다.

5. 파일 접근 감사는 ‘정책만 켜면 모든 파일이 기록된다’가 아니다

T04에서 DACL은 접근 허용·거부에 사용된다고 배웠다. 감사에는 별도의 SACL(System Access Control List, 시스템 접근 제어 목록) 이 사용될 수 있다.

파일 시스템 객체의 접근 감사를 예로 들면 일반적으로 다음 두 조건을 함께 고려한다.

1. Audit File System 같은 관련 감사 정책이 활성화되어 있어야 한다.
2. 감시하려는 파일·폴더에 해당 계정과 접근 종류를 지정한 SACL이 있어야 한다.

예를 들어 중요 파일 D:\Finance\salary.xlsx에서 특정 그룹의 쓰기 시도를 감사하려면, 감사 정책뿐 아니라 그 객체에 맞는 SACL도 필요하다.

감사 정책: File System 감사 활성화
            +
salary.xlsx SACL: Finance-Users의 Write 감사
            ↓
해당 사용자·접근 종류가 일치할 때 감사 이벤트 생성 가능

따라서 “Object Access 감사를 켰는데 파일 접근 로그가 없다”는 상황에서는 단순히 로그 시스템 오류라고 결론 내리지 말고 대상 객체의 SACL 조건도 확인해야 한다.

DACL과 SACL의 목적을 구분하면 다음과 같다.

6. 이벤트 한 건을 읽을 때는 ID보다 ‘문맥 필드’를 함께 본다

Event ID는 이벤트 종류를 식별하는 중요한 단서지만 ID만으로 원인이나 공격 여부가 확정되는 것은 아니다. 같은 ID도 정상 업무와 비정상 행위에서 모두 나타날 수 있다.

이벤트를 볼 때 다음 필드를 함께 읽는 습관이 필요하다.

• 발생 시각
• 로그 이름 또는 채널
• 공급자(Provider)
• Event ID
• 성공/실패 또는 수준(Level)
• 계정·SID
• Logon ID와 Logon Type처럼 세션을 연결하는 값
• 프로세스 이름·PID
• 서비스 이름·실행 파일 경로
• 원격 주소·워크스테이션 이름 등 네트워크 정보
• 대상 객체·작업 내용

모든 이벤트가 이 필드를 전부 가지는 것은 아니다. 이벤트 공급자와 이벤트 종류마다 기록하는 데이터가 다르다.

대표적으로 알아둘 보안 이벤트

다음 표는 모든 Event ID의 암기표가 아니라 상관분석 방법을 익히기 위한 대표 예시다.

특히 4697처럼 감사 하위범주 설정에 따라 기록 여부가 달라질 수 있는 이벤트는 “이 이벤트가 없으니 서비스가 설치되지 않았다”고 단정하면 안 된다.

7. 사건은 ‘점’이 아니라 시간 순서로 연결한다

다음은 학습을 위한 가상 로그다. 실제 시스템에서 수집한 기록이 아니다.

10:14:03  Security 4625  account=svc_backup  source=10.20.5.14
10:14:11  Security 4625  account=svc_backup  source=10.20.5.14
10:16:32  Security 4624  account=svc_backup  logon_type=3  source=10.20.5.14
10:18:08  Security 4697  service=BackupAgent-Test  account=LocalSystem
10:23:40  Security 1102  account=Administrator

이 기록을 볼 때 잘못된 접근은 다음과 같다.

4625가 있다 → 무조건 비밀번호 공격이다.   (X)
4697이 있다 → 무조건 악성 서비스다.       (X)
1102가 있다 → 무조건 공격자가 로그를 지웠다. (X)

더 좋은 분석은 시간·계정·대상을 연결한다.

1. svc_backup 로그온 실패가 짧은 시간에 반복됐다.
2. 같은 계정·출발지에서 이후 로그온 성공이 발생했다.
3. 얼마 뒤 새 서비스 설치 이벤트가 나타났다.
4. 그 뒤 Security 감사 로그 삭제가 기록됐다.
5. 이 연속성은 우선 조사 가치가 높지만, 정상 변경 작업인지 침해인지 추가 확인해야 한다.

확인할 추가 정보는 예를 들어 다음과 같다.

• 해당 시간에 승인된 유지보수 작업이 있었는가?
• svc_backup 계정이 원래 그 서버에 로그온해야 하는 계정인가?
• Logon Type과 원격 주소가 정상 사용 패턴과 맞는가?
• 설치된 서비스의 실행 파일 경로와 전자서명·배포 이력이 정상인가?
• 서비스 계정이 왜 LocalSystem이어야 하는가?
• 로그를 지운 계정의 Logon ID를 이전 이벤트와 연결할 수 있는가?

8. 로그의 ‘Error’가 곧 보안 사고이고 ‘Success’가 곧 안전한 것은 아니다

이벤트의 수준이나 성공 여부를 보안 판단과 혼동하면 안 된다.

Error / Warning / Information

주로 시스템·응용 프로그램의 상태나 심각도를 나타내는 분류다. 오류 이벤트가 있어도 단순 장애일 수 있고, 공격이 성공했는데도 오류가 전혀 없을 수 있다.

Audit Success / Audit Failure

감사한 행위의 결과가 성공했는지 실패했는지를 뜻한다.

예를 들어 다음은 모두 가능하다.

Audit Failure 4625
→ 사용자가 비밀번호를 잘못 입력한 정상 실수일 수 있음

Audit Success 4624
→ 정상 사용자의 정상 로그인일 수도 있고,
   탈취된 계정의 성공 로그인일 수도 있음

따라서 성공=안전, 실패=공격이라는 식으로 해석하지 않는다.