[라온 보안동향보고서] 2026년 7월 주요 보안 이슈

1. 악성코드 현황

1.1. 악성코드 동향

Google은 2026년 6월 Android 보안 게시판에서 Android Framework의 정수 오버플로우 취약점 CVE-2025-48595를 공개했습니다. NVD는 여러 위치의 정수 오버플로우로 인해 코드 실행이 가능해지고, 별도의 기존 실행 권한 없이 로컬 권한 상승으로 이어질 수 있다고 설명합니다. 악용 단계에서 추가 사용자 조작은 필요하지 않지만, 공격 벡터는 로컬(AV:L)이므로 공격자가 먼저 기기 안에서 코드를 실행할 수 있는 경로를 확보해야 합니다. 영향 범위는 Android 14, 15, 16 및 Android 16 QPR2 베타 1~3이며, Google은 제한적인 표적 공격에서 악용됐을 가능성을 언급했습니다.

미국 사이버안보·기반시설보안국(CISA)은 2026년 6월 2일 이 취약점을 실제 악용 취약점(KEV) 목록에 등재했습니다. KEV는 실제 공격에 사용된 근거가 확인된 취약점을 관리하는 목록입니다. CVE-2025-48595는 CWE-190으로 분류되며, CISA-ADP가 산정한 CVSS 3.1 점수는 8.4(High)입니다. 인터넷에서 이 취약점만으로 기기에 직접 침입하는 유형은 아니며, 악성 앱이나 다른 취약점 등으로 로컬 실행 경로를 확보한 공격자가 이후 권한 상승 단계에 활용할 수 있습니다.

이 취약점은 2026-06-01 보안 패치 레벨의 Framework 항목에 포함됩니다. 같은 게시판의 2026-06-05 보안 패치 레벨에는 커널과 칩셋 제조사 구성요소의 별도 취약점도 포함되므로, 2026-06-05 이상을 적용하면 해당 월 게시판에 수록된 전체 문제를 함께 해결할 수 있습니다. 다만 CVE-2025-48595의 구체적인 취약 함수, 메모리 손상 과정, 실제 공격 주체와 전체 익스플로잇 체인은 공개되지 않았습니다.

1. 취약점 요약 표

2. 기술적 분석

(1) 취약점 상세

CVE-2025-48595는 Android Framework의 여러 위치에서 발생할 수 있는 정수 오버플로우 취약점입니다. 정수 오버플로우는 계산 결과가 자료형이 표현할 수 있는 범위를 벗어나 예상과 다른 값으로 처리되는 문제입니다. NVD는 이 문제로 코드 실행이 가능해지고, 별도의 기존 실행 권한 없이 로컬 권한 상승으로 이어질 수 있으며, 악용 과정에서 사용자 조작은 필요하지 않다고 설명합니다. 공개된 AOSP 커밋에서는 Android에 포함된 SQLite 계열 구성요소가 수정되고 SQLite 3.44.5가 반영된 사실이 확인됩니다. 다만 SQLite 버전 변경이 이 취약점 수정과 직접 관련되는지는 공개 자료만으로 확인하기 어렵습니다.

이번 취약점의 구체적인 악용 절차와는 별개로, CWE-190 유형이 코드 실행으로 이어지는 일반적인 원리는 다음과 같습니다. 프로그램이 메모리 할당 크기나 배열 위치를 계산할 때 정수 오버플로우가 발생하면, 실제 필요한 크기보다 작은 메모리가 할당되거나 데이터가 의도하지 않은 위치에 기록될 수 있습니다. 이 상태에서 공격자가 조작한 입력이 처리되면 힙 메모리 손상으로 이어지고, 손상된 메모리 구조를 조작해 공격자가 준비한 코드를 실행할 수 있습니다. 과거 Android 미디어 처리 라이브러리(Stagefright)에서도 정수 오버플로우가 코드 실행으로 이어진 사례가 있었으며, 크기 계산 구간의 정수 연산은 반복적으로 확인되는 취약 지점입니다.

(2) 공격 메커니즘

이 취약점의 CVSS 벡터는 AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H입니다. AV:L은 공격자가 대상 기기에서 코드를 실행할 수 있는 로컬 위치를 먼저 확보해야 함을 뜻합니다. PR:N과 UI:N은 그 상태가 확보된 뒤에는 기존 권한이나 추가 사용자 조작이 요구되지 않는다는 의미입니다. 공개 정보로 확인할 수 있는 공격 흐름은 로컬 실행 경로 확보, 취약점 악용, 권한 상승의 순서입니다. 이 취약점은 원격 초기 침투 수단으로 단독 사용되는 유형은 아니며, 최초 실행 경로 확보에는 별도의 공격 수단이 필요합니다. 공개 정보만으로는 권한 상승 이후의 최종 영향 범위를 구체적으로 확정하기 어렵습니다.

(3) 영향 분석

영향 범위는 Android 14, 15, 16 및 Android 16 QPR2 베타 1~3 가운데 2026-06-01 보안 패치 레벨을 적용하지 않은 기기입니다. 이 취약점은 로컬 실행 경로가 필요하므로 원격에서 단독으로 기기를 침해하는 유형은 아닙니다. 다만 악성 앱 설치나 다른 취약점 등과 결합되면 권한 상승 단계에 사용될 수 있습니다. CVSS의 기밀성·무결성·가용성 영향이 모두 높게 산정된 것은 악용 성공 시의 잠재 영향을 뜻하며, 공개 시점에 동일한 피해가 모두 확인됐다는 의미는 아닙니다. Google이 제한적인 표적 공격에서의 악용 가능성을 언급했고 CISA가 KEV 목록에 등재한 만큼, 해당 버전을 사용하는 조직에서는 공개 익스플로잇의 존재 여부와 관계없이 이 취약점을 우선 패치 대상으로 판단해야 합니다.

3. 공격 시나리오

시나리오 1: 악성 앱 등 로컬 실행 경로와 결합 공식 앱 마켓 외부에서 설치된 악성 앱이나 다른 취약점을 통해 로컬 코드 실행 상태가 먼저 확보된 경우, 공격자는 CVE-2025-48595를 권한 상승 단계에 활용할 수 있습니다. 권한이 상승하면 기존 앱 권한만으로는 수행하기 어려운 후속 행위가 가능해질 수 있습니다.

