심볼릭 링크는 왜 아직도 Windows 권한 상승의 단골 통로일까 (CVE-2026-81963)

이미지 출처: CISA KEV

서비스 하나가 C:\Windows\Temp 밑에 로그 파일을 만든다. 만들고, 쓰고, 지운다. 그 폴더는 사용자 누구나 파일을 만들 수 있는 곳이고, 서비스는 SYSTEM 권한으로 돈다. 이 두 문장이 한 문단 안에 같이 있으면, 그때부터는 취약점 이야기가 됨. CVE-2026-81963으로 정리된 Microsoft Windows의 링크 팔로잉(Link Following) 문제도 이 계열에 속함.

핵심 요약

• 높은 권한 프로세스가 사용자가 통제 가능한 경로를 검증 없이 따라가면서 생기는 권한 상승 유형임
• 공격은 파일을 깨는 게 아니라 경로를 바꿔치기하는 것이며, 경쟁 조건 특성상 흔적이 짧게 스쳐 지나감
• 방어는 패치가 1순위, 그다음이 재분석 지점(reparse point) 생성 탐지와 임시 디렉터리 권한 정리임

링크 팔로잉이 정확히 무슨 뜻인가

파일 시스템에는 "이 경로는 사실 저기를 가리킨다"고 알려주는 장치가 여럿 있음. NTFS의 정션(junction), 심볼릭 링크, 하드 링크, 그리고 객체 관리자 수준의 심볼릭 링크까지. 편의 기능이고 Windows가 오래전부터 쓰던 정상 기능임.

문제는 권한이 높은 코드가 이 링크를 아무 의심 없이 따라갈 때 생김. SYSTEM으로 도는 프로세스가 "C:\Windows\Temp\svc.log를 열고 쓰겠다"고 요청했는데, 그 이름이 사실은 C:\Windows\System32 아래 어딘가를 가리키도록 미리 바꿔져 있었다면? 커널은 요청자의 권한으로 최종 목적지를 열어줌. 권한 검사는 통과함. 애초에 SYSTEM이 요청했으니까. 결과적으로 일반 사용자가 직접은 못 건드릴 파일을 대신 쓰게 만드는 그림이 됨.

여기서 자주 오해하는 부분 하나. 심볼릭 링크를 만들려면 특권이 필요하지 않느냐는 것. 맞는 말이지만 절반만 맞음. 파일 심볼릭 링크는 그렇고, 디렉터리 정션이나 객체 관리자 심볼릭 링크는 일반 권한으로도 만들 수 있는 경로가 존재함. 그래서 이 유형이 십 년 넘게 반복되는 것.

CVE-2026-81963을 어떻게 읽을 것인가

개별 취약점의 세부 동작은 벤더 공지에 담긴 범위 안에서만 이야기하는 게 맞다고 봄. 다만 링크 팔로잉으로 분류된 이슈는 대체로 아래 조건을 공유함.

• 로컬 접근이 전제됨. 원격에서 바로 터지는 종류가 아니라, 이미 들어온 공격자가 권한을 끌어올리는 데 쓰임
• 사용자 상호작용이 거의 필요 없음. 링크를 심어두고 대상 프로세스가 동작하기를 기다리면 됨
• 경쟁 조건(TOCTOU)이 자주 끼어듦. 경로를 검사한 시점과 실제로 여는 시점 사이의 틈을 노림
• 단독으로는 초기 침투가 안 되지만, 랜섬웨어·자격증명 탈취 단계의 디딤돌로 가치가 큼

그래서 CVSS 숫자만 보고 "로컬이니까 나중에"라고 미루면 곤란함. 침해 사고 타임라인에서 이런 취약점은 항상 중간 지점에 박혀 있음.

탐지: 무엇을 봐야 하는가

공격 자체는 조용함. 익스플로잇 바이너리가 화려하게 뜨지 않고, 링크 하나 만들었다가 지우는 게 전부일 때도 있음. 그래도 볼 수 있는 지점은 있음.

• 재분석 지점 생성 이벤트. Sysmon 이벤트 ID 2(파일 생성 시각 변경)와 11(파일 생성)을 공용 임시 경로 기준으로 걸어두면 노이즈 대비 효율이 괜찮음. 특히 C:\Windows\Temp, C:\ProgramData 하위, 사용자 Temp에서 디렉터리가 만들어졌다 짧게 사라지는 패턴이 신호임
• 객체 접근 감사(4656, 4663). 보호 대상 디렉터리에 SACL을 걸고, 예상 밖의 프로세스가 SYSTEM 권한으로 쓰기를 시도하는 순간을 잡음. 전체에 걸면 로그가 폭발하니 대상은 좁게
• 서비스·설치 프로그램의 임시 경로 사용 이력. 어떤 제품이 공용 경로에 SYSTEM으로 파일을 쓰는지 목록을 미리 만들어두는 것이 사실상 절반임. 정상 목록이 없으면 이상 탐지도 없음
• 권한 상승 직후의 행동. 링크 트릭 자체보다, 그 뒤에 따라오는 새 서비스 등록·스케줄 작업 생성·LSASS 접근이 더 잘 보임. 탐지 룰의 무게중심을 이쪽에 두는 것도 방법

완화: 순서대로 하면 됨

• 패치. 뻔하지만 이 유형은 벤더 수정이 유일하게 확실한 답임. 대상 코드가 경로를 열 때 재분석 지점을 거부하거나 최종 경로를 재확인하도록 고쳐지는 것이라 우회 설정으로 대체하기 어려움
• 리다이렉션 신뢰 정책 활용. Windows에는 특권 프로세스가 비특권 사용자가 만든 링크를 따라가지 못하게 막는 완화 기능이 들어와 있음. 자체 개발한 서비스가 있다면 이 정책을 적용하고, 파일을 열 때 재분석 지점을 따라가지 않는 플래그를 쓰도록 코드를 손보는 게 정석임
• 공용 임시 디렉터리 정리. 서비스가 굳이 C:\Windows\Temp를 쓸 이유가 없다면 서비스 전용 경로로 옮기고 ACL을 좁힘. "누구나 쓰기 가능 + SYSTEM이 접근"이라는 조합을 하나씩 줄여나가는 작업임
• 최소 권한. 일반 사용자에게 관리자 권한이 있으면 이런 취약점은 애초에 필요가 없어짐. 반대로 말하면 로컬 관리자 권한 회수가 이 유형 전체에 대한 광역 방어임
• 자산 목록. 오래된 설치 프로그램, 업데이터, 백신 보조 서비스가 의외로 이런 패턴을 많이 갖고 있음. 벤더 패치가 끊긴 소프트웨어를 찾아내는 게 실질적인 이득이 큼

정리하면서

개인적으로는 이 계열 취약점을 볼 때마다 "신뢰 경계가 어디에 그어져 있나"를 다시 그려보게 됨. 파일 이름은 데이터인데, 높은 권한 프로세스에게는 사실상 명령처럼 작동함. 이름을 통제할 수 있는 사람이 결국 대상을 통제하게 되는 구조인 것.

당장 할 수 있는 건 어렵지 않다고 봄. 이번 달 패치 적용 상태 한 번 확인하고, 공용 임시 폴더에 SYSTEM으로 파일 쓰는 서비스가 뭐가 있는지 목록을 만들어보는 것. 그 두 가지만 해도 다음에 비슷한 CVE가 나왔을 때 대응 속도가 확 달라짐. 각자 환경에서 확인해본 결과가 있으면 댓글로 공유해 주시면 좋겠음. 같이 정리해 나가 보아요!