Threat Hunting - 센서와 클라우드

ThreatHunting은 이제 많은 기업 환경에서 필수적으로 수행해야 하는 디펜더로서의 활동이 되었습니다. 특히 최근 EDR (Endpoint Detection and Response) 제품군의 급부상과 함께 많은 관심을 받게 되었습니다. 많은 EDR 제품들은 이벤트와 로그를 클라우드의 스토리지로 수집하고 머신 러닝을 결합하여 알려지지 않은 위협들을 디텍션하는 것도 가능해집니다. 이번 아티클에서는 공개된 여러 도구들을 사용하여 EDR과 비슷한 형태의 디텍션 프레임워크를 구축하는 방법에 대해서 알아 보고, 한계와 해결 방법 등에 대해서 알아 보겠습니다.

Windows Event와 Sysmon

파워쉘 시큐리티 1 - 아티팩트 발굴과 분석에서 설명했듯이 윈도우즈에서는 유닉스 시스템의 syslog와 비슷한 메카니즘인 Windows Event System을 제공하고 있습니다. 많은 EDR 시스템은 이러한 이벤트 정보를 수집하여 분석하는 방식으로 작동합니다. PowerShell 이벤트나 DNS 이벤트와 같이 말웨어의 여러 행위들을 모니터링할 수 있는 여러 이벤트들이 존재합니다. 하지만, 기본적으로 제공되는 이벤트에는 파일, 프로세스나 WMI와 같은 행위들에 대한 모니터링이 매우 어려운 경우가 많습니다. 또한 여러 Windows Event들이 것은 보안을 위해서 만들어진 시스템이 아니라 시스템에 대한 일반적인 모니터링을 위해서 만들어진 경우가 많기 때문에 원하는 정보가 이벤트에서 빠져 있는 경우가 많습니다.

이러한 이유로 인해서 Sysmon이라는 툴을 추가로 설치해서 더 풍부한 이벤트를 컬렉션하는 경우가 많습니다. 물론 상용 EDR 시스템을 사용할 경우 해당 벤더에서 개발한 커스텀 센서를 사용하게 됩니다. 내부의 작동 원리는 대부분 sysmon과 비슷한 범주에 있는 경우가 많고, 거기에 추가적으로 조금더 세밀한 디텍션과 여러 공격 방법에 대한 더 세밀한 디텍션을 제공하는 경우가 많습니다. 특히, sysmon 자체가 EDR과 같은 효과를 내기 위해서 만들어진 것은 아니기 때문에 이벤트 correlation 등을 수행할 때에 많은 제약 사항이 있는 경우도 많습니다.

이벤트 컬렉션과 저장

이러한 Windows Event나 sysmon 등의 이벤트 소스로부터 이벤트를 컬렉셔하고 저장할 방법이 필요하게 됩니다. 상용 SIEM이나 EDR 벤더에서는 이러한 과정을 모두 처리해 주고, 자체적으로 클라우드 스토리지까지 해결해 주게 됩니다. 이러한 벤더를 사용하지 못할 경우 sysmon과 함께 winlogbeat을 사용하여 ElasticSearch로 이벤트를 수집할 수 있습니다.

ElasticSearch는 한 개발자가 여자친구의 요리 recipe들을 저장하기 위한 방법을 찾다가 만들었다는 다큐먼트 기반의 데이타 베이스입니다. 기존의 관계형 데이타베이스와는 다르게 미리 스키마를 지정할 필요가 없어서 굉장히 편리하게 사용할 수 있습니다. 또한 윈도우즈 이벤트 특성상 여러 필드와 데이타의 타입들이 굉장히 다양하기 때문에 기존의 관계형 데이타 베이스에 이러한 이벤트들을 저장하는 것은 굉장히 시간이 걸리고 비효율적인 작업이 됩니다. 그러한 측면에서 ElasticSearch는 Windows Event, Sysmon과 잘 맞는 형태의 데이타 베이스라고 볼 수 있습니다.

또한 ElasticSearch에서는 Kibana라는 훌륭한 웹 기반의 데이타 exploration 도구를 제공하고 있어서, 이벤트들을 시각적으로 빠르게 분석해 볼 수 있는 장점을 가지고 있습니다. ElasticSearch나 Kibana 모두 클라우드 서비스를 제공하고 있어서 자체적으로 매니지 하기 힘들 경우 그러한 서비스를 사용할 수도 있습니다.

오버뷰

이러한 전체적인 과정을 다이어그램으로 표현해 보면 다음과 같습니다.

Sysmon을 통해서 프로세스나 파일, 레지스트리 그리고 WMI 등의 보안상 유용한 많은 이벤트들이 수집되고, 또한 이러한 이벤트들은 winlogbeat이라는 이벤트 수집기를 통해서 ElasticSearch로 모아지게 됩니다. 이러한 데이타 베이스에 대해서 여러 쿼리나 툴, 아니면 Kibana라는 웹 UI를 통해서 Threat Hunting을 하는 것이 가능해집니다.

