관리자 계정 하나면 충분했습니다.

2026년 3월 11일 수요일. 79개국의 Stryker 사무실 직원들은 컴퓨터를 켰고, 화면이 비어 있는 것을 발견했습니다. 로그인 화면은 하나의 로고로 대체되어 있었습니다. 회사 노트북, 업무용 휴대폰, 그리고 회사의 BYOD 프로그램에 등록된 개인 기기까지 모두 동시에, 하룻밤 사이에 초기화되었습니다. 랜섬웨어도, 멀웨어 시그니처도, 엔드포인트 탐지 도구가 잡아낼 수 있었던 그 어떤 것도 없었습니다.

공격자는 Handala라는 이름의 친이란 핵티비스트 그룹으로, Stryker 자신의 IT 관리 인프라를 무기로 삼았습니다.

실제로 무슨 일이 벌어졌는가

이 공격의 핵심은 정교한 익스플로잇도, 제로데이 취약점도 아니었습니다. 훨씬 더 단순하고 훨씬 더 흔한 무언가였습니다. 관리자 계정 하나가 탈취되었고, 그 계정은 Microsoft Intune에 접근할 수 있었습니다.

BleepingComputer의 보도에 따르면 약 80,000대의 기기가 UTC 기준 오전 5시에서 8시 사이에 초기화되었습니다. Handala는 그 수가 79개국에 걸친 이 회사의 글로벌 운영 환경의 서버와 모바일 기기를 포함해 200,000대를 넘었다고 주장했습니다. 오로지 정당한 관리 콘솔 하나만을 통해 실행된 공격이었습니다.

이 공격이 성공한 이유

이 사건의 근본에는 Stryker에만 국한되지 않는 구조적 문제가 있습니다. 대부분의 기업에 해당하는 문제입니다.

대부분의 조직은 관리 업무와 일상 업무를 동일한 기기에서 동일한 사용자 신원으로 문제없이 공존할 수 있는 활동으로 취급합니다. IT 관리자는 이메일에 답하고, 인터넷을 서핑하고, 이따금 링크를 클릭하며, 같은 세션에서 같은 기기로 클라우드 인프라를 관리하고, 접근 변경을 승인하거나, 이번 경우처럼 전체 기기 플릿을 초기화할 권한을 가진 기기 관리 콘솔을 다룹니다.

그것이 바로 공격 표면입니다. 일상 업무 컨텍스트와 권한이 부여된 관리 컨텍스트가 하나의 엔드포인트와 하나의 신원을 공유하면, 그 엔드포인트에 대한 모든 침해는 자동으로 그 신원이 도달할 수 있는 모든 것에 대한 침해가 됩니다. 피싱, 인포스틸러 멀웨어를 통한 자격 증명 탈취, Adversary-in-the-Middle(AiTM) 세션 토큰 탈취, 이 모든 것이 환경에서 가장 강력한 통제 수단으로 곧장 이어지는 경로가 됩니다. 권한 상승은 필요하지 않습니다. 공격자는 이미 존재하는 것을 그대로 사용할 뿐입니다.

Stryker의 경우, 이 접근 권한에는 6개 대륙의 기기를 관리하는 Intune 테넌트가 포함되어 있었습니다.

CISA는 충분히 지켜봤다

공격의 규모와 대담함은 이례적인 반응을 불러일으켰습니다. 미국 사이버보안 및 인프라 보안국인 CISA는 침해된 기기 관리 플랫폼의 위험을 직접적으로 다루는 지침을 발표했습니다. 이 기관은 해당 공격 벡터를 인지하고 있음을 확인하고, 조직들에게 구체적인 조치를 취할 것을 촉구했습니다. 기기 초기화와 같은 고위험 Intune 기능이 실행되기 전에 두 번째 관리자의 승인을 요구하도록 보장하라는 것입니다.

이는 드물고 의미심장한 신호입니다. 연방 보안 기관이 특정 사건 직후에 표적화된 지침을 내놓는다면, 그 메시지는 분명합니다. 이것은 예외적 사례가 아닙니다. 이것은 하나의 패턴이며, 다른 조직들도 높은 확률로 동일한 위험에 노출되어 있습니다.

