PLC 두 모델 사이의 거리를 AI가 좁혔을 때 — 방어자가 다시 계산해야 할 것들

이미지 출처: The Hacker News

보안 컨퍼런스 발표 자료 중에 이런 문장이 있었음. "동일 벤더의 다른 모델로 익스플로잇을 옮기는 데 보통 몇 주가 걸린다." 연구자들이 대형 언어모델을 붙여 그 작업을 시도했더니, 사전 인증(pre-auth) 원격코드실행 익스플로잇이 다른 PLC 모델에서 동작하기까지 걸린 시간이 며칠 단위로 줄었다는 결과가 나옴. 여기서 방어자가 붙잡아야 할 건 "AI가 해킹한다"는 자극적인 헤드라인이 아니라, 익스플로잇 재사용 비용이 내려가면 우리 자산 목록의 우선순위가 통째로 바뀐다는 사실임.

핵심 요약

• 연구자들이 LLM을 활용해 한 PLC 모델의 pre-auth RCE 익스플로잇을 같은 계열 다른 모델로 이식하는 데 성공했고, 기존에 수 주 걸리던 포팅 시간이 크게 단축됨
• 핵심 위협은 새로운 취약점이 아니라 "패치 안 된 소수 모델"이라 안심하던 자산이 더 이상 안전지대가 아니게 된 것
• OT 환경은 즉시 패치가 어려우므로 네트워크 분리·프로토콜 화이트리스트·PLC 상태 변화 모니터링 같은 보상통제로 방어선을 세워야 함

1. 무슨 일이 있었나 — 사건의 뼈대

정리하면 이럼.

• 연구자들이 이미 알려진 PLC 취약점 하나를 골랐음. 인증 없이 네트워크만 닿으면 코드 실행이 가능한 부류, 즉 pre-auth RCE.
• 이 익스플로잇은 특정 모델·특정 펌웨어에서만 동작하도록 만들어져 있었음. 메모리 배치, 함수 오프셋, 프로토콜 처리 루틴이 모델마다 미묘하게 다르기 때문임.
• 연구자들은 대상 모델의 펌웨어를 뜯어 얻은 정보를 LLM에게 주고, 원본 익스플로잇을 다른 모델용으로 다시 쓰게 하는 반복 작업을 돌렸음.
• 결과는 동작하는 익스플로잇. 사람이 붙어서 검증하고 손봐야 하는 구간은 여전히 남았지만, 가장 지루하고 시간을 잡아먹던 "차이 찾아 맞추기" 작업이 대폭 압축됐음.

여기서 오해하지 말아야 할 게 있는데, AI가 스스로 0-day를 발굴해 세상에 없던 공격을 만든 게 아님. 이미 존재하는 공격을 다른 문에 맞는 열쇠로 갈아 끼우는 작업의 인건비가 내려간 것임. 방어 입장에서는 이 구분이 꽤 중요함.

2. 왜 하필 PLC인가

PLC(Programmable Logic Controller)는 공장 라인, 정수장 펌프, 빌딩 공조, 발전 설비 같은 물리 세계를 직접 제어하는 장비임. IT 서버가 털리면 데이터가 새지만, PLC가 털리면 밸브가 열리고 모터가 멈춤. 그런데 이 장비들의 보안 특성이 좀 고약함.

• 패치가 곧 정지: 펌웨어 업데이트는 라인 정지를 의미함. 분기 단위, 심하면 연 단위 정비 기간까지 미뤄짐.
• 수명이 김: 10년, 15년 넘게 도는 장비가 흔함. 벤더가 지원을 끝낸 모델도 현장에서 여전히 돌아감.
• 인증 개념이 얕음: 설계 당시엔 폐쇄망 전제였음. 프로토콜 자체에 인증이 없거나 형식적인 경우가 많음.
• 모델 파편화: 같은 시리즈여도 리비전마다 펌웨어가 다름. 역설적으로 이게 지금까지 일종의 방어막이었음.

마지막 항목이 이번 연구가 건드린 지점임. "우리 장비는 마이너 모델이라 공개된 PoC가 없다"는 말이 그동안 은근한 위안이었는데, 포팅 비용이 내려가면 그 위안은 유통기한이 짧아짐.

3. 방어자 관점에서 바뀌는 계산

위험도 산정을 다시 해야 함. 기존에는 "공개 PoC 존재 여부"가 실질 위험을 가르는 큰 변수였음. 앞으로는 이렇게 봐야 함.

