김정은 사망설이 뜬 날, 대기업 보안팀에서는 무슨 일이 벌어질까

2026년 10월 20일 해외 SNS를 중심으로 갑자기 김정은 북한 국무위원장의 사망설이 퍼지기 시작했다.

10월 23일 국가정보원은 국회 정보위원회에 해당 사망설이 허위라고 판단했다고 보고했다. 북한 매체는 김정은이 10월 19일 평양의 전시회를 방문했다고 보도했고, 이후에도 공개 활동이 이어졌다.

이러한 뉴스를 보면 보통은 아래처럼 행동하게 된다. 

--

일반 직원들은 뉴스를 검색한다.

PR팀은 사실관계를 확인한다.

경영진은 지정학적 영향을 본다.

그런데 대기업 보안팀에서는 조금 다른 대화가 시작된다.

“이거 지금 피싱 미끼로 돌기 시작했나?”

09:07 — Threat Intel 채널에 링크 하나가 올라온다

회사마다 다르겠지만 SOC나 CSIRT가 있는 규모라면 보통 내부에 이런 채널이 있다.

#soc
#security-incident
#threat-intel
#fraud-monitoring

누군가 링크를 하나 던진다.

Unverified reports claiming the death of Kim Jong Un
are rapidly spreading across social media.

처음부터 Incident를 선언하지는 않는다.

아직 회사가 공격당했다는 증거가 없기 때문이다.

대신 Threat Intelligence 쪽에서 watch item 하나가 생긴다.

Topic:
DPRK leadership / Kim Jong Un death rumor

Potential Abuse:
- Spear phishing
- Fake breaking-news pages
- Credential phishing
- Malware delivery
- Executive impersonation
- Journalist impersonation

이걸 하는 이유가 있다.

공격자들도 뉴스를 보고 있기 때문이다.

공격자는 제로데이보다 헤드라인을 더 빨리 무기화할 때가 있다

대규모 사회공학 공격에서 가장 어려운 건 malware를 만드는 일이 아닐 때가 많다.

사람을 클릭하게 만드는 것이다.

예를 들어 직원에게 평소 이런 메일이 온다.

Subject: DPRK Leadership Transition — Internal Briefing

Please review the attached assessment before
today's executive briefing.

평범한 날이라면 상당히 수상하다.

그런데 몇 시간 전부터 모든 뉴스와 SNS가 같은 이야기를 하고 있다면?

갑자기 맥락이 생긴다.

Breaking News
      |
      v
User Curiosity
      |
      v
Urgency
      |
      v
Click

이게 social engineering에서 굉장히 중요한 요소다.

미국 FBI·NSA와 한국 국정원 등이 발표한 공동 권고에서도 Kimsuky 계열 공격자가 북한 전문가 커뮤니티에서 논의되는 최신 현안에 맞춰 스피어피싱 내용을 지속적으로 수정한다고 설명한다. 기자·연구자·학자 등을 사칭하는 방식도 반복적으로 관찰됐다.

즉 이런 뉴스가 뜨면 보안팀에서는

“가짜뉴스네.”

로 끝나는 게 아니라

“좋은 pretext가 하나 생겼네.”

라고 생각하게 된다.

아래는 내가 경험했던 대형 뉴스가 터졌을때의 기업 대응 시나리오이다. 

09:15 — SOC가 메일 로그를 뒤지기 시작한다.

제일 먼저 메일 보안 쪽을 본다.

예를 들어 Microsoft Defender, Proofpoint, Mimecast 같은 시스템에서 최근 inbound mail을 검색한다.

키워드는 공격 탐지를 위한 단서일 뿐, 그 자체로 악성 판정을 내리지는 않는다.

"Kim Jong Un"
"DPRK"
"North Korea"
"leadership transition"
"breaking report"
"emergency briefing"
"intelligence report"
"succession"

결과가 300건 나온다고 300건을 다 Incident 처리하지 않는다.

조건을 더 붙인다.

External Sender
      +
Recent Domain
      +
Attachment
      +
High-value Recipient
      |
      v
Priority Review

특히 수신자를 본다.

누구에게 왔느냐가 중요하다

