FortiMail CVE-2026-104286 제로데이: IoC 기반 조사·격리·업데이트 런북

패치가 늦어지는 구간을 전제로 FortiMail 파일 쓰기 제로데이를 IoC로 확인하고 격리·복구·업데이트까지 이어가는 운영 런북.

게시 2026/10/06

By Daewook Kwon

38 분읽는 시간

사건 개요: 공개(10/01) → 재공지(10/05) → KEV 기한(10/04)

Fortinet FortiMail에서 unauthenticated arbitrary file write가 가능한 취약점(CVE-2026-104286)이 2026-10-01에 Fortinet PSIRT advisory(FG-IR-26-175)로 공개되었고, “in the wild” 악용이 전제된 대응이 확산되었습니다. 홍콩 GovCERT.HK는 2026-10-05에 High Threat Security Alert로 재공지하면서 영향을 받는 버전 범위와 조치 필요성을 다시 한 번 못 박았습니다.¹

영향 버전 범위는 여러 공식/준공식 채널에서 일관됩니다.

FortiMail 7.2.0–7.2.9
FortiMail 7.4.0–7.4.8
FortiMail 7.6.0–7.6.6
FortiMail 8.0.0–8.0.1

이는 GovCERT.HK High Threat Security Alert (A26-10-05), HKCERT Security Bulletin (2026-10-02), 그리고 NVD의 CVE 설명에서 같은 형태로 나타납니다.¹

동시에 CISA KEV(known exploited vulnerabilities)에도 2026-10-01에 추가되었고, due date는 2026-10-04로 매우 짧게 잡혔습니다. KEV 엔트리에는 “forensic triage: Yes”가 명시되어 있어, 단순 차단이 아니라 침해 여부 확인까지 요구사항으로 묶는 흐름입니다.²

여기서 중요한 점은 날짜입니다.

Fortinet advisory 공개: 2026-10-01
CERT-FR advisory 게시: 2026-10-02 (Fortinet advisory를 source로 명시)
GovCERT.HK 재공지: 2026-10-05
KEV due date: 2026-10-04

KEV due date가 이미 2026-10-06 기준으로는 과거가 되었더라도, 현실의 대부분 조직은 그 기한 안에 “패치 + 포렌식”을 끝내지 못합니다. 그래서 운영 관점에서는 “패치 전(또는 지연) 구간”을 전제로 한 런북이 필요합니다.³

무엇이 위험한가: unauth file write는 곧 persistence로 이어집니다

NVD의 요약을 보면 이 취약점은 path traversal(CWE-22)과 NULL byte/NULL character 처리 문제(CWE-158)가 결합되어, 인증 없이 crafted HTTP/HTTPS 요청만으로 underlying system에 임의 파일을 쓸 수 있다고 설명합니다.⁴

메일 게이트웨이에서 “파일 쓰기”가 왜 즉시 incident급이 되느냐는 결국 두 가지 때문입니다.

첫째, FortiMail은 perimeter에 있고 메일 트래픽 전체(본문/첨부/수신자/발신자/헤더/정책 결과)를 처리합니다. 침해되면 개인정보나 영업정보가 메일 경로에서 그대로 노출될 수 있습니다.

둘째, 파일 쓰기가 가능한 위치가 system 설정/서비스 바이너리/동적 로더 체인까지 닿으면, 다음 단계는 매우 단순해집니다.

서비스 바이너리 추가/교체
설정 파일 변조(예: 웹서버 설정)
동적 로더의 preload 메커니즘 악용

실제로 Fortinet이 공개한 IoC(후술)에 /data/etc/ld.so.preload와 /data/lib/liblog.so 조합이 포함되어 있습니다. ld.so.preload는 존재 자체가 이상 신호가 되는 경우가 많고, 여기에 라이브러리를 등록하면 “프로세스들이 시작될 때 공통으로 악성 라이브러리를 로드”하는 형태의 강한 persistence가 만들어집니다. 이 구조는 “패치만 적용”해도 백도어가 남을 수 있다는 결론으로 이어집니다.⁵

