SharePoint 온프레미스, '로그인 화면을 아예 만나지 않는' 요청이 있다 — CVE-2026-56164 방어 노트

이미지 출처: CISA KEV

사내 SharePoint는 대개 이런 취급을 받음. 인트라넷 안쪽이니까, VPN 붙어야 하니까, AD 계정 없으면 못 들어오니까. 그런데 이번에 공개된 CVE-2026-56164는 그 전제를 조용히 무너뜨리는 종류임. 취약점 분류명이 Missing Authentication for Critical Function, 즉 '중요한 기능에 인증이 빠져 있음'인데, 이 말은 공격자가 인증을 깨는 게 아니라 애초에 요구받지 않는다는 뜻임. 자물쇠를 딴 게 아니라 옆문에 자물쇠가 안 달려 있던 상황인 거임.

핵심 요약

• CVE-2026-56164는 SharePoint Server의 특정 기능이 인증 검사를 거치지 않아 미인증 요청만으로 접근되는 결함임. 인증 우회가 아니라 '인증 부재'라는 점이 핵심.
• 온프레미스 SharePoint가 대상이며, 인터넷에 노출된 서버라면 우선순위 최상위로 패치해야 함. SharePoint Online(M365)은 성격이 다름.
• 패치가 최우선이고, 그 전까지는 노출면 차단·IIS 로그에서 '인증 없는 200 응답' 추적·서비스 계정 이상 행위 감시로 버텨야 함.

1. 이 취약점이 왜 유독 위험한가

인증 관련 취약점에도 급이 있음. 자격증명 추측(brute force)은 로그인 실패 로그가 쌓이니 티가 남. 토큰 위조는 서명 검증 로직을 뚫어야 하니 난이도가 있음. 그런데 Missing Authentication은 다름.

• 흔적이 안 남음: 로그인 실패가 없음. 실패한 적이 없으니까. 인증 로그를 아무리 봐도 조용함.
• 익스플로잇 신뢰도가 높음: 메모리 손상 취약점처럼 우연에 기대지 않음. 해당 엔드포인트로 요청을 보내면 그냥 동작함.
• 자동화가 쉬움: 조건이 '요청을 보낼 수 있는가' 하나뿐이라, 인터넷에 노출된 SharePoint를 훑는 스캐닝 코드에 금방 편입됨.

SharePoint는 특히 사정이 나쁨. 문서 저장소이자 워크플로 엔진이고, 서비스 계정 권한으로 도는 서버 사이드 컴포넌트가 많으며, 대개 도메인에 가입돼 있음. 즉 SharePoint 한 대는 파일 서버 한 대가 아니라 AD 내부로 들어가는 발판에 가까움. 과거 SharePoint를 겨냥한 사건들이 하나같이 시끄러웠던 이유가 여기에 있음.

2. 개념 수준에서 본 공격 흐름

구체적인 엔드포인트나 페이로드는 다루지 않음. 다만 이 유형이 어떤 모양으로 굴러가는지는 방어자가 알아야 함.

• 1단계 — 식별: 응답 헤더나 특정 경로의 존재 여부로 SharePoint 서버와 버전대를 추정함.
• 2단계 — 인증 없는 호출: 원래는 인증된 관리·서비스 경로로만 닿아야 할 기능을, 세션 쿠키도 없이 직접 호출함.
• 3단계 — 권한 승계: 그 기능이 서버의 서비스 계정 권한으로 실행되므로, 공격자는 자기 계정이 없어도 서버 계정의 힘을 빌려 쓰게 됨.
• 4단계 — 지속성: 웹셸 배치, 스케줄 작업 등록, 머신키 탈취 같은 후속 작업으로 넘어감. 이 단계부터는 패치를 해도 이미 심어진 것들은 남음.

마지막 문장이 중요함. 패치는 문을 잠그는 일이지, 이미 들어온 사람을 내보내는 일이 아님. 노출돼 있던 서버라면 패치 후 반드시 침해 흔적 점검을 같이 해야 함.

3. 지금 당장 할 일 — 우선순위 순서