대기업 전체 직원 30,000명에게 같은 메일을 뿌렸다면 전형적인 phishing campaign일 가능성이 있다.

그런데 딱 여섯 명에게 갔다고 하자.

CEO Office
Corporate Strategy
Government Relations
Security Leadership
PR Executive
Overseas Business Director

이제 이야기가 달라진다.

내용보다 target selection이 IOC가 된다.

Senior 보안 엔지니어라면 이런 상황에서 가장 먼저 드는 생각 중 하나가 있다.

왜 하필 이 여섯 명이지?

메일 제목이 김정은 사망설인 것보다 오히려 그게 더 중요할 수도 있다.

09:21 — 수상한 메일 하나가 잡힌다

예를 들어 이런 메일이 있었다고 하자.

From:
Asia Policy Center <briefing@asia-policy-example.org>

Subject:
Urgent DPRK Leadership Assessment

Attachment:
DPRK_Leadership_Assessment_20261020.pdf

처음 보면 괜찮아 보인다.

SPF도 통과했다.

DKIM도 있다.

그러면 SOC analyst가 이렇게 끝내면 안 된다.

SPF PASS
DKIM PASS

=> Safe

둘이 의미하는 건 대체로

“이 서버가 이 도메인을 사용할 권한이 있다.”

이지,

“이 도메인 운영자가 선량하다.”

가 아니다.

그래서 도메인을 본다

WHOIS.

Passive DNS.

Certificate Transparency.

도메인 생성 시점.

과거 reputation.

연결 infrastructure.

메일 발송 이력.

Domain Created:
2026-10-20

First Seen:
2026-10-20

Mail Activity:
First observed today

뉴스가 터진 날 만들어진 도메인이다.

조금 더 재미있어진다.

이런 작은 단서들을 하나씩 쌓는다.

New Domain
   +
Relevant Breaking News
   +
Targeted Executives
   +
Document Attachment

아직도 malware라고 확정할 수는 없다.

그래서 첨부파일로 내려간다.

09:28 — 샌드박스에서는 아무것도 안 나온다

파일을 detonating한다.

결과.

Verdict: Clean

Network Activity: None
Dropped Files: None
Suspicious Processes: None

이럴 때 오히려 조금 짜증난다.

명백한 malware라면 처리하기 편하다.

그런데 PDF는 진짜 정상적인 북한 정세 보고서처럼 보인다.

회사 로고도 있다.

문법도 자연스럽다.

그래프까지 그럴듯하다.

마지막 페이지에만 링크 하나가 있다.

Download full intelligence assessment

사용자가 클릭하면 브라우저가 열린다.

09:32 — 여기서 공격 목표가 바뀐다

링크는 Microsoft 365 로그인처럼 보이는 페이지다.

URL은 미묘하다.

login.microsoftonline.com

이 아니라,

login-microsoftonline-security.example

같은 구조다.

이제 malware delivery가 아니다.

Email
  |
  v
PDF
  |
  v
Fake Login Page
  |
  v
Credential Theft

그런데 2026년의 기업 보안에서는 password만 보는 것도 부족하다.

공격자는 계정 비밀번호를 훔치는 대신

OAuth Consent
Session Token
Authentication Cookie
Device Code

같은 걸 노릴 수도 있다.

그래서 Identity 팀까지 호출한다.

“비밀번호 바꾸면 끝 아닌가요?”

대기업 Incident Response에서 꽤 무서운 문장이다.

사용자가 credential phishing에 당했다는 사실을 확인했다고 하자.

초급 대응은 이렇다.

Password Reset

하지만 실제로는 확인할 게 더 많다.

Active Sessions
Refresh Tokens
OAuth Grants
MFA Changes
Registered Devices
Mailbox Rules
Forwarding Rules
App Passwords
Recent Sign-ins

이미 공격자가 세션을 가지고 있다면 password를 바꾸고도 접근이 유지되는 환경이 있을 수 있기 때문이다.

그래서 보통은

Reset Password
      |
      v
Revoke Sessions
      |
      v
Review MFA
      |
      v
Review OAuth Grants
      |
      v
Review Sign-in Logs