런북의 목표: 침해 여부 확인 → 격리 → 업데이트 (순서를 바꾸지 않습니다)

이 케이스는 취약점 대응(vulnerability response)과 침해사고 대응(incident response)의 경계가 빠르게 무너집니다. 이유는 단순합니다.

이미 악용 중(in the wild)
unauthenticated
임의 파일 쓰기
IoC가 “파일/해시/로그 패턴/IP”로 제시됨(즉, 이미 compromise 모델이 존재)

따라서 순서는 고정합니다.

1) 침해 여부 확인(최소한의 triage) 2) 격리(메일 흐름을 살리되 공격면을 닫고 증거를 보존) 3) 업데이트(고쳐진 빌드가 존재한다면 적용, 없으면 workaround 지속)

여기서 중요한 원칙은 ‘증거 보존 후 변경’입니다. 로그/설정/디스크 아티팩트가 한 번 날아가면, 침해 여부를 “모른 채로 운영 재개”하게 됩니다. 이건 보안뿐 아니라 운영 리스크(추가 침해, 데이터 유출 평가 불가, 사후 보고 품질 저하)를 키웁니다.

0단계: 자산 식별과 노출면 정리(메일 흐름 vs HTTP/HTTPS)

0-1. 우리 조직에 FortiMail이 어디에 있나

FortiMail은 “MX 앞단에만 있는 장비”로 끝나지 않는 경우가 많습니다.

inbound SMTP(25) 처리
outbound SMTP relay
webmail/quarantine portal
admin GUI
IBE portal(암호화 메일 열람 포털)

운영자가 놓치기 쉬운 부분은 “admin GUI와 webmail/quarantine/IBE가 같은 HTTPS 인터페이스를 공유”하는 구성입니다. 이 경우 443을 단순 차단하면 사용자 기능까지 같이 죽습니다. Rafael Pfister의 정리에서도 이 점을 명시합니다.⁵

그래서 자산 식별은 최소한 다음을 포함해야 합니다.

인터넷에서 접근 가능한 443/80이 있는지
reverse proxy/WAF/LB가 앞단에 있는지
443이 admin GUI 전용인지, 사용자 포털(격리메일/IBE)까지 포함인지
FortiMail이 내부로 나가는 outbound 통신(예: LDAP, SMTP upstream, object storage, syslog, FortiGuard 업데이트)을 어떤 정책으로 허용받는지

0-2. 버전 확인과 분기 전략(특히 7.2)

CERT-FR는 Fortinet advisory(FG-IR-26-175)를 source로 두고 “upcoming fixed versions”를 명시합니다.

7.4 계열: upcoming 7.4.9
7.6 계열: upcoming 7.6.7
8.0 계열: upcoming 8.0.2
7.2 계열: 7.4 branch로 업그레이드 필요(7.2 branch 자체 수정 릴리스 언급이 없음)

이 내용은 CERT-FR CERTFR-2026-AVI-1257에 그대로 반영되어 있습니다.³

7.2를 쓰는 조직은 “hotfix를 기다려서 해결”이 아니라 “branch upgrade 프로젝트”가 됩니다. 메일 게이트웨이에서 branch upgrade는 운영 측면에서 거의 재구축에 가깝게 비용이 나오는 경우가 많습니다(정책/인증/연동/인증서/로그 적재).

1단계(즉시): 공격면을 닫는 workaround를 적용합니다

여기서 목표는 “완벽한 해결”이 아니라, 패치가 없거나 지연되는 동안 exploit 시도를 줄이고, 이미 침해된 경우 추가 행위를 제한하는 것입니다.

1-1. IBE 비활성화(가장 직접적인 workaround)

여러 정리 글과 Fortinet 문서가 공통으로 가리키는 첫 번째 조치는 IBE(Identity-Based Encryption) 기능을 끄는 것입니다.

