도면 서버가 먼저 뚫렸다 — Cl0p이 노린 Windchill·FlexPLM, 방어자 체크리스트

이미지 출처: The Hacker News

제조사의 네트워크 다이어그램을 그려보면 재미있는 게 하나 보임. ERP, 그룹웨어, VPN 게이트웨이는 다들 신경 써서 이중화하고 로그도 붙여두는데, 정작 제품 설계 데이터가 통째로 들어 있는 PLM 서버는 "협력사가 접속해야 하니까"라는 이유로 인터넷에 열려 있고, 담당자는 IT팀이 아니라 설계팀인 경우가 많음. Cl0p 계열 공격자들이 PTC Windchill과 FlexPLM을 겨냥하고 있다는 이야기가 나왔을 때, 개인적으로 제일 먼저 떠오른 게 이 그림이었음.

핵심 요약

• Cl0p 제휴 조직이 인터넷에 노출된 PTC Windchill·FlexPLM을 표적으로 삼아, 인증 없이 원격 코드 실행이 가능한 결함을 악용하는 정황이 보고됨.
• 이 계열의 전형적 목표는 암호화가 아니라 대량 데이터 탈취 후 협박이므로, 랜섬노트가 뜨기 전에 이미 도면·BOM이 빠져나갔을 수 있음.
• 방어는 패치 적용과 함께 노출 면 축소·아웃바운드 통제·웹 서버 프로세스의 자식 프로세스 탐지가 핵심임.

왜 하필 PLM이었을까

Cl0p이 그동안 건드려 온 대상들을 죽 늘어놓아 보면 패턴이 꽤 선명함. MOVEit, GoAnywhere, Accellion FTA, Cleo… 전부 조직 바깥과 데이터를 주고받는 관문이었음. 이런 시스템들의 공통점은 세 가지인데, 하나는 인터넷에 열려 있어야 기능한다는 것, 둘은 그 안에 조직이 가장 잃기 싫어하는 데이터가 모여 있다는 것, 셋은 보안팀보다 현업 부서가 운영 주도권을 쥐고 있어서 패치 주기가 느리다는 것임.

PLM은 이 조건을 정확히 세 개 다 충족함. Windchill이나 FlexPLM 안에 뭐가 들어 있는지 생각해 보면 아찔한데, CAD 도면, BOM(부품표), 제조 공정 사양, 협력사 계약 문서, 출시 전 제품 스펙 같은 것들임. 유출되면 "고객 개인정보 몇 건" 수준의 이야기가 아니라 회사의 기술 경쟁력 자체가 통째로 상대 손에 넘어가는 사건이 됨. 협박 지렛대로서의 가치가 대단히 높다는 뜻이고, 공격자 입장에선 표적 하나만 성공해도 수익이 크게 나오는 구조임.

인증 없이 원격 코드 실행이 된다는 점도 이들이 좋아하는 조건임. 자격증명 탈취나 피싱 같은 앞단계가 통째로 생략되고, 인터넷 스캔으로 대상을 긁어모은 뒤 자동화된 요청 한 번으로 발판을 만들 수 있음. 그래서 이 계열 캠페인은 표적형이 아니라 대량 수확형으로 진행되는 경우가 많음. "우리 회사가 그렇게 중요한가?" 하는 생각은 이 상황에선 별 의미가 없다는 거죠.

공격 흐름을 개념 수준에서 정리하면

구체적인 요청 형태나 페이로드는 여기서 다루지 않되, 방어 지점을 잡으려면 단계 구분은 필요하니 개념만 짚어봄.

• 1단계 - 노출 자산 식별: 검색 엔진성 스캐너로 특정 배너·경로·로그인 페이지 특징을 가진 호스트를 수집함. 이 단계는 이미 끝나 있다고 보는 게 안전함.
• 2단계 - 인증 전 진입: 인증을 요구하지 않는 엔드포인트를 통해 애플리케이션 서버 권한으로 코드가 실행됨. 자바 기반 웹 애플리케이션 구조 특성상, 실행 주체는 대개 톰캣·애플리케이션 서버 프로세스가 됨.
• 3단계 - 지속성 확보: 웹 디렉터리에 작은 스크립트를 남기거나, 정상 관리 도구를 이용해 다시 들어올 통로를 만들어 둠.
• 4단계 - 탐색과 수집: DB 연결 문자열, 파일 저장소 경로, 서비스 계정 자격증명을 훑고 도면·문서 저장소를 압축함.
• 5단계 - 반출: 클라우드 스토리지나 자체 서버로 대용량 전송이 발생함. 이 지점이 방어자가 마지막으로 잡을 수 있는 기회임.

중요한 건 이 계열이 4~5단계에서 멈추는 경우가 많다는 점임. 파일을 암호화하지 않으니 화면에 아무 일도 안 일어나고, 몇 주 뒤에 유출 사이트에 회사 이름이 올라가면서 처음 알게 됨. "랜섬웨어인데 아무것도 안 잠갔다"는 게 오히려 더 무서운 시나리오인 셈임.

