ConnectWise 공급망 공격 분석:
ARTEX·M365 백업 앱 권한 악용과 대응 [2026]

마이크로소프트는 2026년 10월 21일 ConnectWise Cloud Backup(구 SkyKick Backup) 공급망 침해를 중국 국가 연계 조직 Storm-0940의 소행으로 평가하고, 이 조직이 AI 침투 테스트 프레임워크 ARTEX로 2,250곳이 넘는 Microsoft 365 테넌트에 로그인을 시도했다고 밝혔다. 공격자는 고객이 관리자 동의로 붙여 둔 백업·관리 앱의 자격 증명으로 들어와 사용자 MFA가 적용되지 않았고, Huntress가 본 한 테넌트에서는 앱이 스스로 전역 관리자가 된 뒤 약 5분 만에 다른 앱 2개에 2028년 만료 비밀을 심었다. 이 앱을 쓰거나 쓴 적이 있다면 오늘 앱을 비활성화하고, 로그를 내보내고, 10월 13일 이후 추가된 앱 자격 증명과 역할 할당을 찾는다.

실제 침해 테넌트 수, 데이터 유출 여부, 앱 자격 증명이 처음 새어 나간 경로는 공개되지 않았다. AI가 쓰인 다른 실제 사고는 AI 해킹 사고 사례 2026에 모았다.

한눈에 보기

무슨 일이 있었나: 타임라인

시각은 UTC다(한국 시각은 9시간 더한다).

• 10-10~14: 144.172.64[.]99가 8개 조직의 계정 327개에 패스워드 스프레이를 벌였다. 실패 151,000건 이상, 성공 0건(마이크로소프트).
• 10-14: ConnectWise가 문제를 발견했다(FAQ).
• 10-15: 01:58부터 앱의 역할 자기 할당(벤더 자동화 가능성), 03:44 한 테넌트의 전역 관리자 획득·백도어 비밀 추가, 06:13~08:44 144.172.64[.]128의 테넌트별 Graph 토큰 획득, 09:25~14:20 정책·국가안보·무역·핵심광물 분야 16개 테넌트 표적 시도(실패)가 이어졌다(Huntress, Todyl).
• 10-16~17: ConnectWise 첫 공지(16일 17:47), Cloud Backup 앱 접근 차단(17일 05:01), 앱 신원 7개 비활성화(07:00). 마이크로소프트 위협 인텔리전스 첫 공지(07:16).
• 10-18~21: ConnectWise 점검 가이드 공개(18일)와 계정·자격 증명 전면 재설정(19일). 마이크로소프트의 Storm-0940·ARTEX 분석과 ConnectWise의 귀속 발표(21일).
• 10-25: ConnectWise가 26일부터 기존 백업 복원을 먼저 열겠다고 공지했다.

공격 흐름 단계별 분석

출처마다 본 테넌트가 달라 모든 단계가 모든 테넌트에서 일어나지는 않았다.

1단계 패스워드 스프레이: 성공 0건

• 무엇을: 144.172.64[.]99의 스프레이는 10월 11일 분당 2,900회로 정점이었고 응답의 약 98%가 계정 잠금, 성공한 인증·토큰 발급은 없었다(마이크로소프트). Huntress도 13~14일 144.172.64[.]128의 로펌 테넌트 4곳 스프레이와 curl/7.88.1 토큰 요청을 봤다.
• 의미와 흔적: 스프레이가 앱 자격 증명 탈취 경로라는 근거는 없고, 마이크로소프트는 IP 대역 일치로 두 활동을 연결했다. 사용자 로그인 로그에서 144.172.64.x 실패와 잠금이 몰린 계정을 본다.

2단계 벤더 앱 신원 장악: 경로 미확인

• 무엇을: ConnectWise는 애플리케이션 신원 침해를 확인했다. 제품 취약점 관여 여부는 확인되지 않았고 최초 노출 경로는 조사 중이다(FAQ). ATT&CK T1195, T1528.
• 흔적: 고객 테넌트에는 없다. 앱 등록과 벤더 관리 자격 증명은 ConnectWise 테넌트에 있어 고객에게 보이지 않는다(ConnectWise 가이드). Huntress가 본 자격 증명 유형도 벤더 쪽 client assertion이었다.