Sysmon의 문제

Sysmon의 경우에는 시스템의 여러 activity들을 모니터링 하기 때문에 너무 많은 이벤트들이 쓸데 없이 수집되는 경향성을 가집니다. 결국 각자의 네트워크의 상황에 맞추어 이러한 이벤트들을 필터링해야 하는 과정이 필요합니다. 상용 벤더의 경우 이러한 작업이 이미 이루어져 있거나 고객의 환경에 맞추어 천천히 커스터마이징하는 과정을 거칩니다.

Sysmon의 경우 XML 형태의 설정 파일에서 다음과 같이 특정한 조건을 주어 이벤트를 exclude하거나 include할 수 있습니다.

<Image condition="is">C:\Windows\system32\SppExtComObj.Exe</Image> <!--Microsoft:Windows: KMS activation-->

다음은 특정 커맨드 특히 프로그램등이 크래쉬 되었을 경우 발생하는 에러 리포트 커맨드라인을 필터링하는 예제입니다.

<CommandLine condition="is">C:\WINDOWS\system32\wermgr.exe -upload</CommandLine> <!--Microsoft:Windows:Windows error reporting/telemetry-->

sysmon에 -c 옵션을 통해서 현재의 설정을 리스팅해서 볼수도 있습니다. 아래의 예제의 경우에는 특정한 벤더에서 제공하는 DLL의 로딩 이벤트를 모두 exlucde한 경우입니다. 이 경우 악성 코드에 의해서 로딩 되는 DLL 등을 더 효과적으로 찾는데에 도움이 될 수 있습니다.

PS C:\Users\Administrator\Sysmon> sysmon -c


System Monitor v8.04 - System activity monitor
Copyright (C) 2014-2018 Mark Russinovich and Thomas Garnier
Sysinternals - www.sysinternals.com

Current configuration:
 - Service name:                  Sysmon
 - Driver name:                   SysmonDrv
 - HashingAlgorithms:             MD5,SHA256
 - Network connection:            enabled
 - Image loading:                 enabled
 - CRL checking:                  enabled
 - Process Access:                disabled
...
 - ImageLoad                          onmatch: exclude
        Signature                      filter: is           value: 'Microsoft Windows'
        Signature                      filter: is           value: 'Johannes Schindelin'
        Signature                      filter: is           value: 'Microsoft Corporation'
        Signature                      filter: is           value: 'Google LLC'
        Signature                      filter: is           value: 'Microsoft Windows Hardware Compatibility Publisher'
        Signature                      filter: is           value: 'AhnLab, Inc.'
        Signature                      filter: is           value: 'Microsoft Windows Publisher'
        Signature                      filter: is           value: 'NVIDIA Corporation'
        Signature                      filter: is           value: 'Google Inc'
        Signature                      filter: is           value: 'Windows Phone'

Threat Hunting

Threat Hunting은 여러 도구를 사용하여 다양한 방법으로 시행될 수 있습니다. ElasticSearch를 사용하는 경우 가장 손쉽게 접근할 수 있는 방법은 Kibana를 활용하는 것입니다. Kibana는 손쉽게 설정이 가능하고, ElasticSearch에 바로 접속하여 데이타를 뽑아 와서 데이타를 브라우징하고 비쥬얼라이즈할 수 있는 기능을 제공합니다.

예를 들어 다음과 같이 winlogbeat-* 인덱스를 통해서 winlog.channel의 일정 기간 동안의 여러 이벤트들의 카운트를 비쥬얼라이즈 한 화면입니다. 이를 통해서 시각적으로 주로 어떠한 이벤트들이 많이 발생하고 있는지 파악할 수 있으며, 예를 들어 어떠한 이벤트들을 추가로 필터링하고 스토리지를 절약할지 등에 대한 인사이트도 얻을 수 있습니다.

다음은 KQL 필터와 함께 여러 필드 필터를 달아서 파워쉘 이벤트들을 찾는 과정을 보여 주고 있습니다. 여러 필터를 적용함으로써, 쓸모 없는 이벤트들을 뷰에서 제거하고, KQL을 통해서 예를 들어 “.exe”와 같은 문자열이 나타난 파워쉘 이벤트를 나열하고 있습니다.

이렇게 헌팅된 여러 이벤트들을 조사하는 과정에서 다음과 같이 손쉽게 악성 파워쉘 이벤트등을 검색하는 것이 가능합니다.

이러한 필터 등은 모두 저장해 놓고 나중에 다시 꺼내어 사용 가능합니다. 이러한 수동적인 헌팅은 때때로 예상하지 못한 여러 위협들을 발견하는데에 많은 도움을 줍니다.