까지 같이 간다.

09:41 — 이제 EDR을 본다

메일을 받은 직원 중 한 명이 첨부파일을 열었다고 하자.

그러면 EDR에서 해당 host의 timeline을 만든다.

보고 싶은 건 파일 이름보다 process tree다.

OUTLOOK.EXE
     |
     v
AcroRd32.exe
     |
     v
msedge.exe

여기까진 정상일 수 있다.

하지만 갑자기 이런 식으로 변하면 얘기가 달라진다.

OUTLOOK.EXE
     |
     v
explorer.exe
     |
     v
powershell.exe
     |
     v
rundll32.exe
     |
     v
External Connection

또는

WINWORD.EXE
     |
     v
cmd.exe

같은 parent-child 관계도 바로 눈에 띈다.

보안팀이 “김정은”이라는 단어를 찾는 단계에서

이제는 완전히 다른 것을 보고 있는 것이다.

09:48 — 첫 번째 판단

여기서 Senior Security Engineer가 해야 하는 일이 나온다.

증거가 이렇게 있다고 하자.

Targeted phishing: Confirmed

User opened document: Confirmed

Credential submission: Unknown

Endpoint execution: No evidence

Suspicious sign-in: No evidence

이걸 가지고 결정해야 한다.

PC를 즉시 isolate할 것인가?

계정을 잠글 것인가?

사용자의 세션을 전부 끊을 것인가?

경영진에게 보고할 것인가?

다른 직원에게 공지할 것인가?

회사의 메일 시스템에서 동일 메일을 전부 purge할 것인가?

기술적으로 할 수 있다고 전부 하는 게 항상 정답은 아니다.

대기업 보안팀에서는 “얼마나 세게 대응할지”도 판단한다

Incident Response에서는 흔히 증거를 이렇게 분류한다.

Confirmed
Likely
Possible
Unlikely
Ruled Out

예를 들어,

Phishing Delivery        Confirmed
Attachment Opened        Confirmed
Credential Theft         Possible
Malware Execution        Unlikely
Account Compromise       Unknown

이 상태에서 계정을 전사적으로 disable하면 중요한 임원이 업무를 못 할 수도 있다.

반대로

조금 더 보고 결정하죠.

했다가 실제 compromise라면 공격자에게 시간을 줄 수 있다.

Senior 레벨에서 어려운 건 명령어가 아니다.

불완전한 증거로 결정을 내려야 한다는 것이다.

10:03 — IOC를 전사 환경으로 Pivot한다

한 사람에게 공격이 들어왔다면 같은 infrastructure가 다른 사람에게도 사용됐는지 찾는다.

메일에서 찾은 데이터를 SIEM에 넣는다.

Sender Domain
Sender IP
URL
File Hash
Attachment Name
Redirect Domain
TLS Certificate
User Agent

그리고 데이터를 다른 security control로 확장한다.

Email
  |
  +--> DNS
  |
  +--> Proxy
  |
  +--> EDR
  |
  +--> Identity
  |
  +--> Firewall
  |
  +--> Cloud Logs

이 과정을 pivoting한다고 볼 수 있다.

메일에서는 한 건이었다.

DNS에서 검색하니 18명이 도메인을 조회했다.

Proxy에서는 7명이 접속했다.

그중 2명은 로그인 페이지까지 갔다.

이제 Incident의 크기가 달라진다.

10:14 — 보안팀 전체가 슬슬 붙기 시작한다

조직에 따라 다르지만 사건이 커지면 대략 이런 사람들이 들어온다.

SOC Analyst
Incident Responder
Threat Intelligence
Detection Engineer
Identity Security
Endpoint Security
Email Security
Network Security
Cloud Security

필요하면

Legal
Privacy
PR
Corporate Communications
Executive Protection

도 붙는다.

이때 Slack이나 Teams에 War Room이 하나 생긴다.

#inc-2026-10-dprk-phishing

그리고 첫 메시지는 대략 이렇다.

SEV2 Security Incident

Initial Vector:
Targeted spear phishing

Theme:
DPRK leadership / breaking news

Confirmed Impact:
Under investigation

Affected Users:
7