분리는 사치가 아니다. 그것이 곧 통제다.

Stryker 공격은 평면적인 권한 모델이 어떤 규모의 피해로 이어질 수 있는지를 아주 분명하게 보여줍니다. 공격자는 일련의 취약점을 거쳐 권한을 상승시킬 필요가 없었습니다. 그는 한 계층에서 자격 증명 또는 세션 토큰에 대한 접근 권한을 얻었고, 그 계층만으로도 이미 파국적이고 전 지구적이며 되돌릴 수 없는 피해를 일으키기에 충분하다는 것을 알게 되었습니다.

이 문제에 대한 아키텍처 차원의 답에는 이름이 있습니다. Microsoft Enterprise Access Model(EAM)입니다. 그 핵심 원칙은 계층화된 관리입니다. 권한이 부여된 작업은 전용 계정과 전용 기기로 수행되며, 일상 업무 컨텍스트와 엄격하게 분리됩니다. 이 최소 권한 접근 방식은 침해된 생산성 계정이 관리 계층에 도달할 수 없고, 침해된 관리 계정이 컨트롤 플레인 작업을 수행할 수 없음을 의미합니다. 이는 순수 클라우드 환경과, Entra ID를 통해 온프레미스 Active Directory에 연결되는 하이브리드 구성 모두에 동일하게 적용됩니다. 이러한 환경에서는 과도한 권한을 가진 계정 하나가 여전히 클라우드와 도메인을 이어줄 수 있기 때문입니다.

발상은 단순합니다. 관리 업무는 관리용 기기에서 이루어집니다. Microsoft 365 테넌트, Intune 환경, 또는 Azure 인프라를 관리하는 데 사용하는 신원은 이메일을 읽거나 Teams 통화에 참여하는 데 사용하는 신원과 결코 같지 않습니다. 이러한 관리 세션에 사용되는 기기는 강화되고, 제한되며, 공격 표면을 만들어 내는 일반적인 인터넷 브라우징 및 생산성 컨텍스트로부터 격리됩니다. 측면 이동 경로 자체가 존재하지 않기 때문에, 측면 이동은 구조적으로 더 어려워집니다.

두 개의 방어 계층

이 위협 모델을 제대로 다루려면 두 가지 계층에서 동시에 작업해야 합니다. 누가 관리 계층과 그 자격 증명에 접근할 수 있는지를 보호하는 것, 그리고 그 관리 계층 자체가 어떻게 구성되고 운영되는지를 강화하는 것입니다. 이 둘은 같은 문제가 아니며, 둘 다 중요합니다.

Managed Red Tenant: 관리 컨텍스트를 보호하기

첫 번째 계층은 권한이 부여된 접근을 완전히 격리하는 것입니다. 우리의 Managed Red Tenant는 바로 이를 위해 설계되었습니다.

Managed Red Tenant는 완전히 격리된 클라우드 기반 관리 환경을 제공합니다. 오로지 권한이 부여된 작업에만 사용되는 전용 Microsoft Entra 테넌트(“Red Tenant”)입니다. 관리 신원이 이곳에 존재합니다. 관리 기기가 이곳에서 관리됩니다. 일반 업무 환경에서 그 어떤 것도 이곳으로 흘러들지 않습니다.

컨트롤 플레인에 접근하는 글로벌 관리자와 같은 가장 중요한 역할에 대해서는 “Clean Keyboard” 접근 방식을 구현합니다. 전용 하드웨어, 강화된 정책, 그리고 일상 업무 컨텍스트와의 어떠한 접점도 없는 물리적 Privileged Admin Workstation(PAW)입니다. 컨트롤 플레인 아래의 관리 역할에 대해서는, Red Tenant 내부의 강화된 Azure Virtual Desktop 인프라 위에 구축된 확장 가능한 Virtual Access Workstation(VAW)을 제공합니다. 접근 경로 자체는 Microsoft Entra Private Access로 보호되며, 세션이 수립되기 전에 Zero Trust Network Access와 Conditional Access 정책이 적용됩니다.