시나리오 2: 표적 공격의 권한 상승 단계로 활용 Google이 제한적인 표적 공격에서의 악용 가능성을 언급한 점을 고려하면, 특정 개인이나 조직을 겨냥한 다단계 공격에서 이 취약점이 권한 상승 단계에 포함됐을 가능성이 있습니다. 이 경우에도 취약점 자체가 최초 침투를 수행하는 것은 아니며, 공격자는 앞선 단계에서 기기 내 실행 경로를 확보해야 합니다.

4. 대응 방안

(1) 즉시 조치

Android 14, 15, 16을 사용하는 기기는 최소 2026-06-01 이상, 가급적 해당 월의 전체 취약점을 포함하는 2026-06-05 이상 보안 패치 레벨을 적용해야 합니다. 제조사와 통신사별 배포 일정이 다를 수 있으므로 설정 화면의 Android 보안 업데이트 날짜를 직접 확인해야 합니다. 기업 환경에서는 MDM·EMM으로 관리 대상 기기의 패치 수준을 점검하고, 패치 전까지 공식 앱 마켓 외부 설치와 출처가 확인되지 않은 앱의 실행을 제한해야 합니다. 미국 연방기관은 CISA KEV 등재에 따른 BOD 22-01 조치 기한을 준수해야 하며, 민간 조직도 실제 악용 취약점으로 우선순위를 높여 대응할 필요가 있습니다.

(2) 장기 대응

Android 보안 게시판과 CISA KEV 목록을 정기적으로 확인하고 자산·패치 관리 절차에 반영해야 합니다. 기업 소유 기기와 업무용 개인 기기(BYOD)에 최소 보안 패치 수준을 정하고, 기준을 충족하지 않는 기기의 업무 시스템 접근을 제한하는 방안을 검토할 수 있습니다. 공식 앱 마켓 외부 설치 제한, 앱 출처 검증, 모바일 위협 방어 체계를 함께 적용하면 공격자가 로컬 실행 경로를 확보할 가능성을 낮출 수 있습니다. 패치 적용 여부를 단순 공지로 끝내지 않고 단말별 적용 결과를 확인할 수 있는 관리 절차도 필요합니다.

자체 소프트웨어를 개발하는 조직은 이번 취약점 유형(CWE-190)을 예방 관점에서 참고할 수 있습니다. 메모리 할당 크기와 배열 위치 계산에 사용되는 정수 연산에는 값의 범위 검증을 먼저 적용하고, C/C++ 환경에서는 오버플로우 검사 함수와 컴파일러의 정수 검사 옵션을 빌드·테스트 과정에 포함하면 유사한 결함을 배포 전에 발견할 수 있습니다. 크기 계산 결과가 예상 범위를 벗어나면 처리를 중단하도록 구현하는 것도 같은 유형의 문제를 줄이는 방법입니다.

5. IoC(침해 지표)

현재 공개된 IoC 없음.

6. 탐지 규칙

2026년 7월 말 기준 SigmaHQ와 Elastic의 공개 탐지 규칙 저장소에서 CVE-2025-48595를 직접 명시한 규칙은 확인되지 않았습니다. 세부 익스플로잇 정보와 침해 지표가 공개되지 않아 특정 로그나 파일만으로 악용 여부를 판별하기 어렵습니다. 현재는 보안 패치 적용, 비인가 앱 설치 통제와 관리 대상 단말의 패치 수준 확인이 우선입니다

7. 참고 자료 URL 목록

- https://nvd.nist.gov/vuln/detail/CVE-2025-48595

- https://source.android.com/docs/security/bulletin/2026/2026-06-01

- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-48595

- https://www.helpnetsecurity.com/2026/06/02/android-vulnerability-exploited-cve-2025-48595/

- https://www.sentinelone.com/vulnerability-database/cve-2025-48595/

- https://thehackernews.com/2026/06/google-june-2026-android-update-patches.html

1.2. 악성코드 수집 현황

TouchEn mVaccine을 통해 수집된 2026년 3월부터 6월까지 4개월간의 악성코드 수집·분류 자료를 정리했습니다.

월별 수집 건수는 3월 2,378건, 4월 2,563건, 5월 2,489건, 6월 2,385건입니다. DB 반영 건수는 3월 1,206건, 4월 1,094건, 5월 1,226건, 6월 1,076건입니다. 5월과 비교하면 6월 수집 건수는 4.2%, DB 반영 건수는 12.2% 감소했습니다. 수집 건수 대비 DB 반영 비율도 5월 약 49.3%에서 6월 약 45.1%로 낮아졌습니다. 수집이 4월 고점 이후 두 달 연속 줄어 3월 수준으로 되돌아온 가운데 반영 비율까지 낮아져, 6월은 최근 4개월 중 DB 신규 반영 건수가 가장 적은 달이었습니다. 반영 비율이 내부 분석·분류 기준의 영향을 받는 지표임을 감안하더라도, 수집과 반영이 함께 줄어든 6월은 DB 반영 대상이 된 신규·변종 샘플의 유입이 상대적으로 뜸했던 달로 평가합니다. 유형별 구성과 증감은 1.3절에서 별도로 분석합니다. VoicePhishing은 3월 6건, 4월 8건이 반영된 뒤 5월과 6월에는 모두 0건을 기록했습니다.

6월 주차별 수집 건수는 1주차 605건, 2주차 574건, 3주차 504건, 4주차 702건으로 4주차가 가장 많고 3주차가 가장 적었습니다. 5월은 1주차 626건, 2주차 595건, 3주차 652건, 4주차 616건으로 3주차가 가장 많아 6월과는 주차별 흐름이 달랐습니다. 4월은 1주차 784건으로 최근 4개월 가운데 주간 최고치를 기록한 뒤 2주차 595건, 3주차 541건, 4주차 643건으로 이어졌고, 3월은 1주차 555건, 2주차 655건, 3주차 527건, 4주차 641건이었습니다. 6월의 특징은 3주차까지 완만히 줄던 수집량이 4주차에 702건으로 급증하며 월말에 유입이 집중됐다는 점입니다. 4주차 702건은 최근 4개월에서 4월 1주차 784건 다음으로 높은 주간 수치입니다. 수집 일정에 따른 편차 가능성을 감안하더라도, 이 월말 집중 흐름이 7월 초에도 같은 흐름이 이어지는지 확인해야 합니다.

1.3. 악성코드 유형별 비율 및 전월 비교

2026년 6월 DB 반영 건수는 1,076건으로 5월 1,226건보다 12.2% 감소했습니다. 아래 분류에는 행위·위험 유형(Trojan, Adware, Riskware), 대상 플랫폼(Linux), 공격 수법(VoicePhishing), 일반·기타 분류(Generic, Etc)가 함께 포함됩니다. 단일 기준의 분류 체계가 아닌 만큼, 각 항목의 비율은 내부 DB 반영 결과의 구성비입니다.

