단 3분! Genox Cybersecurity AI가 하는 일을 6단계로 보기 → 24시간 침해사고 신고
Verdict trace

판정 기록(트레이스)
읽는 법

Threat Correlator는 판정 하나마다 무엇을 보고, 어떤 도구를 부르고, 어떤 근거로 결론을 냈는지 기록으로 남깁니다.
아직 공개할 실제 실행 기록이 없어서, 이 페이지에서는 기록의 구조를 설명하고 예시 한 건을 처음부터 끝까지 읽어 봅니다.

예시 기록 보기AI 판정 품질 측정
Structure

기록 한 건에 들어가는 것

위에서 아래로 읽으면 판정이 만들어진 순서와 같습니다.
단계(step)는 판정 하나에 여러 개가 붙고, 단계마다 관찰, 도구 호출, 증거, 추론이 한 묶음입니다.

필드담는 내용읽을 때 확인할 점
input_hash판정에 들어간 입력 묶음 전체의 SHA-256재실행 때 같은 입력을 썼는지 이 값으로 맞춰 봅니다
sources입력이 온 곳(EDR, 메일 게이트웨이, 프록시 등)과 시간 범위빠진 소스가 있으면 판정 범위도 그만큼 좁습니다
steps[].observation그 단계에서 눈여겨본 사실원본 로그를 요약한 문장이라 아래 증거와 맞는지 봅니다
steps[].tool_call호출한 도구, 인자, 결과 요약시간 범위나 호스트명 같은 인자가 맞는지 봅니다
steps[].evidence증거 ID, 원본 위치, 해시인용한 로그가 원본에 실제로 있는지 자동 대조한 결과도 붙습니다
steps[].reasoning증거에서 결론으로 넘어간 이유, ATT&CK 기법 ID근거 문장마다 증거 ID를 가리켜야 합니다
verdict · confidence판정 라벨, 위험도, 신뢰도와 신뢰도를 깎은 이유신뢰도가 낮은 이유가 적혀 있는지 봅니다
recommended_actions권고 조치와 승인 필요 여부호스트 격리, 계정 잠금은 항상 승인 대상입니다
approval승인자 역할 ID, 승인·수정·거절, 시각, 코멘트승인까지 걸린 시간도 여기서 나옵니다
versions모델 버전, 프롬프트 템플릿 버전, 정책 버전프롬프트 문구만 바뀌어도 판정 기준이 바뀐 것입니다
replay나중에 같은 조건으로 다시 돌린 결과와 원래 판정의 차이문장은 달라도 됩니다. 라벨과 위험도가 같은지 봅니다
Example trace

예시 기록 한 건을 처음부터 읽어 봅니다

예시 기록 · 실제 고객 데이터나 실행 기록이 아닙니다. MITRE ATT&CK에 정리된 랜섬웨어 초기 단계 기법(피싱 첨부파일, PowerShell 실행, 섀도 복사본 삭제)을 이어 붙여 저희가 만든 기록입니다. 호스트 이름, 계정, 시각, 신뢰도는 모두 설명용이고, 도메인과 IP는 문서용으로 예약된 값(.example, 203.0.113.0/24)을 썼습니다.

예시 기록 · 실제 고객 데이터나 실행 기록이 아닙니다fin-ws-0412
1 관찰매크로 포함 첨부 메일 수신 · T1566.00109:12
2 관찰WINWORD.EXE가 powershell.exe 실행 · T1059.00109:14
3 관찰vssadmin으로 섀도 복사본 삭제 · T149009:14
판정정탐 · 랜섬웨어 실행 준비 · CRITICAL · 신뢰도 0.9109:15
승인호스트 격리 승인 (analyst-07)09:17
재실행라벨 · 위험도 일치, 문장 일부 다름10/22

이 기록에서 먼저 볼 곳

판정 줄의 신뢰도가 0.91에서 멈춘 이유부터 봅니다. 이 예시에서는 파일 암호화가 아직 관찰되지 않았고, 내려받은 실행 파일의 해시가 위협 인텔에서 일치하지 않았다는 점이 적혀 있습니다. 반대로 신뢰도만 높고 깎은 이유가 비어 있는 기록이라면 그쪽을 더 의심해야 합니다.

그다음은 승인 줄입니다. 호스트 격리는 정책상 자동으로 실행되지 않습니다. 판정이 나온 뒤 분석가가 근거를 읽고 승인하기까지 2분 남짓 걸렸다는 것도 이 기록에서 읽을 수 있습니다.

