⚛️💀 TRITON / TRISIS (2017) — '안전(Safety)' 그 자체를 겨냥한 최초의 악성코드: 슈나이더 트라이콘 SIS와 TriStation 프로토콜

1. 배경/역사 — '파괴'에서 '안전 무력화'로 넘어간 2017년

ICS(산업제어시스템) 악성코드는 세대마다 '무엇을 노리는가'가 달라졌다. 2010년 Stuxnet은 원심분리기를 망가뜨리기 위해 PLC 로직을 조작했다. 2015~2016년 우크라이나 전력망 공격(BlackEnergy · Industroyer)은 개폐기 명령을 직접 말하는 프로토콜 악성코드였다. 그리고 2017년, 세 번째 세대인 TRITON은 목표를 바꿨다. 파괴가 아니라, 파괴를 막아주는 안전 시스템을 꺼버리는 것이다.

무대는 석유화학 공장이었다. 이 공장에는 SIS(Safety Instrumented System, 안전계장시스템)가 있었다. SIS는 압력·온도·밸브 상태가 위험 임계치를 넘으면 사람이 개입하지 않아도 자동으로 공정을 정지시켜 폭발·화재·인명 피해를 막는 '마지막 안전장치'다. 여기에 쓰인 장비가 슈나이더 일렉트릭의 Triconex(Tricon) 계열 컨트롤러였다. Tricon은 TMR(Triple Modular Redundant) 구조로, 세 개의 독립 채널이 투표(voting)로 결과를 결정해 하나가 고장 나도 안전 기능을 유지하도록 설계된 장비다.

2017년 6월, 공장이 예기치 않게 멈췄다. 당시엔 안전 시스템의 기계적 결함으로 여겨졌다. 8월 두 번째 정지가 일어나자 조사가 시작됐고, 엔지니어링 워크스테이션에서 정체불명의 코드가 발견됐다. 12월 FireEye와 Dragos가 이를 TRITON/TRISIS로 공개하면서 사건의 성격이 드러났다. 공격자는 공정을 조작하려 한 것이 아니라, SIS가 안전 정지를 걸지 못하도록 만들려 했다. 즉 '안전'을 끄고, 공정을 위험 상태로 몰아넣으려 한 것이다.

이 사건이 지금도 회자되는 이유는 단순하다. TRITON은 인명 피해를 목적으로 설계된 것으로 평가되는 최초의 공개 악성코드이며, 동시에 IT 보안의 사고방식이 OT(운영기술) 현장에서 그대로 통하지 않는다는 사실을 가장 뼈아프게 보여준 사례다. 사고는 벤더의 패치, 국가 차원의 제재, 규제·표준 개정으로 이어졌다.

2. 감염·전파 경로 — 자기복제가 아니라 '정밀 침투'

TRITON은 웜이 아니다. Morris Worm·Code Red·Blaster·SQL Slammer처럼 스스로 퍼지지 않는다. 대신 한 현장을 정밀하게 장악하기 위한 표적형(타깃형) 프레임워크다. 그래서 전파 경로는 '인터넷 전체'가 아니라 한 공장의 네트워크 안에서 완성된다.

• ① 초기 침투(IT → OT 피벗) — 공장의 IT 네트워크(사무망)를 먼저 장악하고, IT와 OT를 잇는 '다리'를 찾는다. 완전한 에어갭 환경이 아니라, 유지보수·모니터링을 위해 연결된 통로가 곧 침투 경로가 된다.
• ② 엔지니어링 워크스테이션(EWS) 장악 — 목표는 SIS 컨트롤러가 아니라, 그 컨트롤러에 합법적으로 명령을 내릴 수 있는 Windows PC다. EWS에는 정품 엔지니어링 소프트웨어(TriStation 1131)가 깔려 있고, SIS와 대화할 수 있는 유일한 신뢰 노드다. 신뢰된 노드를 점령하면 프로토콜을 새로 뚫을 필요가 없다.
• ③ '정상 트래픽'으로 위장 — TRITON은 EWS에서 TriStation 프로토콜을 직접 구현해 컨트롤러와 대화한다. 그 트래픽은 관리자의 정품 소프트웨어가 보내는 것과 구별하기 어렵다. 네트워크 IDS 입장에선 '오늘도 엔지니어가 접속했구나' 정도로 보인다.
• ④ 물리 키스위치라는 마지막 관문 — Tricon 컨트롤러는 물리 키스위치(keyswitch)가 '프로그램(PROGRAM)' 위치에 있어야 프로그램 변경을 받아들인다. 즉 원격만으로는 로직을 바꿀 수 없다. 조사 결과 이 현장에서는 여러 물리 키가 접근 가능한 상태로 방치돼 있었고, 이 '사소한 운영 실수'가 공격을 성립시킨 결정적 요인 중 하나로 지목됐다.
• ⑤ 지속 접근과 은닉 — 공격자는 EWS에 상주하며 컨트롤러의 프로그램·펌웨어 정보를 읽고, 여러 차례 주입을 시도했다. 정품 엔지니어링 소프트웨어 옆에서 조용히 동작하는 구조라, 호스트 기반 백신·EDR의 시야에서도 쉽게 드러나지 않았다.