월별 DB 반영 분류 현황은 아래 표와 같습니다.

6월 반영 건수를 유형별로 보면 Trojan이 604건(56.1%)으로 가장 많고, Riskware 350건(32.5%), Generic 74건(6.9%), Adware 40건(3.7%), Linux 4건(0.4%), Etc 4건(0.4%)이 뒤를 이었습니다. Trojan과 Riskware 두 유형이 전체 반영 건수의 대부분을 차지하는 구성은 6월에도 그대로였습니다.

전월보다 가장 크게 줄어든 유형은 Linux입니다. Linux는 3월 14건(1.2%)에서 4월 38건(3.5%), 5월 42건(3.4%)까지 늘어났다가 6월에는 4건(0.4%)으로 줄어 5월 대비 90.5% 감소했습니다. 감소 건수는 38건이며, 6월의 반영 건수와 비중은 Etc와 함께 전체 분류 가운데 가장 낮았습니다. 표본이 작아 증감률의 숫자 자체보다 흐름이 중요한데, 두 달 연속 이어지던 Linux 샘플 유입이 6월에 사실상 끊겼습니다. 4~5월의 증가가 일시적 유포였는지는 7월 반영 결과로 확인할 수 있습니다.

Etc는 3월 14건(1.2%), 4월 46건(4.2%), 5월 40건(3.3%)을 기록한 뒤 6월에는 4건(0.4%)으로 줄어 5월 대비 90.0% 감소했습니다. 여러 세부 분류가 합쳐지는 항목 특성상 정확한 원인은 세부 분류 확인이 필요하지만, Linux와 나란히 90% 안팎으로 급감한 점을 보면 6월에는 규모 분류군의 반영 건수가 전반적으로 감소했습니다. 6월 4건은 최근 4개월 중 가장 적은 수치입니다.

Adware는 3월 16건(1.3%), 4월 38건(3.5%), 5월 56건(4.6%)까지 늘어났다가 6월에는 40건(3.7%)으로 줄어 5월 대비 28.6% 감소했습니다. 절대 건수는 16건 감소했으며, 4월과 비교하면 2건 많은 수준입니다.

Generic은 3월 12건(1.0%), 4월 42건(3.8%), 5월 66건(5.4%), 6월 74건(6.9%)으로 넉 달 연속 늘어 5월보다 12.1% 증가했습니다. Trojan은 666건(54.3%)에서 604건(56.1%)으로 9.3%, Riskware는 356건(29.0%)에서 350건(32.5%)으로 1.7% 줄어 두 유형 모두 전월과 비슷한 수준을 유지했습니다. 전체 반영 건수가 12.2% 줄어든 가운데 이 두 유형의 감소 폭은 그보다 작았기 때문에, 건수는 줄었지만 비중은 전월보다 높아졌습니다.

최근 4개월 동안 Trojan과 Riskware는 각각 절반 안팎과 3분의 1 안팎을 차지하며 반영 건수 상위 두 분류를 유지했습니다. 6월 반영 건수 1,076건은 최근 4개월 중 가장 적었고, 수집 건수 대비 DB 반영 비율도 5월보다 낮아졌습니다. 전월 대비 감소는 Linux, Etc와 Adware에서 크게 나타났고, 증가한 분류는 Generic 하나였습니다. Generic은 3월 12건에서 6월 74건으로 넉 달 연속 증가했습니다. 이는 특정 패밀리로 세분화되지 않은 샘플의 비중이 계속 높아지고 있음을 뜻합니다. 신규 샘플 유입과 내부 분류·탐지 규칙 변경의 영향을 구분하기 위해, 주요 Generic 샘플을 다시 분류하고, 같은 기간의 탐지 규칙 변경 이력을 대조해야 합니다.

2. 루팅 및 에뮬레이터, 원격 앱 탐지 현황

2.1. 루팅 탐지 현황(Emulator)

모바일 금융·보안 애플리케이션에서는 루팅 상태와 에뮬레이터 실행 환경을 식별하는 기능이 주요 보안 통제 중 하나입니다. 아래 표는 2026년 7월 내부 시험에서 에뮬레이터의 루팅 상태를 탐지한 결과입니다.

전월과 동일한 시험 대상을 사용했으며, 표에 기재된 모든 항목에서 모든 항목이 전월과 동일하게 탐지됐습니다. 다만 이는 해당 버전과 내부 시험 조건에서의 결과이며, 패키지 변조나 별도의 루팅 은닉·후킹 기법을 추가 적용한 환경까지 포괄하지는 않습니다.

2.2. 루팅 탐지 현황(Real Device)

2026년 7월 실단말에서 루팅 관리·은닉 도구와 동적 계측 도구를 대상으로 탐지 시험을 수행했습니다. 전월 대비 시험 대상과 결과의 변경은 없었습니다. 결과는 표에 기재된 버전과 내부 시험 조건에 한정되며, 도구의 변조본이나 신규 은닉 모듈을 적용한 환경은 별도 시험이 필요합니다.

2.3. 에뮬레이터 탐지 결과

2026년 7월 에뮬레이터별 탐지 시험 결과는 다음과 같습니다. 전월 대비 시험 대상과 탐지 결과의 변경은 없었으며, 표에 기재되지 않은 신규 버전은 별도 검증 대상입니다.

2.4. 원격 탐지 현황

2026년 7월 원격 제어, 화면 공유와 기기 연동 기능을 제공하는 앱의 탐지 결과는 다음과 같습니다. 전월 대비 시험 대상과 결과의 변경은 없었습니다. 탐지 결과는 표에 기재된 정식 앱과 버전을 기준으로 하며, 리패키징 또는 변조된 앱은 별도의 확인이 필요합니다.

3. 국내외 보안 동향

3.1. 체크포인트 VPN 제로데이 취약점과 Qilin 랜섬웨어 연계 공격

1. 사건 요약

Check Point의 Remote Access VPN 및 Mobile Access 환경에서 사용자 인증을 우회할 수 있는 취약점(CVE-2026-50751)이 확인되었습니다. 이 취약점은 패치 공개 전부터 악용된 제로데이로, 인증을 거치지 않은 외부 공격자가 유효한 사용자 비밀번호 없이 VPN에 연결할 수 있습니다. Check Point는 전 세계 수십 개 조직을 대상으로 한 악용을 관측했으며, 한 사례에서 Qilin 랜섬웨어 제휴조직과 관련된 침투 후 활동을 확인했습니다. CISA는 2026년 6월 8일 KEV 목록에 등재하고 연방기관에 6월 11일까지 조치하도록 요구했습니다.