Incident Commander:
Security IR

여기서 중요한 건 김정은 사망설 Incident가 아니다.

Incident 이름은 어디까지나 공격을 설명해야 한다.

10:25 — CEO에게도 같은 메일이 왔다

이제 갑자기 분위기가 달라진다.

공격 대상에 CEO가 포함됐다고 하자.

기술적인 위험이 반드시 더 커진 것은 아니다.

하지만 business impact가 커진다.

CEO mailbox에는 보통

Board Communication
M&A
Financial Information
Strategy
Executive Contacts
Travel Information

같은 데이터가 있다.

그 계정을 공격하려 했다는 사실만으로도 공격자의 목적을 다시 봐야 한다.

Mass Phishing?

or

Targeted Espionage?

누구를 노렸는지가 공격자의 목적을 보여줄 수도 있기 때문이다.

10:39 — “북한 해커인가요?”

누군가는 거의 반드시 묻는다.

그리고 보안팀이 가장 조심해야 하는 순간이다.

김정은 사망설을 미끼로 썼다고 해서 북한 공격자는 아니다.

DPRK-themed lure
        !=
DPRK attribution

APT attribution은 훨씬 많은 증거가 필요하다.

Infrastructure
Malware Family
Code Similarity
TTP
Historical Campaigns
Victimology
Operational Patterns
Intelligence Sources

북한 연계 Kimsuky가 실제로 최신 한반도 현안을 활용하고 언론인·학자 등을 사칭한 스피어피싱을 반복해 왔다는 건 공개적으로 확인돼 있다.

또 북한 연계 공격자가 DMARC 정책이 약한 환경을 악용해 정상적인 기자나 연구자처럼 보이도록 발신자를 위장한 사례에 대해서도 NSA·FBI·미 국무부가 별도 권고를 낸 적이 있다.

하지만 이것과

이번 공격자가 Kimsuky다.

는 완전히 다른 주장이다.

Senior 보안팀일수록 attribution을 늦게 한다.

11:07 — 전사 공지가 나간다

그런데 공지문에도 문제가 있다.

이렇게 보내면 별로다.

WARNING

Kim Jong Un has reportedly died.

Do not click related emails.

회사 스스로 확인되지 않은 사망설을 다시 확산시키는 꼴이 된다.

보안팀이 원하는 공지는 이런 식이다.

Security Advisory

We are observing phishing attempts that reference
recent unverified news concerning North Korea.

Do not open unexpected attachments or sign in
through links received by email.

Report suspicious messages through the phishing
reporting function.

보안 공지의 목적은 뉴스를 전달하는 게 아니다.

사용자의 행동을 바꾸는 것이다.

그리고 뉴스 자체를 차단하면 안 된다

회사 Proxy에서

Kim Jong Un

이 들어간 페이지를 전부 차단하면 어떨까?

별로 좋은 방법이 아니다.

정상 기사까지 다 막힌다.

false positive가 엄청나다.

대신 공격 행동을 본다.

Recently Registered Domain
        +
Credential Form
        +
Brand Impersonation
        +
Email Referral

보안이 성숙할수록

Bad Word

를 차단하기보다는

Bad Behavior

를 잡으려고 한다.

13:20 — Incident가 끝난 것 같지만 이제부터가 진짜 일이다

공격 메일은 삭제했다.

계정도 확인했다.

악성 세션도 발견되지 않았다.

도메인도 block했다.

그럼 끝?

아니다.

이제 Detection Engineer가 들어간다.

오늘 공격을 다음번에는 사람이 찾지 않아도 탐지하게 만들어야 한다.

예를 들어 detection logic을 추가한다.

Newly Registered Domain
       +
External Email
       +
Executive Recipient
       +
Credential Page

또는 EDR에서는

Office Application
       |
       v
Script Interpreter
       |
       v
External Network

같은 행동을 더 강하게 탐지할 수 있다.

Incident 하나가 끝날 때 detection 하나가 좋아지지 않았다면,

보안팀 입장에서는 조금 아쉬운 대응이다.

14:10 — Purple Team은 여기서 다른 생각을 한다