Fortinet CLI reference에는 IBE 서비스를 enable/disable 하는 커맨드가 config system encryption ibe 아래에 있음을 명시합니다.⁶

실제 적용은 다음 형태로 진행됩니다.

config system encryption ibe
    set status disable
end

이 조치의 운영 비용은 명확합니다.

외부 수신자에게 “포털로 들어가 열람”하는 암호화 메일 흐름이 막힐 수 있습니다.
기존에 IBE 기반으로 보안 전송을 설계했다면, 대체 경로(S/MIME, PGP, 별도 secure mail 서비스, 혹은 임시 정책 완화)가 필요합니다.

그럼에도 이 workaround는 “취약점 경로가 IBE와 강하게 연관되어 있다”는 정황과 함께 반복해서 등장합니다.⁵

1-2. 인터넷에서 FortiMail management/web 인터페이스를 분리합니다

GovCERT.HK는 “특수 crafted request로 악용 가능, 즉시 패치 권고” 수준으로 넓게 쓰고 있지만, 실무에서는 먼저 “외부 노출된 HTTP/HTTPS 면”을 없애는 게 가장 확실한 방어입니다.¹

가장 안전한 그림은 다음 중 하나입니다.

(권장) admin GUI는 관리망에서만 접근 가능하게 분리
사용자 포털(webmail/quarantine/IBE)이 필요하면, 사용자 포털만 reverse proxy/WAF 뒤로 두고 admin은 별도 경로로 제한

Rafael Pfister가 지적하듯 “HTTPS를 통째로 막으면 사용자 포털도 같이 죽는” 구성이 흔합니다. 그래서 ‘무조건 443 차단’이 아니라, “무엇이 443에서 동작하는지”를 먼저 분해해야 합니다.⁵

1-3. WAF가 있다면 요청 패턴을 차단합니다(보조 장치)

Rescana는 Fortinet advisory 기반으로, WAF가 있을 경우 /ibe로 들어오는 POST 요청 중 path traversal 시퀀스(예: ../)를 포함하는 패턴을 차단하라고 정리합니다.⁷

이 조치는 어디까지나 “보조”입니다.

변형된 traversal(..%2f, 이중 인코딩, 널 바이트, 혼합 인코딩)가 들어오면 우회될 수 있습니다.
취약점이 /ibe만의 문제인지(또는 다른 엔드포인트로도 reachable인지) 확정할 수 없습니다.

따라서 WAF 룰은 “인터넷 노출이 이미 존재하고 즉시 구조 변경이 어려운 조직”에서 시간을 버는 용도로만 보는 편이 낫습니다.

2단계: IoC 기반 침해 여부 확인(파일 → 네트워크 → 로그)

KEV 엔트리는 CVE-2026-104286에 대해 forensic triage를 요구합니다. 말 그대로 “취약점 대응으로 끝내지 말고, 침해 여부를 확인”하라는 의미입니다.²

여기서는 Fortinet advisory에 포함된 IoC(파일/해시/IP/로그 패턴)를 중심으로, 운영팀이 당장 실행 가능한 체크리스트로 재구성합니다. Fortinet 원문(FG-IR-26-175)은 제 환경에서 403/timeout로 직접 열람이 불가능했기 때문에, 공식 채널(CERT-FR, GovCERT.HK, HKCERT)과 함께 “Fortinet IoC를 재인용한 2차 문서”를 교차 확인해 사용합니다.³

2-1. 파일 IoC: 존재 여부 + 해시 일치 여부

Rafael Pfister가 정리한 “파일 경로 목록”은 다음과 같습니다.⁵

/data/lib/liblog.so
/data/etc/ld.so.preload
/bin/smit
/data/bin/webconsole
/data/bin/mailservice
/data/etc/httpd.conf
/data/migadmin.tar.gz

Rescana는 같은 목록에 대해 MD5를 함께 제공합니다(출처를 Fortinet advisory로 표시).⁷