정리하면 TRITON의 감염 경로는 '에어갭의 환상 → 유지보수용 다리 → 신뢰된 EWS → 안전 컨트롤러'라는 4단 사슬이다. 흔한 랜섬웨어 사슬과 겉모습은 비슷하지만, 마지막 화살표의 도착지가 사람의 목숨을 지키는 장치라는 점이 근본적으로 다르다.

3. 동작 원리 상세 분석 — 두 개의 세계, 하나의 프레임워크

TRITON의 구조를 이해하는 열쇠는 '악성코드가 두 개의 서로 다른 세계에서 동시에 살아야 한다'는 점이다. 하나는 x86 Windows 세계(EWS), 다른 하나는 전용 실시간 컨트롤러 세계(Tricon)다. 그래서 TRITON은 하나의 실행 파일이 아니라 역할이 나뉜 프레임워크로 구성됐다는 분석이 지배적이다.

[ 공장 IT/OT 네트워크 ]
        │  (① 초기 침투 · IT→OT 피벗)
        ▼
┌──────────────────────────────────────────────┐
│ 엔지니어링 워크스테이션 (Windows + TriStation 1131) │
│                                              │
│  trilog.exe   ← 런처/로더                     │
│  library.zip  ← 파이썬 프레임워크              │
│    └ tslib    ← TriStation 프로토콜을 구현한 계층 │
│  TsLow.dll / TsHi.dll ← 저수준 통신 DLL         │
│  inject.bin   ← 컨트롤러에 밀어 넣을 페이로드     │
└──────────────────────────────────────────────┘
        │  (② TriStation 프로토콜, UDP 1502 계열)
        │     → 정품 엔지니어링 툴과 구별이 어려움
        ▼
┌──────────────────────────────────────────────┐
│ Triconex SIS 컨트롤러 (TMR: 3중 채널 + 투표)    │
│  · 프로그램/펌웨어 정찰                        │
│  · 메모리 읽기 / 쓰기                         │
│  · 키스위치 상태 조회·조작                     │
│  · ★ 안전 트립(trip) 로직을 무력화하려 시도     │
└──────────────────────────────────────────────┘
   ✗ 실패 → 컨트롤러가 안전 정지/장애 상태로 진입
        → 공정 정지(2017-06 / 2017-08) → 피해자 측 조사 시작

3-1. TriStation은 '엔지니어링 언어'다. TriStation 프로토콜은 엔지니어가 노트북에서 SIS 컨트롤러에 접속해 프로그램을 올리고 내리고(다운로드/업로드), 메모리를 읽고 쓰고, 상태를 조회하기 위한 사내 표준 대화법이다. 즉 태생적으로 강력한 권한을 가진 통로다. TRITON은 이 대화법을 파이썬으로 다시 구현해, 컨트롤러에게는 '정품 툴이 접속한 것'처럼 보이게 만들었다.

3-2. 왜 '메모리 쓰기 + 트립 무력화'인가. SIS가 위험을 감지하면 컨트롤러는 트립(trip)을 걸어 공정을 안전 정지시킨다. 공격자가 노린 것은 트립이 걸리지 않게 하는 것이다. 이를 위해 컨트롤러 메모리(안전 로직이 사용하는 상태·변수 영역)에 값을 쓰거나 페이로드를 주입해, 위험 임계치를 넘어도 정지시키지 않는 상태를 만들려 했다. 이것이 ATT&CK for ICS의 Impair Process Control(T0836) 이다. 데이터를 훔치는 것이 아니라, 물리 공정이 '위험해도 멈추지 않게' 만드는 것이다.

