크라우드스트라이크 두 사고가 가리키는 커널 위험

권한 상승 버그는 12일 만에 패치됐습니다. 봐야 할 것은 그 권한이 놓여 있던 자리입니다.

엔드포인트 보안 제품은 대부분 같은 방식으로 호스트 접근 권한을 확보합니다. ring 0에서 도는 커널 모드 드라이버를 올리고, 호스트의 모든 프로세스와 파일 쓰기, 시스템 콜을 들여다보는 방식입니다. EDR 에이전트가 유저스페이스(userspace) 도구로는 잡을 수 없는 것을 잡아내는 근거도 이 접근 권한입니다. ps에 안 잡히는 루트킷, 다른 프로세스 메모리에 코드를 주입하는 프로세스, 백신보다 먼저 로드되는 드라이버가 그렇습니다. 그 드라이버의 버그가 운영체제의 버그가 되는 이유이기도 합니다.

크라우드스트라이크는 이 거래의 양면을 2년이 조금 넘는 간격으로 두 번, 구조가 전혀 다른 방식으로 보여 줬습니다. 2024년 7월에는 잘못된 콘텐츠 업데이트 하나가 850만 대의 윈도우 장비에서 커널 드라이버를 하루 만에 무너뜨렸습니다. 2026년 9월에는 한 연구자가 이와 무관한 버그를 찾아냈습니다. 이번에는 유저스페이스 기능 쪽이었고, 이미 호스트에 들어와 있는 공격자가 최신 패치 상태의 장비에서 SYSTEM 권한까지 올라갈 수 있는 경로였습니다. 코드도 다르고 버그 유형도 다르지만 바탕에 깔린 모양은 같습니다. 특권 집행 로직이 호스트마다 한 곳에 모여 있고, 그 로직이 틀렸을 때 무엇까지 할 수 있는지 밖에서 확인하는 장치가 없습니다.

2024년 7월에 벌어진 일

2024년 7월 19일, 크라우드스트라이크는 윈도우 센서 전체에 Rapid Response Content 업데이트를 내보냈습니다. 센서 코드는 그대로였고, 콘텐츠와 설정만 바꾸는 업데이트였습니다. 이 업데이트가 Falcon 윈도우 센서의 중심인 커널 드라이버 CSagent.sys의 누락된 경계 검사를 건드렸습니다. 결과는 커널을 패닉으로 몰고 간 out-of-bounds read였습니다. 전 세계 850만 대의 윈도우 장비에서 블루스크린과 부팅 루프가 한꺼번에 발생했습니다.

'한꺼번에'를 가능하게 만든 경로를 따로 볼 필요가 있습니다. 크라우드스트라이크의 근본 원인 분석은 개선 방안으로 "단계적 배포"를 제시하고, 카나리로 먼저 검증한 뒤 배포 링 단위로 확대하는 절차를 함께 적었습니다. 장애 이전 이 콘텐츠 채널에는 그런 절차가 없었다는 뜻입니다. 커널 드라이버는 정의상 이미 호스트 전체를 피해 범위로 갖습니다. 여기에 단계 구분 없는 전역 동시 배포가 더해지면, 파일 하나의 결함이 그 드라이버를 돌리는 모든 고객에게 같은 순간의 사고가 됩니다.

마이크로소프트의 대응은 이 사고 하나를 넘어 구조 자체를 겨냥한 가장 분명한 판단입니다. 서드파티 엔드포인트 보안을 커널 밖 유저스페이스로 옮기는 작업을 진행 중이고, 근거는 유저스페이스에서 나는 장애가 운영체제 전체를 끌고 내려가지 않고 조용히 끝난다는 것입니다.

2026년 9월에 벌어진 일

FalconFlank는 2024년의 반복이 아닙니다. 제품 표면도, 발견한 연구자도, 버그 유형도 다릅니다. 이 구분을 흐리면 여기서 끌어내는 결론도 함께 틀어집니다.

2026년 9월 3일, Chaotic Eclipse라는 이름의 연구자가 크라우드스트라이크에 사전 통보 없이 동작하는 PoC(proof-of-concept)를 GitHub에 공개했습니다. 대상은 Falcon의 "Microsoft Office File Malicious/Suspicious Macro Removal" 기능이었습니다. 탐지된 매크로 위협을 정리하려고 상승된 권한으로 도는 교정 루틴입니다. 이 루틴에는 CWE-367 검사 시점과 사용 시점 사이의 경쟁 조건(TOCTOU)이 있었습니다. Falcon이 파일 위치를 확인하는 순간과 그 위치에 실제로 손을 대는 순간 사이를 권한 없는 프로세스가 먼저 차지해, 보호된 신뢰 디렉터리에 임의의 파일을 쓸 수 있었습니다.