Path	MD5 (Rescana 재인용)	의미(관찰)
`/data/lib/liblog.so`	`64c90a00c7fda4d5c7973ed64c25783a`	Added
`/bin/smit`	`5241738a3e9988404239e12243f6d35b`	Modified
`/data/bin/webconsole`	`ae0ea6502d3fa5f0664bceb73189eb54`	Added
`/data/bin/mailservice`	`f90fa81a5f521d785f2b2f765e3ab897`	Added
`/data/etc/httpd.conf`	`61af1c4bce1c2eebc8ff689ca5337791`	Modified
`/data/etc/ld.so.preload`	`8eb64f25d2a8e18e05aae058629473cf`	Added
`/data/migadmin.tar.gz`	`49a7156a7d043cc8f9f680579db22f86`	Modified

여기서 운영 판단은 간단합니다.

위 파일이 “존재”하는 것 자체가 위험 신호일 수 있습니다(특히 ld.so.preload).
해시가 “일치”하면 강하게 침해를 의심해야 합니다.
해시가 “불일치”해도 안심할 수 없습니다(버전/빌드/아키텍처/공격자 변형으로 달라질 수 있음).

즉, IoC 매칭은 “침해 확정의 지름길”이지 “침해 부정의 근거”가 아닙니다.

(실행 가능한 절차) VM이라면 디스크를 오프라인으로 마운트해서 해시를 뜹니다

메일 게이트웨이는 격리·재기동·업데이트만으로 상태가 변합니다. 내가 선호하는 방식은 VM일 때 스냅샷을 만든 뒤, 디스크를 read-only로 마운트해 IoC를 확인하는 것입니다.

아래 예시는 KVM/libvirt 환경을 가정합니다.

1) VM 스냅샷 생성

  
# 예: 도메인 이름이 fortimail-prod 인 경우
virsh snapshot-create-as --domain fortimail-prod --name pre-triage-20261006 --atomic

2) 스냅샷/디스크 경로 확인

virsh domblklist fortimail-prod

3) qemu-nbd로 디스크 연결(읽기 전용 권장)

  
sudo modprobe nbd max_part=8
sudo qemu-nbd --read-only --connect /dev/nbd0 /var/lib/libvirt/images/fortimail-prod.qcow2
lsblk /dev/nbd0

4) 파티션을 read-only로 마운트

  
sudo mkdir -p /mnt/fortimail
sudo mount -o ro /dev/nbd0p1 /mnt/fortimail

5) IoC 해시 체크 스크립트 실행

  
cat > iocs_fortimail_cve-2026-104286_md5.tsv <<'EOF'
64c90a00c7fda4d5c7973ed64c25783a	/data/lib/liblog.so
5241738a3e9988404239e12243f6d35b	/bin/smit
ae0ea6502d3fa5f0664bceb73189eb54	/data/bin/webconsole
f90fa81a5f521d785f2b2f765e3ab897	/data/bin/mailservice
61af1c4bce1c2eebc8ff689ca5337791	/data/etc/httpd.conf
8eb64f25d2a8e18e05aae058629473cf	/data/etc/ld.so.preload
49a7156a7d043cc8f9f680579db22f86	/data/migadmin.tar.gz
EOF

cat > check_fortimail_iocs.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
ROOT="${1:-/mnt/fortimail}"
IOC_LIST="${2:-iocs_fortimail_cve-2026-104286_md5.tsv}"

printf '%-6s  %-34s  %s\n' "STATE" "MD5" "PATH"

while IFS=$'\t' read -r expected path; do
  target="${ROOT}${path}"
  if [[ ! -e "$target" ]]; then
    printf '%-6s  %-34s  %s\n' "MISS" "$expected" "$path"
    continue
  fi
  if [[ -f "$target" ]]; then
    got=$(md5sum "$target" | awk '{print $1}')
    if [[ "$got" == "$expected" ]]; then
      printf '%-6s  %-34s  %s\n' "MATCH" "$got" "$path"
    else
      printf '%-6s  %-34s  %s (got %s)\n' "DIFF" "$expected" "$path" "$got"
    fi
  else
    printf '%-6s  %-34s  %s (not a regular file)\n' "WARN" "$expected" "$path"
  fi