3-3. 물리 계층과의 충돌. 아무리 프로토콜을 완벽히 흉내 내도, 컨트롤러의 물리 키스위치가 PROGRAM이 아니면 프로그램 변경은 거부된다. 그래서 TRITON에는 키스위치 상태를 조회·조작하고, 필요하면 안전 기능을 우회하려는 로직이 포함된 것으로 분석됐다. 결국 이 사고의 성립 조건은 소프트웨어 취약점 + 물리 통제 실패의 결합이었다.

3-4. '실수'가 드러낸 공격. 공격자의 주입 시도는 최종적으로 컨트롤러를 안전 정지/장애 상태로 몰아넣었다. 의도는 '멈추지 않게' 하는 것이었지만, 결과는 공장이 멈추는 것이었다. 이 예기치 못한 정지가 아니었다면 공격은 훨씬 오래 숨어 있었을 수 있다. 즉 이 사건을 세상에 알린 것은 방어 기술이 아니라 공격자의 실패였다는 점이 냉정한 교훈이다.

3-5. 재사용 가능한 '무기'라는 성격. TRITON은 한 현장에서만 쓰이도록 만들어진 일회용 도구가 아니라, 다른 SIS/ICS로 이식 가능한 프레임워크로 평가됐다. 실제로 이후 안전 시스템을 노리는 공격 툴킷(모듈형 ICS 공격 프레임워크)의 등장 정황이 보고되면서, 'SIS를 겨냥하는 위협'은 일회성 사건이 아니라 하나의 계보가 됐다.

4. 피해 규모/영향 — 숫자보다 무거운 것

• 직접 피해: 확인된 현장은 석유화학 공장 1곳, 공정 정지 2회(2017년 6월, 8월). 인명 피해·대규모 환경 재해는 없었지만, 안전 시스템이 무력화될 수 있었던 최초의 실제 사례다.
• 탐지 경위: 첫 정지는 기계 결함으로 오인됐고, 두 번째 정지 후 조사에서야 EWS의 코드가 발견됐다. 탐지까지 약 6개월이 걸렸다.
• 업계·규제 파장: CISA의 ICS 악성코드 분석보고서(MAR/AR18-352A, 'HatMan')와 각국 ICS-CERT 권고가 발간됐고, 벤더(슈나이더)는 Triconex 제품 보안 강화 조치를 내놨다. 2021년에는 Triconex 컨트롤러의 '비정상 조건 검사 미흡(CWE-754)' 취약점 묶음(CVE-2021-22742~22747)이 공개되는 등 펌웨어·검사 로직 강화가 이어졌다.
• 제재·귀속: 2020년 10월 미 재무부 OFAC가 러시아 CNIIHM을 제재하며 TRITON 개발·활용을 근거로 제시했다. 국가 배후 위협으로 공식 문서에 못 박힌 사건이 됐다.
• 정책적 영향: 이 사건은 'IT와 OT의 사고방식이 다르다'는 명제를 규제 언어로 끌어올렸다. 기능 안전(제어가 안전하게 실패하게 만드는 설계)과 보안(외부 명령이 신뢰된다는 가정을 없애는 설계)을 같은 시스템에서 함께 고민해야 한다는 흐름이 본격화됐다.

정리하면 TRITON의 '숫자'는 작다. 그러나 '의미'는 악성코드 역사에서 가장 무거운 축에 든다. 피해 규모가 아니라 표적의 성질이 이 사건을 유명하게 만들었다.

5. PoC (교육용 모의 코드 4종)

아래 코드는 모두 교육용 모의(mock) 실습이다. 실제 TriStation 프로토콜의 명령 코드·정수·패킷 형식은 쓰지 않았고, 컨트롤러에 프로그램을 내려보내는 기능도, 실제 취약점을 겨냥하는 익스플로잇도 없다. 목적은 "안전 트립을 끄는 명령이 구조적으로 무엇을 하는가"를 눈으로 확인하는 것뿐이다. 모든 실습은 인터넷과 분리된 가상 랩(/tmp/lab)에서, 여러분이 직접 만든 모의 컨트롤러를 상대로만 수행한다. 실제 설비·타인의 시스템을 대상으로 한 실행은 불법이다.

PoC 1 — '가상 SIS 컨트롤러' 만들기. 안전 정지(trip)가 무엇을 판단하는지부터 재현한다.

# PoC 1: 가상 SIS 컨트롤러 — 안전 트립이 '왜' 걸리는지 이해하는 모의 코드
# 실제 Triconex/TriStation과 무관한 순수 교육용 시뮬레이터. 로컬 출력만 한다.
TRIP_LIMIT   = 100.0   # 위험 임계치 (상징값)
TRIP_ENABLED = True    # 안전 로직 사용 여부 (정상 상태)