익스플로잇 체인(exploit chain)은 셸을 직접 띄우는 대신 DLL 사이드로딩을 거칩니다. PoC는 교정이 진행되는 구간에 악성 라이브러리를 PowerShell v1.0 런타임 디렉터리에 심어 둡니다. 공개된 분석들에서는 bcrypt.dll이었습니다. 이후 그 런타임을 로드하는 프로세스가 심어진 라이브러리를 SYSTEM 권한으로 함께 올립니다. 성립 조건은 공격자가 이미 호스트에서 낮은 권한으로 코드를 실행할 수 있는 상태입니다. 원격 초기 침투 수단이 아니라 로컬 권한 상승 경로이고, 해당 기능이 제공되지 않는 Falcon GovCloud는 영향을 받지 않습니다.

크라우드스트라이크는 CVE-2026-40058(CWE-367)을 할당해 2026년 9월 15일에 공개하면서, 영향받는 센서 라인(7.34 이상, 7.32 LTS, 7.35~8.10, 레거시 윈도우용 7.16)의 수정 빌드를 같은 날 배포했습니다. 오늘 기준으로 이 버그는 패치된 상태이고, 조율 없는 공개부터 수정까지 약 12일의 노출 기간이 있었습니다. 패치가 없는 진행형 제로데이가 아닙니다. 그 기간에 크라우드스트라이크가 안내한 조치는 취약한 매크로 제거 설정을 끄고 Cloud Anti-malware for Office Files에 의존하라는 것이었습니다. 특권 기능의 버그를 막는 임시 조치가 그 특권 기능을 끄는 일이었습니다.

CVSS 8.8(High) 점수는 NVD와 CVE.org, 크라우드스트라이크 자체 권고문에서 직접 확인했습니다.

서로 다른 두 버그, 같은 원인

두 사건을 "크라우드스트라이크 커널이 두 번 무너졌다"고 묶으면 사실과 맞지 않습니다. CSagent.sys는 ring 0에서 도는 커널 드라이버입니다. 매크로 제거 기능은 신뢰 디렉터리에 파일을 쓸 수 있는 유저스페이스 특권 루틴입니다. 구성 요소와 실패 양상이 다릅니다. 이를 하나의 커널 버그로 묶으면 구조적 차이를 놓치게 됩니다.

두 사고 모두 호스트의 특권 집행 로직에 문제가 생겼을 때 독립적으로 이를 확인하는 장치가 없었다는 점에서 만납니다. 커널 드라이버의 경계 검사가 빠지면 장비 전체가 패닉에 빠질 수 있습니다. 유저스페이스 교정 루틴은 쓰지 말아야 할 위치에 파일을 쓰도록 속을 수 있습니다. 악성 매크로를 정리하려고 부여한 권한이 공격자가 라이브러리를 심는 데 필요한 권한과 같기 때문입니다. 작동 방식은 달라도, 한곳에 권한이 모이면 그곳의 버그가 국소적으로 끝나지 않을 수 있습니다.

여기서 나오는 반론에도 답이 필요합니다. "로더블 커널 모듈 대신 eBPF로 옮기면 되지 않느냐"는 것입니다. 로더블 커널 모듈은 검증기 없이 ring 0에서 돌기 때문에 버그가 호스트를 그대로 패닉으로 몰 수 있고, 2024년에 일어난 일이 정확히 그것입니다. eBPF 프로그램은 로드되기 전에 커널 검증기(verifier)의 검사를 거치고, 원리대로라면 거부된 프로그램이 할 수 있는 최악은 로드에 실패하는 정도입니다. 의미 있는 개선이면서, 끝난 문제는 아닙니다. 검증기 자체에도 out-of-bounds CVE가 있었고, 크라우드스트라이크의 리눅스용 유저스페이스 eBPF 센서는 벤더 코드가 아니라 검증기 버그를 통해 RHEL 9.4에서 커널 패닉을 일으킨 적이 있습니다. eBPF는 커널 모듈 실패 양상의 피해 범위를 좁힐 뿐, "특권을 가진 온호스트 구성 요소가 커널을 함께 끌고 내려갈 수 있다"는 범주 자체를 없애지는 않습니다.

Alpacon은 여기서 무엇이 다른가

