PagePowerShell Script Block Logging
(3) 스크립트 블록 로깅 활성화 시 로깅 차이
Last updated
Was this helpful?
(3) 스크립트 블록 로깅 활성화 시 로깅 차이
Last updated
Was this helpful?
Windows7 과 Windows10 환경에서 스크립트 블록 로깅 설정이 되어 있을 때와 설정이 되어 있지 않을 때, 다음 4가지 유형으로 난독화된 파워셸 명령문을 실행하고 각각 어떻게 로깅이 되는지 알아보도록 하겠다.
다이렉트로 명령어를 실행하는 경우
ps1 파일을 통해 실행하는 경우
명령 프롬프트를 통해 실행하는 경우
vbs 파일을 통해 실행하는 경우
Windows7 기반의 운영체제를 사용하면 기본적으로 파워셸에 대한 로그를 남기지 않는다. PSReadLine 폴더 자체가 존재하지 않기 때문에 텍스트 파일로 남는 로그는 기대하기 힘드므로 파워셸에 대한 로그를 확인하기 위해서는 스크립트 블록 로깅 설정을 활성화하는 것이 좋을 것이다.
스크립트 블록 로깅 설정을 바로 할 수 있으면 좋겠지만 몇 가지 제약사항이 존재한다. WMF 버전이 5.1 이상이 되어야 하며 .NET Framework 버전 또한 4.5.2 버전 이상을 만족해야 한다. 해당 환경 설정 관련은 마이크로소프트 문서에서 확인할 수 있다.
파워셸 버전이 만족되었다면 이전 게시글에서 진행한 것처럼 로컬 그룹 정책 편집기에서 스크립트 블록 로깅을 활성화하면 된다. 스크립트 블록 로깅에 대한 이벤트 로그 결과는 이벤트 뷰어 -> 응용 프로그램 및 서비스 로그 -> Microsoft -> Windows -> PowerShell -> Operational 에서 확인할 수 있다.
또는 다음 명령어를 입력하여 레지스트리에 값을 추가하여도 정상적으로 로깅이 된다.
reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging” /v “EnableScriptBlockLogging” /t REG_DWORD /d 1 /f
ConsoleHost_history.txt 로그 파일에는 난독화된 상태로 명령문이 로깅되어 있다.
파워셸에 다이렉트로 난독화된 명령문을 실행한 결과 40961, 40962 ID 이후 prompt 값을 가지는 4104 ID가 오고 난독화된 명령문이 로깅되었다. 이어서 40961, 40962 ID가 다시 기록되고 4104 ID를 가지는 복호화된 명령문이 로깅되었다.
파워셸에 다이렉트로 명령문을 실행했을 때 이벤트 로그가 남는 순서는 위와 같다.
파워셸을 실행했을 때 40961, 40962, 4104가 발생하면서 파워셸이 실행된 시각이 로깅된다. 이어서 난독화된 명령문을 입력하게 되면 4104 ID가 다시 한 번 발생하면서 난독화 된 명령문 그대로 로깅한다. 그 후 난독화된 명령문을 해독하는 과정에서 다시 한 번 40961, 40962 ID가 발생하게 되고, 복호화된 명령문을 4104 ID로 로깅한다. Windows10 운영체제의 경우 Windows7과 동일했다.
ps1 파일을 통해 난독화된 명령문을 실행하는 경우 40961, 40962 ID 이후 4104 ID로 난독화된 명령문이 로깅되어 있으며, 다시 한 번 40961, 40962 ID가 나오고 4104 ID로 복호화된 명령문이 로깅되어 있다. 난독화된 명령문과 함께 실행된 ps1 파일의 경로가 함께 로깅되는 것을 확인할 수 있다.
Windows10의 경우 Windows7과 동일한 결과를 확인할 수 있었으며, 그 외 ConsoleHost_history.txt 에서는 실행된 ps1의 명령문에 대한 로깅이 전혀 남지 않는 것을 확인했다.
명령 프롬프트를 통해 실행한 결과 Windows7, Windows10 모두 난독화된 명령문은 로깅이 되지 않았으며 40961, 40962 ID 뒤에 바로 복호화된 명령문이 4104 ID로 로깅된 것을 확인할 수 있다.
로깅 과정은 위와 같다. 명령 프롬프트에서 난독화된 파워셸 명령문을 실행한 결과 40961, 40962 ID가 발생한 뒤 복호화된 파워셸 명령문이 4104 ID로 로깅되었다. 파워셸을 실행한 시각은 명령 프롬프트 창에서 파워셸 명령문을 입력하는 시각과 동일하다. 그 외 ConsoleHost_history.txt 에서는 실행된 명령문에 대한 로깅이 전혀 남지 않는 것을 확인했다.
Windows7, Windows10 모두 난독화된 파워셸 명령문을 실행하는 vbs 파일을 실행한 결과 명령 프롬프트에서 수행한 결과와 동일한 결과를 볼 수 있다. 난독화된 명령문은 로깅이 되지 않았으며 40961, 40962 ID 뒤에 바로 복호화된 명령문이 4104 ID로 로깅된 것을 확인할 수 있다.
vbs 파일에서 명령 프롬프트를 통해 파워셸을 실행하는 것과 파워셸을 바로 실행하는 것에는 차이가 존재하지 않았다.
명령 프롬프트에서 난독화된 파워셸 명령문을 실행한 결과 40961, 40962 ID가 발생한 뒤 복호화된 파워셸 명령문이 4104 ID로 로깅되었다. 파워셸을 실행한 시각은 vbs파일을 실행하는 시각과 동일하다. 그 외 ConsoleHost_history.txt 에서는 실행된 명령 프롬프트 명령문에 대한 로깅이 전혀 남지 않는 것을 확인했다.
각 운영체제에서 난독화된 파워셸 스크립트가 어떻게 로깅되는지 연구한 결과는 아래 표와 같다. 두 운영체제 모두 큰 틀에서 봤을 때, 비슷한 결과를 확인할 수 있었다.
파워셸 스크립트 블록 로깅 설정을 활성화했을 때, 다이렉트로 명령어를 실행하거나 ps1 파일을 통해 실행하는 경우에는 난독화된 스크립트와 복호화된 스크립트가 모두 로깅이 되었다. 하지만 명령 프롬프트를 통해 실행하거나 vbs 파일을 통해 실행하는 경우에는 난독화된 스크립트가 로깅되지 않고 바로 복호화된 스크립트가 로깅되었다.
Windows10 환경에서 기본적으로 ConsoleHost_history.txt 파일에 파워셸 로깅을 남기지만, 공격자들이 주로 사용하는 공격 수단인 ps1, vbs 등 스크립트 파일을 실행하는 경우에는 로그가 남지 않는다. 따라서 Windows10 환경을 사용하더라도 파워셸 스크립트 블록 로깅 설정을 하는 것이 공격자의 행위를 명확하게 파악할 수 있는 방법이다. Windows7 환경에서는 기본적인 로깅도 지원해주지 않기 때문에 더욱 더 스크립트 블록 로깅 설정을 활성화하는 것이 사고 분석에 도움이 될 것이다.
