yamato-security/enablewindowslogsettingsWindows 이벤트 로그를 올바르게 활성화하기 위한 문서 및 스크립트.
이 문서는 sigma 규칙에 대한 로깅을 중점으로 Windows 이벤트 로그를 올바르게 구성하고 모니터링하는 또 다른 가이드입니다.
이 문서는 작성 중이므로 정기적으로 다시 확인해 주시기 바랍니다.
Zach Mathis (@yamatosecurity). 더 많은 연구와 테스트를 수행하면서, 개선의 여지가 많기 때문에(문서와 탐지 규칙 생성 모두에서) 이 문서를 주기적으로 업데이트할 계획입니다. PR은 환영하며 기여자로 기꺼이 추가하겠습니다. 이 문서에서 오류를 발견하시면 알려주시기 바랍니다. 가능한 한 빨리 수정하겠습니다.
이 문서가 유용하다고 생각되시면 GitHub에 스타를 눌러주세요. 계속 업데이트하는 데 동기부여가 될 것입니다.
대부분의 정보는 Microsoft의 Advanced security auditing FAQ, sigma 규칙, ACSC Event Logging Guide 및 제 연구/테스트에서 얻은 것입니다. 특히 모든 방어자들을 위해 위협 탐지를 오픈 소스로 무료 제공해 주신 sigma 커뮤니티에 감사드립니다.
기본적으로 Windows는 악성 활동 탐지와 포렌식 조사에 필요한 많은 이벤트를 기록하지 않습니다.
또한 이벤트 파일의 기본 최대 크기는 클래식 이벤트 로그(Security, System, Application)의 경우 20MB, PowerShell의 경우 15MB에 불과하며, 다른 거의 모든 로그는 1MB에 불과하므로 시간이 지나면서 증거가 덮어쓸 가능성이 높습니다.
이 저장소에는 시스템 관리자가 Windows 머신을 쉽게 구성하여 사고 발생 시 필요한 로그를 확보할 수 있도록 간단한 배치 스크립트가 제공되어 있습니다. 대규모 네트워크의 경우 이 문서를 참조 자료로 사용하고 그룹 정책 및/또는 InTune으로 엔드포인트를 구성하는 것이 좋습니다.
기본 Windows 이벤트 로깅 설정을 개선할 것을 적극 권장하며 가장 정확한 정보를 제공하기 위해 최선을 다하고 있습니다. 그러나 지나친 로깅 활성화로 인한 부작용이나 이 저장소에 있는 내용의 정확성에 대해서는 어떠한 책임도 지지 않습니다. 프로덕션에 배포하기 전에 테스트 머신에서 시스템에 적용할 모든 변경 사항을 이해하고 테스트할 책임은 사용자에게 있습니다. 최소 일주일 동안 사용자 환경을 모방한 테스트 머신에서 가능한 한 많은 로깅을 켜고, 너무 많은 노이즈를 생성하는 이벤트가 있는지 또는 원하지만 생성되지 않는 이벤트가 있는지 확인하는 것이 좋습니다.
Hayabusa의 이벤트 ID 메트릭 명령을 사용하여 evtx 파일에 있는 이벤트 ID의 총 개수와 백분율을 확인할 수 있습니다.
예시: hayabusa.exe eid-metrics -f path/to/Security.evtx
Process Creation일 것입니다.
현재 Sigma 탐지 규칙의 약 절반이 이 이벤트에 의존합니다.
이는 Sysmon(이벤트 ID 1)을 설치하거나 기본 제공 Security 로그 이벤트 ID 4688을 활성화하여 수행할 수 있습니다.
Sysmon 1은 실행 파일의 해시 및 메타데이터와 같은 자세한 정보를 제공하므로 이상적이지만, Sysmon을 설치할 수 없는 경우 기본 제공 Security 4688 로그를 사용할 수 있습니다. 그러나 많은 탐지 규칙이 명령줄 로깅에 의존하므로 명령줄 로깅도 함께 활성화하는 것이 중요합니다. 안타깝게도 Security 4688은 Sysmon 프로세스 생성 로그만큼 자세한 정보를 제공하지 않으므로 모든 Process Creation 규칙이 Security 4688에서 작동하는 것은 아닙니다.
기본 Windows 감사 설정으로는 sigma 규칙의 약 10~20%만 사용할 수 있습니다!
규모에 맞게 수행하기에는 실용적이지 않지만, 로그를 활성화/비활성화하고 최대 파일 크기를 확인 및/또는 구성하는 가장 쉬운 방법은 이벤트 뷰어에서 로그를 마우스 오른쪽 버튼으로 클릭하고 속성(Properties)을 여는 것입니다.
기본 제공 wevtutil 명령을 사용할 수 있습니다.
예시: wevtutil sl Security /ms:1073741824를 사용하면 Security 로그의 최대 파일 크기를 1GB로 늘릴 수 있습니다.
예시:```powershell $sysmon = Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational $sysmon.MaximumSizeInBytes = 2048000000 #2GB $sysmon.SaveChanges()
## Option 4: 그룹 정책
클래식 이벤트 로그(예: `Security`, `System`, `Application`)의 최대 파일 크기를 늘리는 것은 간단하지만, 안타깝게도 다른 로그의 최대 파일 크기를 변경하려면 관리 템플릿을 설치하거나/및 레지스트리를 직접 수정해야 합니다. 시작 시 배치 또는 PowerShell 스크립트로 파일 크기를 늘리는 것이 더 쉬울 수도 있습니다.
# 구성 스크립트
최대 파일 크기를 늘리고 적절한 로그를 활성화하는 스크립트가 여기에 제공되어 있습니다: [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/YamatoSecurityConfigureWinEventLogs.bat)
# 로그 설정 구성
## Sysmon 로그 (1382개의 sigma 규칙)
파일: `Microsoft-Windows-Sysmon%4Operational.evtx`
기본 설정: `Not installed`
sysmon을 설치하고 구성하는 것은 Windows 엔드포인트에서 가시성을 높이기 위해 할 수 있는 가장 좋은 일이지만 계획, 테스트 및 유지 관리가 필요합니다.
이것은 그 자체로 큰 주제이므로 현재 이 문서의 범위를 벗어납니다.
다음 자료를 확인하세요:
* [TrustedSec Sysmon Community Guide](https://github.com/trustedsec/SysmonCommunityGuide)
* [Sysmon Modular](https://github.com/olafhartong/sysmon-modular)
* [Florian Roth's updated fork of the Swift On Security's sysmon config file](https://github.com/Neo23x0/sysmon-config)
* [Ion-storm's updated fork of the Swift On Security's sysmon config file](https://github.com/ion-storm/sysmon-config)
* [Cyb3rWard0g's sysmon config file](https://github.com/OTRF/Blacksmith/blob/master/resources/configs/sysmon/sysmon.xml)
## 보안 로그 (1045개의 sigma 규칙(903개의 프로세스 생성 규칙 + 142개의 기타 규칙))
파일: `Security.evtx`
기본 설정: `Partially enabled`
보안 로그는 구성하기 가장 복잡하므로 별도의 문서를 만들었습니다: [ConfiguringSecurityLogAuditPolicies.md](https://github.com/yamato-security/enablewindowslogsettings/blob/HEAD/ConfiguringSecurityLogAuditPolicies.md)
## PowerShell 로그 (175개의 sigma 규칙)
파일: `Microsoft-Windows-PowerShell%4Operational.evtx`
### 모듈 로깅 (30개의 sigma 규칙)
모듈 로깅을 켜면 이벤트 ID `4103`이 활성화됩니다.
모듈 로깅은 이전 OS 및 PowerShell 버전에서 실행 가능하다는 장점이 있습니다: PowerShell 3.0(Win 7 이상).
또 다른 이점은 실행된 PowerShell 명령과 결과를 모두 기록한다는 것입니다.
단점은 매우 많은 수의 이벤트가 생성된다는 것입니다.
예를 들어, 공격자가 Mimikatz를 실행하면 2000개 이상의 이벤트로 7MB의 로그가 생성됩니다!
#### 모듈 로깅 활성화
기본 설정: `No Auditing`
##### 옵션 1: 그룹 정책을 통한 활성화
그룹 정책 편집기(`gpedit.msc`)에서 `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell`을 열고 `Turn on Module Logging`을 활성화합니다.
`Options` 창에서 `Show...` 버튼을 클릭하여 기록할 모듈을 구성합니다.
`Value` 입력란에 `*`를 입력하여 모든 모듈을 기록합니다.
##### 옵션 2: 레지스트리를 통한 활성화```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames → * = *
기본 설정: Win 10/2016+에서 PowerShell 스크립트가 AMSI에 의해 의심스러운 것으로 플래그되면 경고 수준으로 기록됩니다.
스크립트 블록 로깅을 켜면 이벤트 ID 4104가 활성화됩니다. 스크립트 블록 호출 시작/중지 이벤트 기록을 활성화하면 EID 4105 및 4106도 활성화되지만, 이는 단지 노이즈를 만들 뿐이므로 권장되지 않습니다.
스크립트 블록 로깅은 PowerShell 5.0+ (Win 10+)에서 기본적으로 지원되지만, .NET 4.5 및 WMF 4.0+를 설치하면 이전 OS(Win 7+)에서도 활성화할 수 있습니다.
안타깝게도 단일 Windows 이벤트 로그의 최대 크기는 32KB이므로 이보다 큰 PowerShell 스크립트는 32KB 크기의 블록으로 분할됩니다.
원본 PowerShell Operational.evtx 파일이 있다면 block-parser 도구를 사용하여 이러한 로그를 하나의 읽기 쉬운 텍스트 파일로 병합할 수 있습니다.
스크립트 블록 로깅의 좋은 점 중 하나는 악성 스크립트가 XOR, Base 64, ROT13 등으로 난독화되어 있더라도 디코딩된 스크립트가 기록되어 분석이 훨씬 쉬워진다는 것입니다.
이 로그는 모듈 로깅보다 다루기 쉽습니다. 공격자가 Mimikatz를 실행할 경우 약 5MB와 100개의 이벤트만 생성되는 반면, 모듈 로깅은 7MB와 2000개가 넘는 이벤트가 생성되기 때문입니다.
그러나 스크립트 블록 로깅에서는 명령의 출력이 기록되지 않습니다.
그룹 정책 편집기에서 컴퓨터 구성 > 관리 템플릿 > Windows 구성 요소 > Windows PowerShell을 열고 PowerShell 스크립트 블록 로깅 켜기를 활성화합니다.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1
기본 설정: 감사 없음
전사 로그를 사용하면 PowerShell 로그를 로컬 컴퓨터의 텍스트 파일로 저장할 수도 있습니다. 공격자는 일반적으로 안티포렌식을 위해 전사 로그를 쉽게 삭제할 수 있지만, 모든 이벤트 로그를 지우면서도 삭제할 전사 로그를 찾지 않는 시나리오가 있을 수 있습니다. 따라서 가능하면 전사 로그도 활성화하는 것이 좋습니다. 기본적으로 사용자의 문서 폴더에 저장됩니다. 이상적으로는 전사 로그를 쓰기 전용 네트워크 파일 공유에 저장해야 하지만, 실제로 구현하기는 어려울 수 있습니다. 전사 로그의 장점은 각 명령의 타임스탬프와 메타데이터를 포함하며, Mimikatz 실행 시 6KB 미만으로 매우 저장 효율적이라는 점입니다. 단점은 전사 로그가 PowerShell 터미널에 표시되는 내용만 기록한다는 것입니다.
그룹 정책 편집기에서 컴퓨터 구성 > 관리 템플릿 > Windows 구성 요소 > Windows PowerShell을 열고 PowerShell 전사 켜기를 활성화합니다.
그런 다음, 출력 디렉터리를 지정합니다.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)
### 참고 자료
* [Mandiant 블로그: PowerShell 로깅을 통한 가시성 향상](https://www.mandiant.com/resources/blog/greater-visibilityt)
## 시스템 로그 (시그마 규칙 55개)
파일: `System.evtx`
기본 설정: `Enabled. 20 MB`
권장 설정: `Enabled. 128 MB+`
악성코드는 종종 지속성, 로컬 권한 상승 등을 위해 서비스를 설치하며, 이 로그에서 해당 활동을 찾을 수 있습니다. 또한 다양한 취약점이 악용되는 것을 여기서 탐지할 수도 있습니다.
> **참고: System 로그와 관련해 주의할 점은 필드의 매개변수가 때때로 로컬 언어로 번역된다는 것입니다. 따라서 영어만 사용하는 시그니처는 비영어 시스템에서는 탐지하지 못할 수 있습니다. 예를 들어, 영어 시스템의 EID 7045 매개변수에는 `Enabled`로 기록되지만 일본어 시스템에서는 `有効`로 기록될 수 있습니다.**
> **참고: `Application` 로그와 마찬가지로 여러 공급자가 동일한 이벤트 ID에 기록하므로 채널뿐만 아니라 공급자 이름으로도 필터링해야 할 수 있습니다. 예를 들어 이벤트 ID `1`은 다양한 공급자가 서로 다른 이벤트에 사용합니다.**
중요한 이벤트 ID:
| Event ID | 설명 | 시그마 규칙 | Hayabusa 규칙 | 수준 | 비고 |
| :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | 시스템 절전/최대 절전 모드 | 0 | 아직 없음. | 정보 | 공급자: `Power-Troubleshooter` |
| 1 | 시스템 시간 변경 | 0 | 아직 없음. | 정보 | 공급자: `Kernel-General` |
| 12 | OS 시작 | 0 | 아직 없음. | 정보 | |
| 13 | OS 종료 | 0 | 아직 없음. | 정보 | |
| 16 | 레지스트리 하이브 액세스 기록 삭제 | 2 | 아직 없음. | 높음~치명적 | 패스워드 덤퍼는 SAM 레지스트리 키에서 패스워드 해시를 덤프한 후 액세스 기록을 지울 수 있습니다. 하지만 이는 정상적으로도 발생하므로 오탐(FP)을 필터링해야 합니다. |
| 55 | NTFS 파일 시스템 손상 | 1 | 없음 | 높음 | NTFS 취약점에 대한 공격을 탐지할 수 있습니다. |
| 104 | 시스템 이벤트 로그가 지워짐 | 1 | 있음 | 중간 | |
| 6005 | 이벤트 로그 서비스 시작됨 | 0 | 있음 | 정보 | |
| 6006 | 이벤트 로그 서비스 중지됨 | 0 | 있음 | 정보 | |
| 6008 | 예기치 않은 종료 | 0 | 있음 | 정보 | |
| 6038 | NTLMv1이 사용됨 | 1 | 없음 | 낮음 | |
| 7031 | 서비스 충돌 | 0 | 있음 | 낮음 | |
| 7034 | 서비스 충돌 | 0 | 있음 | 낮음 | |
| 7036 | 서비스 시작/중지 | 2 | 있음 | 정보~높음 | 누군가 Defender 등을 중지하는 것을 탐지하는 데 사용할 수 있습니다. |
| 7040 | 서비스 시작 유형 변경 | 0 | 있음 | 정보 | 공격자가 서비스를 비활성화했음을 나타낼 수 있습니다. |
| 7045 | 서비스 설치 | 37 | 있음 | 정보~치명적 | 악성코드가 자주 자신을 서비스로 설치하거나 서비스를 남용하므로 가장 중요한 시스템 이벤트 ID입니다. |
| 20001 | 새 PNP 장치 | 0 | 있음 | 정보~? | 수준은 USB 장치 허용 여부에 따라 달라집니다. 장치가 처음 연결된 때만 기록합니다. 비USB PNP 장치 이벤트는 매우 시끄럽기 때문에 필터링하는 것이 좋습니다. |
## 애플리케이션 로그 (시그마 규칙 16개)
이 로그는 대부분 노이즈이지만 여기서 몇 가지 중요한 증거를 찾을 수 있습니다.
일부 타사 안티바이러스 소프트웨어는 여기에 기록합니다.
Application 로그와 관련해 주의할 점은 공급업체마다 동일한 이벤트 ID를 다른 이벤트에 사용할 수 있으므로 이벤트 ID뿐만 아니라 공급자 이름으로도 필터링해야 한다는 것입니다.
파일: `Application.evtx`
기본 설정: `Enabled. 20 MB`
권장 설정: `Enabled. 128 MB+`
중요한 이벤트 ID:
| 이벤트 ID | 공급자 | 설명 | 시그마 규칙 | Hayabusa 규칙 | 수준 | 비고 |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | `Audit-CVE`, `Microsoft-Windows-Audit-CVE` | 알려진 취약점(CVE) 악용 시도 | 1 | 없음 | 치명적 | 사용자 모드 애플리케이션이 알려진 취약점 악용 시도 시 CveEventWrite API를 호출할 때 생성되는 이벤트를 탐지합니다. MS는 2020/01에 CVE-2020-0601(Windows CryptoAPI 취약점)부터 이 로그를 사용하기 시작했습니다. 안타깝게도 CVE가 이 로그에 기록되는 것은 약 그 정도가 유일합니다. |
| 325 | `ESENT` | ESE DB 생성 | 2 | 없음 | 정보~치명적 | 프로세스가 ESE 데이터베이스를 생성할 때 탐지합니다. 이것은 Exchange, AD, 인증서 서비스, SRUM 등 다양한 용도로 사용됩니다. 보안상 가장 중요한 ESE DB는 도메인 컨트롤러에 있는 모든 도메인 사용자의 패스워드 해시 파일인 NTDS.dit입니다. NTDS.dit 덤프를 탐지하는 두 가지 시그마 규칙이 있지만, 관리자가 백업을 위해 ntdsutil을 사용하거나 섀도 복사본이 생성되는 경우 오탐이 발생할 수 있습니다. |
| 326 | `ESENT` | ESE DB 연결 | 1 | 없음 | 정보~치명적 | NTDS.dit 액세스를 탐지할 수 있습니다. |
| 1000, 1001 | `Application Error`, `Windows Error Reporting` | 애플리케이션 오류 | 1 | 없음 | 정보~높음 | |
| 1034, 11724 | `MsiInstaller` | 애플리케이션 제거됨 | 1 | 없음 | 정보~낮음 | |
| 1040 | `MsiInstaller` | 애플리케이션 설치 | 1 | 없음 | 정보~중간 | |
| 33205 | `MSSQLSERVER` | SQL 감사 이벤트 | 6 | 없음 | 정보~높음 | MSSQL 백도어, SQL/명령 삽입 등을 탐지할 수 있습니다. |
## Windows Defender 운영 로그 (시그마 규칙 10개)
파일: `Microsoft-Windows-Windows Defender%4Operational.evtx`
기본 설정: `Enabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
Windows Defender 경고(모니터링에 중요)뿐만 아니라 제외 항목 추가, 변조 방지 비활성화, 기록 삭제 등도 탐지할 수 있습니다.
## Bits-Client 운영 로그 (시그마 규칙 6개)
파일: `Microsoft-Windows-Bits-Client%4Operational.evtx`
기본 설정: `Enabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
Bitsadmin.exe는 공격자가 악성코드 다운로드 및 실행에 남용하는 인기 있는 [lolbin](https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/)입니다.
이 로그에서 그 증거를 찾을 수 있지만, 주의해야 할 오탐이 많이 있을 것입니다.
## 방화벽 로그 (시그마 규칙 6개)
파일: `Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx`
기본 설정: `Enabled? 1 MB`
권장 설정: `Enabled. 256 MB+`
여기에서 방화벽 규칙이 추가/수정/삭제된 증거를 찾을 수 있습니다.
악성코드는 C2 서버와 통신할 수 있도록 방화벽 규칙을 추가하거나, 측면 이동을 위한 프록시 규칙을 추가하는 경우가 많습니다.
## NTLM 운영 로그 (시그마 규칙 3개)
파일: `Microsoft-Windows-NTLM%4Operational.evtx`
기본 설정: `Enabled but Auditing is disabled. 1 MB`
이 로그는 NTLM 인증을 비활성화하려는 경우 활성화하는 것이 좋습니다.
NTLM을 비활성화하면 일부 통신이 중단될 가능성이 높으므로 DC 및 기타 서버에서 이 로그를 모니터링하여 누가 여전히 NTLM을 사용하는지 확인하고, 전역적으로 비활성화하기 전에 해당 사용자부터 점진적으로 NTLM을 비활성화할 수 있습니다.
4624와 같은 로그온 이벤트에서 인바운드 연결에 NTLM이 사용되는 것을 탐지할 수 있지만, 아웃바운드 NTLM 연결을 만드는 사용자를 모니터링하려면 이 로그를 활성화해야 합니다.
감사를 활성화하려면 그룹 정책에서 `Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options`를 열고 적절한 다양한 `Network security: Restrict NTLM:` 설정을 구성합니다.
참조: [Farewell NTLM](https://www.scip.ch/en/?labs.20210909)
## Security-Mitigations KernelMode 및 UserMode 로그 (시그마 규칙 2개)
파일: `Microsoft-Windows-Security-Mitigations%4KernelMode.evtx`, `Microsoft-Windows-Security-Mitigations%4UserMode.evtx`
기본 설정: `Enabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
현재 이 로그들에 대한 시그마 규칙은 2개뿐이지만, Exploit Protection, Network Protection, Controlled Folder Access 및 Attack Surface Reduction 로그(약 40개 이상의 이벤트 ID)를 모두 수집하고 모니터링해야 합니다.
안타깝게도 Attack Surface Reduction 로그(이전의 WDEG(Windows Defender Exploit Guard) 및 EMET)는 여러 로그에 분산되어 있으며 검색하려면 복잡한 XML 쿼리가 필요합니다.
세부 정보: [공격 표면 감소 기능 이해 및 사용](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction?view=o365-worldwide)
## PrintService 로그 (시그마 규칙 2개)
Print Spooler 공격자를 탐지하려면 운영(Operational) 로그도 활성화하는 것이 좋습니다. (예: PrintNightmare 등)
### Admin (시그마 규칙 1개)
파일: `Microsoft-Windows-PrintService%4Admin.evtx`
기본 설정: `Enabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
### Operational (시그마 규칙 1개)
파일: `Microsoft-Windows-PrintService%4Operational.evtx`
기본 설정: `Disabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
## SMBClient 보안 로그 (시그마 규칙 2개)
파일: `Microsoft-Windows-SmbClient%4Security.evtx`
기본 설정: `Enabled. 8 MB`
권장 설정: `Enabled. 128 MB+`
PrintNightmare(의심스러운 IP에서 거부된 SMB 게스트 로그온)와 사용자가 숨겨진 공유를 마운트하는 것을 탐지하는 데 사용됩니다.
## AppLocker 로그 (시그마 규칙 1개)
파일: `Microsoft-Windows-AppLocker%4MSI and Script.evtx`, `Microsoft-Windows-AppLocker%4EXE and DLL.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx`
기본 설정: `Enabled if AppLocker is enabled? 1 MB`
권장 설정: `Enabled. 256 MB+`
AppLocker를 사용하는 경우 이 로그가 활성화되고 모니터링되도록 하는 것이 중요합니다.
## CodeIntegrity 운영 로그 (시그마 규칙 1개)
파일: `Microsoft-Windows-CodeIntegrity%4Operational.evtx`
기본 설정: `Enabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
Windows 코드 무결성 검사에 의해 차단된 드라이버 로드 이벤트를 탐지하려면 이 로그를 확인하세요. 로드에 실패한 악성 드라이버를 나타낼 수 있습니다.
## Diagnosis-Scripted 운영 로그 (시그마 규칙 1개)
파일: `Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx`
기본 설정: `Enabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
악용에 사용되는 diagcab 패키지의 증거를 여기에서 찾을 수 있습니다.
## DriverFrameworks-UserMode 운영 로그 (시그마 규칙 1개)
파일: `Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx`
기본 설정: `No Auditing. 1 MB`
권장 설정: `Enabled. 128 MB+`
연결된 USB 장치를 탐지합니다.
## WMI-Activity 운영 로그 (시그마 규칙 1개)
파일: `Microsoft-Windows-WMI-Activity%4Operational.evtx`
기본 설정: `Enabled on Win10/2016+. 1 MB`
권장 설정: `Enabled. 128 MB+`
공격자는 종종 지속성 및 측면 이동을 위해 WMI를 악용하므로 모니터링하는 것이 중요합니다.
## TerminalServices-LocalSessionManager 운영 로그 (시그마 규칙 1개)
파일: `Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`
기본 설정: `Enabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
역방향 프록시 도구인 ngrok가 방화벽을 우회하기 위해 트래픽을 로컬 RDP 포트로 전달할 때를 탐지합니다.
링크: [RDP 터널링을 통한 네트워크 제한 우회](https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling)
## TaskScheduler 운영 로그 (시그마 규칙 1개)
파일: `Microsoft-Windows-TaskScheduler%4Operational.evtx`
기본 설정: `Disabled. 1 MB`
권장 설정: `Enabled. 128 MB+`
공격자는 종종 지속성과 측면 이동을 위해 작업을 남용하므로 이 로그를 활성화해야 합니다.