단계별로 읽기

  1. 메일 수신 (step 1). 메일 게이트웨이 로그에 billing@invoice-notice.example에서 온 메일이 있고, 첨부는 견적서_1021.docm입니다. AI는 mail.search(message_id=…)로 메일 원본 메타데이터를, intel.domain_whois("invoice-notice.example")로 도메인 정보를 조회했습니다. 결과는 도메인 생성 3일 차. 근거 문장은 "매크로 포함 Office 첨부와 신규 도메인 조합, T1566.001 가능성"이고 증거 E1, E2를 가리킵니다. 이 단계만으로는 판정을 내지 않았습니다.
  2. PowerShell 실행 (step 2). Sysmon 이벤트 ID 1(프로세스 생성)에 부모가 WINWORD.EXE, 자식이 powershell.exe -NoP -W Hidden -enc JABjAD0A…인 줄이 있습니다. AI는 edr.process_tree(host="fin-ws-0412", from="09:12", to="09:20")로 프로세스 트리를 받고, 인코딩된 명령을 디코딩해 https://203.0.113.45/u.ps1을 내려받는 코드임을 확인했습니다. baseline.parent_child(host, 30d) 조회에서 이 호스트는 지난 30일 동안 Office 앱이 PowerShell을 띄운 적이 없었습니다. 근거는 T1059.001, 증거는 E3, E4입니다.
  3. 섀도 복사본 삭제 (step 3). Sysmon 이벤트 ID 11(파일 생성)로 C:\Users\user01\AppData\Local\Temp\upd.exe가 생기고, 20초 남짓 뒤 이벤트 ID 1에 vssadmin.exe delete shadows /all /quiet가 찍혔습니다. 부모는 upd.exe입니다. intel.hash_lookup은 일치 없음으로 돌아왔습니다. 근거는 T1490(시스템 복구 방해)이고, ATT&CK의 T1490 항목에도 암호화 전에 섀도 복사본부터 지운 랜섬웨어 사례가 여럿 올라 있습니다.
  4. 판정. 정탐, 랜섬웨어 실행 준비 단계, 위험도 CRITICAL, 신뢰도 0.91. 신뢰도를 깎은 이유로 "대량 파일 변경 미관찰", "upd.exe 해시 인텔 불일치" 두 가지가 적혀 있습니다.
  5. 권고 조치와 승인. 호스트 네트워크 격리(승인 필요), 같은 첨부 해시를 가진 메일 회수, 발신 도메인과 203.0.113.45 차단. 격리는 analyst-07이 09:17에 승인했고, 코멘트로 "파일서버 SMB 세션 확인 요청"을 남겼습니다. 차단 두 건은 고객과 합의한 자동 대응 정책 범위 안이라 승인 없이 실행됐습니다.
  6. 재실행. 다음 날 같은 input_hash, 모델 버전, 정책 버전으로 다시 돌린 결과 라벨과 위험도는 같았고 신뢰도는 0.89, 근거 문장의 표현은 일부 달랐습니다. 문장은 비교 대상이 아니므로 "일치"로 기록됩니다.
Raw record

같은 기록을 원문 형태로 보면

위 예시를 기록 형식 그대로 줄여 옮겼습니다.
필드 이름은 설명용이며, 실제 내보내기 형식은 출시 때 문서로 공개합니다.

// 예시 기록 · 실제 고객 데이터나 실행 기록이 아닙니다
{
  "trace_id": "VT-EXAMPLE-0001",
  "input_hash": "sha256:9f3a…c21e",
  "sources": [
    {"type": "mail_gateway", "range": "09:00~09:20"},
    {"type": "edr_sysmon",   "host": "fin-ws-0412", "range": "09:00~09:20"}
  ],
  "steps": [
    {"n": 1,
     "observation": "매크로 포함 첨부(견적서_1021.docm), 발신 도메인 생성 3일 차",
     "tool_calls": ["mail.search(message_id=…)", "intel.domain_whois(\"invoice-notice.example\")"],
     "evidence": [{"id": "E1", "ref": "mailgw/2026/10/21/09.log#L2207", "sha256": "1c0d…7be2", "verified": true},
                  {"id": "E2", "ref": "intel/whois/invoice-notice.example", "verified": true}],
     "reasoning": "E1+E2: 스피어피싱 첨부 가능성", "attack": ["T1566.001"]},
    {"n": 2,
     "observation": "WINWORD.EXE → powershell.exe -NoP -W Hidden -enc …",
     "tool_calls": ["edr.process_tree(host=\"fin-ws-0412\", from=\"09:12\", to=\"09:20\")",
                    "baseline.parent_child(host=\"fin-ws-0412\", window=\"30d\")"],
     "evidence": [{"id": "E3", "ref": "sysmon:EventID=1 RecordID=884213", "verified": true},
                  {"id": "E4", "ref": "baseline/fin-ws-0412/parent_child", "verified": true}],
     "reasoning": "E3: Office 앱이 인코딩된 PowerShell 실행, E4: 30일간 전례 없음",
     "attack": ["T1059.001"]},
    {"n": 3,
     "observation": "upd.exe 생성 후 vssadmin.exe delete shadows /all /quiet",
     "tool_calls": ["edr.process_tree(…)", "intel.hash_lookup(\"sha256:3b7e…a19f\")"],
     "evidence": [{"id": "E5", "ref": "sysmon:EventID=11 RecordID=884240", "verified": true},
                  {"id": "E6", "ref": "sysmon:EventID=1 RecordID=884251", "verified": true}],
     "reasoning": "E6: 복구 수단 삭제, 암호화 전 단계로 판단", "attack": ["T1490"]}
  ],
  "verdict": {"label": "true_positive", "severity": "critical",
              "summary": "랜섬웨어 실행 준비 단계",
              "confidence": 0.91,
              "confidence_notes": ["대량 파일 변경 미관찰", "upd.exe 해시 인텔 불일치"]},
  "recommended_actions": [
    {"action": "isolate_host", "target": "fin-ws-0412", "requires_approval": true},
    {"action": "recall_mail", "match": "attachment_sha256", "requires_approval": false},
    {"action": "block", "targets": ["invoice-notice.example", "203.0.113.45"], "requires_approval": false}
  ],
  "approval": {"action": "isolate_host", "by": "analyst-07", "decision": "approved",
               "at": "2026-10-21T09:17:40+09:00", "comment": "파일서버 SMB 세션 확인 요청"},
  "versions": {"model": "correlator-model-x.y", "prompt_template": "triage-vNN", "policy": "auto-response-YYYY.MM"},
  "replay": {"at": "2026-10-22T10:05:12+09:00", "same_input_hash": true,
             "label_match": true, "severity_match": true, "confidence": 0.89,
             "text_diff": "근거 문장 표현 일부 다름"}
}