Alpacon도 호스트에 에이전트를 올리는 보안 제품입니다. 그래서 이 글은 "크라우드스트라이크의 구조가 문제다"에서 멈출 수 없습니다. Alpacon의 에이전트 Alpamon은 무엇을 다르게 하는지, 그리고 그 답이 어디에서 끝나는지까지 적어야 합니다.

Alpamon은 Go로 작성한 유저스페이스 에이전트입니다. 명령 실행과 스트리밍에는 os/exec와 creack/pty를 사용합니다. eBPF 프로그램이나 커널 모듈을 쓰지 않고, 다른 프로세스에 ptrace 후크도 걸지 않습니다. 의도적인 아키텍처 선택입니다. Alpamon이 죽어도 유저스페이스 프로세스 하나만 멈추고, 커널 패닉으로 이어지는 CrowdStrike류 실패 양상을 구조적으로 피하며 커널 공격 표면을 추가하지 않습니다. 호스트와 다른 프로세스는 계속 실행됩니다. Alpamon은 커널에서 돌지 않으므로 커널 패닉을 일으키는 주체가 될 수 없습니다.

이 주장은 FalconFlank 쪽 실패 양상까지 그대로 이어지지는 않습니다. 특권을 가진 로컬 판단이 틀리는 경우입니다. Alpamon은 공개 키만 가지고 있고, 명령을 인가하는 개인 키는 암호화된 채 교체되며 AI 서버에 남도록 설계돼 있습니다. 그 인가 판단을 Alpamon 혼자 내리지 않도록 하기 위해서입니다. 실제로 기본값으로 세 리전 모두에 적용되는 것은 exec lane의 위험도 게이트입니다. 에이전트가 커맨드 API, MCP, OS 수준 sudo로 보내는 명령은 실행되기 전에 채점되고, 회색 지대로 분류된 명령은 사람 승인 대기 상태로 보류될 수 있습니다. FalconFlank의 바탕에 있던 취약점은 이런 점검이 경로 어디에도 없던 특권 기능이 스스로 움직이도록 속을 수 있었다는 것입니다. 더 정확히 말하면 손상된 에이전트가 아무것도 할 수 없다는 뜻이 아니라, 에이전트가 Alpacon을 거쳐 보내는 명령은 기본값으로 실행 전에 판단된다는 것입니다. FalconFlank의 교정 루틴에는 없었던 점검입니다.

Alpamon도 특권을 가진 호스트 에이전트이므로 공격 대상에서 벗어나지 않습니다. 공개 키만 두는 모델, 아웃바운드 전용 네트워크, Work Session 범위 제한으로 위험을 좁혔을 뿐 신뢰 기점(trust anchor)이라는 성격은 남습니다. 커널 밖에 머무는 것도 우연이 아니라 명시된 아키텍처 선택입니다. Alpacon은 execve/eBPF 수준의 우회 탐지를 EDR의 역할로 두고 범위 밖에 둡니다. 커널 수준 런타임 모니터링까지 내려가면 커널 공격 표면과 피해 범위를 다시 가져오기 때문입니다. Alpacon은 권한 상승 문제 전반을 해결한다고 주장하지 않습니다. Alpacon이 말하는 범위는 좁습니다. 호스트에서 실행을 제어하는 에이전트가 850만 대를 부팅 루프에 빠뜨린 2024년과 같은 실패 양상을 함께 지지는 않는다는 것입니다.

다음 보안 점검에서 확인할 것

이런 사고 두 건에서 얻을 것은 "크라우드스트라이크를 쓰지 마라"가 아닙니다. 상시 권한으로 도는 에이전트에 던질 질문 목록입니다. PAM과 EDR은 물론, root나 SYSTEM으로 상시 실행되는 모든 것이 대상입니다.

1. 어느 ring에서 돌고, 그곳의 크래시는 어디까지 닿습니까? 커널 모듈은 호스트를 패닉으로 몰 수 있습니다. eBPF는 검증기가 범위를 제한하지만 CVE가 없지는 않습니다. 유저스페이스는 프로세스 하나가 죽을 뿐 운영체제를 끌고 내려가지 않습니다.
2. 에이전트가 스스로 판단합니까, 아니면 다른 곳에서 내려진 판단을 서명된 상태로 받아 실행합니까? 판단과 실행을 함께 쥔 특권 기능이 FalconFlank의 모양입니다. 제 일을 하는 데 필요한 접근 권한이, 공격자가 그것을 악용하는 데 필요한 접근 권한과 같습니다.
3. 이 에이전트의 손상되거나 결함 있는 인스턴스는 어디까지 건드릴 수 있습니까? 호스트 한 대입니까, 아니면 단계 구분 없는 전역 배포를 통해 전체가 한꺼번에입니까?