3단계 고객 테넌트에 앱 전용 로그인

• 무엇을: OAuth 2.0 클라이언트 자격 증명 흐름으로 테넌트마다 Graph 앱 전용 토큰을 받았다. 사용자 상호작용이 없어 MFA와 사용자용 조건부 액세스가 적용되지 않았다. 테넌트 GUID 오름차순으로 돌았다(Todyl). ATT&CK T1199.
• 얻은 권한: 앱에 동의된 권한 그대로다. Todyl 기준 Cloud Backup 앱은 전체 사서함(EWS), OneDrive·SharePoint, Teams 채팅 읽기·쓰기와 복원 권한을 가졌고, 마이크로소프트는 Directory.ReadWrite.All 같은 고권한이 악용됐을 가능성이 높다고 봤다.
• 흔적: Entra의 Sign-in logs > Service principal sign-ins 탭(사용자 로그인 탭에는 없다)에서 앱 ID로 거르고 묶인 행은 펼쳐 본다(ConnectWise). 정상 백업은 마이크로소프트 내부 IPv6(fd00:: 대역)에서 인증했고, 악성 로그인은 VPS의 IPv4, Python-urllib/3.12, 자격 증명 유형 clientAssertion, 조건부 액세스 notApplied, AS14956(RouterHosting)이었다(Todyl).

4단계 역할 자기 할당과 백도어 비밀

• 무엇을: Huntress가 본 한 테넌트에서 10월 15일 03:44 Cloud Management Teams 앱이 스스로 전역 관리자가 되고, Python-urllib/3.12 스크립트로 테넌트의 다른 앱 2개(MSP 관리 앱, 보안 업체 앱)에 2028년 만료 클라이언트 비밀을 추가했다(약 5분). 두 번째 테넌트의 활동도 2분 안팎 차이였고, 백도어를 심을 앱은 무작위로 고른 것으로 보였다. ATT&CK T1098.003, T1098.001.
• 미확정: 이 변경은 144.172.64[.]128의 첫 인증(06:13)보다 약 2시간 30분 앞섰고 마이크로소프트 내부 IPv6에서 온 것으로 기록됐다. Huntress는 두 단계를 같은 행위자로 묶지 않았다. 01:58부터 약 50곳의 역할 자기 할당(주로 Exchange 관리자)은 벤더 앱의 User-Agent(kiota-dotnet)라 벤더 자동화일 수 있다.
• 흔적: 아래 표의 RoleManagement·ApplicationManagement 감사 기록. Defender XDR 경고는 'Application self-assigned Global Administrator role'이다.

5단계 후속 접근: 정찰과 Key Vault

• 무엇을: 마이크로소프트는 일부 환경에서 Graph 정찰, 앱 자격 증명 수정, ID·그룹·특권 역할 변경을 확인했고 이런 변경은 원래 앱을 정리한 뒤에도 백도어로 남는다고 경고했다. Defender for Key Vault 탐지 설명에는 Key Vault 비밀 대량 읽기와 키 언랩이 나오지만 범위는 공개되지 않았다. ATT&CK T1555.006.
• 확인된 범위: Huntress는 검토한 테넌트에서 사서함·파일 조작을 찾지 못했다. ConnectWise는 확인된 하류 고객 침해가 없지만 무단 활동이 없었다는 보증은 아니라고 했다.
• 흔적의 한계: Graph 디렉터리 읽기는 감사 흔적이 없다(Huntress). 요청별 출발지 IP는 미리 켠 MicrosoftGraphActivityLogs에만 남아, 없으면 정상 백업 읽기와 공격자 읽기를 가를 수 없다(Todyl).

AI는 정확히 무엇을 했나

AI가 한 일(마이크로소프트 서술)