done < "$IOC_LIST"
EOF

chmod +x check_fortimail_iocs.sh
./check_fortimail_iocs.sh /mnt/fortimail iocs_fortimail_cve-2026-104286_md5.tsv

예상 출력은 이런 형태입니다.

STATE   MD5                                PATH
MISS    64c90a00c7fda4d5c7973ed64c25783a   /data/lib/liblog.so
DIFF    61af1c4bce1c2eebc8ff689ca5337791   /data/etc/httpd.conf (got 9c0...)
MATCH   8eb64f25d2a8e18e05aae058629473cf   /data/etc/ld.so.preload

MATCH가 1개라도 나오면 침해로 간주하고 격리/재설치를 기본값으로 잡는 편이 안전합니다.
DIFF도 위험합니다. 공격자 변형이거나, 정상 파일이 변조된 상태일 수 있습니다.
MISS만 나온다고 해서 결백이 증명되는 것은 아닙니다.

스캔이 끝났으면 마운트 해제 및 nbd 분리까지 마칩니다.

  
sudo umount /mnt/fortimail
sudo qemu-nbd --disconnect /dev/nbd0

2-2. 네트워크 IoC: 공격자 IP로의 접속 흔적과 차단

Rafael Pfister와 Rescana 모두, Fortinet이 게시한 것으로 알려진 IP 두 개를 지표로 제시합니다.⁵

79.141.169.187
45.129.0.192

운영에서 현실적인 절차는 순서가 있습니다.

1) 차단부터 합니다(egress + ingress) 2) 과거 로그를 뒤져서 흔적을 찾습니다 3) 흔적이 있으면 범위를 확장합니다(메일 유출 가능성 평가로 넘어감)

차단은 FortiMail 자체에서 하기보다, 가능하면 상단 firewall에서 egress를 먼저 막는 편이 좋습니다. FortiMail이 침해된 상태라면 “장비 내부에서의 차단 룰”은 신뢰하기 어렵습니다.

과거 흔적은 최소한 다음 데이터 소스에서 찾습니다.

상단 firewall allow log
reverse proxy/WAF access log
NetFlow/VPC flow logs
FortiMail system log(외부로 내보낸 경우)

Splunk 예시(환경에 맞게 index/sourcetype 수정):

(index=netfw OR index=proxy OR index=fortimail)
( dest_ip="79.141.169.187" OR dest_ip="45.129.0.192" OR src_ip="79.141.169.187" OR src_ip="45.129.0.192" )
| stats count min(_time) as first_seen max(_time) as last_seen values(action) as action values(dest_port) as ports by src_ip dest_ip
| convert ctime(first_seen) ctime(last_seen)

2-3. 로그 IoC: cron(/migadmin), archive account, IBE 오류 패턴

Fortinet advisory가 제시한 것으로 알려진 로그 패턴은 크게 세 가지 축으로 요약됩니다.

1) root cron이 /migadmin와 연관된 shell 실행 2) archive account가 원격 IP로 설정됨(특히 79.141.169.187) 3) IBE decrypter의 Base64 디코딩 오류, 그리고 비정상 login 실패 패턴

Rafael Pfister의 “Assessing compromise” 요약에 이 내용이 그대로 정리되어 있습니다.⁵

운영 관점에서 이 지표가 의미 있는 이유는 다음과 같습니다.

cron은 persistence의 대표적인 경로입니다.
archive account는 메일 내용을 외부로 복제/exfiltration 하는 구현 수단이 될 수 있습니다.
IBE 오류 패턴은 exploit 트래픽이 IBE 경로를 건드린 흔적으로 해석될 여지가 있습니다.

Splunk 예시(문자열은 환경 로그 포맷에 맞춰 조정):

