afd.sys — 소켓 하나가 커널 권한까지 이어지는 통로

이미지 출처: CISA KEV

Windows 커널 드라이버 중에서 유독 자주 이름이 오르내리는 파일이 하나 있음. afd.sys, 정식 명칭으로는 Ancillary Function Driver for WinSock. 애플리케이션이 소켓을 만들 때 사용자 모드의 winsock 호출을 커널 네트워크 스택으로 연결해주는 다리 역할을 함. 문제는 이 다리가 모든 사용자 계정에서 접근 가능하다는 점임. 게스트든 서비스 계정이든 소켓 하나만 열 수 있으면 afd.sys의 IOCTL 인터페이스에 도달함. 이번 CVE-2026-68820은 그 인터페이스에서 발생하는 Use-After-Free 결함임.

핵심 요약

• afd.sys의 해제된 커널 객체를 다시 참조하는 결함으로, 로컬 권한상승(LPE)에 악용될 수 있음
• 원격 최초 침투용이 아니라 2단계 무기 — 이미 들어온 공격자가 SYSTEM으로 올라설 때 쓰임
• 패치가 유일한 근본 해결책이고, 그 전까지는 로컬 실행 통제와 커널 크래시·토큰 이상 탐지로 버텨야 함

Use-After-Free가 왜 커널에서 치명적인가

사용자 모드에서 UAF가 터지면 대개 프로세스 하나가 죽고 끝남. 그런데 커널에서는 이야기가 완전히 달라짐. 해제된 객체가 있던 메모리 자리를 공격자가 자기 데이터로 다시 채울 수 있으면, 커널이 그 데이터를 여전히 유효한 객체인 줄 알고 읽어감. 그 안에 함수 포인터나 권한 구조체 참조가 들어 있었다면 커널의 실행 흐름 자체가 공격자 손에 넘어가는 것임.

afd.sys에서 이런 결함이 생기는 전형적인 패턴은 비동기 I/O 처리 과정임. 소켓 작업을 걸어두고 완료를 기다리는 동안 다른 스레드에서 같은 핸들을 닫거나 취소하면, 참조 카운트 관리가 어긋나면서 아직 쓰이고 있는 객체가 먼저 해제되는 상황이 만들어짐. 경쟁 조건이다 보니 한 번에 성공하지는 않지만, 공격자 입장에서는 그냥 수천 번 반복하면 되는 문제라 실질적인 방어벽이 되지 못함.

공격자는 이걸 어디에 쓰는가

중요한 건 이 취약점의 위치임. 인터넷에서 바로 찔러 들어오는 원격 실행 취약점이 아님. 이미 어떤 경로로든 사용자 권한을 확보한 다음에 쓰는 카드임. 그래서 실제 침해 흐름은 대개 이런 모양이 됨.

• 피싱 첨부나 취약한 웹 애플리케이션을 통해 일반 사용자 권한으로 코드 실행 확보
• afd.sys 같은 로컬 커널 취약점으로 SYSTEM 권한 획득
• LSASS 메모리 접근, 자격증명 탈취, EDR 프로세스 무력화 시도
• 도메인 내부로 횡이동, 지속성 확보

afd.sys 계열 취약점이 랜섬웨어 조직과 국가 배후 그룹 양쪽에서 꾸준히 재활용되어 온 이유가 여기 있음. 어떤 환경에서든 존재하고, 어떤 계정에서든 닿을 수 있는 드라이버라 범용성이 압도적임. 한 번 안정적인 익스플로잇이 완성되면 대상을 가릴 필요가 없다는 뜻임.

탐지 — 무엇을 봐야 하나

커널 UAF 익스플로잇은 그 자체로 조용한 편이지만, 완전히 무흔적은 아님. 개인적으로는 다음 세 갈래를 같이 보는 걸 추천함.

첫째, 실패의 흔적. 익스플로잇은 성공보다 실패가 훨씬 많음. 힙 그루밍이 어긋나면 커널이 그냥 죽음. 이벤트 로그에서 Bugcheck(이벤트 ID 1001)와 예기치 않은 종료(ID 41)가 특정 단말에서 반복적으로 발생하는지 봐야 함. 평소 멀쩡하던 서버가 갑자기 하루에 세 번 블루스크린을 봤다면 하드웨어 문제로 넘기기 전에 그 시각 전후의 프로세스 생성 기록을 먼저 확인해볼 만함.