def sis_vote(readings):
    """TMR(3중 채널) 투표를 흉내: 다수결로 위험 여부를 결정한다."""
    over = sum(1 for r in readings if r > TRIP_LIMIT)
    return over >= 2   # 3채널 중 2채널 이상이 임계 초과 → 위험

def safety_scan(readings):
    global TRIP_ENABLED
    risk = sis_vote(readings)
    if not TRIP_ENABLED:
        return "[!] 안전 정지 기능이 비활성 상태 → 위험 신호를 무시한다 (이것이 공격의 목표)"
    return "TRIP: 공정 안전 정지" if risk else "정상 운전"

if __name__ == "__main__":
    print("[정상]", safety_scan([80.0, 82.0, 79.0]))
    print("[위험]", safety_scan([130.0, 128.0, 131.0]))

PoC 2 — 엔지니어링 프레임의 구조 이해. 실제 프로토콜 대신 가상 명령 코드로 요청/응답을 표현해, EWS가 컨트롤러에게 보내는 대화의 뼈대를 본다.

# PoC 2: 엔지니어링 요청 프레임의 '구조'만 재현 (가상 opcode — 실제 값과 다름)
# 실제 익스플로잇 바이트/실제 TriStation 명령 정수는 포함하지 않는다.
FICTIONAL_OPCODES = {
    0x01: "READ_STATUS",      # 컨트롤러 상태 조회
    0x02: "READ_MEMORY",      # 메모리 읽기
    0x03: "WRITE_MEMORY",     # 메모리 쓰기  ← 공격이 악용하는 지점
    0x04: "GET_KEYSWITCH",    # 물리 키스위치 상태
}

def build_request(op, payload=b""):
    """가상 EWS→SIS 요청 프레임. op + 길이 + 페이로드 구조만 보여준다."""
    if op not in FICTIONAL_OPCODES:
        raise ValueError("unknown op")
    frame = {"op": FICTIONAL_OPCODES[op], "len": len(payload), "data": payload}
    print(f"[EWS → SIS] {frame}")
    return frame

def controller_side(frame, keyswitch_program=False):
    """모의 컨트롤러: 쓰기 요청은 물리 키스위치가 PROGRAM일 때만 수용한다."""
    if frame["op"] == "WRITE_MEMORY" and not keyswitch_program:
        print("[SIS] 쓰기 거부: 키스위치가 PROGRAM 위치가 아님 (물리적 안전장치)")
        return False
    print("[SIS] 요청 수용")
    return True

if __name__ == "__main__":
    f = build_request(0x03, b"<mock-payload>")
    controller_side(f, keyswitch_program=False)   # 기본은 거부 → 정상
    controller_side(f, keyswitch_program=True)    # 키스위치 방치 시 수용됨

PoC 3 — '트립 무력화'를 모의 랩에서 재현. PoC 1의 가상 컨트롤러에 PoC 2의 쓰기 요청을 연결해, 안전 로직이 꺼지는 과정을 눈으로 확인한다. 실제 컨트롤러 메모리 주소·페이로드는 일절 쓰지 않는다.

# PoC 3: 두 모의 컴포넌트를 연결 — '안전 트립 무력화'가 무엇을 바꾸는지 확인
# 대상은 오직 로컬에서 실행하는 모의 컨트롤러 객체다.
import importlib.util, sys

# (교육용) PoC 1의 모듈을 sis.py 로 저장해 두었다고 가정
spec = importlib.util.spec_from_file_location("sis", "/tmp/lab/sis.py")
sis = importlib.util.module_from_spec(spec); spec.loader.exec_module(sis)

def inject_disable_trip(target_module, authorized_keyswitch):
    """'안전 정지 비활성화'라는 효과만 재현한다(실제 인젝션 아님)."""
    if not authorized_keyswitch:
        print("[!] 키스위치가 PROGRAM 아님 → 주입 실패 (방어 성공 시나리오)")
        return False
    target_module.TRIP_ENABLED = False
    print("[!] 모의 컨트롤러의 안전 정지 기능이 꺼졌다 → 이후 위험 신호를 무시한다")
    return True

if __name__ == "__main__":
    print("[위험 상태 진입]", sis.safety_scan([140.0, 139.0, 141.0]))
    inject_disable_trip(sis, authorized_keyswitch=False)   # 1) 방어되는 경우
    inject_disable_trip(sis, authorized_keyswitch=True)    # 2) 키스위치 방치 → 성공
    print("[같은 위험 상태]", sis.safety_scan([140.0, 139.0, 141.0]))  # 정지되지 않음