이 질문들이 위험을 0으로 만들어 주지는 않습니다. 위험이 어디에 있는지에 대한 정직한 답을 줍니다. 크라우드스트라이크의 사후 분석과 패치 노트가 내놓은 답도 같았습니다. 사고가 난 뒤였다는 점만 다르고, 그것도 두 번이었습니다.

자주 묻는 질문

FalconFlank(CVE-2026-40058)는 아직 패치되지 않은 진행형 취약점입니까?

아닙니다. 크라우드스트라이크는 조율 없는 공개가 있었던 2026년 9월 3일로부터 12일 뒤인 2026년 9월 15일에 수정된 센서 빌드를 배포했습니다. 윈도우용 Falcon 센서 7.34 이상, 7.32 LTS, 7.35~8.10, 레거시 윈도우/서버용 7.16을 쓰면서 업데이트를 적용한 고객은 보호됩니다. 실제 공격에 악용됐다는 확인된 보고는 없고, 크라우드스트라이크 권고문도 Cloud Anti-malware for Office Files 설정이 켜져 있었다면 고객이 그 기간 내내 보호된 상태였다고 적고 있습니다.

FalconFlank도 2024년 장애처럼 커널 모드 취약점입니까?

아닙니다. 이 구분은 흐려 두면 안 됩니다. 2024년 장애는 ring 0 커널 드라이버인 CSagent.sys의 버그였습니다. FalconFlank는 유저스페이스에서 특권으로 도는 Office 매크로 제거 기능의 CWE-367 검사 시점과 사용 시점 사이 경쟁 조건이고, DLL 사이드로딩으로 익스플로잇됐습니다. 구성 요소가 다르고 실패 양상도 다릅니다. 공통된 교훈은 커널 자체가 아니라 특권 집행 로직을 한 곳에 모아 두는 구조에 있습니다.

어떤 EDR 계열 에이전트든, 이 사고들이 가리키는 커널 모드 위험은 무엇입니까?

위험은 특정 버그 하나가 아닙니다. 커널 모드 드라이버는 검증기 없이 ring 0에서 돌기 때문에, 그곳의 버그는 자신이 속한 프로세스가 아니라 호스트 전체를 무너뜨릴 수 있습니다. eBPF는 이 위험을 좁힙니다. 검증기가 안전하지 않은 프로그램을 로드 시점에 거부하기 때문입니다. 그렇다고 없어지지는 않았습니다. 검증기 자체에 out-of-bounds CVE가 있었고, 크라우드스트라이크의 리눅스 eBPF 센서가 검증기 버그를 통해 RHEL 9.4에서 커널 패닉을 일으킨 적도 있습니다. 벤더에 물을 것은 그 에이전트가 어느 ring에서 도는지, 그곳에서 크래시가 났을 때 무엇을 치르게 되는지입니다.

이 이야기는 Alpacon 자체 호스트 에이전트에도 적용됩니까?

Alpacon의 호스트 에이전트 Alpamon은 Go 유저스페이스 프로세스입니다. 커널 모듈도, eBPF도, ptrace도 없습니다. 크래시는 그 프로세스 안에 머물고 호스트를 패닉으로 몰지 않으며, 이 실패 양상은 2024년 장애가 바탕에서 이어지는 지점입니다. FalconFlank의 실패 양상은 다릅니다. 크래시가 아니라, 특권을 가진 로컬 기능이 스스로 움직이도록 속는 경우입니다. 이 모양에 답하는 것은 기본값으로 세 리전 모두에 적용되는 exec lane의 위험도 게이트입니다. 에이전트가 커맨드 API, MCP, OS 수준 sudo로 보내는 명령은 실행 전에 채점되고, 회색 지대로 분류된 명령은 사람 승인 대기 상태로 보류될 수 있습니다. FalconFlank의 교정 루틴에는 없었던 점검입니다. Alpamon도 호스트에 상시 접근 권한을 가진 특권 에이전트입니다. 이 위험도 게이트와 아웃바운드 전용 네트워크로 좁혀졌을 뿐 없어진 것은 아니며, 커널 밖에 머무는 선택이 한 가지 위험의 범위를 정하고 exec lane의 판단이 다른 위험의 범위를 정할 뿐, 어느 쪽도 Alpamon을 공격 대상에서 빼 주지는 않습니다.