공격이 실제로 발생하지 않았더라도 이런 이슈는 좋은 훈련 소재가 된다.

Red/Purple Team에서는 이런 시나리오를 생각할 수 있다.

Breaking News
      |
      v
Targeted Email
      |
      v
Fake Document
      |
      v
Credential Phishing
      |
      v
Cloud Account Access

그다음 질문한다.

메일 Gateway에서 잡히나?

사용자가 클릭하면 Proxy에서 잡히나?

credential을 입력하면 Identity Protection에서 잡히나?

공격자가 로그인하면 SIEM에 뜨나?

OAuth persistence를 만들면 탐지되나?

Email
  |
  v
Endpoint
  |
  v
Identity
  |
  v
Cloud

공격 chain 전체에서 몇 번이나 탐지할 기회가 있었는지 보는 것이다.

그리고 이것이 Defense in Depth다

보안 시스템 하나가 완벽해서 사고를 막는 경우만 있는 것은 아니다.

메일 보안이 실패할 수 있다.

Email Security: Miss

사용자가 파일을 열 수 있다.

User Awareness: Miss

그래도 EDR이 잡을 수 있다.

EDR: Detect

EDR도 놓쳤다면 Identity에서 잡을 수 있다.

Identity: Detect

Identity까지 뚫렸다면 CloudTrail이나 SIEM에서 잡을 수도 있다.

Cloud Detection: Detect

결국 구조는 이렇다.

Email
  |
  v
Endpoint
  |
  v
Identity
  |
  v
Network
  |
  v
Cloud

어느 한 단계가 실패해도 다음 단계가 존재한다.

이게 실제 기업 보안에서 중요한 구조다.

Senior Security Engineer가 보는 건 “메일 한 통”이 아니다

Junior analyst에게 사건은 이렇게 보일 수 있다.

Suspicious Email

조금 지나면 이렇게 보인다.

Phishing Campaign

Senior 레벨에서는 조금 더 크게 본다.

Geopolitical Event
        |
        v
Threat Actor Opportunity
        |
        v
Target Selection
        |
        v
Initial Access
        |
        v
Identity
        |
        v
Corporate Environment

결국 보는 건 하나다.

Attack Path.

김정은 사망설이 허위였다는 게 보안팀에게는 별로 중요하지 않을 수도 있다

10월 23일 국정원은 이번 사망설이 사실이 아니라고 판단했다.

그런데 공격자는 뉴스가 사실인지 확인하고 공격을 시작할 필요가 없다.

사람들이 관심을 갖고 있으면 충분하다.

True News
    \
     \
      --> Attention --> Click

Rumor
     /
    /

공격자에게 필요한 건 진실이 아니라 Attention일 수 있다.

결국 그날 대기업 보안팀에서 벌어지는 일

아침에는 SNS 루머 하나였다.

몇 시간 뒤에는 이렇게 변할 수 있다.

08:50  Breaking News

09:07  Threat Intel Watch

09:15  Email Hunting

09:21  Suspicious Campaign Found

09:32  Credential Phishing Confirmed

09:41  Endpoint Investigation

09:48  Account Risk Assessment

10:03  Enterprise-wide IOC Pivot

10:14  Incident War Room

10:25  Executive Targeting Identified

10:39  Attribution Discussion

11:07  Employee Advisory

13:20  Detection Engineering

14:10  Purple Team Scenario

밖에서 보면 그냥

“김정은 사망설이 돌았다.”

라는 뉴스다.

그런데 보안팀 입장에서 보면

New Pretext Available

이라는 의미가 하나 더 생긴다.

그래서 큰 뉴스가 터졌을 때 SOC가 뉴스 사이트보다 먼저 확인하는 곳은 의외로

메일 Gateway,

SIEM,

EDR,

Identity Provider일 수도 있다.

뉴스팀은 묻는다.

“이게 사실인가?”

보안팀은 조금 다른 질문을 한다.

“그래서 지금 누가 이걸 공격에 쓰고 있지?”

그리고 어쩌면 그게 대기업 보안팀에서
세상이 돌아가는 뉴스를 바라보는 가장 직업병 같은 방법일지도 모른다.