• 노출 자산부터 확인: 외부에서 접근 가능한 SharePoint가 있는지부터 봄. "우리는 없다"는 확신은 대개 틀림. 협력사 포털, 오래전 만든 익스트라넷, 퇴사자가 세팅한 테스트 서버가 꼭 하나씩 나옴.
• 패치 적용: Microsoft가 배포한 해당 제품 버전용 보안 업데이트를 올림. SharePoint는 팜(farm) 구조라 전 노드에 적용 후 설정 마법사까지 완료해야 실제로 반영되는 경우가 많음. 파일만 덮고 끝냈다고 착각하는 사고가 잦은 지점임.
• 임시 완화: 즉시 패치가 어렵다면 인터넷 노출을 끊는 게 가장 확실함. WAF나 리버스 프록시 앞단에서 인증 없는 관리·서비스 경로 접근을 차단하고, 가능하면 접근 자체를 VPN 뒤로 넣음.
• 사후 점검: 노출 이력이 있었다면 패치 후 웹셸 스캔, 신규 파일 검사, 서비스 계정 활동 검토를 세트로 진행함.

4. 탐지 — 어디를 봐야 하나

이런 유형은 '실패 로그'가 아니라 성공 로그의 이상함에서 잡힘. 관점을 바꿔야 함.

• IIS 로그의 인증 필드: cs-username이 비어 있는데 응답 코드가 200인 요청. 정상 사용자라면 인증을 거치므로 사용자명이 찍힘. 익명인데 성공했다는 조합 자체가 신호임.
• 비정상 Referer·User-Agent: SharePoint 내부 기능을 브라우저 흐름 없이 직접 때리면 Referer가 없거나 어색함. 스캐너 계열 UA도 같이 봄.
• 프로세스 계보: w3wp.exe가 cmd.exe나 powershell.exe를 자식으로 띄우는 순간. 이건 SharePoint 계열 사고의 거의 모든 사례에서 공통으로 나오는, 가장 값싸고 강력한 탐지 규칙임.
• 웹 디렉터리 파일 생성: LAYOUTS 같은 웹 경로에 .aspx 파일이 새로 생기는 이벤트. 배포 창구가 아닌 시간대에 생긴 파일은 특히 의심함.
• 서비스 계정의 외부 통신: SharePoint 서비스 계정이 갑자기 외부로 나가거나, 도메인 컨트롤러 쪽을 기웃거리는 인증 로그.

개인적으로는 세 번째 항목, w3wp.exe의 자식 프로세스 탐지를 제일 먼저 넣는 걸 추천함. CVE 하나에 종속되지 않고 웹셸 실행 전반을 잡아주기 때문에, 다음에 나올 SharePoint 취약점에도 그대로 유효함. 탐지 규칙은 이렇게 취약점이 아니라 행위를 기준으로 만들어 둘 때 오래 감.

5. 이번 건에서 배울 것

Missing Authentication 계열 결함이 반복해서 나오는 이유는 단순함. 개발 과정에서 "이 기능은 내부에서만 호출되니까 인증 체크는 상위 계층이 해주겠지"라는 암묵적 신뢰가 코드 곳곳에 스며들기 때문임. 그리고 그 상위 계층은 리팩터링 몇 번 거치면서 조용히 사라짐. 남는 건 아무도 지키지 않는 문 하나.

방어자 입장에서 이 이야기가 주는 교훈은 '네트워크 경계가 인증을 대신해 줄 거라 믿지 말자' 정도로 정리됨. 인트라넷 안에 있으니 괜찮다는 가정은 그 자체가 또 하나의 암묵적 신뢰임. 공격자가 VPN 계정 하나만 얻어도, 협력사 포털 하나만 찾아도 그 가정은 무너짐.

마무리

정리하면 순서는 이러함. 노출 확인 → 패치(팜 전체 + 설정 마법사) → 침해 흔적 점검 → 행위 기반 탐지 규칙 정비. 이 중 앞의 두 개는 오늘 안에 시작할 수 있는 일이고, 뒤의 두 개는 다음에 비슷한 CVE가 떴을 때 여러분을 살려줄 일임.

SharePoint 운영하시는 분들, 이번 주말은 좀 바쁘실 것 같음. 사내에 잊혀진 SharePoint 서버 하나쯤 찾아내셨다면 댓글로 알려주세요. 다들 하나씩은 나오더라구요. 같이 점검해보아요!