index=fortimail
(
  "migadmin" OR
  "ui=cron" OR
  "Invalid Base64" OR
  "IBE" OR
  "archive" OR
  "admin logged out" OR
  "(null)" OR
  "79.141.169.187" OR
  "45.129.0.192"
)
| stats count min(_time) as first_seen max(_time) as last_seen values(host) as hosts values(source) as sources by _raw
| sort -count

여기서 중요한 운영 팁 하나는, “FortiMail 로컬 로그만” 보지 말고 상단의 웹 접근 로그를 같이 보라는 점입니다.

이 취약점은 HTTP/HTTPS 요청 기반으로 설명되며(NVD, HKCERT, KEV 엔트리 요약 모두 동일한 방향), 실제 공격은 웹 로그에 먼저 남고 시스템 로그는 그 다음 단계에서 남을 가능성이 큽니다.⁴

3단계: 격리(Quarantine) — 메일 흐름을 유지하면서 공격면을 줄입니다

IoC 매칭이 발생했거나, 확신은 없지만 의심 정황이 쌓였다면 격리는 “장비를 끄는 것”이 아니라 “기능을 분리하는 것”에 가깝습니다.

내 기준에서 격리의 우선순위는 다음과 같습니다.

1) 공격자가 재진입/추가 행위를 못 하게 막는다 2) 메일 수신/발신 비즈니스가 멈추지 않게 한다 3) 포렌식에 필요한 최소 증거를 보존한다

3-1. 외부에서 들어오는 HTTP/HTTPS를 먼저 끊습니다

CVE 설명 자체가 crafted HTTP/HTTPS 요청을 전제로 합니다.⁴

가장 단순한 격리 방식은 “인터넷에서 FortiMail의 443/80에 닿지 않게” 하는 것입니다. 다만 앞서 말했듯 443이 사용자 포털까지 포함하면, 서비스 영향이 생깁니다.⁵

운영에서 현실적인 절충안은 다음 중 하나입니다.

admin GUI만 별도 관리망 VIP로 분리하고, 외부 VIP에서는 사용자 포털만 제한적으로 노출
사용자 포털이 당장 없어도 되면 443 전체를 내부로만 제한
구조 변경이 당장 어렵다면 WAF에서 강한 allowlist(사내 고정 IP/VPN)로 줄이는 방식

3-2. SMTP(25) 흐름은 별개로 살려둡니다

Rafael Pfister는 “SMTP on port 25 is not affected by either option; mail flow continues”라고 명시합니다. 즉, workaround/격리 조치가 HTTP/HTTPS면을 대상으로 설계된다면, SMTP만 유지하는 구조가 가능합니다.⁵

실제로 메일 게이트웨이 운영에서 자주 쓰는 수습 시나리오는 이렇습니다.

inbound SMTP는 계속 처리
사용자 포털/IBE/admin GUI는 제한
필요하면 임시로 backup MX로 우회

backup MX가 없다면 이 사건을 계기로 최소한의 failover를 설계해야 합니다(클라우드 보안 게이트웨이든, 내부에 축소 정책의 대기 장비든).

3-3. egress를 조입니다(특히 IoC IP)

IoC로 제시된 IP는 즉시 차단합니다.⁷

추가로, 침해가 의심되는 동안에는 FortiMail에서 “불필요한 outbound”를 줄이는 편이 낫습니다.

외부 임의 목적지로 나가는 443/80
외부 DNS(가능하면 내부 resolver로 고정)

메일 게이트웨이는 생각보다 outbound 통신이 다양합니다(업데이트, 리레이, LDAP, syslog, NTP). 운영팀이 허용 리스트를 명확히 가지고 있으면, incident 구간에 “허용되지 않은 egress”를 탐지하기가 쉬워집니다.

4단계: 복구(Eradication/Recovery) — 패치보다 재설치가 먼저일 수 있습니다

이번 케이스는 IoC에 ld.so.preload가 포함되어 있습니다. 이건 운영적으로 의미가 큽니다.

단순히 취약점이 막혀도, preload 기반 persistence가 남아 있으면 프로세스 레벨에서 계속 후킹이 가능해집니다.
따라서 “업데이트(패치) = 치료”가 아닙니다.