PoC 4 — 방어/탐지 연습. 이제 공격자 관점이 아니라 방어자 관점으로 넘어간다. 정상 엔지니어링 세션 프로파일에서 벗어난 쓰기 시도를 잡아내는 모의 탐지기와, 물리 키스위치 통제를 코드로 점검한다.

# PoC 4: 모의 탐지 로직 — '비정상 엔지니어링 쓰기'를 잡아낸다
NORMAL_WINDOW = ("09:00", "18:00")      # 정상 엔지니어링 작업 시간
ALLOWED_OPS   = {"READ_STATUS", "READ_MEMORY", "GET_KEYSWITCH"}

def is_anomalous(session):
    """session = {time, host, src_ip, op, keyswitch_program, ticket_id}"""
    if session["op"] == "WRITE_MEMORY" and not session["ticket_id"]:
        return "작업 티켓 없는 메모리 쓰기 (변경관리 위반)"
    if not (NORMAL_WINDOW[0] <= session["time"] <= NORMAL_WINDOW[1]):
        return "업무시간 외 엔지니어링 세션"
    if session["keyswitch_program"] and session["op"] == "WRITE_MEMORY":
        return "가장(PROGRAM) 상태에서의 쓰기 — 물리 통제 로그와 대조 필요"
    return None

def check_keyswitch_policy(policy):
    """물리 키 관리 정책의 가장 흔한 실패를 코드로 점검한다."""
    bad = [k for k, v in policy.items() if v == "left_in_program"]
    return ("[FAIL] PROGRAM 위치로 방치된 키: " + ", ".join(bad)) if bad \
           else "[OK] 모든 키가 통제된 위치에 있다"

if __name__ == "__main__":
    s1 = {"time": "23:40", "host": "EWS-01", "src_ip": "10.10.4.7",
          "op": "WRITE_MEMORY", "keyswitch_program": True, "ticket_id": None}
    print("탐지:", is_anomalous(s1))
    print(check_keyswitch_policy({"SIS-1": "run", "SIS-2": "left_in_program"}))
    print(check_keyswitch_policy({"SIS-1": "run", "SIS-2": "run"}))

마지막으로, 이런 코드를 실행하지 않고 네트워크에서 이상 징후를 보는 규칙 아이디어(개념 예시)를 정리해 둔다. 실제 배포 전에는 반드시 자기 현장 트래픽으로 오탐을 조정해야 한다.

# 개념 예시(모의): '정상 프로파일 밖' 엔지니어링 트래픽 알림 규칙 스케치
# 실제 시그니처 정수/바이트는 의도적으로 넣지 않는다 — 자기 망 트래픽으로 조정할 것.
rule:
  name: sis_engineering_out_of_profile
  if:
    - proto: udp
    - dst_port_in: [1502]           # 엔지니어링 프로토콜 포트(개념)
    - src_not_in: [ENG_WORKSTATIONS] # 승인된 EWS 목록 밖에서 온 요청
    - op_in: [WRITE_MEMORY, PROGRAM_DOWNLOAD]
  then:
    - alert: "비승인 호스트의 SIS 쓰기 시도 — 즉시 물리적 확인 + 세션 격리"
    - log_fields: [ts, src_ip, op, keyswitch_state, ticket_id]

6. 방어 방법/교훈 — '마지막 안전장치'를 어떻게 지킬 것인가