지금 당장 확인할 것들

• 노출 여부부터 확인: 사내에 Windchill·FlexPLM 인스턴스가 몇 개인지, 그중 외부에서 직접 닿는 게 있는지 확인함. 자산 목록에 없던 테스트·개발 인스턴스가 열려 있는 경우가 실제로 제일 많음.
• 벤더 보안 공지 확인 후 패치: PTC 보안 공지를 확인해 해당 버전에 대한 수정판을 적용함. 즉시 패치가 어렵다면 최소한 접근 통제를 앞단에 두어야 함.
• 인터넷 직접 노출 해제: 협력사 접속이 필요하다면 VPN 또는 신원 인지형 프록시 뒤로 넣고, 소스 IP 허용 목록을 적용함. 완화책 중 효과 대비 비용이 가장 좋은 방법임.
• 아웃바운드 통제: PLM 서버가 임의의 외부 주소로 대용량 업로드를 할 이유는 없음. 기본 차단 후 필요한 목적지만 허용하는 구성으로 바꾸면 5단계를 끊을 수 있음.
• 서비스 계정 권한 점검: 애플리케이션 서버가 로컬 관리자나 도메인 권한으로 돌고 있지 않은지 확인함. 진입에 성공해도 확산이 안 되게 만드는 게 목표임.

탐지 관점 - 무엇을 로그에서 찾을 것인가

패치가 끝났더라도 이미 들어와 있었는지는 별도로 봐야 함. 침해 후 조사 관점에서 우선순위가 높은 항목들임.

• 웹/애플리케이션 서버 프로세스의 자식 프로세스: 톰캣이나 자바 프로세스가 cmd, powershell, 셸을 띄우는 이벤트는 정상 운영에서 거의 발생하지 않음. EDR 규칙 한 줄로 잡을 수 있는 가장 가성비 높은 신호임.
• 웹 디렉터리의 신규 파일: 배포 경로에 최근 생성·수정된 jsp·jar·클래스 파일이 있는지 타임스탬프 기준으로 정렬해 확인함. 정식 배포 이력과 대조하는 게 핵심임.
• 인증 없이 접근된 엔드포인트: 웹 접근 로그에서 인증 세션 없이 200 응답을 받은 요청, 평소 쓰이지 않던 경로에 대한 반복 요청, 동일 IP의 짧은 간격 스캔 패턴을 찾음.
• 비정상 아웃바운드: PLM 서버에서 나가는 세션 중 평소 통계 대비 전송량이 튀는 구간, 처음 보는 목적지 도메인, 야간·주말 시간대 대용량 전송을 봄.
• 계정·권한 변화: 새로 생성된 관리자 계정, 기존 서비스 계정의 로그인 위치 변화, 스케줄 작업·서비스 신규 등록 여부를 점검함.
• DB 접근 패턴: 애플리케이션이 평소 사용하지 않던 대량 SELECT나 저장소 전체 순회 흔적이 남았는지 확인함.

여기서 하나 덧붙이자면, 이런 사건이 터졌을 때 로그 보존 기간이 짧아서 조사가 막히는 경우를 자주 봄. 초기 침투가 몇 주 전이었다면 2주짜리 로그로는 아무것도 못 밝힘. 인터넷에 노출된 시스템만이라도 로그 보존을 길게 잡아두는 것을 개인적으로 강하게 추천함.

PLM을 '설계 시스템'이 아니라 '외부 관문'으로 다시 분류하기

이번 사건에서 얻을 수 있는 가장 오래 가는 교훈은 특정 제품의 패치가 아니라고 봄. 조직 안에는 보안팀의 자산 목록에는 흐릿하게 잡혀 있지만 실제로는 인터넷에 노출된 채 핵심 데이터를 쥐고 있는 시스템이 반드시 몇 개씩 있음. PLM, 문서 협업 도구, 파일 전송 서버, 협력사 포털, 견적 시스템 같은 것들이죠.

이런 자산들을 "현업 부서 소유"가 아니라 "외부 접점 자산"으로 다시 분류하고, 노출 면 점검·패치 SLA·로그 수집·아웃바운드 통제를 동일한 기준으로 적용하는 것. 이게 다음 캠페인이 왔을 때 이름만 바뀐 똑같은 사건을 겪지 않는 방법인 것 같음. 공격자는 제품을 노리는 게 아니라 관리 주체가 애매한 지점을 노리는 거니까 말입니다.

주말에 시간 내서 우리 조직의 외부 노출 목록을 한 번 쭉 뽑아보는 것부터 같이 해보아요. 의외로 "이게 왜 열려 있지?" 싶은 게 하나쯤은 나올 거고, 그 하나가 다음 사건을 막아줄 수도 있음. 관련해서 궁금한 점이나 각자 조직에서 쓰는 탐지 규칙이 있으면 댓글로 나눠주세요.