설계 도면 서버를 노린 웹셸, PTC Windchill RCE가 KEV에 오른 이유

이미지 출처: The Hacker News

제조업체의 사내망 깊숙한 곳에는 외부에 잘 알려지지 않은 시스템이 하나씩 있다. 도면, 부품 명세, 설계 변경 이력이 전부 모여 있는 PLM(제품 수명주기 관리) 서버가 그렇다. PTC Windchill이 바로 그 자리에 있는 제품인데, 여기서 발견된 원격코드실행(RCE) 취약점이 미국 CISA의 KEV(알려진 악용 취약점) 목록에 올랐고, 실제 공격에서 웹셸이 계속 심어지고 있다는 보고가 이어지고 있음.

핵심 요약

• PTC Windchill의 RCE 취약점이 실제 악용 사례 확인으로 CISA KEV에 등재됨
• 공격자는 RCE를 발판으로 서버에 웹셸을 올려 지속 접근·내부 이동을 시도함
• 방어의 핵심은 즉시 패치·외부 노출 차단·웹셸 흔적 탐지의 3박자

왜 하필 PLM 서버가 표적이 되나

Windchill 같은 PLM 시스템은 공격자 입장에서 보면 '한 번 뚫으면 회사의 지식 자산이 통째로 따라오는' 곳임. 신제품 도면, 협력사 정보, 생산 공정 데이터가 한데 모여 있으니 산업 스파이나 랜섬웨어 조직 모두에게 가치가 높음. 게다가 이런 내부 업무 시스템은 "어차피 사내에서만 쓰니까"라는 생각에 인터넷에 그대로 노출돼 있거나, 패치 주기가 한참 밀려 있는 경우가 흔함. 공격자가 노리기 딱 좋은 조건이 갖춰져 있는 셈.

RCE에서 웹셸로 이어지는 흐름

구체적인 공격 코드는 다루지 않고 개념만 짚자면 흐름은 단순함. 인증 우회 혹은 입력 검증이 부실한 지점을 통해 서버에서 임의의 코드를 실행할 수 있게 되면, 공격자는 가장 먼저 웹셸을 남김. 웹셸은 웹 서버가 해석하는 스크립트 파일(JSP, ASPX 등) 형태로 심어지는 작은 원격 제어판 같은 것임. 정상 페이지처럼 보이는 URL에 요청을 보내면 그 뒤에서 명령이 실행됨.

웹셸이 무서운 이유는 '재방문 보장'에 있음. 취약점을 패치하더라도 이미 디스크에 떨어진 웹셸 파일은 그대로 남기 때문에, 패치만 하고 흔적 점검을 건너뛰면 공격자는 같은 문으로 다시 들어옴. KEV에 올랐다는 건 "이론이 아니라 지금 당하고 있는 취약점"이라는 신호라, 패치와 침해 흔적 조사를 한 묶음으로 가야 함.

방어자가 지금 해야 할 점검

• 패치 우선순위 최상위로: Windchill을 운영 중이라면 벤더 공지에 맞춰 해당 RCE 패치를 즉시 적용함. KEV 등재 항목은 미루는 순간 그 자체가 위험임.
• 외부 노출 차단: 관리·업로드 인터페이스가 인터넷에서 직접 닿는지 확인하고, 가능한 한 VPN이나 사내망 뒤로 숨김. 접근을 꼭 필요한 IP 대역으로만 제한함.
• 웹 디렉터리 무결성 점검: 웹 애플리케이션 배포 경로에 최근 생성·수정된 스크립트 파일이 있는지 확인함. 정상 빌드 시점과 어긋나는 파일 타임스탬프가 첫 단서가 되는 경우가 많음.
• 접근 로그 들여다보기: 평소 호출되지 않던 단일 페이지에 POST 요청이 반복되거나, 사용자 에이전트가 어색하고 한 IP에서 명령 실행성 파라미터가 줄줄이 들어오는 패턴을 찾음.
• 아웃바운드 통신 감시: 서버가 외부로 먼저 연결을 맺는 정황(역방향 셸, 데이터 반출)이 보이는지 방화벽·프록시 로그에서 확인함.

패치 이후가 진짜 시작

경험상 이런 사고에서 가장 자주 빠지는 단계가 '패치 후 정리'임. 구멍은 막았는데 이미 들어와 있던 웹셸이나 추가로 만든 계정, 예약 작업이 남아 있으면 며칠 뒤 똑같은 일이 반복됨. 그래서 패치를 끝냈다면 곧바로 해당 서버의 파일 시스템 변경 이력, 신규 관리자 계정, 스케줄러 항목을 한 번 훑어보길 개인적으로 추천함. 가능하면 사고 이전 시점의 백업과 현재 상태를 비교해 보는 것이 가장 확실함.

Windchill을 쓰지 않더라도 교훈은 똑같음. 내부 업무용이라 방심했던 시스템일수록 패치는 느리고 노출은 넓은 경우가 많음. 우리 회사의 '도면 창고'는 지금 인터넷 어디에서 닿을 수 있는지, 마지막 패치는 언제였는지 이번 기회에 같이 점검해 보아요. 점검하다 막히는 부분이 있으면 댓글로 남겨 주세요.