브라우저 팝업으로 CMD나 PowerShell 실행을 유도하는 피싱 공격은 그룹 정책(GPO)에서 Execution Policy를 AllSigned 또는 Disabled로 명시하고, AppLocker로 실행 경로와 해시를 제한해 기술적으로 차단할 수 있다. 특히 Windows PowerShell 2.0 기능을 끄고 스크립트 블록 로깅을 활성화해 공격 시도를 실시간으로 감지하고 대응하는 체계를 구축하는 것이 핵심이다.
2023년부터 2025년까지 브라우저 팝업을 띄워 사용자가 직접 명령어를 복사해 CMD나 PowerShell에 입력하게 만드는 이른바 ClickFix 방식의 피싱 공격이 빈번하다. 이런 공격은 기존 악성코드 배포 방식과 달리 사용자의 능동적인 행위를 유도하므로 단순한 백신 프로그램만으로는 대응에 한계가 있다. 기업 보안 담당자는 엔드포인트 수준에서 스크립트 실행 권한을 엄격히 제한하고, 우회 경로를 미리 차단하는 하드닝(Hardening) 전략을 세워야 한다.
PowerShell 실행 제한 및 Execution Policy 설정 방법
Windows PowerShell의 실행 정책(Execution Policy)은 스크립트 실행 여부를 결정하는 중요한 보안 계층이다. 많은 관리자가 기본 설정인 Undefined(사실상 Restricted와 유사) 상태로 방치하곤 하는데, 이는 프로세스 레벨의 Bypass 옵션으로 쉽게 무력화된다. 2024년과 2025년 최신 보안 가이드라인에서는 그룹 정책의 MachinePolicy 및 UserPolicy를 사용해 실행 정책을 명시적으로 강제하라고 권고한다.
가장 강력한 방법은 실행 정책을 Disabled로 설정해 모든 스크립트 실행을 막는 것이지만, 업무 효율을 생각한다면 AllSigned 설정을 추천한다. AllSigned 정책을 적용하면 신뢰할 수 있는 게시자가 디지털 서명한 스크립트만 실행 가능하다. 덕분에 공격자가 배포한 임의의 .ps1 파일이나 명령줄 스크립트 실행을 원천적으로 막을 수 있다. 사용자가 팝업창 지시대로 명령어를 입력해도 서명되지 않은 스크립트는 실행 단계에서 거부되므로 매우 효과적인 방어 수단이 된다.
PowerShell 7(PowerShell Core) 환경에서는 그룹 정책 관리 체계가 기존 Windows PowerShell과 다르게 동작할 수 있다. 이를 해결하려면 그룹 정책 설정 내에서 “Use Windows PowerShell Policy Settings” 옵션을 체크해 통합 관리해야 한다. 이렇게 하면 MachinePolicy의 AllSigned 또는 Disabled 설정이 PowerShell 7 환경에도 동일하게 적용되어, 버전 간 보안 공백 없이 일관된 실행 제한 정책을 유지한다.
그룹 정책과 AppLocker를 활용한 엔드포인트 방어 설정
단순한 실행 정책 변경만으로는 부족하며, AppLocker 같은 애플리케이션 제어 솔루션을 병행해 하드닝을 적용해야 한다. AppLocker는 파일 경로, 게시자 서명, 파일 해시를 기반으로 실행 여부를 결정한다. 공격자가 PowerShell.exe 파일을 다른 경로로 복사하거나 이름을 바꿔 실행하려는 시도를 효과적으로 막는 원리다. 예를 들어 PowerShell.exe가 원래 설치된 시스템 경로에서만 실행되도록 규칙을 정의하고, 그 외 위치에서 실행되는 모든 인스턴스를 차단한다.
AppLocker를 적용할 때는 즉시 차단하기보다 감사(Audit Only) 모드를 먼저 사용하는 것이 실무적으로 중요하다. 감사 모드로 이벤트 뷰어 로그를 분석하면 조직 내에서 사용 중인 정상 스크립트와 프로그램 중 무엇이 차단 대상인지 미리 파악할 수 있다. 정상 업무 프로세스가 중단되는 손실을 최소화하고, 정교하게 다듬은 예외 규칙을 적용한 뒤 강제 적용(Enforce) 모드로 전환하는 단계적 접근이 필요하다.
또한, 도메인 환경의 사용자(Domain Users)가 임의로 PowerShell을 실행하지 못하도록 Windows Server 2022 등의 그룹 정책에서 직접 실행 권한을 거부할 수 있다. 기술적 숙련도가 낮은 사용자가 피싱 공격에 노출되었을 때, 시스템 수준에서 실행 진입점을 완전히 차단해 피해 가능성을 없애는 전략이다.
| 보안 설정 항목 | 설정 값/방법 | 기대 효과 | 비고 |
|---|---|---|---|
| Execution Policy | AllSigned / Disabled | 서명되지 않은 악성 스크립트 실행 차단 | MachinePolicy 적용 필수 |
| AppLocker | 경로 및 해시 기반 규칙 | PowerShell 파일 복사/이름 변경 실행 방지 | Audit 모드 선행 권장 |
| PowerShell 2.0 | 기능 해제 (Disable) | 하위 호환성 취약점을 이용한 우회 공격 차단 | Windows 기능 켜기/끄기 |
| Script Block Logging | 활성화 (Enabled) | 실행된 모든 명령어의 상세 로그 기록 | 이벤트 뷰어 모니터링 |
브라우저 피싱 유도 공격 실제 차단 사례와 로그 분석
2024년 보안 포럼과 실무 사례를 보면, 사용자가 브라우저 팝업 안내에 따라 악의적인 .ps1 스크립트를 실행하려 했을 때 AllSigned 정책과 AppLocker가 적용된 시스템에서는 즉각 차단되었다. 공격자는 주로 시스템 오류를 가장해 특정 명령어를 복사해 터미널에 붙여넣도록 유도하지만, 하드닝을 마친 엔드포인트에서는 권한 부족이나 서명되지 않은 스크립트라는 경고 메시지와 함께 프로세스가 종료된다.
이런 공격 시도를 사후 분석하고 대응하려면 “Turn on PowerShell Script Block Logging” 기능을 반드시 활성화해야 한다. 스크립트 블록 로깅은 난독화된 스크립트라도 실제 실행 단계에서 디코딩된 최종 명령어를 이벤트 로그에 기록한다. 보안 담당자는 이벤트 뷰어로 어떤 명령어가 입력됐는지, 어떤 외부 도메인에서 페이로드를 다운로드하려 했는지 상세히 추적할 수 있으며 이는 침해 사고 분석(Forensics)의 핵심 데이터가 된다.
실무적인 대응 프로세스는 다음과 같다.
- 브라우저 팝업을 통한 명령어 입력 유도 피싱 발생.
- 시스템의 Execution Policy(AllSigned)가 서명되지 않은 스크립트 실행을 거부.
- AppLocker 규칙이 비정상 경로에서의 PowerShell 실행 시도를 차단.
- Script Block Logging으로 실행 시도된 전체 명령어 텍스트가 이벤트 로그에 기록.
- 보안 담당자가 로그를 분석해 공격자의 C2 서버 주소를 식별하고 전사 차단 조치 수행.
PowerShell 7/2.0 및 Constrained Mode 주의사항과 대응
보안 강화 과정에서 간과하기 쉬운 부분이 하위 호환성 버전인 Windows PowerShell 2.0이다. PowerShell 2.0은 실행 정책 강제화 같은 최신 보안 기능을 우회할 수 있는 취약점이 많아, 공격자들이 하위 버전으로 실행 환경을 전환해 공격을 수행하곤 한다. 따라서 그룹 정책이나 Windows 기능 설정에서 PowerShell 2.0 기능을 완전히 해제하는 조치가 반드시 병행되어야 한다.
AppLocker로 스크립트를 제한하면 시스템이 자동으로 Constrained Language Mode(제한된 언어 모드)로 전환될 수 있다. 이 모드에서는 시스템 API 호출이나 특정 .NET 클래스 사용이 제한되어 보안성은 높아지지만, 로그상으로는 단순히 실행이 차단된 것처럼 보일 때가 있다. 일부 기본 명령어는 여전히 실행될 가능성이 있으므로, 이 모드에만 의존하지 말고 실행 정책 설정과 로깅 시스템을 다각도로 병행 운용해야 한다.
다만 지나치게 엄격한 정책은 정상적인 소프트웨어 설치나 시스템 관리 스크립트 작동을 방해해 편의성을 떨어뜨린다. 임시 폴더(\Temp)에서 실행되는 정상 설치 스크립트가 차단된다면, 해당 경로에 대해서만 한시적으로 예외 규칙을 적용하는 토글 방식을 활용하거나 내부적으로 검증된 서명 인증서를 배포해 AllSigned 정책에서도 정상 작동하도록 관리하는 체계가 필요하다.
최신 ClickFix 피싱 공격 같은 사용자 유도형 위협을 막으려면 단순한 주의 교육보다 시스템적인 강제 제어 장치가 필수적이다. 그룹 정책을 통한 Execution Policy 명시적 설정, AppLocker 실행 경로 제한, PowerShell 2.0 해제, 스크립트 블록 로깅 활성화라는 4가지 핵심 조치로 엔드포인트 보안을 강화하자. 지금 즉시 조직 내 Windows 터미널 권한 설정 상태를 점검하고, 감사 모드부터 단계적으로 보안 하드닝을 적용해 잠재적인 시스템 침해 사고를 예방하시기 바란다.