2. 확인된 사실

(1) 시간순 경과: 2026년 5월 7일부터 CVE-2026-50751 악용이 시작된 것으로 Check Point가 확인했습니다. 6월 4일 조사에 착수했고, 6월 8일 CISA가 이 취약점을 KEV 목록에 등재하면서 연방기관에 6월 11일까지 패치를 적용하도록 요구했습니다.

(2) 취약점의 성격: 영향 대상은 Check Point Remote Access VPN, Mobile Access 및 Spark 방화벽입니다. 실제 악용은 ① Remote Access VPN 또는 Mobile Access가 활성화되어 있고, ② 원격접속에 IKEv1을 사용하며, ③ 레거시 Remote Access 클라이언트를 허용하고, ④ 머신 인증서를 필수로 요구하지 않는 네 조건이 모두 충족된 구성에서 가능합니다. 인증서 검증 로직의 결함으로 인증을 거치지 않은 외부 공격자가 유효한 사용자 비밀번호 없이 VPN에 연결할 수 있으며, CVSS 3.1 점수는 9.3입니다. 같은 핫픽스는 IKEv1 사이트 간 VPN에서 중간자 공격이 가능한 CVE-2026-50752 (CVSS 7.4)도 함께 수정했으며, 이 취약점의 실제 악용은 확인되지 않았습니다.

(3) 랜섬웨어 연계: Check Point는 최소 1건에서 Qilin 랜섬웨어 제휴조직과 관련된 침투 후 활동을 관측했습니다. 다만 공격 주체가 Qilin 랜섬웨어를 사용하는 금전적 목적의 공격자라는 판단은 중간 신뢰도의 평가로 제시됐습니다.

3. 미확인 정보 및 주장

Check Point는 공격 인프라와 침투 후 행위를 근거로 Tox 프로토콜 사용 가능성과 Palo Alto Networks·Fortinet·F5의 다른 VPN 취약점 병행 악용 가능성을 제시했습니다. 이는 제조사 분석이며 각 제품의 개별 침해가 공식 확인된 것은 아닙니다. Kaupo Cloud HK, Shock Hosting, Vultr의 가상 서버가 공격에 사용된 정황도 관측됐으나, 모든 인프라가 동일 조직에 속하는지는 확인되지 않았습니다. 실제 데이터 유출이나 시스템 암호화가 발생한 조직 수는 공개되지 않았습니다.

4. 기술 분석

(1) 이번 사건에서 확인된 수법: 공격자는 IKEv1 기반 원격접속의 인증서 검증 로직을 악용해 유효한 사용자 비밀번호 없이 VPN에 연결했습니다. 취약 구성에서는 계정 탈취나 비밀번호 대입 없이 외부 접속이 가능했으며, 최소 1건에서 Qilin 랜섬웨어 제휴조직과 관련된 침투 후 활동이 확인됐습니다. VPN 접속 이후 내부 자원 접근이나 권한 확대에는 별도의 후속 행위가 필요합니다.

(2) 분석·추정 영역: Check Point는 공격 인프라와 침투 후 행위를 근거로 다른 제조사의 외부 노출 장비 취약점도 함께 악용됐을 가능성을 제시했습니다. 이 내용은 제조사의 분석이며, Palo Alto Networks·Fortinet·F5 제품의 개별 침해가 확인됐다는 의미는 아닙니다. 이번 사건에서 공식적으로 확인된 초기 진입점은 네 가지 조건을 모두 충족한 Check Point IKEv1 원격접속 구성입니다.

5. 영향 및 대응

확인된 영향: 전 세계 수십 개 기관에서 악용 활동이 관측되었고, 그중 1건에서 Qilin 랜섬웨어 제휴조직의 침투 후 활동이 확인되었습니다. 문제가 되는 설정 조건에 해당하는 조직은 비밀번호가 유출되지 않았더라도 외부에서 VPN 접속이 가능한 상태였습니다.

제조사·당국이 수행한 대응: Check Point는 긴급 수정 패치를 배포하고, IKEv2로의 전환과 머신 인증서 의무화를 권고했습니다. CISA는 KEV 등재와 함께 연방기관에 6월 11일까지 패치를 완료하도록 지시했습니다.

대응 권고: 먼저 네 가지 취약 설정 조건이 모두 충족되는지 확인하고 긴급 수정 패치를 적용해야 합니다. 패치 적용 후에도 2026년 5월 7일 이후 VPN 접속 기록에서 평소와 다른 지역·시간대·단말의 성공 접속을 점검하고, 의심 계정의 인증정보를 교체하며 활성 세션을 무효화해야 합니다. watchTowr가 6월 12일 취약점 재현 정보와 탐지 자료를 공개한 이후에는 기술 정보가 널리 공유된 상태이므로, 외부에 노출된 장비를 우선순위에 두고 패치와 로그 점검을 완료해야 합니다.

6. 시사점

이번 취약점의 노출 여부는 사용자 비밀번호의 강도보다 레거시 VPN 설정과 머신 인증서 적용 여부에 크게 좌우됐습니다. 계정 보안을 강화하더라도 IKEv1, 레거시 클라이언트 허용, 머신 인증서 미요구 설정이 함께 남아 있으면 인증 단계가 우회될 수 있습니다. 악용이 시작된 5월 7일과 제조사가 조사에 착수한 6월 4일 사이에는 약 한 달의 간격이 있으므로, 패치 적용만으로 조치를 끝내지 말고 해당 기간의 성공 접속 기록을 별도로 점검해야 합니다. CISA의 KEV 등재는 실제 악용 확인을 전제로 하므로, 일반 취약점보다 높은 우선순위로 다루는 것이 적절합니다. 재현 정보가 공개되면서 악용 진입장벽이 낮아진 만큼, 외부에 노출된 미패치 장비를 찾는 탐색과 악용 시도가 증가할 가능성이 있습니다. 이 단계에서는 장비의 노출 시간이 위험 수준을 좌우하므로, 외부 노출 장비의 패치 일정을 앞당겨야 합니다.

▶출처/참고자료:

- https://blog.checkpoint.com/security/check-point-releases-important-hotfix-for-vulnerabilities-in-deprecated-ikev1-vpn-protocol/

- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-50751

