세미프로젝트2_03_노이즈 필터와 그 너머

GitHub: CAPE-Intelligent-Noise-Filter

노이즈 필터

CAPE로 악성코드를 분석하면 report.json이 나온다. 문제는 이 안에 윈도우 OS 기본 동작이 너무 많이 섞여 있다는 점이었다. 텔레메트리 통신, 언어팩 로딩, 가상환경 기본 이벤트 같은 것들 말이다. 실제 악성 행위를 보려면 결국 이 잡음부터 걷어내야 한다. 분석가가 이걸 수동으로 하나씩 분류하는 건 너무 비효율적이라는 생각이 들었다.

그래서 노이즈를 걸러내는 레이어를 만들기로 했다. CAPE의 Processing 단계에서 동작하는 전처리 모듈이다. 필터링 대상은 레지스트리 읽기, 쓰기, 삭제, 파일 읽기, 쓰기, 삭제, 뮤텍스, 실행 명령어 같은 behavior 계열과 도메인, 호스트, HTTP 같은 network 계열을 합쳐 총 11개 카테고리로 잡았다.

설계할 때 가장 신경 쓴 건 필터링한 데이터를 그냥 지워버리면 안 된다는 점이었다. 오탐이면 어떡할까. 필터가 진짜 악성 행위를 같이 먹어버리면 어떡할까. 이런 걱정이 있었다. 그래서 삭제 대신 격리 방식을 택했다. report.json 안에 filtered_artifacts라는 별도 영역을 만들어 옮기도록 했다. 원본은 건드리지 않으니 언제든 다시 확인할 수 있다.

자동 베이스라인

노이즈를 걸러내려면 먼저 "무엇이 정상인가"를 알아야 한다. 화이트리스트를 수동으로 하나씩 등록하는 건 비현실적이라 이 부분도 자동화하는 스크립트를 따로 만들었다.

원리는 단순하다. 아무 악성코드도 넣지 않은 빈 VM을 돌리면 순수하게 윈도우만 동작한 결과가 나온다. 이 결과를 그대로 화이트리스트에 등록하면 수천 개 수준의 정상 행위 룰을 한 번에 만들 수 있다. 환경마다 정상 행위가 조금씩 다르기 때문에 이 과정이 특히 중요하다.

필터가 실제로 잘 작동하는지 검증도 필요했다. 그래서 필터 적용 전후의 아티팩트 수를 비교하는 스크립트도 만들었다. 긴 로그를 전부 눈으로 비교하긴 어려우니 최소한 진짜 악성 행위는 살아 있고 잡음만 줄었는지 확인할 수 있는 장치를 마련한 셈이다.

여기까지가 내 지분

운영 문서까지 포함해 README와 RUNBOOK도 정리했다. 설치 절차와 장애 대응, 롤백 절차를 한 번에 볼 수 있게 묶었다. 일단 이 단계에서는 여기까지로 마무리했다.

이걸 만들고 나니 오히려 뒤에 붙일 아이디어가 더 많이 떠올랐다. 노이즈 필터는 기반 공사에 가까워서 그 위에 올릴 수 있는 게 꽤 많다. IOC 정제 파이프라인이나 환경별 교차 비교 분석 같은 것들이다. 지금 당장은 아니더라도 나중에 하나씩 붙여볼 만하다고 느꼈다.

오픈소스와 모듈형 구조

CAPE를 쓰면서 특히 인상적이었던 건 모듈형 구조였다. Processing, Reporting, Signature 같은 단계가 분리되어 있다. 내가 만든 필터도 Processing 클래스를 상속받아 적절한 위치에 끼워 넣기만 하면 됐다. 원래 CAPE 흐름대로 데이터를 파싱한 뒤 바로 다음 단계에서 내 필터가 동작하는 구조라 기존 코드를 크게 건드릴 필요도 없었다.

이번에 다시 느낀 건 오픈소스의 장점이 단순히 코드를 볼 수 있다는 데만 있지 않다는 점이다. 잘 만들어진 오픈소스는 구조 자체가 확장을 전제로 설계돼 있다. 새 기능을 붙이고 싶으면 정해진 인터페이스에 맞춰 모듈만 만들면 된다. 이 감각은 나중에 뭘 만들든 계속 가져가야 할 것 같다. 운영의 맥락과 확장성을 같이 보는 습관을 더 의식적으로 가져가보자.