• Storm-0940은 늦어도 9월부터 ARTEX로 수백 개 조직 공격을 자동화했고, ConnectWise 건에서는 정찰, 패스워드 스프레이, OAuth 앱 악용을 '기계 속도'로 가속했다. '공격자를 대신한 AI 에이전트'가 탈취한 앱 자격 증명으로 인증해 일부 환경에서 Graph·디렉터리 작업까지 했고, 그림 1에는 앱 자격 증명 4개로 4분 안에 200회 넘게 로그인한 수치가 있다.
• ARTEX는 어떤 AI 모델이든 붙이는 오픈소스 다중 에이전트 LLM 침투 테스트 도구이고, 10월 8일 비공개로 바뀔 때 포크가 12,000개를 넘었다(Wiz). 구조와 탐지 규칙은 ARTEX 한국어판 탐지 규칙과 한계에 있다.

사람이 한 일과 공개되지 않은 것

• 붙인 AI 모델과 단계별 AI 판단을 보여 주는 설정·세션 기록은 공개되지 않았다. 16개 테넌트 표적 시도의 두 번째 묶음은 수동으로 보였다(Huntress).
• 테넌트 GUID 정렬 순회는 정렬된 목록을 도는 단순 스크립트와도 맞아 AI 판단의 증거로 보기 어렵다(분석).
• Wiz는 같은 행위자와 겹치는 활동에서 에이전트형 신호를 봤다. 소스맵을 받은 몇 분 뒤 그 안의 내부 API를 불렀고, 막히면 다른 엔드포인트나 새 IP로 옮겼으며, 세션이 24~30시간 이어졌다.

과장된 해석 바로잡기

• '2,250곳 해킹'이 아니다. 원문은 로그인 '시도'다. 마이크로소프트와 ConnectWise 모두 실제 침해 테넌트 수를 밝히지 않았다.
• 'MFA 우회'가 아니다. 처음부터 MFA가 걸리지 않는 앱 전용 인증 경로였다. 원문도 '대화형 사용자 로그인 없이'라고 썼다.
• ScreenConnect·RMM 경로가 아니다. ConnectWise는 다른 제품의 영향 징후가 없다고 했으니 ScreenConnect 감사 로그는 이번 흔적을 찾을 곳이 아니다.
• 한국 금융권 공격 조직과 같다는 근거는 없다. 마이크로소프트는 한국 금융기관 유출을 ARTEX가 쓰인 보도 사례로만 들었다. 한국 건은 Recorded Future가 TAG-217로 따로 추적하고(보안뉴스 보도), Wiz는 마이크로소프트와 Zscaler가 ARTEX를 서로 다른 두 행위자와 연결했다고 정리했다. 보안뉴스·한국경제 기사 제목의 한국 금융권 연결은 같은 도구라는 뜻이다. 금융권 사건은 금융권 16개사 침해사고 분석에 있다.
• '3시간 만에 특권 접근'은 캠페인 전체 설명이다. 수백 개 조직 대상 캠페인에 그런 사례가 여러 건이라는 뜻이지 ConnectWise 고객 테넌트마다의 수치가 아니다.

왜 뚫렸나: 원인

• 자격 증명 하나가 동의한 모든 테넌트에서 통한다. 게시자가 쥔 자격 증명 하나로 동의한 모든 테넌트의 토큰을 받는다(Todyl). 그 자격 증명은 고객이 바꾸거나 감시할 수 없다.
• 앱 전용 인증은 사람용 보호 장치 밖이다. 워크로드 ID는 MFA를 할 수 없고, 워크로드 ID용 조건부 액세스는 테넌트에 등록된 단일 테넌트 서비스 주체에만 적용되며 Workload Identities Premium 라이선스가 필요하다(Microsoft Learn).
• 백업·관리 앱 권한이 원래 넓다. 디렉터리 역할을 할당할 수 있는 앱은 스스로 전역 관리자가 될 수 있어, 벤더 자격 증명 교체는 '필요하지만 충분하지 않다'(Huntress).
• 쓰지 않는 연결도 살아 있었다. Todyl이 본 범위에서 백업 구독이 없는 테넌트 9곳도 앱이 남아 대상이 됐다.
• 로그가 짧다. Entra 감사·로그인 기록은 Free 7일, P1·P2 30일이고 라이선스를 올려도 소급되지 않는다. Graph 활동 로그는 P1·P2에서 켠 시점부터 쌓인다(Microsoft Learn). 10월 26일 기준으로 계산하면 Free 테넌트의 10월 15일 기록은 이미 지워졌고 P1·P2도 11월 14일 무렵 사라진다.
• 안내가 실제 관리자에게 늦게 닿는다. ConnectWise는 리셀러·유통사에 안내를 고객 테넌트 관리자에게 전하라고 거듭 요청했다. MSP를 거쳐 쓰는 조직은 이 경로를 확인한다. 협력사 관리 일반론은 RMM 공급망 리스크 점검 가이드에 있다.