- https://labs.watchtowr.com/marking-your-own-homework-check-point-remote-access-vpn-ikev1-authentication-bypass-cve-2026-50751/

- https://www.bleepingcomputer.com/news/security/cisa-orders-feds-to-patch-check-point-flaw-exploited-by-ransomware-gangs/

- https://www.helpnetsecurity.com/2026/06/08/check-point-cve-2026-50751-qilin-ransomware/

3.2. Miasma 계열 공급망 공격의 PyPI·npm·GitHub 확산 사례

1. 사건 요약

2026년 5월 중순부터 6월 초까지 PyPI, npm 및 GitHub에서 인증정보 탈취와 자가 확산 기능을 갖춘 Miasma 계열 공급망 공격이 확인됐습니다. 명칭은 악성 코드에 남겨진 ‘Miasma: The Spreading Blight’ 문구에서 유래했으며, 보안 연구기관들은 코드와 행위의 유사성을 근거로 Shai-Hulud 계열로 분류합니다. durabletask 패키지, @redhat-cloud-services 패키지군과 Microsoft 계열 GitHub 저장소에서는 서로 다른 배포 방식이 사용됐습니다.

2. 확인된 사실

(1) PyPI durabletask 사건 — 2026년 5월 19일: 탈취된 게시 권한을 이용해 durabletask 1.4.1~1.4.3 악성 버전 3개가 PyPI에 게시됐습니다. 공개 분석은 패키지 저장소의 배포물이 직접 변조된 사건으로 설명하지만, 게시 권한이 탈취된 최초 경로는 공개 자료만으로 확정하기 어렵습니다.

(2) Red Hat 계열 npm 사건 — 2026년 6월 1일: @redhat-cloud-services 범위의 npm 패키지 32개와 90개 이상의 버전이 변조됐습니다. Microsoft는 원본 프로젝트(업스트림)의 CI/CD 파이프라인과 GitHub Actions OIDC 게시 절차가 악용됐다고 설명했습니다. 악성 패키지는 유효한 빌드 출처 증명을 포함했고, preinstall 훅으로 개발·클라우드 인증정보 수집과 추가 감염을 시도했습니다. 주간 다운로드 수 116,991건은 Phoenix Security 집계치로 기관별 범위에 따라 달라질 수 있습니다.

(3) 후속 npm 확산 — 2026년 6월 3~4일: 별도 후속 확산에서 57개 npm 패키지와 286개 이상의 악성 버전이 확인됐습니다. 일반적인 preinstall·postinstall 항목 대신 157바이트 binding.gyp 파일로 node-gyp 실행을 유도하는 “Phantom Gyp” 기법이 사용됐습니다. 이는 32개 @redhat-cloud-services 패키지 사건과 구분되는 별도 집계입니다.

(4) Microsoft GitHub 저장소 사건 — 2026년 6월 5일: Azure Functions Action을 포함한 Microsoft 계열 저장소에 악성 설정 파일과 코드가 삽입됐습니다. Claude Code, Cursor, Gemini CLI, VS Code의 프로젝트 설정을 이용해 저장소를 열거나 작업을 시작할 때 실행되도록 구성됐습니다. StepSecurity는 4개 Microsoft 조직의 저장소 73개가 약 105초 사이에 비활성화된 것으로 추정했지만, Microsoft나 GitHub가 공식 대응 시간을 발표한 것은 아닙니다.

(5) 공통 행위와 한계: 각 사건은 GitHub·npm 토큰, AWS·Azure·GCP, Kubernetes 등 개발·클라우드 인증정보를 수집하고 탈취한 권한을 추가 감염에 재사용하는 기능을 포함했습니다. 다만 모든 사건에서 동일한 코드와 배포 경로가 사용된 것은 아니며, 패키지 다운로드 또는 저장소 접근만으로 실제 인증정보 탈취 성공을 단정할 수 없습니다.

3. 미확인 정보 및 주장

최종 피해 조직 수는 공개되지 않았습니다. 패키지 다운로드 수와 악성 버전 수는 노출 규모를 보여주지만, 실제 코드 실행이나 인증정보 탈취 성공 건수와 동일하지 않습니다. PyPI·npm·GitHub 사건이 전 단계가 연결된 하나의 공격 체인인지는 확정되지 않았습니다.

4. 기술 분석

(1) 확인된 수법: npm 확산에서는 preinstall 훅이나 binding.gyp을 통해 설치 시 코드를 실행했고, PyPI 사건에서는 악성 배포물이 패키지 저장소에 직접 게시됐습니다. GitHub 저장소 사건은 Claude Code·Cursor·Gemini CLI·VS Code의 프로젝트 설정 파일을 악용해 개발자가 저장소를 열거나 세션을 시작할 때 실행되도록 했습니다. 유포 방식은 달랐지만 개발·클라우드 인증정보를 수집하고, 확보한 게시 권한을 후속 감염에 재사용한다는 목적은 공통적이었습니다.

(2) 분석·추정 영역: 일련의 공격에서는 preinstall, binding.gyp, 개발도구 설정 파일 등 서로 다른 실행 경로가 짧은 간격으로 사용됐습니다. 유포 방식이 달라 단일 설치 스크립트나 파일명만 탐지하는 방식으로는 전체 사례를 포괄하기 어렵습니다.

5. 영향 및 대응

확인된 영향: PyPI와 npm에는 악성 패키지 버전이 실제 게시됐고, Microsoft 계열 GitHub 저장소에는 악성 커밋이 삽입됐습니다. @redhat-cloud-services 패키지군의 주간 다운로드 수는 116,991건(Phoenix Security 집계)이었으나, 다운로드가 곧 악성 코드 실행이나 인증정보 탈취 성공을 의미하지는 않습니다. 탈취 대상에 개발 계정과 여러 클라우드 환경의 인증정보가 포함돼 있어 성공한 경우 피해가 개발 환경 밖으로 확대될 수 있습니다.

플랫폼·벤더가 수행한 대응: npm과 PyPI에서는 확인된 악성 버전이 제거됐고, GitHub는 악성 콘텐츠 유포 우려가 있는 Microsoft 계열 저장소를 비활성화했습니다. Microsoft와 보안 연구기관은 영향받은 패키지와 행위 기반 탐지 지표를 공개했으며, 관련 게시 토큰과 클라우드 인증정보 교체를 권고했습니다.

