IOC(Indicator of Compromise)는 침해당했는지를 알려 주는 단서입니다. 의미와 종류, 활용법, 그리고 과신하지 말아야 할 이유까지 — 모두 방어 관점에서 살펴봅니다(공격 절차는 다루지 않습니다).
IOC의 주요 종류
"흔적이 어디에 남느냐"에 따라 넷으로 나뉩니다.
| 종류 | 예 | 어디서 대조하는가 |
|---|---|---|
| 네트워크 | 공격자 서버 IP/도메인, C2 URL | 방화벽 / 프록시 / DNS 로그 |
| 파일 | 악성코드 SHA-256 해시, 특징적 파일명 | EDR / 안티바이러스 / 파일 목록 |
| 호스트 | 의심스러운 레지스트리 키, 낯선 상주 프로세스 | OS 로그, 프로세스 목록 |
| 행위 | 이상한 시각/국가의 로그인, 갑작스러운 대량 트래픽 | 인증 로그, 트래픽 모니터링 |
IOC vs IOA — "흔적" vs "행위"
흔히 대비되는 것이 **IOA(Indicator of Attack)**입니다. 그 차이는 IOC의 강점과 약점을 동시에 보여줍니다.
IOC(Indicator of Compromise) = 결과의 흔적
- 이미 일어난 일의 증거(해시, IP)
- 알려진 악성과 기계적으로 대조 가능 — 빠름
- 하지만 공격자가 쉽게 바꿈(일회용)
- 본질적으로 사후 대응적
IOA(Indicator of Attack) = 진행 중인 행위
- 기법의 흐름: 권한 상승 → 측면 이동 → 탈취
- 실시간에 더 가깝게 잡아냄
- 흔적보다 바꾸기 어려움(공격의 본질이므로)
- 도입이 무거움 — 메커니즘 이해가 필요
공격자에게 각각이 얼마나 '바꾸기 쉬운가'(고통의 피라미드)
IOC 중에서도 공격자가 하나를 바꾸는 데 드는 노력 — 즉 당신이 그것을 잡았을 때 공격자가 얼마나 아픈가 — 는 천차만별입니다. 아래일수록 바꾸기 쉽고, 위일수록 어렵습니다.
그래서 해시와 IP 대조는 빠르게 작동하지만 빠르게 낡습니다. 기법(어떻게 공격하는가)을 이해할수록 방어가 더 오래 유효합니다.
소규모에서도 IOC 활용하기
전용 EDR이나 위협 인텔리전스 구독이 없어도, 할 수 있는 현실적 최소한이 있습니다.
신뢰할 수 있는 출처에서 IOC 얻기
로그와 의존성에 대조
적중 시 격리하고 조사
자신의 IOC를 기록하고 다른 기기도 점검
실제 사례: 무엇이 대조할 단서가 되었나
IOC는 IP 주소와 해시만이 아닙니다. 이 사이트에서 다룬 공급망 사례에서는 패키지의 "버전" 자체가 가장 먼저 확인할 대상이었습니다.
| 사례 | 단서 | 사용자가 확인한 것 |
|---|---|---|
| XZ Utils(2024) | 악성 코드가 들어간 버전(5.6.0과 5.6.1) | OS나 컨테이너에 그 버전이 있는지. 미국 CISA는 5.4.6 같은 오염되지 않은 버전으로 내리라고 권고했다 |
| Codecov(2021) | 배포된 스크립트의 해시(SHA-256)가 공식 값과 맞지 않았다 | 한 회사가 이 확인을 해서 변조가 발견되었다. 사용자는 CI에서 그것을 얼마나 오래 돌렸는지, 어떤 시크릿에 닿을 수 있었는지를 살폈다 |
| Trivy(2026) | 악의적으로 공개된 버전(v0.69.4 등)과 공개된 확인 항목 | 해당 기간에 CI가 그 버전이나 태그를 썼는지. 썼다면 모든 인증 정보를 교체 |
세 사례 모두 단서는 침해당한 쪽이나 당국이 공개했고, 대조는 사용자가 직접 했습니다. 공식 공지가 나오면 먼저 같은 버전이나 해시가 내 환경에 있는지 확인하세요. 그것이 IOC 활용의 기본입니다.
IOC에는 유효 기간이 있다
IOC 취급에 관한 IETF 문서 RFC 9424(2023)는 IOC를 발견, 평가, 공유, 배포, 탐지, 대응, 폐기의 흐름으로 관리한다고 설명합니다. 마지막 단계가 있는 것은 IOC가 낡기 때문입니다.
- 공격자가 버린 IP 주소와 도메인은 나중에 정상 서비스가 다시 쓸 수 있다. 오래된 목록으로 차단하면 정상 통신이 막힐 수 있다
- 1바이트만 바꿔도 해시가 달라지므로, 같은 공격의 새 빌드는 일치하지 않는다
- 그래서 IOC마다 날짜와 출처를 기록하고 정기적으로 다시 검토한다
내 환경에서 IOC를 대조하는 방법
전용 제품이 없어도 공개된 IOC 중 버전, 해시, 도메인 세 가지는 직접 대조할 수 있습니다.
- 버전: lockfile을 의존성 취약점 스캐너에 붙여 넣어 알려진 악성 버전이나 취약한 버전이 들어 있는지 확인합니다. OS 패키지는
xz --version처럼 각 명령으로 버전을 확인합니다 - 해시: 내려받은 파일의 값을
sha256sum 파일(Windows는certutil -hashfile 파일 SHA256)로 계산해 공식 값이나 공개된 IOC와 비교합니다 - 도메인과 IP: DNS 로그와 웹 서버 접근 로그에서 공개된 도메인이나 IP를 검색합니다. 로그가 없는 기간은 확인할 수 없으므로 로그 보존 기간도 확인하세요
일치하면 해당 기기, 키, 토큰을 끊고 위 3단계로 넘어갑니다.
본 사이트의 견해: IOC는 침해를 사후에 확인하는 것이고, 주된 목표는 침입 예방이다
IOC 대조는 중요하지만, 그것은 침해가 일어난 뒤에 흔적을 확인하는 일입니다. 흔적이 보일 무렵이면 이미 침해당한 것입니다. 그래서 본 사이트는 IOC 대조를 점검 도구로 유지하면서, 무게는 침입을 막는 설계에 둡니다: 최소 권한, 신속한 패치(CVE 모니터링), 피싱 저항 MFA, 그리고 시크릿을 절대 평문으로 저장하지 않기. 사후 대응적 흔적 대조에 기대는 방어는 늘 한 발 늦습니다. 흔적으로 "알아채는" 힘과 침입을 "예방하는" 힘이 둘 다 필요합니다.
출처(1차 자료)
- IETF RFC 9424, "Indicators of Compromise (IoCs) and Their Role in Attack Defence"(2023년 8월) — rfc-editor.org(IoC의 정의, 고통의 피라미드, IoC의 수명 주기와 폐기)
- 미국 CISA, "Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094"(2024년 3월 29일) — cisa.gov(영향받는 버전과 권장 조치)
- Codecov와 Trivy의 출처는 각 사례 기사에 실려 있습니다
다음으로 읽기
- 용어집: IOA(Indicator of Attack)란 · C2란 · EDR이란 · CVE란(취약점 식별자) · 랜섬웨어란 · 피싱이란
- 사례: XZ Utils 백도어 · Trivy 공급망 침해
- 복구: 백업과 복구 기초
- 내 사이트 점검: 내 웹사이트나 서버가 해킹됐는지 확인하는 법