우리 조직에서 찾아볼 흔적

조사 기간은 최소 10월 13일부터, 기록이 있으면 서비스 주체 로그인은 10월 1일부터다(ConnectWise). 공개 IP로만 좁히지 않는다.

• 앱 ID 8개: 506e08f9-6e9a-4da4-942b-a099a03644ae(Cloud Backup), 2399d300-6fca-4e6a-a686-399fefe75b83, 24205314-2b89-4e07-a2a4-579e898a5640(Teams), b78f6a77-d4e5-46fb-87e5-d1648bd02519, 0de14c77-b9b0-4137-9360-34878a929827, 412dcf96-176d-4b3a-a1b0-4981ad66971e, b2b55f5b-7758-4719-8d8f-88ae172e6bdb(이상 10월 17일 비활성화), c921256f-04a7-44e8-9b2a-69c33929ba19(FAQ의 비활성화 권고). 마이크로소프트 쿼리에는 3개만 있어 8개 모두 본다(분석).
• 지표: IP 144.172.64[.]128·[.]99·[.]60과 10월 15~16일 VPN IP 187.15.88[.]186·187.15.90[.]217·187.15.89[.]186(마이크로소프트), 144.172.94[.]243(Huntress). User-Agent Python-urllib/3.12, python-requests/2.31.0·2.34.2, curl/7.88.1, azure-toolkit/1.0은 정상 관리자도 쓰니 단독 근거가 아니다(ConnectWise).
• Sentinel, 서비스 주체 로그인(일반 점검): AADServicePrincipalSignInLogs | where TimeGenerated >= datetime(2026-10-01) and AppOwnerTenantId == "3f9cd7a0-127a-4ed4-bf06-2f830d5616b7" | summarize count() by AppId, IPAddress, UserAgent, ClientCredentialType, ResultType. 마이크로소프트 예시의 SigninLogs도 본다.
• Sentinel, 역할 자기 할당(일반 점검): AuditLogs | where TimeGenerated >= datetime(2026-10-13) and OperationName == "Add member to role" | extend Sp = tostring(InitiatedBy.app.servicePrincipalId) | where isnotempty(Sp) and tostring(TargetResources) contains Sp
• SIEM이 없을 때(일반 점검): 승인된 읽기 권한(Connect-MgGraph -Scopes "Application.Read.All")으로 대상 테넌트에 연결한 뒤 Get-MgServicePrincipal -All -Property Id,AppId,DisplayName,PasswordCredentials,KeyCredentials | ConvertTo-Json -Depth 6와 Get-MgApplication -All -Property Id,AppId,DisplayName,PasswordCredentials,KeyCredentials | ConvertTo-Json -Depth 6로 비밀·인증서 메타데이터를 확인한다. 유효 시작일(StartDateTime)은 추가된 시각이 아니니 그것으로 거르지 말고 10월 13일 이후 감사 기록·승인 내역과 대조한다. 찾은 KeyId로 서비스 주체 로그인의 ServicePrincipalCredentialKeyId를 검색해 성공 로그인이 있으면 그 비밀이 쓰인 근거가 되지만, 검색 결과가 없다고 미사용을 단정하지 않는다.

대응 순서

오늘