대응 권고: 검증된 정상 버전을 명시적으로 고정하고 package-lock.json과 같은 잠금 파일(lock file)을 저장소에서 관리해야 합니다. 영향 확인 전에는 npm install --ignore-scripts 또는 npm ci --ignore-scripts로 설치 스크립트 실행을 임시 차단하고, 필요한 스크립트만 검토 후 허용할 수 있습니다. 문제 버전을 설치했거나 영향을 받은 저장소를 AI 코딩 도구·IDE에서 연 이력이 있으면 개발자 계정, npm·GitHub 토큰, CI/CD 비밀정보와 클라우드 인증정보를 점검하고 교체해야 합니다.

6. 시사점

이번 공격은 공개 CVE보다 패키지 게시 권한과 CI/CD 권한, 개발 환경의 자동 실행 설정을 집중적으로 악용했습니다. 인증정보가 탈취되면 정상 조직의 이름과 게시 절차를 이용해 악성 패키지나 빌드 결과물을 배포할 수 있으므로 토큰의 발급·보관·회수와 최소 권한 관리가 필요합니다.

AI 코딩 도구와 IDE의 프로젝트 설정도 공급망 공격 경로가 될 수 있습니다. 저장소를 열거나 세션을 시작하는 동작만으로 명령이 실행되지 않도록 Claude Code·Cursor·Gemini CLI·VS Code의 프로젝트 단위 설정과 자동 실행 작업을 검토해야 합니다.

유효한 빌드 출처 증명과 Sigstore 서명은 “어디에서 어떤 절차로 만들어졌는지”를 확인하는 수단이며, 배포 절차 자체가 침해된 경우 코드의 안전성까지 보장하지 못합니다. 출처 증명 검증과 함께 잠금 파일(lock file) 무결성, 변경 이력, 실행 행위와 게시 권한을 교차 점검해야 합니다. 이번 사례에서 preinstall, binding.gyp, 개발도구 설정 파일로 실행 경로가 연속적으로 바뀐 점을 고려하면, 단일 설치 훅이나 파일명 차단만으로는 유사 공격을 충분히 통제하기 어렵다고 판단합니다. 따라서 개발 환경에서 자동 실행되는 지점을 목록화하고 기본 차단 정책을 적용해야 합니다.

▶출처/참고자료:

- https://www.microsoft.com/en-us/security/blog/2026/06/02/preinstall-persistence-inside-red-hat-npm-miasma-credential-stealing-campaign/

- https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-again-azure-functions-action-and-72-other-repositories-disabled-after-supply-chain-attack-targeting-ai-coding-agents

- https://phoenix.security/miasma-azure-hades-pypi-supply-chain-worm-2026/

- https://snyk.io/blog/node-gyp-supply-chain-compromise-self-propagating-npm-worm-binding-gyp/

- https://docs.npmjs.com/cli/v11/commands/npm-ci/

3.3. 노팅엄대학교 학생·동문 개인정보 유출

1. 사건 요약

영국 노팅엄대학교는 2026년 6월 9일 Campus Solutions 학생기록 시스템에서 비인가 활동을 확인하고 6월 10일 사고를 공개했습니다. 대학은 학생기록 플랫폼을 지원하는 외부 업체의 Oracle WebLogic 기반 플랫폼 취약점을 통해 시스템 일부가 침해됐다고 밝혔습니다. 피해 인원은 공식 확정되지 않았으며, Have I Been Pwned(HIBP)는 공개된 데이터셋에서 약 45만 5천 개 계정을 확인했습니다. 공개 데이터에서 확인된 노출 항목에는 연락처, 생년월일, 여권번호, 시민권 상태, 인종·장애 관련 정보, 학사·재정 정보가 포함됐습니다. 대학은 초기 통지에서 국민보험번호(영국의 사회보장 식별번호)와 보호 특성 정보(인종·장애 등 영국 차별금지법상 민감정보)가 접근됐을 가능성도 안내했으나, 이는 조사 중인 잠정 범위입니다. 대학은 시스템 격리와 포렌식 조사를 진행하고 감독·수사기관에 신고했으며, 피해자에게 신용 모니터링을 제공했습니다.

2. 확인된 사실

(1) 시간순 경과: 대학은 6월 9일 Campus Solutions 학생기록 플랫폼에서 비인가 활동을 확인하고 6월 10일 침해 사실을 공개했습니다. 6월 17일 후속 발표에서는 포렌식 조사 결과 외부 업체가 운영하는 Oracle WebLogic 기반 플랫폼의 취약점이 악용됐다고 설명했습니다. 대학은 파일을 암호화하는 랜섬웨어 공격이나 내부 실수로 인한 유출이 아니며, 직접적인 금전 요구도 받지 않았다고 밝혔고, East Midlands Special Operations Unit (EMSOU)이 형사 수사를 진행하고 있습니다.

(2) 침투 경로: 대학은 Oracle WebLogic 기반 외부 플랫폼의 취약점이 악용됐다고 발표했지만 CVE 번호는 공개하지 않았습니다. Oracle은 6월 10일 PeopleSoft Enterprise PeopleTools의 Updates Environment Management 구성요소에서 인증 없이 원격 코드 실행(RCE)이 가능한 CVE-2026-35273 (CVSS 9.8)을 공개했습니다. Mandiant는 5월 27일부터 6월 9일까지 ShinyHunters 계열 UNC6240이 이 취약점을 악용한 교육기관 대상 캠페인을 확인하고, 취약 엔드포인트가 의심되는 전 세계 100개 이상 조직에 통지했습니다. 이 가운데 68%가 고등교육기관이었습니다. 사건 시기와 대상 환경은 일치하지만 노팅엄대학교는 해당 CVE를 직접 확정하지 않았습니다.

(3) 유출 규모와 항목: HIBP는 공개된 데이터셋에서 약 45만 5천 개 계정을 확인했습니다. 공개 데이터에서 확인된 노출 항목은 이름, 주소, 전화번호, 생년월일, 여권번호, 시민권 상태, 인종·장애 관련 정보, 학사정보와 결제·재정정보입니다. 한편 대학은 학생·동문에게 보낸 초기 통지에서 조사 중인 잠정 범위로 국민보험번호와 보호 특성 정보가 접근됐을 가능성을 안내했습니다. 국민보험번호는 대학이 조사 초기 단계에서 안내한 항목이며, 공개 데이터에서 확인된 항목에는 포함되지 않습니다. 유출 데이터의 용량에 대해 공격자 측은 약 40GB 탈취를 주장했으며, HIBP 분석 기준으로 실제 공개된 데이터셋은 약 10GB 수준입니다. 대학이 검증한 정확한 파일 용량은 공개되지 않았습니다.

