![[보안] YARA 규칙 활용한 악성코드 분석: 실제 사례와 작성 팁](https://blog.pswq.net/wp-content/uploads/2026/07/yara-malware-analysis-case-study-tips-thumbnail.jpg)
목차
- YARA 규칙이 아직도 중요한 이유
- YARA 규칙 작성, 어디서부터 시작하면 되나
- 기본 구조는 이렇게 봐두시면 됩니다
- 실제 사례로 보는 YARA 악성코드 탐지 흐름
- 1. 문자열 후보 추출
- 2. 첫 번째 초안 규칙 작성
- 3. 규칙 테스트
- 4. Python으로 자동화하기
- YARA 규칙 작성 시 자주 부딪히는 문제
- ⚠️ 제가 직접 겪은 트러블슈팅 4가지
- 1. API 이름만 넣었다가 오탐 폭발
- 2. wide 옵션을 빼먹어서 탐지 실패
- 3. 파일 크기 조건을 안 걸어서 잡음 증가
- 4. 정상 파일 기준선이 없어서 규칙 품질 판단 실패
- 검증 단계에서 꼭 보는 체크리스트
- 검증 결과 예시 정리
- 디지털 포렌식과 위협 헌팅에서의 활용 팁
- 정리: 좋은 YARA 규칙은 화려하지 않고 오래 버팁니다
- 자주 묻는 질문
- YARA만으로 악성코드 탐지가 충분한가요?
- 정규식만 잘 쓰면 되나요?
- 초보자는 어디서 가장 많이 실수하나요?
- 운영 환경에 바로 넣어도 될까요?
[보안] YARA 규칙 활용한 악성코드 분석: 실제 사례와 작성 팁
악성 샘플이 쏟아지는 환경에서 YARA 규칙 기반 탐지는 여전히 가장 강력한 도구입니다. 시그니처(signature, 특정 패턴 식별 정보) 기반이라고 하면 좀 올드하게 들릴 수 있지만, 현장에서는 아직도 엄청 중요하거든요. 특히 위협 헌팅(threat hunting, 위협 추적)이나 디지털 포렌식(digital forensics, 디지털 증거 분석) 단계에서 파일 묶음을 빠르게 훑어야 할 때, YARA 규칙 하나 잘 써두면 시간을 꽤 아낄 수 있습니다. 저도 처음엔 정규식 몇 개 넣으면 끝나는 줄 알았는데, 오탐(false positive, 정상 파일을 악성으로 잘못 판단) 때문에 삽질 좀 했습니다. 근데 몇 번 제대로 부딪혀 보니까, 규칙을 어떻게 나눠 쓰고 어떤 문자열을 고르느냐에 따라 결과가 완전히 달라지더라고요.
이번 글에서는 YARA 규칙 작성부터 실제 사례 기반의 악성코드 탐지 흐름, 그리고 제가 직접 해보며 겪었던 트러블슈팅까지 정리해보겠습니다. 너무 이론적으로만 가지 않고, 실무에서 바로 써먹기 좋게 풀어볼게요.
수집한 샘플, YARA 규칙, 분석 시스템, 결과 검증 흐름을 한눈에 보여주는 개요 이미지입니다.
YARA 규칙이 아직도 중요한 이유
쉽게 말해 YARA는 파일 안에서 우리가 찾고 싶은 흔적을 규칙으로 정의해서 걸러내는 도구입니다. 안티바이러스처럼 모든 걸 알아서 해주는 도구는 아니지만, 분석가가 의도를 담아 탐지 포인트를 직접 설계할 수 있다는 게 핵심이죠.
- 위협 헌팅에서 대량 파일 스캔이 빠릅니다.
- 디지털 포렌식에서 의심 파일의 공통 패턴을 추려내기 좋습니다.
- IOC(Indicator of Compromise, 침해 지표) 수준을 넘어서 문자열, 바이트 패턴, 조건식을 함께 쓸 수 있습니다.
- 샘플 간 유사도를 빠르게 보는 1차 필터로 유용합니다.
현장에서 중요한 건 완벽한 자동화보다 재현 가능한 규칙입니다. 예를 들어 악성코드 패밀리(family, 계열)가 바뀌어도 공통으로 남는 문자열, 뮤텍스 이름(mutex name, 중복 실행 방지용 이름), C2 관련 흔적, 패커(packer, 실행 파일 압축 도구) 특성 같은 걸 잘 잡으면 꽤 오래 써먹을 수 있습니다.
YARA 규칙 작성, 어디서부터 시작하면 되나
YARA 규칙 작성은 문법보다도 무엇을 고를지가 더 어렵습니다. 저도 처음엔 눈에 띄는 문자열을 마구 넣었었는데, 정상 프로그램에도 흔한 API 이름만 잔뜩 들어가 있으면 오탐이 많이 나더라고요. 그래서 보통은 아래 순서로 접근합니다.
- 샘플 여러 개에서 반복되는 문자열을 찾습니다.
- 너무 일반적인 문자열은 제외합니다.
- 문자열(string)과 조건(condition)을 분리해서 생각합니다.
- 파일 크기, 헤더, 섹션 특성 같은 보조 조건을 붙입니다.
- 정상 파일 세트에도 반드시 테스트합니다.
기본 구조는 이렇게 봐두시면 됩니다
rule Suspicious_Downloader_Generic
{
meta:
author = "13년차의 서버실"
description = "Generic downloader pattern example"
scope = "malware triage"
strings:
$s1 = "User-Agent" ascii wide
$s2 = "http://" ascii
$s3 = "https://" ascii
$s4 = "cmd.exe /c" ascii wide
$mz = { 4D 5A }
condition:
$mz at 0 and 2 of ($s*)
}이 규칙은 아주 단순한 예시입니다. 실제로 써보니까 여기서 중요한 건 문자열 조합과 조건의 균형이더라고요. 단일 문자열 하나만 믿으면 약하고, 반대로 조건을 너무 빡빡하게 잡으면 놓치는 악성코드가 많아집니다.
실제 사례로 보는 YARA 악성코드 탐지 흐름
제가 홈랩에서 테스트할 때 자주 쓰는 방식은 이렇습니다. 공개 분석용 샘플이 있거나, 내부 교육용으로 만든 모의 샘플이 있을 때 먼저 문자열을 추출하고, 거기서 반복 패턴을 뽑아 규칙을 만듭니다. 처음엔 이게 뭔가 싶었는데, 막상 몇 번 해보면 흐름이 꽤 단순합니다.
1. 문자열 후보 추출
strings suspicious_sample.bin | less
strings suspicious_sample.bin | grep -Ei "http|powershell|cmd.exe|User-Agent|mutex"
xxd suspicious_sample.bin | less여기서 바로 규칙으로 만들지 않고, 여러 샘플에서 반복되는 후보만 남깁니다. 한 개 샘플에만 있는 임시 문자열은 오히려 방해가 되는 경우가 많았습니다.
2. 첫 번째 초안 규칙 작성
rule Case_Study_Downloader_Family
{
meta:
description = "Case-study style downloader family selector"
analyst = "13년차의 서버실"
strings:
$a1 = "powershell -enc" ascii wide nocase
$a2 = "Software\\Microsoft\\Windows\\CurrentVersion\\Run" ascii wide
$a3 = "User-Agent:" ascii wide
$a4 = "cmd.exe /c" ascii wide
$a5 = "%TEMP%" ascii wide
$b1 = { 50 45 00 00 }
condition:
$b1 and 3 of ($a*)
}여기서 3 of ($a*) 같은 조건이 실전에서 꽤 유용합니다. 패밀리 변종마다 일부 문자열은 빠질 수 있거든요. 전부 일치해야 한다고 걸어두면 놓치는 악성코드가 많았습니다.
문자열 추출, 후보 정리, 규칙 초안 작성, 샘플/정상 파일 검증 순서를 보여주는 이미지입니다.
3. 규칙 테스트
yara case_study_downloader.yar suspicious_sample.bin
yara -r case_study_downloader.yar ./samples/
yara -r case_study_downloader.yar ./benign_files/여기서 중요한 포인트! 악성 샘플만 테스트하면 반쪽짜리 검증입니다. 정상 파일 세트에 같이 돌려봐야 합니다. 저도 예전에 악성 샘플에서만 잘 맞는다고 좋아했다가, 운영 서버의 관리 스크립트까지 잡아내는 바람에 식겁했었거든요.
4. Python으로 자동화하기
파일 수가 많아지면 수동 실행이 금방 귀찮아집니다. 이럴 때는 yara-python 같은 바인딩(binding, 언어 연동 라이브러리)을 써서 자동화하는 편이 낫습니다.
import os
import yara
rules = yara.compile(filepath="case_study_downloader.yar")
scan_root = "./samples"
for root, _, files in os.walk(scan_root):
for name in files:
path = os.path.join(root, name)
try:
matches = rules.match(path)
if matches:
print(f"MATCH: {path} -> {[m.rule for m in matches]}")
except Exception as exc:
print(f"ERROR: {path} -> {exc}")실제로 써보니까 이 방식이 편하더라고요. 결과를 JSON으로 떨구거나, 해시(hash, 파일 고유값)와 함께 저장해서 후속 분석으로 넘기기 좋습니다.
YARA 규칙 작성 시 자주 부딪히는 문제
규칙을 조금만 늘리면 금방 현실적인 문제가 생깁니다. 특히 위협 헌팅 환경에서는 성능과 오탐 관리가 핵심입니다.
| 문제 | 원인 | 제가 주로 쓰는 해결 방법 |
|---|---|---|
| 오탐이 많음 | 너무 일반적인 문자열 사용 | 파일 경로, 레지스트리, 실행 인자 조합으로 조건 강화 |
| 탐지를 놓침 | 조건이 너무 엄격함 | all of 대신 n of 패턴으로 완화 |
| 성능 저하 | 짧고 흔한 문자열 과다 사용 | 의미 있는 긴 문자열 위주로 정리 |
| 변종 대응이 약함 | 고정 문자열만 사용 | wide, ascii, nocase와 조합 조건 활용 |
| 분석 재현이 어려움 | 메타 정보 부족 | meta에 분석 목적과 범위 기록 |
⚠️ 제가 직접 겪은 트러블슈팅 4가지
이 섹션은 진짜 경험 기반으로 적어보겠습니다. 이런 건 문법 문서만 봐서는 감이 잘 안 옵니다.
1. API 이름만 넣었다가 오탐 폭발
CreateProcess, VirtualAlloc 같은 API 이름은 악성코드에서도 많이 보이지만 정상 프로그램에도 흔합니다. 처음엔 이걸 넣고 탐지율이 좋아진 줄 알았는데, 정상 유틸리티까지 줄줄이 걸리더라고요. 그 뒤로는 API 이름 단독 사용을 거의 안 합니다.
2. wide 옵션을 빼먹어서 탐지 실패
윈도우 계열 샘플은 UTF-16LE 형태 문자열이 많아서 wide 옵션을 빼먹으면 생각보다 많이 놓칩니다. 저도 한참 규칙이 안 맞아서 샘플을 다시 뜯어봤더니 문자열 인코딩 때문이었습니다. 드디어 됐다! 싶었던 순간이었네요.
3. 파일 크기 조건을 안 걸어서 잡음 증가
특정 계열이 유난히 작은 드로퍼(dropper, 추가 악성 파일을 떨어뜨리는 파일)였다면 filesize 조건이 꽤 유효합니다. 물론 절대적인 기준은 아니지만, 보조 필터로는 좋습니다.
condition:
uint16(0) == 0x5A4D and filesize < 500KB and 2 of them4. 정상 파일 기준선이 없어서 규칙 품질 판단 실패
이건 의외로 많이 놓칩니다. 악성코드 탐지는 결국 비교 문제거든요. 정상 샘플 집합이 없으면 규칙이 좋은지 나쁜지 판단이 안 됩니다. 그래서 저는 테스트할 때 최소한 아래 두 묶음은 따로 둡니다.
- 의심 샘플 디렉터리
- 정상 유틸리티, 스크립트, 설치 파일 디렉터리
탐지 결과를 정탐, 오탐, 미탐으로 나눠 검토하는 장면을 보여주는 이미지입니다.
검증 단계에서 꼭 보는 체크리스트
YARA 규칙 검증은 단순히 맞는지 틀렸는지로 끝나지 않습니다. 얼마나 재현 가능하고, 팀이 같이 써도 이해 가능한지가 중요합니다.
- 악성 샘플에서 반복 일치하는가
- 정상 파일에서 오탐이 과도하지 않은가
- 규칙 이름(rule name)이 목적을 설명하는가
- meta 정보에 작성자와 설명이 있는가
- 문자열 선택 이유를 나중에 설명할 수 있는가
여기서 중요한 건 성능도 같이 보는 겁니다. 위협 헌팅에 바로 넣을 규칙이라면, 테스트 환경에서만 괜찮고 실제 파일 서버나 증적 저장소에서는 느린 규칙이 있을 수 있거든요. 저는 그래서 초안 규칙, 검증 통과 규칙, 운영 적용 규칙을 분리해두는 편입니다.
검증 결과 예시 정리
[+] malicious set: matched expected family samples
[+] benign set: no matches on baseline utilities
[!] one admin script matched during first test
[+] final rule tuned after removing generic string이런 식으로 남겨두면 나중에 규칙 수정할 때 맥락을 잃지 않습니다. 생각보다 이 기록이 큰 차이를 만듭니다.
디지털 포렌식과 위협 헌팅에서의 활용 팁
YARA 규칙 작성은 악성코드 분석가만의 영역은 아닙니다. 인프라 엔지니어, 보안 운영 담당자도 충분히 활용할 수 있습니다. 특히 디지털 포렌식 단계에서는 압수 이미지나 추출 파일 묶음에서 의심 흔적을 1차로 좁히는 데 좋고, 위협 헌팅 단계에서는 특정 행위 패턴이 남긴 파일 산출물을 찾는 데 도움이 됩니다.
- 침해사고 이후 수집한 파일 묶음에서 공통 산출물 찾기
- 메일 첨부파일 보관소에서 유사 샘플 선별하기
- 샌드박스(sandbox, 격리 분석 환경) 산출물 재분류하기
- 기존 IOC 탐지에서 놓친 변종 후보 찾기
혹시 이런 경험 있으신가요? 백신은 조용한데 뭔가 찜찜한 파일이 계속 보이는 상황 말입니다. 그럴 때 YARA 규칙은 정말 손에 익혀둘 가치가 있습니다.
정리: 좋은 YARA 규칙은 화려하지 않고 오래 버팁니다
결국 YARA 악성코드 분석의 핵심은 복잡한 문법이 아니라 근거 있는 문자열 선택과 검증 습관입니다. 제가 직접 해보니, 처음엔 멋있어 보이는 규칙보다 단순하지만 설명 가능한 규칙이 훨씬 오래 살아남더라고요. 최신 악성코드 탐지라고 해서 무조건 거대한 자동화부터 갈 필요는 없습니다. 오히려 기본적인 YARA 규칙 작성 흐름을 제대로 잡아두면, 나중에 다른 탐지 체계와 연결하기도 수월합니다.
다음 글에서는 YARA 규칙을 파일 해시 기반 분류와 어떻게 같이 쓰면 좋은지, 그리고 샌드박스 결과와 연결하는 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 기반 이상 징후 분석과도 연결해보시면 흐름이 잘 보이실 겁니다.
좋은 규칙의 조건, 검증 순서, 오탐 줄이는 팁을 한 장으로 요약한 이미지입니다.
자주 묻는 질문
YARA만으로 악성코드 탐지가 충분한가요?
아닙니다. YARA는 매우 유용한 필터이지만, 동적 분석(dynamic analysis, 실행 기반 분석)이나 로그 분석과 함께 써야 맥락이 보입니다. 저는 보통 1차 선별용으로 먼저 돌립니다.
정규식만 잘 쓰면 되나요?
정규식도 도움이 되지만, 실전에서는 문자열, 바이트 패턴, 조건식 조합이 더 중요합니다. 정규식 하나로 해결하려고 하면 오히려 복잡해지는 경우가 많습니다.
초보자는 어디서 가장 많이 실수하나요?
대부분 일반적인 문자열을 너무 많이 넣는 것, 그리고 정상 파일 검증을 생략하는 것에서 시작합니다. 저도 딱 그랬습니다.
운영 환경에 바로 넣어도 될까요?
테스트 없이 바로 넣는 건 권하지 않습니다. 최소한 악성 샘플 세트와 정상 파일 세트에서 검증하고, 성능도 확인한 뒤 단계적으로 적용하는 게 안전합니다.
![[보안] Wireshark로 악성 트래픽 탐지: 네트워크 포렌식 기법](https://blog.pswq.net/wp-content/uploads/2026/06/wireshark-malicious-traffic-analysis-thumbnail.jpg)