• IT/OT 분리와 '다리' 통제 — 에어갭은 선언이 아니라 운영이다. IT↔OT 사이의 모든 연결(원격 유지보수, 모니터링, VPN, USB)을 목록화하고, 최소 권한·MFA·세션 기록을 적용한다. '편의를 위한 상시 개방'이 가장 큰 구멍이다.
• 엔지니어링 워크스테이션 하드닝 — EWS는 곧 SIS의 관리자 권한이다. 전용 장비로 격리하고, 불필요한 소프트웨어·인터넷·이동식 매체를 차단하며, 응용 프로그램 허용목록(allowlisting)으로 정품 엔지니어링 툴 외 실행을 막는다.
• 물리 키스위치 = 보안 통제 — 키는 '관리 항목'이 아니라 '보안 장치'다. 사용 후 즉시 통제 위치로 복귀, 사용 로그 기록, 다중 승인 절차를 둔다. TRITON 사고의 성립 조건이 바로 이 지점이었다.
• 프로토콜 화이트리스트와 행위 모니터링 — 엔지니어링 프로토콜 트래픽은 '정상 관리 트래픽'이라 시그니처로 잡히지 않는다. 대신 누가, 언제, 어디서, 어떤 명령을 보내는지 프로파일링하고, 승인된 EWS·작업 티켓·업무시간을 벗어난 쓰기를 알림으로 잡는다(변경관리와 보안 모니터링의 융합).
• SIS 변경 감사 — 컨트롤러 프로그램·펌웨어·키스위치 상태의 기준값(baseline)을 주기적으로 캡처하고, 오프라인 대조로 무단 변경을 탐지한다. 안전 로직의 무결성은 곧 인명 안전이다.
• 기능 안전과 보안의 통합 설계 — '제어가 안전하게 실패한다(fail-safe)'는 원칙과 '어떤 명령도 신뢰하지 않는다(zero trust)'는 원칙을 같은 아키텍처에서 설계한다. 표준(IEC 62443 등)과 벤더 권고를 주기적으로 반영한다.
• 가정 점검표(체크리스트) — ① SIS에 도달하는 모든 경로를 아는가 ② EWS에서 정품 툴 외 실행을 막았는가 ③ 물리 키는 통제되는가 ④ 엔지니어링 트래픽을 프로파일링하는가 ⑤ 안전 로직 변경을 감사하는가. 다섯 질문에 모두 '예'라고 답하지 못하면, 그것이 오늘의 우선순위다.

교훈 한 줄. 안전 시스템을 디지털로 연결하는 순간, 그 안전 시스템도 공격면이 된다. 마지막 방어선을 지키는 일은 방화벽 한 대가 아니라, 물리 통제 · 변경관리 · 트래픽 프로파일링 · 표준 준수가 겹쳐진 다층 구조로만 가능하다. 그리고 이 사건을 세상에 알린 것은 완벽한 방어가 아니라 공격의 '실수'였다는 사실을, 우리는 불편하게 기억해야 한다.

출처

• CISA — MAR-17-352-01 HatMan — Safety Instrumented System Attack (TRITON 공식 악성코드 분석보고서) — cisa.gov/news-events/analysis-reports/ar18-352a
• Mandiant (FireEye) — Attackers Deploy New ICS Attack Framework "TRITON" (최초 공개 분석) — mandiant.com/resources/blog/attackers-deploy-new-ics-attack-framework-triton
• MITRE ATT&CK — Triton (Software S1009) · Impair Process Control (T0836) — attack.mitre.org/software/S1009 · attack.mitre.org/techniques/T0836
• Dragos — Xenotime (위협 그룹 프로필 · TRISIS 명명) — dragos.com/threat/xenotime
• U.S. Department of the Treasury (OFAC) — 제재 지정 (2020-10-23, CNIIHM) — treasury.gov — OFAC Enforcement 2020-10-23
• NVD — CVE-2021-22742 등 Triconex 컨트롤러 '비정상 조건 검사 미흡(CWE-754)' 취약점 (사후 강화 사례) — nvd.nist.gov/vuln/detail/CVE-2021-22742
• Wikipedia — Triton (malware) (타임라인·귀속·영향 정리) — en.wikipedia.org/wiki/Triton_(malware)
• Wikipedia — Triconex (TMR 구조·SIS 개념) — en.wikipedia.org/wiki/Triconex

※ 본문의 PoC 코드는 구조 이해 목적의 교육용 모의 코드이며, 실제 TriStation 명령 정수·컨트롤러 페이로드·익스플로잇은 포함하지 않습니다. 모든 실습은 인터넷과 분리된 격리 랩(가상 디렉터리 /tmp/lab)에서 '직접 만든 모의 컨트롤러'를 대상으로만 수행해야 하며, 실제 설비나 타인의 산업 시스템을 대상으로 한 실행은 불법입니다.

함께 읽기: ⚛️ Stuxnet (2010) — 원심분리기를 파괴한 세계 최초의 사이버 무기 · ⚡ Industroyer / CrashOverride — 전력망 프로토콜을 그대로 말한 악성코드 · 🔥 Flame (2012) — MD5 충돌로 MS 인증서를 위조한 스파이 플랫폼 · 🦅 SolarWinds SUNBURST (2020) — 빌드 파이프라인을 감염시켜 신뢰를 무기로 삼은 사건 · ☠️ NotPetya (2017) — 같은 해 '공급망에서 시작해 세계를 멈춘' 파괴형 와이퍼