자동화

실제 상용 EDR 제품에서는 Kibana와 비슷한 형태의 UI나 KQL과 비슷한 형태의 쿼리 랭귀지를 제공하거나 아예 API를 노출 시켜서 쿼리를 가능하게 해줍니다. 많은 경우 이러한 로직들은 사용자가 접근할 수 없는 경우도 대부분이지만, 백엔드에서는 API를 사용한 디텍션 로직 작성과 의심스러운 이벤트 쿼리가 정기적으로 이뤄지는 것이 보통입니다.

ElasticSearch도 이러한 것이 가능한데, 예를 들어 파이썬의 Python Elasticsearch Client를 사용하여 여러 헌팅, 디텍션 로직 작성이 가능해집니다. 다른그림에서 제공하는 threathuntingtool 라이브러리는 Python Elastic Client 라이브러리를 이용하여 여러 헌팅 로직들을 미리 작성해 놓은 툴입니다.

예를 들어 파워쉘 헌팅과 관련된 로직들은 threathunting/powershell.py 코드에 존재합니다. 또한 평면적인 이벤트들을 재조합하여 컨텍스트를 부여하는 기능 또한 가지고 있습니다. 예를 들어 다음의 코드는 개개의 스크립트 블락들을 재조합하여 머신 러닝이나 휴리스틱 룰들이 처리할 수 있는 형태의 의미 있는 텍스트를 만들어 주는 코드의 일부분입니다.

class ScriptProcessor:

...

    def construct_script_block(self, hit):
        message_total = int(hit.winlog.event_data.MessageTotal)
        message_number = int(hit.winlog.event_data.MessageNumber) - 1

        print('ScriptBlockId: %s (%s/%s)' % (hit.winlog.event_data.ScriptBlockId, message_number, message_total))
        if not hit.winlog.event_data.ScriptBlockId in self.ScriptBlocks:
            self.ScriptBlocks[hit.winlog.event_data.ScriptBlockId] = Script(hit.winlog.event_data.ScriptBlockId, message_total)

        self.ScriptBlocks[hit.winlog.event_data.ScriptBlockId].add_message(message_number, hit.winlog.event_data.ScriptBlockText

또한 약간의 휴리스틱 디텍션 기능도 가지고 있어서, 이를 사용한 파워쉘 말웨어 디텍션 모델등의 작성에 도움을 줍니다.

class Detector:
    HeuristicRules = [
        {
            'Name': 'Download-DecoyDocx', 
            'Patterns': 
                [r'DownloadFile.*\(.*.docx\)'], 
            'Debug': True
        }, 
        {
            'Name': 'Shellcode', 
            'Patterns': 
                ['Invoke-Shellcode'], 
            'Debug': False
        }, 
        {
            'Name': 'Shellcode-Run', 
            'Patterns': 
                ['kernel32.*VirtualAlloc', 'kernel32.*CreateThread'], 
            'Debug': False
        }, 
        ...

결론

Threat Hunting은 최근 SOC에 있어서 필수적인 요소로 자리 잡았습니다. SIEM과 같은 전통적인 보안 요소들을 사용하는 것이 대부분이지만, 점점 더 많은 엔터프라이즈 환경들이 EDR 환경으로 넘어 가고 있습니다. 하지만 고가의 EDR 환경을 도입할 수 있는 여력이 없는 경우 이미 공개된 툴들을 사용하여 상용 EDR에 미치지는 못하지만, 어느 정도의 비슷한 효과를 거둘수 있습니다. 많은 상용 EDR의 경우에도 현재 발전하는 공격자의 공격 기술들을 따라 가는 입장으로서 완벽하다고 볼수는 없습니다. 다만, 엔드포인트에 대한 가시성 확보 차원에서 최소한의 센서 설치와 이벤트 중앙화, 그리고 그에 대한 머신 러닝과 휴리스틱 디텍션 정책 수립등은 EDR의 도입 여부와 상관 없이 엔터프라이즈 보안을 위한 필수 요소로 자리 잡아 가고 있습니다. 이번 아티클을 통해서 Sysmon, Winlogbeat, ElasticSearch와 같은 공개된 도구로 텔레메트리 수집과 그에 대한 분석에 대해서 개괄적으로 알아 보았습니다.

트레이닝 정보

다른그림은 Threat 인텔리젼스와 지식 제공 회사로서 다음과 같은 Threat Hunting과 관련된 트레이닝을 제공합니다. 많은 관심과 참여 바랍니다.

윈도우즈 파워쉘 보안과 악성 코드 분석
Malware Detection With Machine Learning
Threat Hunting + Threat Intelligence - hunting for APT threats using telemetry mining and real world APT cases (jeongoh@darungrim 문의)

Twitter Facebook LinkedIn