(4) 영향 대상 범위: 대학 공식 성명은 특정 캠퍼스를 명시하지 않고, 재학생과 일부 동문·지원자의 개인정보가 접근됐을 수 있다는 전제로 대응 중이라고 밝혔습니다.

(5) 금전 요구: 대학은 금전적 몸값 요구를 받은 바 없다고 밝혔습니다.

3. 미확인 정보 및 주장

ShinyHunters가 이번 공격의 배후를 자처했고 유출 자료를 공개한 것으로 알려졌습니다. 대학은 “잘 알려진 사이버 범죄 조직”이라고만 언급했으며 특정 조직을 공식 배후로 지목하지 않았습니다. 공격자 측이 제시한 정확한 탈취 용량과 해외 캠퍼스 침해 주장은 대학 발표로 확인되지 않았습니다.

4. 기술 분석

(1) 확인된 수법: 대학 공식 발표에서 확인된 내용은 Campus Solutions를 지원하는 외부 Oracle WebLogic 기반 플랫폼의 취약점이 악용됐다는 점입니다. Oracle이 공개한 CVE-2026-35273은 PeopleSoft PeopleTools의 Environment Management 구성요소에서 인증 없이 원격 코드 실행으로 이어질 수 있는 취약점입니다. Mandiant가 관측한 교육기관 대상 캠페인의 시기와 환경은 노팅엄대학교 사고와 일치하며, 본 보고서는 CVE-2026-35273을 이번 사고의 유력한 침투 경로 기술합니다.

(2) 분석 영역: 응용 프로그램 계정과 권한을 통제하더라도 그 아래 PeopleSoft·미들웨어 계층에서 인증 없는 코드 실행이 가능하면 학생기록 데이터에 접근할 수 있습니다. 따라서 학사 시스템 점검에서는 화면·업무 기능뿐 아니라 PeopleTools, 애플리케이션 서버와 Environment Management 구성요소의 외부 노출 및 패치 상태를 별도로 관리해야 합니다.

5. 영향 및 대응

확인된 영향: 학생기록 시스템 일부에 비인가 접근이 발생해 개인정보가 유출됐습니다. 대학은 공식 피해 인원을 확정하지 않았으며, HIBP가 공개 데이터셋에서 확인한 계정은 약 45만 5천 개입니다. 공개 데이터에서 확인된 항목에 여권번호와 생년월일처럼 변경이 어렵거나 장기간 사용되는 식별자가 포함돼 장기적인 신원 도용 위험이 남습니다.

대학이 수행한 대응: 노팅엄대학교는 이상 활동 확인 직후 시스템을 격리하고 외부 전문업체 및 영국 교육·연구 전산망 기관 JISC와 포렌식 조사를 진행했습니다. 정보위원회(ICO), Action Fraud, 영국 학생지원기구(OfS) 등에 사고를 신고했으며, 지원 헬프라인과 TransUnion TrueIdentity를 통한 12개월 무료 신용 모니터링을 제공하고 있습니다.

대응 권고: 여권번호와 생년월일처럼 변경이 어렵거나 장기간 사용되는 식별자가 유출된 경우 비밀번호 변경 안내만으로는 충분하지 않습니다. 관련 식별자를 본인 확인에 사용하는 서비스는 추가 검증과 이상 거래 모니터링을 적용해야 합니다. 국내 대학과 기업도 학사·인사 시스템의 PeopleTools·미들웨어·애플리케이션 서버 패치 상태와 외부 노출 여부를 업무 애플리케이션과 분리해 점검할 필요가 있습니다.

6. 시사점

여권번호·생년월일과 민감정보는 비밀번호처럼 쉽게 변경할 수 없어 장기적인 신원 도용 위험이 남습니다. 동문·지원자 정보도 유출 대상에 포함된 만큼 보유 기간, 목적 종료 후 삭제와 재학생 데이터와의 분리 보관 정책을 점검해야 합니다. Mandiant가 통지한 의심 엔드포인트 가운데 고등교육기관의 비중이 높았다는 점에서 PeopleSoft를 운영하는 교육기관이 유사한 외부 노출과 패치 상태를 별도로 점검해야 할 근거가 됩니다. Mandiant가 통지한 의심 엔드포인트 가운데 고등교육기관의 비중이 높았다는 점에서, PeopleSoft 계열 환경을 운영하는 교육기관은 우선 점검 대상으로 보는 것이 타당합니다. 이번 사건에서 드러난 위험은 개별 대학의 애플리케이션 관리에 그치지 않고, 학사 미들웨어의 외부 노출과 패치 관리라는 여러 교육기관에 공통된 운영 위험에 해당합니다. 같은 구성을 운영하는 국내 기관이라면 침해 정황이 없더라도 선제 점검 대상에 포함해야 합니다.

▶출처/참고자료:

- https://www.nottingham.ac.uk/Home/Alerts/Cyber-attack-incident.aspx

- https://www.securityweek.com/university-of-nottingham-confirms-breach-after-hackers-leak-data/

- https://www.theregister.com/cyber-crime/2026/06/11/shinyhunters-raids-nottingham-uni-for-student-alumni-data/5253961

- Oracle, CVE-2026-35273 보안 권고

- Google Cloud/Mandiant, ShinyHunters targets education sector

- Have I Been Pwned, University of Nottingham 데이터셋 등록 공지

3.4. 이란 주요 은행 4곳 대상 사이버 공격과 결제 서비스 중단

1. 사건 요약

2026년 6월 이란의 주요 국영은행을 대상으로 두 차례의 사이버 공격과 서비스 중단이 발생했습니다. 6월 14일에는 4개 은행이 공유하는 통신 인프라에서 디지털뱅킹과 결제 처리가 중단됐고, 6월 23일에는 3개 은행의 카드 결제 시스템 장애로 ATM과 POS 단말기 이용에 광범위한 차질이 발생했습니다. 당국은 1차 공격에서 고객 계좌와 데이터의 무단 접근·삭제·변조는 확인되지 않았다고 발표했으며, 2차 공격의 데이터 무결성 영향은 공개하지 않았습니다. Black Wolves가 배후를 자처했지만 당국은 공격 주체를 공식 지목하지 않았고 두 공격의 동일 주체 여부도 확인되지 않았습니다.

2. 확인된 사실

