CVE-2026-50522, SharePoint 역직렬화 결함을 EDR 로그에서 먼저 잡아내기

이미지 출처: CISA KEV

사내 문서, 결재 양식, 부서 포털, 협업 위키까지 — 규모 있는 조직에서 SharePoint는 대개 '없어서는 안 되는' 자리에 앉아 있음. 그만큼 인증된 사용자가 서버로 보내는 데이터의 종류도 많고, 그중에는 사람이 읽으라고 만든 게 아니라 서버끼리 주고받는 직렬화된 객체도 섞여 있음. CVE-2026-50522는 바로 그 지점, 즉 '신뢰하지 않은 데이터를 서버가 되살리는 과정'에서 벌어지는 문제임.

핵심 요약

• CVE-2026-50522는 신뢰되지 않은 데이터의 역직렬화(CWE-502) 계열 결함으로, 조작된 직렬화 객체가 SharePoint 서버에서의 코드 실행으로 이어질 수 있음.
• 가장 확실한 방어는 벤더 패치 적용이고, 탐지 관점의 핵심은 SharePoint 앱풀 프로세스(w3wp)가 갑자기 자식 프로세스나 웹셸을 만들어내는 순간을 잡는 것.
• 서비스 계정 최소 권한과 네트워크 분리로 '뚫린 다음'의 확산을 좁혀두는 게 방어자의 실질적 승부처임.

역직렬화가 왜 위험한가 — 데이터가 코드로 바뀌는 지점

직렬화(serialization)는 메모리 위의 객체를 저장·전송하기 좋게 바이트 덩어리로 납작하게 만드는 작업이고, 역직렬화(deserialization)는 그걸 다시 객체로 복원하는 과정임. 문제는 복원할 때 서버가 '이 데이터가 어디서 왔는지, 어떤 타입이어야 정상인지'를 충분히 검증하지 않으면, 공격자가 원하는 객체 구조를 그대로 만들어 넣을 수 있다는 데 있음.

단순히 값 하나 바꾸는 수준이 아니라, 복원 과정에서 자동으로 호출되는 메서드들을 사슬처럼 엮어 원치 않는 동작으로 흘려보내는 방식이 알려져 있음(이른바 가젯 체인). 세부적인 페이로드 제작법은 여기서 다루지 않지만, 핵심 개념은 "입력 데이터가 실행 흐름을 결정하게 되는 순간 신뢰 경계가 무너진다"는 것임. SharePoint 계열이 과거부터 이 부류 취약점의 단골이었던 건 ViewState, machineKey처럼 서명·복원이 얽힌 구조를 많이 품고 있기 때문임.

CVE-2026-50522가 건드리는 신뢰 경계

이 결함의 본질은 서버가 외부에서 들어온 직렬화 데이터를 '내가 만든 정상 데이터'와 똑같이 취급해 복원해버리는 데 있음. 인증 상태나 특정 요청 경로에 따라 조건은 달라지지만, 성공 시 코드가 실행되는 맥락은 대개 SharePoint 웹 애플리케이션 풀 계정, 즉 w3wp.exe가 가진 권한임. 이 계정이 넓은 권한을 갖고 있을수록, 그리고 다른 서버와 자유롭게 통신할수록 피해 반경이 커짐. 공개된 CVSS 수치나 세부 버전 범위는 벤더 고지에 맞춰 확인해야 하며, 여기서는 방어 설계에 집중함.

방어자 관점: 어디를 보면 탐지되는가

역직렬화 공격은 '입구'보다 '결과'에서 티가 나는 경우가 많음. 즉 요청 자체를 완벽히 걸러내기 어렵더라도, 실행 이후의 행위는 비교적 뚜렷한 신호를 남김.

• w3wp의 수상한 자식 프로세스: SharePoint 앱풀 프로세스가 cmd.exe·powershell.exe·mshta 같은 프로세스를 생성하면 거의 항상 이상 신호임. EDR에서 이 부모-자식 관계를 상시 룰로 걸어둘 것.
• 웹셸 파일 생성 감시: LAYOUTS, TEMPLATE, wwwroot 하위에 신규 .aspx/.ashx가 생기는 이벤트를 파일 무결성 모니터링으로 잡음.
• IIS·ASP.NET 로그: 비정상적으로 큰 __VIEWSTATE 값, 반복되는 ViewState MAC 검증 실패, 특정 관리 엔드포인트로의 예상 밖 POST 패턴.
• AMSI 연동 경보: 최신 SharePoint는 AMSI 통합을 지원하므로, 이를 켜두면 복원 직후 실행되는 악성 스크립트 단계에서 한 번 더 걸림.

완화와 하드닝 체크리스트

• 패치 최우선: 벤더 보안 업데이트 적용이 근본 해결책임. 테스트 핑계로 미루는 기간이 곧 노출 창구가 됨.
• ViewState 무결성 점검: ViewState MAC이 확실히 활성화돼 있는지 확인하고, machineKey 유출이 의심되면 지체 없이 로테이션.
• AMSI 통합 활성화: 지원 버전이라면 반드시 켜서 실행 단계 탐지 계층을 하나 더 확보.
• 최소 권한 서비스 계정: 앱풀 계정에 과한 권한을 주지 말고 gMSA 등으로 관리, 도메인 관리자급 위임은 금물.
• 네트워크 분리: SharePoint 서버가 내부 어디로든 자유롭게 나가지 못하도록 세그먼트를 나누고, 관리 인터페이스는 외부에 노출하지 않음.
• WAF는 보조 수단: 알려진 가젯 시그니처나 이상 직렬화 패턴 차단은 도움이 되지만, 우회 가능성이 있으므로 단독 방어선으로 믿지 말 것.

마무리하며

개인적으로는 이런 역직렬화 계열 취약점을 만날 때마다 '입구를 다 막겠다'는 욕심보다, 패치·최소권한·행위 탐지 세 축을 동시에 두껍게 쌓는 쪽을 추천함. 특히 w3wp가 셸을 띄우는 룰 하나만 제대로 걸려 있어도 실제 사고에서 초동이 완전히 달라지는 걸 여러 번 봤음. 우리 환경에도 그 룰이 켜져 있는지, machineKey 관리가 되고 있는지 오늘 한 번씩 확인해 보아요. 각자 SharePoint 로그에서 잡아낸 이상 징후가 있다면 댓글로 공유해 주시면 같이 정리해 봅시다.