Microsoft Entra Internet Access는 관리 세션에서의 공용 인터넷 접근을 차단하고, 연결을 권한이 부여된 인터페이스와 승인된 테넌트 환경으로 엄격하게 제한합니다. Universal Conditional Access Evaluation을 통해 거의 실시간에 가까운 세션 취소가 가능하며, 이는 취소된 자격 증명이 유효한 세션으로 계속 유지되지 않음을 의미합니다.

Managed Red Tenant는 우리의 Cloud Security Operations Center(CSOC)가 연중무휴로 모니터링하며, 관리 권한과 접근 패턴을 정확히 겨냥해 특별히 개발된 탐지 기능을 갖추고 있습니다. 어떻게든 이 환경에서 자격 증명 하나를 침해한 공격자라 하더라도, 글로벌 기기 플릿에 초기화 명령을 실행할 세 시간의 미탐지 시간을 갖지는 못할 것입니다.

이는 Intune 관리자와 같은 역할에 특히 중요합니다. 이들은 클라이언트를 보호하는 방법은 알지만, 권한이 부여된 관리 워크스테이션을 보호하는 일에는 다른 역량이 필요합니다. Enterprise Access 아키텍처, 신원 강화, Zero Trust 통제 같은 것들이며, 이는 일반적으로 보안 팀의 몫입니다. Managed Red Tenant는 이 부담을 완전히 덜어 줍니다. Intune 관리자는 스스로 보안 워크스테이션 전문가가 될 필요 없이, 전문적으로 관리되고 일관되게 강화된 워크스테이션을 제공받습니다. 이는 조직 내 모든 고권한 역할에 적용됩니다.

Managed Intune: 관리 계층 자체를 보호하기

두 번째 계층은 Stryker 공격에서 무기로 사용된 도구인 Intune이 최고 수준의 보안 표준에 따라 구성되고, 운영되며, 지속적으로 관리되도록 보장하는 것입니다. 우리의 Managed Intune 서비스가 이를 담당합니다.

이와 같은 사건에서 얻을 수 있는 핵심 교훈 중 하나는, 조직들이 유기적으로 성장한 Intune 환경을 물려받는 경우가 많다는 것입니다. 정책 위에 정책이 쌓이고, 감사하기 어려운 포털을 통한 수동 변경이 이루어지며, Microsoft 자체의 진화하는 권장 사항을 따라가지 못한 보안 기준선이 존재합니다. 구성 드리프트가 악용 가능한 허점을 만들어 내는 것이 바로 이런 종류의 환경입니다.

Microsoft는 최근 Microsoft Intune 보안을 위한 모범 사례를 발표했습니다. 이는 Microsoft 역시 Intune 강화를 업계 전반에서 명시적인 주의가 필요한 주제로 여기고 있다는 신호입니다. 우리의 Managed Intune 서비스는 이러한 원칙에 기반하며, 우리는 Microsoft의 권장 사항을 우리 기준선의 일부로 구현했습니다.

우리의 Managed Intune 서비스는 glueckkanja Intune Foundation에 기반합니다. 검증되고 지속적으로 관리되는 기기 관리 모범 사례 집합으로, Terraform과 우리 자체 TerraProvider를 사용해 전적으로 코드로 배포됩니다. 모든 변경은 자동화되고, 버전 관리되며, 감사 가능합니다. 공격자가 의도된 것과 실제로 설정된 것 사이의 간극을 파악해 악용할 수 있는, 문서화되지 않은 클릭 방식 구성은 존재하지 않습니다.

보안 관점에서 이는 Zero Trust, App Protection Policy, 그리고 Endpoint Security 구성이 설계상 일관되게 적용됨을 의미합니다. Windows, macOS, iOS, Android 전반에 걸쳐, 일회성 배포가 아니라 지속적으로 강제되고 계속 업데이트되며 Microsoft 자체 보안 지침을 따라가는 기준선으로서 적용됩니다.