verified는 인용한 로그가 원본 저장소에 실제로 있는지 자동 대조한 결과입니다. 하나라도 false면 판정은 보류되고 분석가에게 넘어갑니다. 이 대조를 어떻게 세는지는 AI 판정 품질 페이지의 출력 날조 탐지 항목에 적어 두었습니다.

How to use it

기록을 받은 쪽에서 하는 일

판정 기록은 Genox만 보는 내부 로그로 끝나지 않습니다.
고객 보안팀과 감사인이 직접 열어 보는 것을 전제로 만듭니다.

감사 대응

감사나 사고 조사에서 "왜 이 호스트를 격리했나"라는 질문을 받으면 기록 한 건으로 답합니다. 무엇을 봤는지는 evidence에, 누가 승인했는지는 approval에, 그때 어떤 모델과 정책이 돌았는지는 versions에 있습니다. 증거는 위치와 해시로 남기므로 원본 로그 보존 기간을 판정 기록 보존 기간과 맞춰 두셔야 합니다.

오탐 분석

오탐으로 확정된 판정은 어느 단계에서 어긋났는지 찾아봅니다. 도구 호출 인자가 틀렸는지, 기준선 조회가 비어 있었는지, 추론이 증거를 넘어섰는지는 step을 하나씩 따라가면 보통 드러납니다. 저희가 월간 리포트에 오탐 사례를 실을 때도 이 기록을 그대로 붙입니다.

규칙 개선

같은 이유로 신뢰도가 깎인 판정이 반복되면 수집 범위나 탐지 규칙을 손볼 곳이 보입니다. 위 예시라면 파일서버 감사 로그가 sources에 없어서 측면 이동 여부를 확인하지 못했습니다. 정책을 고친 뒤에는 지난 판정을 새 정책 버전으로 다시 돌려 차이를 확인합니다.

What's next

실제 기록은
준비되는 대로 공개합니다

Research Lab 격리 환경에서 공개된 공격 기법을 재현하고 Threat Correlator가 판정한 기록을 정리하고 있습니다. 고객 데이터가 섞이지 않는 실행 기록이 쌓이면 이 페이지에 원문 그대로 올립니다. 그 전까지 이 페이지의 기록은 모두 예시입니다.

공개할 때 지킬 것

  • 판정이 틀린 기록도 맞은 기록과 같이 올립니다
  • 재현에 쓴 기법 ID와 재현 절차를 함께 적습니다
  • 기록마다 모델·정책 버전을 남기고, 버전이 바뀌면 다시 돌린 결과를 덧붙입니다
  • 격리 환경의 호스트명과 계정은 실제 고객 환경과 겹치지 않게 만듭니다
Related

같이 보면 좋은 페이지

AI 판정 품질을 어떻게 재는가

판정 기록을 바탕으로 정확도, 오탐·미탐, 근거 누락, 재실행 일치도를 재는 방법입니다.

측정 방법 보기

Threat Correlator

경보를 사건 단위로 묶고 증거, 근거, 판정, 권고 조치, 신뢰도를 기록하는 엔진입니다.

Threat Correlator

플랫폼

Vulnerability Scanner, Behavioral Analyzer, Threat Correlator, Research Lab이 어떻게 이어지는지 봅니다.

플랫폼 보기

참고 자료

도입이나 보안 문제로
상의할 일이 있다면

상담 신청 이메일 문의 admin@genox.one 24시간 침해사고 신고
상담 신청하기