Rafael Pfister도 “update alone does not remove an established backdoor”에 가깝게 정리하며, remediation으로 reinstall/restore/credential rotation을 강조합니다.⁵

여기서 내 결론은 보수적입니다.

IoC가 1개라도 매칭되면 재설치를 기본값으로 둡니다.

4-1. 재설치 전략: 새 인스턴스 + 검증된 설정 복원

VM이면 새 VM을 깨끗한 이미지로 올리고, 기존 장비에서 “검증한 설정”만 가져오는 방식이 가장 깔끔합니다.

기존 장비에서 설정 export(가능하면 격리된 관리망에서)
설정 파일을 diff/리뷰해서 “archive account/forwarding/remote destination” 같은 위험 설정이 섞였는지 확인
새 인스턴스에 import

하드웨어 appliance인 경우에는 조직마다 선택지가 갈립니다.

유지보수 계약이 있다면 Fortinet TAC/PSIRT 가이드를 받아 forensic image 확보 절차를 병행
최소한 로그/설정/이벤트를 외부로 안전하게 백업해둔 뒤 조치

4-2. 크리덴셜/키/연동 계정 회전(메일 게이트웨이 특유의 범위)

메일 게이트웨이는 다른 인프라보다 “몰아 넣은 크리덴셜”이 많습니다.

FortiMail 관리자 계정
LDAP bind 계정
upstream SMTP 인증(릴레이 계정)
downstream 연동(예: SIEM/syslog 토큰, API 키)
TLS private key(인바운드/아웃바운드, 포털)

침해 가능성이 있으면 이 범위를 좁히기 어렵습니다. 특히 메일 내용/자격 증명/키가 같이 노출될 수 있다는 점이 본질적인 리스크입니다.

4-3. 메일 유출 평가: archive/forwarding을 우선 확인합니다

Fortinet IoC 요약에는 “archive account with remote destination”이 포함됩니다. 공격자가 메일을 외부로 복제하는 현실적인 방법이기 때문입니다.⁵

따라서 복구 단계에서 우선 확인할 항목은 기술적으로는 단순합니다.

archive account 목록과 목적지(IP/도메인)
정책 기반 forwarding/redirect 규칙
외부로 전송되는 journaling 구성

이 부분은 설정 export를 diff로 보는 게 가장 빠릅니다.

5단계: 업데이트(패치/업그레이드) — ‘나왔는지’부터 확인합니다

GovCERT.HK는 “Patches … are available”라고 적고 있지만, CERT-FR는 2026-10-02 시점 기준으로 upcoming fixed version을 명시하는 형태로 작성되어 있습니다.¹

즉, 2026-10-06 시점에 조직이 해야 하는 실무는 이렇습니다.

1) Fortinet advisory(FG-IR-26-175)와 Fortinet support portal에서 “내가 받을 수 있는 빌드가 실제로 릴리스되었는지” 확인 2) 릴리스되지 않았다면 workaround 지속 + 모니터링 강화 3) 릴리스되었다면, ‘침해 여부 확인 → 격리 → 업데이트’ 순서로 적용

KEV 엔트리도 “mitigations … or discontinue use if mitigations are unavailable”에 가까운 문장 구조를 취합니다. 패치가 없을 수도 있다는 전제를 깔고 있습니다.²

업데이트 적용 후에는 최소한 다음을 확인해야 합니다.

IBE를 다시 켰다면(운영상 필요) 외부 노출을 어떻게 제한할지 구조가 바뀌었는지
admin GUI 접근 경로가 관리망으로 고정됐는지
IoC 파일 경로에 흔적이 없는지(업데이트 전과 동일한 방식으로 재확인)

반론과 회의론: IoC는 강력하지만, 좁은 문입니다

IoC 기반 런북을 쓰면 실행은 빨라집니다. 대신 다음 함정이 있습니다.

1) 해시 기반 매칭은 버전에 민감합니다