둘째, 권한 변화의 순간. UAF의 최종 목적은 토큰 탈취임. 부모 프로세스는 일반 사용자 컨텍스트인데 자식 프로세스가 SYSTEM으로 뜨는 조합, 서비스로 등록되지 않은 임의 경로의 바이너리가 SYSTEM 무결성 수준으로 실행되는 조합이 핵심 신호임. Sysmon 이벤트 ID 1의 IntegrityLevel과 부모-자식 관계를 엮어서 보면 잡히는 경우가 많음.

셋째, 준비 동작. 커널 익스플로잇은 메모리 레이아웃을 원하는 모양으로 만드는 준비 단계가 필요함. 짧은 시간 안에 소켓을 대량으로 생성하고 닫는 비정상적인 패턴, 사용자 프로세스가 \Device\Afd 핸들을 평소와 다른 규모로 여는 동작이 여기 해당함. 정상 네트워크 애플리케이션과 구분하려면 기준선이 필요하니, 평소 환경에서 어떤 프로세스가 얼마나 소켓을 여는지를 미리 재둬야 의미가 있음.

완화 — 우선순위대로

• 패치가 1순위임. afd.sys는 시스템 핵심 구성요소라 우회 설정으로 막을 수 있는 성격이 아님. 월간 누적 업데이트를 서버·클라이언트 모두에 적용하는 것 외에 근본 해법이 없음.
• 초기 침투 지점을 줄이는 것이 실질적 2순위임. 로컬 권한상승은 코드 실행이 선행되어야 성립함. 애플리케이션 화이트리스트(WDAC, AppLocker)로 사용자 쓰기 가능 경로에서의 실행을 차단하면 익스플로잇 바이너리가 착지할 곳 자체가 사라짐.
• ASR 규칙과 자격증명 보호를 켜둘 것. Credential Guard가 켜져 있으면 SYSTEM을 얻더라도 LSASS에서 평문 자격증명을 긁어가기가 훨씬 까다로워짐. 권한상승을 못 막았을 때 피해 반경을 줄이는 층이 됨.
• 커널 무결성 계층 활용. HVCI(메모리 무결성)를 켜두면 커널 메모리 조작 이후 임의 코드를 실행하는 단계에서 추가 장벽이 생김. 드라이버 호환성 확인이 필요하니 테스트 그룹부터 적용하는 걸 권함.
• 패치 적용 여부를 실제로 검증할 것. WSUS나 Intune에서 "적용됨"으로 뜨는 것과 실제 afd.sys 파일 버전이 올라간 것은 다른 이야기임. 재부팅이 밀린 단말에서 흔히 어긋남.

취약점 관리 관점에서

로컬 권한상승 취약점은 CVSS 점수만 보면 원격 실행보다 낮게 나오는 경우가 많음. 그래서 패치 우선순위 목록에서 자꾸 뒤로 밀림. 하지만 실제 침해 사고 보고서를 읽다 보면 결정적인 장면은 거의 항상 "사용자 권한에서 SYSTEM으로 올라간 순간"임. 그 전까지는 대응 여지가 있었는데 그 이후로는 아무것도 못 하게 되는 지점이라서 그럼.

그러니까 커널 드라이버 관련 LPE는 점수와 무관하게 별도 트랙으로 관리하는 편이 나음. 특히 다중 사용자가 로그인하는 터미널 서버, 개발자가 로컬 관리자 권한 없이 작업하는 워크스테이션, 컨테이너 호스트처럼 권한 경계 자체가 보안 모델의 근간인 시스템이 우선 대상임.

마무리

afd.sys 취약점이 반복해서 등장하는 걸 보면, 이건 개별 버그를 하나씩 잡는 문제라기보다 공격 표면 자체가 넓다는 구조적 사실에 가까움. 모든 계정이 접근 가능한 커널 인터페이스가 있고 그 안에서 복잡한 비동기 상태 관리를 한다면, 다음 CVE는 시간 문제일 뿐임.

그래서 개인적으로는 이번 건을 단발성 패치 이슈로 넘기지 말고 탐지 규칙을 한 번 정비하는 계기로 삼는 걸 추천함. 커널 크래시 급증 알림, 부모-자식 무결성 수준 불일치 탐지 — 이 두 가지만 제대로 걸어둬도 다음번 afd.sys 취약점이 나왔을 때 훨씬 편해짐. 다들 이번 주 패치 현황 한 번씩 확인해보아요. 각자 환경에서 잡아낸 탐지 규칙 있으면 댓글로 나눠주시면 좋겠습니다!