NetScaler 두 취약점이 연쇄 악용됐다…패치 뒤 흔적도 확인하라

|작성자: QUASA 편집팀|5 분 소요
NetScaler 두 취약점이 연쇄 악용됐다…패치 뒤 흔적도 확인하라

10월 19일 공개된 Rapid7의 NetScaler 침해 분석은 10월 초 조사한 영향받는 14.1 빌드의 NetScaler ADC에서 CVE-2026-88771과 CVE-2026-88779가 연쇄 악용됐다고 기록했다. 공격자는 root 권한으로 코드를 실행한 뒤 웹셸과 지속성 수단을 설치했고, 내부 서비스를 정찰하고 장비 설정과 키 관련 자료를 반출했다.

대응은 실행 중인 빌드와 SAML 구성을 확인해 해당 수정 버전을 적용하는 데서 시작한다. 이어 인터넷에서 로그인 서비스에 닿는 경로를 줄이고, 취약했던 기간의 인증·재부팅 기록과 웹셸, 외부 통신, 자료 반출 흔적을 조사해야 한다. 패치는 취약점을 닫지만 이미 설치된 접근 수단이나 반출된 비밀정보까지 처리하지는 않는다.

로그 주입과 SAML 재부팅이 맞물린 방식

두 취약점은 공격에서 서로 다른 역할을 했다. CVE-2026-88771을 통해 인증 전에 공격자가 제어한 명령 문자열이 로그에 남았고, CVE-2026-88779를 악용한 SAML 처리 오류가 인증 데몬 충돌과 재부팅을 유발했다. 재부팅 뒤 오류 처리기가 남아 있던 문자열을 읽으면서 명령이 root 권한으로 실행됐다.

조사 기록에는 악성 인증 요청, nsaaad 충돌, Pitboss 재부팅, 재부팅 후 처리기의 실행이 차례로 나타난다. 최초 악성 파일의 생성 시점도 명령 실행 기록과 맞아떨어졌다. 재부팅은 이 사례에서 단순한 서비스 장애가 아니라 앞서 심어 둔 명령이 실행되는 계기였으므로, 관리자는 장애 로그와 인증 로그를 같은 시간축에서 살펴야 한다.

실행은 한 번으로 끝나지 않았다. 장비에는 여러 날에 걸친 재부팅과 오류 처리기의 재실행이 기록됐고, 공격자는 이를 이용해 구성요소를 다시 배치하고 접근 수단을 유지했다. 따라서 패치 직후 악성 프로세스가 보이지 않더라도 취약했던 기간의 파일 생성 시각, 시작 작업 변경과 외부 연결을 함께 조사할 필요가 있다.

영향 빌드와 SAML 설정에 따라 수정 버전이 다르다

영향받는 NetScaler ADC의 외부 연결 범위를 줄이고 수정 버전을 적용하는 대응

Beazley Security의 NetScaler 권고문에 따르면 일반 NetScaler ADC·Gateway에서 CVE-2026-88771의 수정 기준은 14.1 계열 14.1-73.37과 13.1 계열 13.1-64.23이지만, SAML 관련 CVE-2026-88779까지 수정하려면 각각 14.1-73.41과 13.1-64.28 이상이 필요하다. ADC의 FIPS·NDcPP 제품군에는 별도 빌드 기준이 적용된다.

CVE-2026-88771은 추가 기능을 켜지 않은 장비에도 영향을 줄 수 있다. 반면 연쇄 공격에서 재부팅을 일으킨 CVE-2026-88779는 SAML 인증 구성이 전제다. 관리자는 제품명만 보지 말고 실제 빌드, Gateway 또는 AAA의 SAML 사용 여부, 같은 고가용성 구성에 속한 상대 장비의 상태를 각각 확인해야 한다.

두 취약점의 결과도 구분해야 한다. SAML 처리 오류 자체는 서비스 거부 조건으로 설명되며, 앞서 로그에 명령이 주입된 취약 장비에서 재부팅과 결합할 때 명령 실행으로 이어졌다. CVE-2026-88771을 이미 수정한 장비에서도 같은 방식의 코드 실행이 확인됐다고 해석해서는 안 된다. 다만 해당 장비가 수정되기 전에 인터넷에 노출됐다면, 그 기간에 설치된 웹셸이나 시작 작업이 남아 있는지는 별도로 조사해야 한다.

침해가 의심되는 장비는 재부팅이나 재구축 전에 확보할 수 있는 휘발성 자료와 로그를 보존하는 것이 조사에 도움이 된다. 이 과정과 수정 버전 적용을 함께 계획하고 작업 시각을 남기면 패치 전 공격 흔적과 패치 과정에서 생긴 변경을 구분할 수 있다. 수정 빌드 설치 여부는 화면의 완료 표시만이 아니라 실제 실행 버전으로 확인해야 한다.

패치 뒤에도 로그인 서비스의 직접 노출을 줄인다

Cloudflare의 NetScaler Gateway 방어 설명은 패치를 우선 적용한 뒤 공개 로그인 경로 앞에 별도 접근 정책과 WAF를 두고, 원본 장비로 직접 연결되는 경로도 제한할 것을 제안한다. 접근 정책은 로그인 서비스에 도달할 수 있는 대상을 줄이고, WAF는 그 경로로 들어오는 웹 요청을 검사한다.