MD5가 딱 맞으면 강력한 지표지만, 공격자가 바이너리를 살짝만 바꿔도 해시는 달라집니다. 반대로 정상 업그레이드/빌드 차이로 바이너리가 달라졌을 가능성도 있습니다.

결론은 “MATCH면 침해로 본다”는 단방향 규칙입니다. “DIFF/MISS면 안전”이라는 역방향 규칙을 만들면 위험해집니다.

2) 로그 패턴은 환경마다 빠질 수 있습니다

FortiMail이 로컬 로그만 남기고 외부로 전달되지 않았을 수 있습니다.
WAF/프록시가 없으면 웹 접근 로그가 남지 않을 수 있습니다.
로그 보존 기간이 짧으면, 이미 흔적이 사라졌을 수 있습니다.

그래서 최소한 incident 구간에는 FortiMail 로그를 외부로 내보내고, 상단 네트워크 장비의 allow log 보존을 늘리는 쪽이 낫습니다.

3) “IBE를 끄면 안전”이라고 단정하면 안 됩니다

Fortinet 문서와 여러 요약은 IBE disable을 workaround로 제시하지만, 이것이 취약점 경로 전체를 제거한다는 보장은 없습니다. 운영에서는 workaround를 “시간을 벌기 위한 조치”로만 두고, 외부 노출면 자체를 없애는 구조 변경을 병행하는 편이 안전합니다.⁶

앞으로 지켜볼 것: advisory 업데이트, 추가 IoC, 그리고 ‘패치 이후의 포렌식’

이 사건은 이미 악용이 전제되어 있고, KEV에도 올라갔으며, Fortinet advisory의 업데이트에 따라 대응 범위가 계속 바뀔 수 있습니다.²

내가 특히 지켜보는 포인트는 세 가지입니다.

1) FG-IR-26-175의 revision history에서 IoC/우회/영향 범위가 추가되는지 2) 7.4.9/7.6.7/8.0.2(또는 그에 준하는 fixed build)가 실제로 배포되었는지 3) IoC가 “파일 + 특정 IP”에만 고정되어 있는지, 아니면 공격 캠페인의 확장(다른 C2, 다른 persistence) 신호가 나오는지

패치가 나온 뒤에도, IoC가 한 번이라도 맞았던 조직은 ‘패치 적용’이 아니라 ‘재설치 + 크리덴셜 회전 + 유출 평가’까지 해야 사건이 끝납니다. 파일 쓰기 기반 침해는 운영 체감상 “이미 내부에 심어둔 상태”로 보는 게 더 정확합니다.

실행 체크리스트: 침해 여부 확인 → 격리 → 업데이트

A. 30분 안에 해야 하는 것

FortiMail 버전 확인 및 영향을 받는지 판단¹
인터넷에서 FortiMail HTTP/HTTPS 접근 경로 확인(방화벽 VIP, LB, WAF)
IBE 사용 여부 확인 후, 가능한 경우 IBE disable 적용⁶
IoC IP(79.141.169.187, 45.129.0.192) egress/ingress 차단⁷

B. 반나절 안에 해야 하는 것

(가능하면 오프라인) 파일 IoC 경로 존재/해시 확인⁷
상단 firewall/WAF/프록시 로그에서 IoC IP 및 /ibe 접근 패턴 검색⁴
FortiMail 시스템 로그에서 cron(/migadmin), archive account, IBE Base64 오류 패턴 검색⁵

C. IoC가 하나라도 맞았을 때(incident 모드)

변경 전에 로그/설정/디스크 스냅샷을 보존
외부 HTTP/HTTPS 노출 제거(관리망 분리)
새 인스턴스 재설치 + 검증된 설정 복원
관리자/연동 계정/키 회전
archive/forwarding 기반 유출 평가

이 순서를 지키면, 패치가 늦어지는 구간에서도 “조사와 격리”가 뒤섞이며 시간을 태우는 상황을 줄일 수 있습니다.

참고 자료

News, Security