1. M365 관리자: 앱을 끄되 지우지 않는다. Enterprise apps에서 위 앱 ID를 찾아 Properties의 'Enabled for users to sign-in?'을 No로 저장하면 새 토큰 발급이 막힌다(Todyl). Cloud Application Administrator 역할이면 되고, 앱·Object ID, 바꾼 사람, UTC 시각을 적는다. 삭제는 조사 뒤에 정한다(마이크로소프트).
2. 보안 담당: 같은 날 증거를 내보낸다. 감사 로그(JSON), 로그인 로그 4종(대화형·비대화형·서비스 주체·관리 ID), Purview 감사, SIEM, Graph 활동 로그를 보존하되 내보내기 때문에 차단을 미루지 않는다(ConnectWise). 10월 15일 기록이 없으면 '기록 없음'으로 적고, 보관이 Entra 라이선스와 별개인 Purview 감사에서 같은 기간을 찾는다(Microsoft Learn).
3. 보안 담당: 위 표와 쿼리로 10월 13일 이후를 훑는다. 시도, 인증 성공, 설정 변경, 데이터 접근을 서로 다른 결론으로 적고 주소 일치만으로 침해를 단정하지 않는다(ConnectWise). Defender XDR 헌팅 원자료는 30일까지라 지금 돌린다(마이크로소프트).
4. 침해 대응 담당: 앱의 역할 자기 할당이나 만든 적 없는 비밀이 나오면 침해 사고로 다룬다. 감사 이벤트와 자격 증명의 키 ID·지문·유효 기간을 먼저 저장하고, 앱 담당자·변경 기록으로 확인한 뒤 권한 있는 대응자가 무단 자격 증명·역할·소유자·동의를 지운다(마이크로소프트). 그 키 ID로 로그인을 다시 찾고 앱이 닿을 수 있던 메일·파일·Key Vault로 영향 범위를 잡는다. 신고 판단은 침해사고 대응 실무와 신고기한을 본다.
5. MSP·리셀러를 거쳐 쓰는 조직: 관리 업체에 서면으로 묻는다. 우리 테넌트의 앱 존재, 비활성화 시각, 점검 결과와 기록 보존 여부를 받는다. 업체 테넌트 점검이 우리 테넌트 점검을 대신하지 않는다(ConnectWise 가이드).
6. 클라우드 담당: 무단 열람이나 노출이 의심되는 비밀은 즉시 교체에 착수한다. 관련 로그와 키 식별자를 보존하고 무단 접근을 차단한 뒤, 노출 가능한 비밀 목록 → 새 비밀 발급·배포 → 옛 비밀 폐기 → 옛 비밀 사용 흔적 확인 순서로 진행한다(일반 점검).
7. IT 책임자: 추가 조사 기록을 오늘부터 수집한다. 라이선스와 수집 상태를 확인하고 Entra 감사·로그인(서비스 주체 포함)·사용 가능한 Graph 활동 로그를 진단 설정으로 Log Analytics나 스토리지에 보내 30일보다 길게 보관한다. 새 수집으로 과거의 미수집 기록이 복원되지는 않는다(Microsoft Learn).

이번 주

1. 보안 담당: 데이터 접근을 따로 판단한다. Purview에서 앱의 메일·파일·Teams 읽기를 보고, 숨은 규칙은 Get-InboxRule -Mailbox <사서함> -IncludeHidden으로 본다. 정상 백업 읽기와 구분이 안 되면 '판단 불가'와 이유를 남긴다(ConnectWise).
2. M365 관리자: 제3자 앱 재고를 만든다. 게시자, 관리자 동의, 담당자와 함께 Directory.ReadWrite.All, 역할 할당을 바꾸는 RoleManagement.ReadWrite.Directory, 앱 자격 증명을 바꾸는 Application.ReadWrite.All 등의 권한을 구분해 적고, 마이크로소프트 권고대로 최소 권한만 남기며 쓰지 않는 앱은 비활성화한다.
3. 보안관제: 상시 경보를 건다. 서비스 주체 자격 증명 추가, 앱의 역할 자기 할당, 고권한 앱의 비정상 앱 전용 활동이 대상이다(마이크로소프트).
4. 백업 담당: 보호 공백을 기록한다. 마지막 성공 복구 지점을 확인하고, ConnectWise 공식 안내 뒤 재연결해 백업 작업이 도는지 본다(ConnectWise).