공개 도메인에만 통제를 걸어 두면 원본 IP 주소나 다른 호스트 이름으로 같은 인증 서비스에 접속하는 경로가 남을 수 있다. 그래서 공개 로그인 주소뿐 아니라 원본으로 향하는 직접 연결도 확인해야 한다. 웹 인증 경로에 둔 통제는 DTLS를 사용하는 다른 Gateway 리스너까지 자동으로 적용되지 않으므로, 그 인터페이스의 노출과 수정 상태는 따로 살펴야 한다.

접근 제한은 이후 장비에 도달할 요청을 줄이는 조치다. 취약했던 장비에 이미 설치된 웹셸이나 외부 명령 채널은 별도의 침해 조사 대상이다. 네트워크 경계를 바꾼 시각을 기록해 두면 그 전후의 연결을 나눠 보고, 변경 이후에도 이어지는 비정상 통신을 찾기 쉽다.

웹셸에서 설정 반출까지 이어지는 조사 순서

NetScaler 고가용성 구성의 양쪽 장비에서 지속성과 침해 흔적을 확인하는 조사

조사는 로그인 요청 한 건이나 악성 파일 하나를 찾는 데 그쳐서는 안 된다. 확인된 침해에는 CSS 파일처럼 보이는 주소로 연결한 PHP 웹셸, 재시작 뒤 접근을 복구하는 작업, 외부 명령 채널과 내부 정찰 도구가 함께 있었다. 한 흔적이 발견되면 같은 장비의 다른 접근 경로와 고가용성 상대 노드까지 범위를 넓히는 편이 타당하다.

  1. 인증 로그에서 비정상적인 사용자 이름과 명령 문자열을 찾고, nsaaad 충돌·Pitboss 재부팅·재부팅 뒤 오류 처리기의 실행 기록을 시간순으로 맞춘다. 요청과 명령 실행 사이에 간격이 있을 수 있으므로 한 시각의 이벤트만 검색하지 않는다. 충돌 기록만으로 침해를 단정하지 말고 이후 파일과 프로세스 흔적에 연결한다.
  2. Gateway의 LogonPoint 사용자 지정 디렉터리와 Apache 설정을 대조한다. 조사된 장비에서는 .slap.receiver, .ctxs.receiver, receiver.deb라는 웹셸과 CSS 형태의 주소 별칭이 확인됐다. 이 웹셸은 명령 결과를 HTTP 404 응답 본문에 담았으므로, 오류 응답도 요청 경로와 응답 크기를 함께 살펴볼 만하다.
  3. 시작 스크립트, 예약 작업, 감시 프로세스와 /bin/sh 권한 변경을 확인한다. /nsconfig/.slap, /nsconfig/.relay, /flash/.nsvm 경로는 해당 침해에서 사용된 지속성 단서다. 공격 코드에는 악성 파일을 고가용성 상대 노드로 동기화하려는 기능도 있었으므로, 한쪽 장비만 검사한 결과로 구성 전체를 판단하기 어렵다.
  4. 장비에서 외부로 향한 명령 채널·업로드 연결과 내부로 향한 정찰 연결을 나눠 조사한다. 이 사례의 정찰 도구는 DNS, LDAP·Active Directory, 관리 서비스와 VMware vCenter에 닿는 경로를 조사했다. 로컬 로그가 삭제됐을 가능성을 고려해 방화벽과 프록시 기록도 장비의 접속 시각에 맞춰 본다.
  5. /nsconfig, 과거 설정 백업, 웹 서버 설정과 시스템 백업이 수집·압축·전송됐는지 확인한다. 조사된 장비에서는 웹 경로에 둔 별도 압축 자료가 실제로 다운로드된 기록도 있었다. 외부 업로드 기록과 웹 다운로드 기록을 모두 봐야 자료가 빠져나간 경로를 놓치지 않는다.

이 파일명과 경로는 확인된 침해의 단서이지 모든 공격에 공통인 목록은 아니다. 해당 파일이 없을 때도 낯선 PHP 처리 설정, 시작 작업, 네트워크 연결 또는 삭제 흔적이 남아 있을 수 있다. 서로 다른 로그와 파일의 시각을 연결해 실제 실행 범위를 판단해야 한다.

반출된 설정이 자격증명 교체 범위를 정한다

NetScaler 설정과 백업에는 관리자 설정, LDAP·RADIUS 연결 정보, 암호화된 자격증명, SSL 개인키와 키 암호화 관련 자료가 들어갈 수 있다. 어떤 압축 자료가 만들어졌고 무엇이 전송됐는지 확인한 뒤, 그 자료에 포함된 계정과 키를 식별해야 한다. 실제 반출이 확인된 자료에 포함된 비밀정보는 폐기·교체 범위에 넣고 연결된 서비스의 인증 기록도 살펴야 한다.

웹셸이나 지속성 장치가 발견됐다면 악성 파일만 삭제해 정상 상태를 회복했다고 판단하기 어렵다. 변경된 Apache 설정, 시작 작업, 고가용성 동기화 경로와 상대 노드의 상태를 함께 조사하고, 신뢰할 수 있는 상태에서 재구축할 필요가 있는지 결정해야 한다. 이 사례처럼 설정 자료의 다운로드까지 확인됐다면 장비 복구와 별개로 해당 계정과 키의 교체가 사고 수습의 핵심 작업으로 남는다.

함께 읽기:

공유:

뉴스레터 구독

최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.

0