결정적으로, Managed Intune은 현대적 엔드포인트 관리가 요구하는 운영 성숙도를 반영합니다. 지속적인 컴플라이언스 모니터링, 체계적인 변경 거버넌스, 정기적인 서비스 리뷰가 선택적 옵션이 아니라 기본 운영으로 포함됩니다. 그러나 Intune 구성을 보호하는 것은 절반에 불과합니다. 콘솔에 접근하는 관리자가 보호되지 않은 기기에서 그렇게 한다면 관리 계층은 여전히 노출된 채로 남습니다. 바로 이 지점에서 Managed Red Tenant가 이 모델을 완성합니다.

모든 구성이 Intune Foundation을 기반으로 코드로 배포되기 때문에, 우리는 동료 검토(Peer Review)를 포함한 엄격한 4-eyes 원칙과 추가적인 자동화 검증, 그리고 통제된 배포 파이프라인을 강제합니다. 이를 통해 Intune Foundation 내에서 관리되지 않는 포털 변경을 제거하고, 모든 기기에 걸쳐 일관되고 감사 가능하며 안전한 기준선을 보장합니다.

관리 접근은 GDAP와 Azure Lighthouse를 활용한 최소 권한 모델로 통제되며, 명확하게 정의된 책임과 고객 테넌트에 대한 엄격하게 제한된 접근을 갖춥니다. 이는 권한이 부여된 작업과 관련된 공격 표면을 상당히 줄여 줍니다.

파괴적 작업을 포함한 기기 수준의 작업은 그 실행이 조직 고유의 프로세스 및 내부 거버넌스 프레임워크와 긴밀하게 연결되어 있으므로, 고객의 책임으로 남습니다. Microsoft와 CISA는 이러한 작업을 Intune의 다중 관리자 승인 통제와 같은 추가적인 보호 장치로 보호할 것을 권장합니다.

불편한 질문

Stryker 공격은 Microsoft Intune에 대한 고발이 아닙니다. Intune은 설계된 그대로 정확히 동작했습니다. 인증된 관리자로부터 받은 명령을 실행했습니다. 실패는 도구에 있지 않았습니다. 누가, 어떤 컨텍스트에서, 어떤 수준의 인가로 그 도구에 도달할 수 있는지에 대한 통제가 부재했다는 데 있었습니다.

이것은 거버넌스와 아키텍처의 문제입니다. 그리고 이는 오늘날 Microsoft 365를 운영하는 대부분의 조직에 존재하는 바로 그 문제입니다.

여러분의 관리자가 일상 업무에 사용하는 것과 동일한 기기 및 신원으로 Intune, Entra ID, 또는 Azure에 접근한다면, 그리고 여러분의 Intune 환경이 체계적이고 자동화된 운영 모델이 아니라 수년간의 수동 포털 변경을 거쳐 성장해 왔다면, 여러분은 3월 11일 Stryker가 짊어졌던 것과 동일한 구조적 위험을 안고 있는 것입니다. 문제는 여러분이 그 취약점을 막기 전에 공격자가 먼저 그것을 찾아낼 것인가입니다.

Managed Red Tenant는 권한 및 신원 계층을 다룹니다. Managed Intune은 구성 및 운영 계층을 다룹니다. 이 둘이 함께 Stryker 공격을 가능하게 했던 두 가지 허점을 막습니다.

두 서비스 중 하나가 여러분의 현재 환경에 어떻게 적용되는지, 또는 여러분의 구체적인 취약점이 어디에 있는지 이해하고 싶으시다면, 기꺼이 함께 이야기 나누겠습니다.

또한 곧 Stryker 사건이 애초에 어떻게 가능할 수 있었는지를 살펴보는 심층 분석 기사를 발표할 예정입니다.

추가 정보

• CISA: Securing Cloud Business Applications
• Microsoft: Microsoft Intune 보안을 위한 모범 사례
• TechCrunch: 해커가 Stryker 기기를 대량 초기화한 후 CISA가 기업들에게 Microsoft Intune 시스템을 보호할 것을 촉구하다
• Azure Marketplace의 Managed Red Tenant