이번 달

1. 보안 책임자: 고권한 앱 동의 기준을 정한다. 백업·관리 SaaS를 붙이기 전에 요구 권한과 이유, 벤더의 자격 증명 보관·교체 방식, 사고 알림 경로를 서면으로 받고 분기마다 권한을 다시 본다(일반 점검).
2. 보안 책임자: 자체 단일 테넌트 앱에는 워크로드 ID 조건부 액세스를 검토한다. 제3자 멀티테넌트 앱에는 적용되지 않으니 그런 앱은 최소 권한과 비활성화가 주 통제다(Microsoft Learn).

자가점검

'아니오'가 나온 항목부터 대응 순서로 돌아간다.

1. 과거 것까지 ConnectWise·SkyKick 앱을 앱 ID로 찾아 지우지 않고 비활성화했는가

옛 설치는 다른 이름으로 보이고, 삭제하면 설정·권한 같은 증거가 사라진다.

2. 10월 15일 전후 서비스 주체 로그인과 감사 기록을 내보내 두었는가

Entra Free는 7일, P1·P2는 30일 뒤 지워지고 소급되지 않는다.

3. 10월 13일 이후 앱의 역할 자기 할당과 새 비밀·인증서를 확인했는가

벤더가 자격 증명을 바꿔도 테넌트 안에 추가된 것은 남는다.

4. 고권한 제3자 앱 목록과 담당자를 알고 있는가

앱 전용 권한에는 MFA도, 제3자 앱용 조건부 액세스도 걸리지 않는다.

5. 앱 자격 증명 추가와 역할 자기 할당에 경보가 울리는가

Huntress 사례에서 전역 관리자 획득부터 백도어 비밀 추가까지 약 5분이었다.

테넌트 침해가 의심되면 증거부터 지키며 대응하기

앱이 스스로 관리자 역할을 받았거나 만든 적 없는 비밀이 보였다면, 보안 전문 기업 SENTRIX의 침해사고 대응으로 침해 원인 분석(포렌식), 피해 범위 산정과 보고서, KISA·수사기관 신고 지원, 재발 방지 대책을 함께 정할 수 있다. 메일 제목에 [긴급]을 붙이면 영업일 기준으로 우선 확인한 뒤 초기 대응 범위와 일정을 안내한다. 별도 보관본 없이 보관 기간이 지나 삭제된 로그는 복구할 수 없으니, 문의 전이라도 지금 남은 기록부터 내보내 둔다. 침해사고 긴급 대응 문의하기

참고 자료

• 마이크로소프트 보안 블로그, AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise(2026-10-21)
• Microsoft Threat Intelligence(링크드인), ConnectWise Cloud Backup 공급망 공격 추적 공지(2026-10-17)
• ConnectWise Trust Center, Cloud Backup (formerly known as SkyKick) Service Interruption, FAQ(2026-10-16 게시, 2026-10-25 갱신)
• ConnectWise, Cloud Backup technical investigation and remediation guide(2026-10-18)
• Huntress, ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks(2026-10-16, 2026-10-19 갱신)
• Todyl, Investigation: Unauthorized Access Through the ConnectWise Cloud Backup Microsoft 365 App(2026-10-16, 2026-10-23 갱신)
• Wiz, ARTEX in the Wild: Storm-0940 Expands Targeting of IT and Software Vendors(2026-10-22)
• Microsoft Learn, Conditional Access for workload identities(2026-03-24)·Microsoft Entra data retention(2026-03-25)
• 보안뉴스(보도), "3시간 만에 관리자 권한 탈취"…중국 해커, 韓 금융권 공격 AI 도구로 클라우드 침투(2026-10-23)
• 한국경제(보도), 중국계 AI 해킹 도구 확산…韓日 금융기관도 공격받았다(2026-10-24)