• 같은 코드베이스를 공유하는 형제 모델은 한 묶음으로 취급. A 모델에 PoC가 나왔으면 B·C 모델도 노출 상태로 간주하고 대응 우선순위를 매기는 게 안전함.
• "어렵다"는 시간 지연에 기대지 않기. 포팅 난이도는 공격자 입장에서 비용이었지 방어책이 아니었음. 비용이 줄면 방어 효과도 같이 줄어듦.
• 노출면이 유일한 상수. 인터넷이나 사무망에서 PLC 관리 포트에 닿을 수 있느냐, 이게 여전히 가장 확실한 통제 지점임.

4. 지금 당장 할 수 있는 탐지·완화

펌웨어를 못 올린다고 손 놓을 필요는 없음. 개인적으로는 아래 순서를 추천함.

• 노출 자산 실사부터: Shodan이나 Censys 같은 검색엔진에 자사 IP 대역을 넣어 산업용 프로토콜 포트가 외부로 열려 있는지 확인. 놀랍게도 "설치 업체가 원격 유지보수용으로 뚫어둔 포트"가 이 단계에서 자주 나옴.
• 망 분리와 단방향 통로: 제어망과 업무망 사이에 방화벽·DMZ를 두고, 가능하면 데이터는 나가는 방향만 허용. 엔지니어링 워크스테이션은 제어망 안쪽에 두고 별도 계정으로 관리.
• 프로토콜 화이트리스트: Modbus, S7comm, EtherNet/IP 같은 제어 프로토콜은 통신 상대와 기능 코드가 사실상 고정임. "허용된 HMI IP에서 온 읽기 요청만" 같은 규칙을 세우면 정체불명의 쓰기·다운로드 명령이 곧바로 걸림.
• PLC 상태 변화를 이벤트로 다루기: 프로그램 다운로드, RUN/STOP 모드 전환, 펌웨어 업데이트 시도는 정상 운영 중엔 거의 안 일어나는 행위임. 이런 이벤트를 SIEM으로 보내고 정비 일정과 대조하면 탐지 정확도가 꽤 높음.
• 펌웨어 해시·설정 기준선 관리: 정상 상태의 펌웨어 버전과 로직 프로그램을 기록해두고 주기적으로 비교. 변조 여부를 판단할 기준선이 없으면 사고 후 포렌식이 거의 불가능해짐.
• 정비 창에 맞춘 패치 계획: 벤더 권고를 모아두고 다음 정비 기간에 한 번에 반영할 목록을 미리 만들어두는 게 현실적임. 급할 때 만들면 항상 빠뜨리게 됨.

5. 조금 더 넓게 보면

이번 연구가 던지는 메시지는 OT에만 국한되지 않음. 익스플로잇을 다른 아키텍처·다른 버전·다른 제품으로 옮기는 작업 전반이 저렴해지고 있다는 신호로 읽는 게 맞다고 봄. 그동안 우리는 "취약점은 있지만 실제로 공격하려면 실력과 시간이 필요하니까"라는 암묵적 완충재 위에서 위험을 계산해왔는데, 그 완충재가 얇아지는 중임.

그렇다고 비관할 일만은 아닌 것 같음. 같은 도구는 방어 쪽에서도 씀. 펌웨어 차이 분석, 로그 상관관계 찾기, 자산 목록 정리, 탐지 규칙 초안 작성 같은 작업도 똑같이 빨라짐. 결국 남는 건 누가 먼저 자기 환경을 정확히 파악하고 있느냐의 문제인 것 같음. 공격자는 우리 네트워크 구조를 모르지만, 우리는 알 수 있음. 그게 유일하게 우리 쪽이 앞선 카드임.

마무리

오늘 당장 할 일 하나만 고르라면, 제어망 장비 목록을 열어서 "이 모델이랑 같은 계열인 형제 모델에 공개된 취약점이 있나"를 확인해보는 것부터 권하고 싶음. 목록이 없으면 목록 만드는 게 첫 과제고. 지루한 작업이지만 이런 게 쌓여야 나중에 뉴스가 터졌을 때 몇 분 안에 "우리는 해당 없음" 또는 "여기 세 대 위험함"이라고 답할 수 있음.

혹시 현장에서 제어망 자산 관리하시는 분들, 어떤 방식으로 기준선 잡고 계신지 궁금함. 댓글로 공유해주시면 같이 배워보아요!