(1) 1차 — 2026년 6월 14일: Bank Melli Iran, Bank Tejarat, Bank Saderat Iran, Export Development Bank of Iran 등 4개 은행이 공유하는 통신 인프라에서 장애가 발생해 디지털뱅킹, 결제 처리와 온라인 거래가 중단됐습니다. 이란 은행조정협의회(Banking Coordination Council)는 공유 네트워크의 이상 활동을 확인한 뒤 비상대응 절차에 착수하고 영향받은 시스템을 격리했다고 밝혔습니다.

(2) 2차 — 2026년 6월 23일: 3개 은행의 카드 기반 결제 시스템이 공격을 받아 ATM, POS 단말기와 모바일 앱의 카드 기능에 전국 단위 장애가 발생했습니다.

(3) 데이터 피해 여부: 6월 14일 1차 공격에 대해 협의회는 고객 계좌와 데이터의 무단 접근·삭제·변조가 없었다고 발표했습니다. 6월 23일 2차 공격에서는 고객 자산 보호를 위해 카드망 일부를 선제적으로 차단했다고 밝혔으나, 데이터 무결성 영향은 공개하지 않았습니다. 현재 공개된 직접 피해는 정보 유출보다 서비스 가용성 저하에 집중됩니다.

(4) 영향 범위: 해당 은행의 디지털뱅킹과 결제 서비스에 광범위한 장애가 발생했고, 일부 지역에서는 ATM·POS 단말기와 주유소 카드 결제에도 차질이 보고됐습니다. 현지 보도는 일부 서비스 장애가 2주 이상 이어졌다고 전했지만, 이 기간이 모든 은행과 서비스에 동일하게 적용된 것은 아니며 기관별 완전 복구 시점도 공식 집계되지 않았습니다. 장기 장애 보도는 일부 서비스에 대한 현지 보도이며, 은행별 실제 복구 상태와는 차이가 있을 수 있습니다.

3. 미확인 정보 및 주장

Black Wolves는 텔레그램에서 공격 배후를 자처하며 “조용한 전쟁이 벌어지고 있으며 이란은 사이버 공격을 받고 있다”고 주장했습니다. 이는 공격자 측의 직접 주장으로, 이란 당국이나 독립 조사기관이 관여 사실을 확인하지 않았습니다. 구체적인 공격 기법과 1차·2차 공격의 동일 주체 여부도 공개되지 않았습니다.

4. 기술 분석

현재 공개 자료에는 최초 침투 경로, 사용된 도구와 구체적인 공격 방식이 포함되어 있지 않아, 이번 공격을 DDoS, 내부 시스템 침해, 파괴형 공격 가운데 특정 유형으로 분류하기 어렵습니다. 다만 1차 공격에서는 복수 은행이 공유하는 통신 인프라에서, 2차 공격에서는 카드 결제망에서 장애가 발생해 여러 기관과 서비스로 확산됐습니다. 기술적으로 확인되는 핵심 위험은 공통 인프라의 장애가 개별 은행의 디지털뱅킹·ATM·POS 서비스로 그대로 전파됐다는 점입니다.

5. 영향 및 대응

확인된 영향: 1차 공격으로 4개 은행의 디지털뱅킹과 결제 처리가 중단됐고, 2차 공격으로 3개 은행의 ATM·POS 및 모바일 카드 기능에 전국 단위 장애가 발생했습니다. 1차 공격에서는 고객 계좌와 데이터의 무단 접근·삭제·변조가 없었다고 당국이 발표했지만, 2차 공격의 데이터 무결성 영향은 공개되지 않았습니다. 현재 확인된 직접 피해는 개인정보 유출보다 결제와 금융 서비스의 가용성 저하에 집중됩니다.

당국·은행이 수행한 대응: 이란 은행조정협의회는 이상 행위를 감지한 뒤 긴급대응 체계로 전환해 영향받은 시스템을 격리했습니다. 은행들은 고객 자산 보호를 위해 일부 카드망을 선제적으로 차단하고 사고 원인 조사와 서비스 복구를 진행했습니다. 일부 장애가 장기화됐다는 현지 보도가 있으나, 은행별 복구 범위와 완료 시점은 공식적으로 통합 공개되지 않았습니다.

대응 권고: 이번 사건의 핵심 영향은 서비스 가용성 저하이므로 유출 방지뿐 아니라 업무 연속성 관점의 점검이 필요합니다. 여러 금융기관이 공동으로 사용하는 통신망, 카드 승인·결제 중계 구간과 인증 인프라의 의존 관계를 식별하고, 각 구간이 중단됐을 때 사용할 대체 경로와 수동 처리 절차를 검증해야 합니다. 고객 안내 채널과 비상 연락 수단이 중단된 업무 시스템과 같은 인프라에 종속돼 있지 않은지도 함께 확인해야 합니다.

6. 시사점

공동 통신 인프라의 장애가 여러 은행의 서비스 중단으로 이어진 만큼, 금융 사고의 영향은 유출 건수뿐 아니라 결제·거래 기능의 중단 범위와 복구 시간으로도 평가해야 합니다. 6월 14일과 23일의 공격이 동일 주체에 의한 연속 공격인지는 확인되지 않았으므로 현재 단계에서는 별개 사건으로 구분해 대응하는 것이 적절합니다. 다만 짧은 기간에 통신망과 카드 결제망에서 각각 장애가 발생한 만큼, 사고가 확인된 시스템뿐 아니라 여러 기관이 공통으로 의존하는 인프라 구간과 인접 인프라까지 점검 범위에 포함해야 합니다. 복구 계획도 개별 은행 시스템뿐 아니라 공통 서비스 중단을 기준으로 시험해야 합니다. 공개 자료에서 확인된 핵심 피해가 정보 유출보다 장기간의 서비스 장애에 집중됐다는 점을 고려하면, 금융권 사이버 위협 대응 범위를 유출 차단뿐 아니라 공동 인프라 복구 역량까지 확대해야 합니다. 공동망 의존도가 높은 구조에서는 개별 기관의 통제만으로는 충분히 줄이기 어려운 동시 중단 위험이 발생할 수 있으므로, 복구 목표 시간은 개별 기관이 아니라 공동 인프라 단위로 설정하는 편이 효과적입니다.

▶출처/참고자료:

- https://thepaypers.com/fraud-and-fincrime/news/cyberattack-disrupts-services-at-four-major-iranian-banks

- https://english.aawsat.com/world/5287824-cyberattack-hits-state-banks-iran

- https://iranwire.com/en/news/154127-islamic-republic-confirms-cyberattack-on-banking-infrastructure/

- https://iranwire.com/en/news/154374-major-cybersecurity-failure-four-largest-iranian-banks-face-3rd-week-of-outages/