Crow-Eye — Windows 포렌식 엔진

Windows를 위한 포렌식 타임머신.
Crow-Eye는 단지 탐지만 하지 않습니다 — 타임라인에서 실제로 무슨 일이 일어났는지를 재구성하며, 수집부터 출처 기록까지 추적 가능한 판정에 이르기까지 전 과정을 다룹니다.

목차

• 개요
• ✨ 주요 기능
• 👥 Crow-Eye가 필요한 사용자
• 🧭 하위 시스템 한눈에 보기
• 🏗️ 아키텍처
• 📥 다운로드 및 설치
• 🚀 빠른 시작
• 📂 지원 아티팩트
• 🔧 분석 모드
  • 📎 증거 가져오기(타사 데이터)
• 🧠 사용자 행동 분석(UBA)
• 🧩 상관관계 엔진
• 👁️ Eye — 포렌식 AI 어시스턴트
• 📖 Eye-Describe — 바이트 수준 아티팩트 지식 베이스
• 🧪 품질 및 검증
• 🔬 연구 플랫폼
• 🛠️ 기술 참고 사항
• 📸 스크린샷
• 🚧 로드맵
• 📚 문서
• 🤝 기여하기
• 🌐 웹사이트 및 커뮤니티
• 📄 라이선스
• 📝 Crow-Eye 인용
• 💖 지원
• 크레딧

개요

Crow-Eye는 수집, 분석, 검증, 인텔리전스, AI를 하나로 통합하는 오픈소스(GPL-3.0) Windows 포렌식 엔진입니다. 대부분의 보안 도구는 *"이게 나쁜가?"*라고 묻고 정상으로 보이는 것은 모두 무시합니다. Crow-Eye는 다른 질문을 던집니다: "무슨 일이 있었나?" — 의심스러운 활동이든 아니든 모든 활동을 상호 연관시켜 시스템에서 실제 발생한 사건들의 정확한 순서를 재구성하므로, 조사의 진실은 알림에서 추측되는 것이 아니라 증거로부터 재구성됩니다.

이러한 재구성 우선 설계는 APT 및 국가 주도 위협을 사냥하는 데 정확히 필요한 것입니다: 정교한 공격자는 합법적인 도구(powershell.exe, PsExec, certutil)와 행동의 순서 속에 숨어 있으며, 정상으로 보이는 것을 무시하는 도구에는 보이지 않습니다. Crow-Eye는 어떤 것도 무시하지 않고 로그 변조와 안티포렌식에서도 살아남는 실행 아티팩트를 기반으로 추론하기 때문에 공격은 숨을 수 없습니다. 동일한 엔진은 일상적인 DFIR 작업과 컴퓨터에서 무슨 일이 있었는지 알고 싶은 비전문가에게도 쉽게 접근할 수 있도록 유지됩니다.

• 🕰️ 탐지만 하지 말고 재구성하라 — 실제로 발생한 일의 타임라인을 다시 만듭니다.
• 🖥️ 크로스 플랫폼 — Windows에서 완전한 라이브 + 오프라인 분석; Linux에서 오프라인 분석 및 포렌식 이미지 파싱(라이브 파서는 Windows 전용).
• 🔒 설계상 프라이버시 — 데이터가 기기 밖으로 나가는 시간 0ms; Eye AI 어시스턴트는 완전히 에어갭 환경에서 실행할 수 있습니다.
• 🧾 법정 적격 — 증거는 암호화로 봉인되며 모든 단계를 감사할 수 있습니다.
• 📦 현재 버전: 0.12.6 · 상관관계 엔진: 1.7.0 · 라이선스: GPL-3.0.

✨ 주요 기능

• 탐지보다 재구성. 모든 아티팩트를 알림 더미가 아닌 탐색 가능한 엔터티별 스토리 하나로 상호 연관시킵니다.
• 처음부터 끝까지 통합 — 수집 → 상관관계 → 타임라인 → 행동 분석 → AI → 봉인된 사건 메모리: 기존 단일 도구가 포괄하지 못하는 완전한 파이프라인.
• 로그 수준이 아닌, 아티팩트 심층. Prefetch, Amcache, ShimCache, SRUM, MFT, USN, LNK/점프 목록 등은 로그 전용 도구를 무력화하는 로그 삭제 및 "living-off-the-land" 속임수에서도 살아남습니다.
• Eye AI 어시스턴트 — 감사 가능하고 변조 증거가 남는 증거물 관리 체인을 갖춘 자연어 포렌식 조사. 클라우드, 사설 서버, 또는 완전 오프라인에서 실행 가능.
• 사용자 행동 분석(UBA) — 원시 아티팩트를 평문으로 된, HR/검사관이 읽을 수 있는 활동 스토리로 변환.
• 무료 및 오픈소스(GPL-3.0) — 누구나 감사할 수 있으며, 활발한 연구 및 문서화 노력이 진행 중입니다.

👥 Crow-Eye가 필요한 사용자

Crow-Eye는 매우 다양한 작업 흐름에서 사용됩니다. 각 사용자는 다른 문을 통해 엔진에 들어옵니다:

어떤 수집 도구든 작동합니다. Crow-Eye는 자체 수집 도구를 요구하지 않습니다. 오프라인 가져오기를 Velociraptor, KAPE, EDR 수집 패키지 또는 기타 수집 도구가 생성한 원시 아티팩트 폴더에 지정하면 지원되는 아티팩트를 인덱싱하고 해당 폴더에서 오프라인 파서를 실행합니다. 별도로 Plaso, Autopsy, Volatility 또는 다른 도구의 출력물은 증거 가져오기를 통해 CSV, JSON 또는 SQLite로 가져와 기본 아티팩트와 함께 상호 연관시킬 수 있습니다.

🧭 하위 시스템 한눈에 보기

Crow-Eye는 통합 루프로 구축되었습니다 — 각 단계는 다음 단계로 이어지며, 원시 디스크에서 방어 가능한 판정까지 연결됩니다.

🏗️ 아키텍처

Crow-Eye는 파서 묶음이 아닌 통합 파이프라인입니다. 증거는 한 방향으로 흐르며, 모든 단계는 소스 레코드에 대한 연결을 유지합니다.```mermaid %%{init: {"flowchart": {"nodeSpacing": 60, "rankSpacing": 70, "curve": "basis"}, "themeVariables": {"fontSize": "17px", "fontFamily": "system-ui, sans-serif"}} }%% flowchart TB

%% ═══════════ 1. EVIDENCE SOURCE ═══════════ S1["Live Windows system"] S2["Forensic image
E01 · VHDX · VMDK · Raw"] S3["Collected artifacts
Velociraptor · KAPE · EDR"] S4["Third-party output
Plaso · Autopsy · Volatility"]

%% ═══════════ 2. INGEST ═══════════ I1["CROW-CLAW
live acquisition"] I2["IMAGE PARSING
direct, no mounting"] I3["OFFLINE IMPORTER
SCAN → COLLECT → PARSE"] I4["IMPORT EVIDENCE
CSV · JSON · SQLite"]

PARSERS["ARTIFACT PARSERS<br/>18 artifact types · live and offline"]

%% ═══════════ 3. CASE ═══════════ CASE[("CASE DATABASES
Target_Artifacts/
Imported_Evidence/")]

%% ═══════════ 4. ANALYSIS ═══════════ TL["INTERACTIVE TIMELINE
heat map · week · day"] UB["USER BEHAVIOR ANALYTICS
40 detections · plain-English story"] CE["CORRELATION ENGINE
Feathers → Wings → Engines → Pipelines"] RES[("Correlation results")] DL["DYNAMIC LINKING
non-destructive enrichment overlay"] INTEL[("Crow_Intelligence.db
SID · MAC · hash · GUID → name")]

%% ═══════════ 5. AI LAYER ═══════════ EYE["EYE
GEP-governed AI assistant"] NM["NARRATIVE MAP
hash-chained case memory"] COMP["COMPLIANCE
live GEP status · EvidenceSeal audit"]

OUT["LIVING REPORT<br/>CSV · JSON · HTML"]

%% ═══════════ FLOW ═══════════ S1 --> I1 S2 --> I2 S3 --> I3 S4 --> I4

I1 --> PARSERS
I2 --> PARSERS
I3 --> PARSERS

PARSERS -- "parsed artifacts" --> CASE
I4 -- "verbatim copy or<br/>converted to feather" --> CASE

CASE -- "read-only" --> TL
CASE -- "read-only" --> UB
CASE -- "read-only" --> CE
CASE -- "read-only" --> DL
CE --> RES
DL --> INTEL

CASE -- "read-only queries" --> EYE
RES -. "queried on demand" .-> EYE
EYE <== "verdict · narrative · evidence" ==> NM

EYE -- "audited by" --> COMP

EYE -- "report_* tools" --> OUT

%% ═══════════ STYLE ═══════════ classDef src fill:#334155,stroke:#94a3b8,stroke-width:2px,color:#f1f5f9 classDef ing fill:#0f766e,stroke:#2dd4bf,stroke-width:2px,color:#f0fdfa classDef store fill:#92400e,stroke:#fbbf24,stroke-width:3px,color:#fffbeb classDef ana fill:#1e40af,stroke:#60a5fa,stroke-width:2px,color:#eff6ff classDef ai fill:#6b21a8,stroke:#c084fc,stroke-width:2px,color:#faf5ff classDef out fill:#166534,stroke:#4ade80,stroke-width:2px,color:#f0fdf4

class S1,S2,S3,S4 src
class I1,I2,I3,I4,PARSERS ing
class CASE,RES,INTEL store
class TL,UB,CE,DL ana
class EYE,NM,COMP ai
class OUT out

linkStyle default stroke-width:2px

*증거 소스 → 수집 → 사례 데이터베이스 → 분석 → AI 계층 → 보고서*


**읽는 방법:**

| 단계 | 중요 사항 |
|---|---|
| ① → ② | **사례에 들어가는 네 개의 독립된 통로.** Crow-Eye 자체 수집기가 필요하지 않습니다. Velociraptor, KAPE 또는 EDR 패키지의 폴더는 Offline Importer를 통해 들어가고, 타사 CSV/JSON/SQLite는 Import Evidence를 통해 들어갑니다. |
| ② → ③ | 모든 것이 한곳, 즉 **사례 데이터베이스**로 수렴됩니다. 파싱된 아티팩트는 `Target_Artifacts/`에 들어가고, 가져온 타사 증거는 `Imported_Evidence/`에 들어가 자동으로 탐지됩니다. |
| ③ → ④ | **세 가지 분석 경로는 서로 독립적입니다.** Timeline과 UBA는 사례 데이터베이스를 직접 읽습니다. 둘 다 상관 분석 실행이 필요하지 않습니다. Correlation Engine은 *추가* 계층이지 필수 조건이 아닙니다. |
| ③ → ④ | **Dynamic Linking은 Timeline 및 UBA와 나란히 위치합니다** — 사례 데이터베이스의 네 번째 독립 판독기입니다(Timeline 시각화와는 아무 관련이 없습니다). ID 매핑(SID → 사용자 이름, MAC → 네트워크, 해시/GUID → 앱)을 사례별 `Crow_Intelligence.db`로 수집한 다음, 비파괴적인 `ATTACH` + `LEFT JOIN`을 통해 **아티팩트 데이터 테이블에 인라인으로** 해당 컨텍스트를 오버레이합니다. 레코드가 *읽히는* 방식만 변경하며 증거 자체는 절대 변경하지 않습니다. |
| ④ → ⑤ | Eye는 사례 데이터베이스를 직접 쿼리하고 **요청 시** 상관 분석 결과를 가져올 수 있습니다. 증거 자체에는 절대 접촉하지 않으며, Crow-Eye가 실행하고 기록하는 도구 호출을 생성합니다. |
| ⑤ → 보고서 | **Living Report는 Eye 단독으로** `report_*` 도구를 통해 작성됩니다. Timeline과 UBA는 분석 표면일 뿐이며 보고서에 기록하지 않습니다. 사례 수준의 분석 결과는 [Search & Export](#-search--export)를 통해 별도로 내보낼 수 있습니다. |
| ⑤ ↔ | **Narrative Map은 양방향입니다**: Eye도 쓰고 사용자도 쓰며, 그 내용은 매 턴 Eye의 프롬프트에 주입됩니다. 그것은 기억이며, 사용자가 명령할 수 있습니다. |
| ⑤ ⟳ | **Compliance 페이지는 Eye를 감사합니다.** Eye가 수행하는 모든 도구 호출은 **EvidenceSeal** 해시 체인에 고정됩니다. 페이지는 해당 체인과 `EYE_Logs/`에서 검증된 규칙별 **GEP** 상태(10가지 원칙)를 실시간으로 렌더링하며 `audit_trail.json`으로 내보낼 수 있습니다. |

**독립적인 단계.** Timeline과 UBA는 사례 아티팩트 데이터베이스를 **직접** 읽습니다. 둘 다 상관 분석 실행이 필요하지 않으며, Timeline은 Correlation Engine에 의존하지 않습니다(자체적인 경량 시간 그룹화를 적용합니다). Correlation은 Eye가 결과를 쿼리할 수 있는 추가 분석 계층입니다.

**설계상 읽기 전용.** 파싱은 사례 데이터베이스에 기록합니다. 모든 다운스트림 단계(UBA, Timeline, 상관 분석 뷰어, Eye)는 해당 데이터베이스를 **읽기 전용**으로 엽니다. 원본 증거는 절대 수정되지 않습니다. [Dynamic Linking](#-analysis-modes)은 사례 데이터베이스를 읽어 ID 매핑의 사례별 `Crow_Intelligence.db`를 구축하고, 행을 다시 쓰는 대신 비파괴적인 `ATTACH` + `LEFT JOIN` 쿼리를 통해 아티팩트 데이터 테이블을 인라인으로 보강합니다.

**설계상 통제됨.** Eye가 취하는 모든 행동은 변조 방지 **EvidenceSeal** 해시 체인에 고정되며, **Compliance** 페이지는 [Ghassan Elsman Protocol (GEP)](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md)에 대해 Eye를 지속적으로 검증합니다. 규칙별 실시간 상태를 `EYE_Logs/audit_trail.json`으로 내보낼 수 있습니다.

## 📥 다운로드 및 설치

> **권장:** 공식 웹사이트에서 패키지된 Windows 빌드(**MSI 설치 프로그램 / EXE**)를 받으세요. Python 설정이 필요 없으며 바로 실행됩니다.

### ▶️ [Windows용 Crow-Eye 다운로드 → crow-eye.com/download](https://crow-eye.com/download)

**설치된 MSI/EXE 빌드는 Crow-Eye를 실행하는 권장 방법**이며, 업데이트에서 **최우선 순위**입니다:

- 🛡️ **가장 빠른 수정.** 문제가 발견되거나 버그가 신고되면 **가능한 한 빨리** 업데이트된 EXE를 릴리스합니다. 패키지 빌드에 수정 사항이 가장 먼저 반영됩니다.
- 🔄 **내장 자동 업데이트.** 설치된 앱에서 **설정 → 업데이트**를 열어 **업데이트를 확인하고 자동으로 설치**할 수 있습니다. 수동 재설치가 필요 없습니다.
- 📦 **설정 불필요.** Python, Node 또는 종속성 설치가 필요 없습니다.

> 소스에서 실행하는 것을 선호하시나요? 아래의 **[빠른 시작](#-quick-start)**를 참조하세요. 소스 빌드는 기여자를 위한 것으로 **자동 업데이트 기능을 포함하지 않습니다**. 자동 업데이트를 원한다면 MSI/EXE를 사용하세요.

## 🚀 빠른 시작

### 옵션 A — 설치 빌드(권장)
[crow-eye.com/download](https://crow-eye.com/download)에서 **MSI/EXE**를 다운로드하고 설치한 다음, 관리자 권한으로 **Crow-Eye**를 실행하세요. 사례를 만들고 분석을 시작하세요.

### 옵션 B — 소스에서 실행(개발자)

> 기여자와 고급 사용자를 위한 방법입니다. 이 경로에는 **자동 업데이트 기능이 포함되지 않습니다**. 자동 업데이트를 원한다면 MSI/EXE를 사용하세요.

**요구 사항**(첫 실행 시 자동으로 설치됨):
- Python 3.12.4
- **Node.js 및 npm** — **Timeline Visualization**에 필요
- 주요 패키지: PyQt5, python-registry, pywin32, pandas, streamlit, altair, olefile, windowsprefetch, sqlite3, colorama, setuptools

**권장 하드웨어**

| | 최소 | 대규모 사례 권장 |
|---|---|---|
| **RAM** | 8 GB | 16 GB+ (수백만 개 레코드의 MFT/USN 세트) |
| **디스크** | 5 GB 여유 공간 | 파싱할 증거 크기의 2배 이상 여유 공간 |
| **CPU** | 4코어 | 8코어 이상 |
| **OS** | Windows 10/11(전체) · Linux(오프라인 및 이미지 분석) | — |

> 상관 분석은 매우 큰 데이터 세트에서 일정한 메모리로 스트리밍되므로 RAM이 병목이 되는 경우는 드뭅니다. 일반적으로 디스크 처리량과 여유 공간이 병목입니다.

**실행**(Crow-Eye가 시스템 아티팩트에 접근할 수 있도록 관리자 권한으로 실행):```bash
python "Crow Eye.py"

The main interface opens, you create a case, and all analysis output is organized under that case directory for later review and reporting.

🖥️ 크로스 플랫폼 참고: Linux에서는 라이브 파서가 자동으로 비활성화되고 Crow-Eye는 오프라인 / 포렌식 이미지 모드로 실행됩니다. 전체 라이브 수집은 Windows에서만 가능합니다.

📂 지원 아티팩트

Crow-Eye는 라이브 시스템과 오프라인 소스(수집된 폴더 또는 포렌식 이미지) 모두에서 Windows 실행, 파일 시스템 및 사용자 활동 아티팩트의 광범위한 집합을 파싱합니다.

Jump Lists & LNK는 Crow-Eye 자체의 전용 LNK / Jump List 파서로 파싱됩니다 — 타사 모듈이 아닙니다.

사용자 지정 레지스트리 / 잠긴 파일: Windows는 작동 중에 라이브 레지스트리 하이브(NTUSER.DAT, SOFTWARE, SYSTEM)를 잠급니다. 라이브 시스템을 사용자 지정 분석하려면 외부 미디어(WinPE/Live CD)로 부팅하거나, 포렌식 수집 도구를 사용하거나, 디스크 이미지를 분석하세요.

아티팩트별 세부 정보

• Jump Lists & LNK — Crow-Eye의 전용 파서가 표준 시스템 위치에서 자동으로 파싱합니다 (파일 액세스, 대상 경로, 타임스탬프 및 메타데이터).
• Registry — 시스템 하이브를 자동으로 파싱합니다. 사용자 지정 레지스트리 분석을 위해 하이브 파일을 CrowEye/Artifacts Collectors/Target Artifacts(또는 케이스의 registry/ 폴더)에 복사하세요:
  • NTUSER.DAT from C:\Users\<Username>\NTUSER.DAT
  • SOFTWARE from C:\Windows\System32\config\SOFTWARE
  • SYSTEM from C:\Windows\System32\config\SYSTEM
  • Windows는 작동 중에 이를 잠급니다 — 라이브 시스템의 경우 외부 미디어(WinPE/Live CD)로 부팅하거나, 포렌식 수집 도구를 사용하거나, 디스크 이미지를 분석하세요.
• Prefetch — C:\Windows\Prefetch를 파싱하여 실행 기록 및 포렌식 메타데이터(실행별 타임스탬프 포함)를 추출합니다.
• Event Logs — 시스템/보안/애플리케이션 로그를 데이터베이스로 자동 파싱하여 종합 분석을 수행합니다.
• ShellBags — 폴더 액세스 기록과 사용자 탐색 패턴을 보여줍니다.
• Recycle Bin — $RECYCLE.BIN을 파싱하여 삭제된 파일 이름, 원래 경로, 삭제 시간 및 크기를 복구합니다 (라이브 시스템 및 디스크 이미지).
• MFT — MFT(마스터 파일 테이블)를 파싱하여 파일 메타데이터, 속성, 타임스탬프 및 삭제된 파일 정보를 추출합니다 (NTFS, Windows 7/10/11).
• USN Journal — 타임스탬프와 전체 이름 기록이 포함된 파일 생성/수정/삭제/이름 변경 이벤트를 추적하여 타임라인 재구성에 사용합니다.
• SRUM — 앱 리소스 사용량(포그라운드/백그라운드 시간에 대한 기간 막대) 및 애플리케이션별 네트워크 활동을 시각화합니다.
• Storage Forensics Analyzer — 모든 물리 디스크와 해당 파티션의 전체 트리 뷰; 색상으로 구분된 파티션 유형(EFI, Linux, Recovery, Hidden/swap, …); 부팅 가능한 USB, 숨겨진 Linux 루트, Intel Rapid Start에 대한 경고; 원시 섹터 매직 스캐닝 폴백.

🔧 분석 모드

🦅 Crow-Claw 수집

Crow-Claw는 라이브 시스템 또는 마운트된 이미지에서 아티팩트를 수집하고 보존하기 위한 Crow-Eye의 특화 수집 엔진입니다.

• 선택적 수집 — 특정 아티팩트 범주(레지스트리, 이벤트 로그, 파일 시스템)를 선택하거나 전체를 수집합니다.
• 심층 스캔 — 디렉터리와 하위 디렉터리를 탐색하여 포렌식 흔적을 찾습니다.
• 안전한 보존 — 아티팩트는 포렌식 무결성을 유지하는 구조화된 케이스 디렉터리에 저장됩니다.

🔍 오프라인 분석 (Offline Importer)

대상에 대한 라이브 연결 없이 모든 소스에서 수집된 아티팩트를 분석합니다 — 세 가지 명확한 작업:

• SCAN (검색) — 소스를 탐색하여 지원되는 모든 아티팩트를 파일 이름 및 확장자 패턴으로 인덱싱합니다 (빠르고 읽기 전용; 이 단계에서는 파일 내용을 읽지 않으며 매직 바이트 검사도 수행하지 않습니다). 아무것도 이동하지 않습니다.
• COLLECT (수집) — 식별된 파일을 케이스의 live_acquisition 폴더에 유형별로 정리하여 물리적으로 복사합니다.
• PARSE (세부 분석) — 유형별(AMCACHE, EVTX, PREFETCH, …)로 식별된 항목을 검토하고 선택한 파일(또는 전체)을 포렌식 데이터베이스로 파싱합니다.

파싱은 Crow-Eye의 전용 오프라인 파서가 처리합니다 — 라이브 모드와 동일한 아티팩트 로직을 수집된 파일에 적용합니다: Prefetch, Registry, MFT, USN (MFT/USN 상관기 포함), AmCache, ShimCache, SRUM, Event Logs, LNK/JumpLists, Recycle Bin.

📎 증거 가져오기 (타사 데이터)

원시 아티팩트 외에도 Crow-Eye는 타사 포렌식 출력을 케이스로 직접 가져올 수 있습니다 — Plaso, Autopsy, Volatility 또는 모든 사용자 지정 내보내기 — 상관 실행을 먼저 요구하지 않고 Eye와 Timeline에서 사용할 수 있게 합니다.

케이스 데이터베이스 관리자가 케이스 트리 아래의 모든 .db를 자동으로 검색하므로 가져온 증거는 즉시 다음에서 사용할 수 있습니다:

• The Eye — 네이티브 아티팩트와 함께 자연어로 질의 가능 (가져올 때 스키마 매니페스트가 새로고침됨).
• 대화형 타임라인 — imported 아티팩트 유형으로 제공되며, 시간 창 필터링과 시간 범위가 작동합니다.
• 상관 엔진 — 네이티브 아티팩트와의 교차 도구 상관을 위한 Feather로 사용 가능.

가져오기는 표준 라이브러리만 사용하며(sqlite3 / csv / json) 백그라운드 작업자에서 실행되므로 대용량 가져오기가 UI를 차단하지 않습니다.

⚡ 라이브 분석

실행 중인 Windows 시스템에서 아티팩트를 직접 분석하고, 표준 위치에서 자동으로 추출하여 실시간 포렌식 분석을 수행합니다.

🗂️ 케이스 관리

모든 조사는 케이스입니다: 아티팩트 데이터베이스와 분석 출력을 구성하는 자체 포함 디렉터리입니다. Crow-Eye는 최근 케이스를 추적하고(즐겨찾기, 태그, 상태 포함), 열 때 케이스를 검증하며, 구성을 원자적으로 작성하고(크래시 세이프), 기성 의미 매핑이 포함된 케이스 구성 가져오기/내보내기와 템플릿을 지원합니다.

🕰️ 대화형 타임라인 시각화

통합 시간 그리드에서 아티팩트 간 이벤트를 상호 연관시키며, 히트 맵, 주, 일 보기를 제공합니다 — 단순한 슈퍼 타임라인이 아니라 정체성으로 연결되고 법정에서 추적 가능한 스토리입니다.

타임라인은 케이스의 파싱된 아티팩트 데이터베이스를 직접 읽으며 상관 엔진과 독립적입니다 — 사용하기 위해 feather를 만들거나, wing을 작성하거나, 파이프라인을 실행할 필요가 없습니다. 타임라인은 자체적인 경량 시간 그룹화(정확한 타임스탬프 및 시간 창 상관, 애플리케이션/경로/사용자별 그룹화)를 적용하여 그리드에서 이벤트를 연결합니다. 증거 가져오기를 통해 가져온 증거도 imported 아티팩트 유형으로 타임라인에 나타나며, 시간 창 필터링과 시간 범위가 작동합니다.

🔎 검색 및 내보내기

케이스 데이터베이스 전체에 대한 전문 검색과 CSV(스프레드시트), JSON(다른 도구와의 통합), 상세 HTML 보고서(검색어와 연결된 모든 아티팩트를 통합한 전체 도시에) 내보내기를 지원합니다.

🔗 동적 연결

SID, MAC 주소, 해시 같은 원시 기술 식별자를 즉시 사람이 읽을 수 있는 컨텍스트로 변환합니다. 동적 연결은 비파괴적 SQL ATTACH 쿼리를 사용하여 보기를 강화하므로 원본 증거는 절대 수정되지 않으며, 대량 IOC 위협 피드를 수집하여 알려진 악성 지표를 인라인으로 표시할 수 있습니다.

🧠 사용자 행동 분석 (UBA)

원시 아티팩트를 평이한 언어의 활동 스토리로 전환 — 사용자와 해당 애플리케이션이 실제로 수행한 작업을 관리자/HR이 읽을 수 있도록 설명하며, 모든 진술은 정확한 소스 증거로 추적할 수 있습니다.

사용자 행동 분석 (UBA) 는 케이스의 Target_Artifacts/ 폴더에 있는 파싱된 아티팩트 데이터베이스를 읽고(엄격히 읽기 전용) 선언적 규칙 집합을 통해 재생하여 명확하고 시간순의 활동 스토리를 생성합니다. "User Behavior" 도구 모음 버튼 또는 Ctrl+Shift+B 로 열 수 있습니다 (케이스가 로드되어 있어야 합니다).

• 🧩 선언적 동작 탐지 40가지 (uba/config/behavior_rules.json) — 코드 없이 조정 가능 — 각 탐지는 심각도로 분류됩니다: 일상(routine) · 주목할 만함(notable) · 의심스러움(suspicious) · 심각(critical).
• 🕵️ 중요한 행동을 탐지합니다: 로그인 / 로그아웃 / 잠금 해제, 프로그램 시작 · 실행 · 설치, 파일 열기 / 삭제 / 추론된 복사, USB 디바이스 연결, 네트워크 공유 액세스, 지속성 및 자동 시작, 명시적 자격 증명 사용(runas), 계정 및 그룹 변경, 서비스 변경, 시스템 시계 변조(의심스러움), 이벤트 로그 삭제(심각).
• 🗺️ 세 가지 보기 — 활동 스토리 피드, 활동 맵 히트맵(일 × 시간), 그리고 이 케이스의 각 탐지를 작동 중 / 제한적 / 데이터 없음 / 설계상으로 표시하는 "What we can see" 정직성 보고서.
• 🔗 모든 활동은 증거로 뒷받침됩니다. 항목을 클릭하면 정확한 지원 레코드(database : table : rowid)가 열립니다 — 소스 없이 주장되는 것은 없습니다.
• 👤 정직한 귀속. 행위자는 사용자 / 애플리케이션 / 시스템으로 식별되거나(또는 비워 둠) — UBA는 누가 무엇을 했는지 추측하지 않습니다.

탐지 범위

40가지 탐지는 네 가지 심각도 클래스와 파싱된 아티팩트 집합의 전체 범위를 다룹니다:

필터: 자유 텍스트 검색 · 사용자/행위자("Unattributed" 및 로그인 세션 토글 포함) · 행동 클래스(사용자 / 애플리케이션 / 시스템) · 심각도 · 애플리케이션(200개 이상 프로그램에 대한 검색 가능한 다중 선택) · 빠른 사전 설정이 포함된 날짜/시간 범위(전체 기간 / 첫 날 / 마지막 날 / 마지막 활동 시간).

데이터 소스: Security, System 및 Application 이벤트 로그 · USN Journal · MFT · UserAssist · BAM · Prefetch · ShimCache · AmCache · MUICache · ShellBags · LNK / JumpLists · Recycle Bin · SRUM(애플리케이션, 네트워크, 연결) · 레지스트리 하이브.

포렌식 보장

• 읽기 전용. 소스 데이터베이스는 읽기 전용으로 열립니다. 분석은 증거를 절대 건드리지 않습니다.
• 전체 출처. 모든 이벤트는 database → table → rowid를 포함하며 필요 시 실제 소스 행을 엽니다.
• 귀속은 절대 추측하지 않습니다. 이벤트는 사용자, 애플리케이션, 시스템에 귀속되거나 비워 둡니다. 대화형 로그온 세션은 컨텍스트 레이블("<user> 세션 동안")로만 사용되며, 작업을 귀속시키는 데 사용되지 않습니다.
• 정직한 표현. 문구는 의도적인 상호 작용(UserAssist, SRUM 포그라운드)과 애플리케이션이 생성할 수도 있는 아티팩트(ShellBags, LNK, JumpLists)를 구분하며, 카드에 명시적인 주의 사항을 표시합니다.
• 부재는 암시가 아니라 명시됩니다. What we can see 보고서는 이 특정 케이스의 모든 탐지를 표시하므로 누락된 데이터가 "아무 일도 없었다"로 조용히 읽히지 않습니다.

UBA는 규칙 기반 행동 상관 및 분류이며 통계/ML 이상 징후 점수가 아닙니다 — 모든 발견은 명시적이고 감사 가능한 규칙에 매핑됩니다. 전체 탐지 카탈로그는 RELEASE_NOTES.md를 참조하세요.

🧩 상관 엔진

Correlation Engine v1.7.0 — 재구성 핵심. 릴리스 기록은 RELEASE_NOTES.md를 참조하세요.

Crow-Eye Correlation Engine은 프로덕션 등급의 포렌식 상관 시스템입니다. 모든 소스에서 Windows 아티팩트를 수집하고 정규화하여, 고립된 레코드를 시스템에서 발생한 일, 시기, 관련된 사용자를 보여주는 일관된 내러티브로 바꿔주는 시간 및 정체성 관계를 표면화합니다. 가장 일반적인 조사 질문에 대한 기본 제공 상관 규칙(Wings)으로 즉시 작동하며, 분석가가 코드를 만지지 않고 사용자 지정 규칙을 작성할 수 있게 하고, 의미 해석은 작성 가능한 규칙과 조사자에게 맡깁니다 — 블랙박스 점수에 절대 맡기지 않습니다.

🎥 사용자 가이드

범용 데이터 가져오기: 상관 엔진은 CSV, JSON 또는 SQLite 형식의 모든 포렌식 도구 출력을 가져와 Feather 데이터베이스로 변환할 수 있습니다. 즉, 타사 도구(Plaso, Autopsy, Volatility 등)의 데이터를 Crow-Eye 네이티브 아티팩트와 상호 연관시켜 모든 포렌식 데이터 소스에 걸친 통합 상관 분석을 만들 수 있습니다.

🎯 정확성 및 증거 완전성

실제 약 700K 레코드 Windows 케이스에 대해 엔드투엔드로 검증된 집중적인 정확성 개선 작업이 이전 신뢰성 작업 위에 추가되었습니다. 아래의 모든 수정 사항은 pytest 회귀 테스트 스위트로 고정되며, 두 엔진 모두에 대해 기본 7개 wing을 실행하는 총체적 검증 하네스로 검증됩니다.

정체성 엔진이 모든 증거를 포착합니다

• 수정됨: 시간 필터가 활성화된 상태에서 정체성 엔진이 각 feather의 첫 번째 행만 반복하고 있었습니다 (시간대 인식 vs 순수 datetime 비교가 TypeError를 발생시켜 행별 루프가 중단됨). 검증 케이스에서 확인된 레코드 수가 3,558 → 745,615로 급증했습니다.
• 수정됨: 로그 레코드가 모든 이벤트를 해당 이벤트 PROVIDER로 축소하여 정체성으로 삼았습니다 (SecurityLogs 레코드 33,855개 모두 하나의 정체성을 공유함). 이제 아티팩트별 매핑은 채널/공급자 메타데이터보다 실제 행별 엔터티(User, ComputerName, NewProcessName, TargetUserName)를 우선합니다.
• 수정됨: 파서가 각 행에 artifact 열을 기록하지 않아 아티팩트 인식 필드 매핑이 실행되지 않았습니다. 이제 엔진은 feather_metadata.artifact_type으로 대체하므로 SecurityLogs / SystemLogs / ApplicationLogs는 해당 아티팩트별 정체성 우선순위를 사용합니다.
• 수정됨: 자리 표시자 문자열이 잘못된 정체성이 되었습니다 ('N/A', 'Unknown', '-', nil-GUID가 관련 없는 레코드를 함께 묶음). 이제 검증기가 30개 이상의 자리 표시자 변형을 거부합니다.
• 전체 범위 창 하나에 대한 순 결과: Execution Proof wing은 정체성 엔진에서 2,856개의 cross-feather (High) 매칭을, 시간 엔진에서 643개의 cross-feather 매칭을 표면화하며, 나머지 6개 wing에서는 각 wing당 24–118개의 cross-feather 매칭이 나타납니다.

더 이상 "모든 것이 Low — 뭔가 잘못됨" 없음

• 수정됨: 단일 feather 매칭이 High로 태그되었습니다. feather_count == 1인 매칭은 이제 confidence_category="Low - single feather"를 받으므로 High 보기는 실제 cross-feather 상관에 집중합니다.
• 수정됨: 경로 인식 복합 키가 동일한 정체성을 여러 feather로 분할하고 있었습니다 (각 feather가 경로를 다르게 저장하므로 chrome은 10개 이상의 키를 가지며 상관되지 않았습니다). 이제 키는 이름만 사용합니다 — cross-feather 상관이 다시 작동합니다.

경로 분류를 통한 가장(impersonation) 탐지 — 매칭이 형성된 후 엔진은 모든 레코드의 경로를 TRUSTED(Program Files, System32, WinSxS, BAM/SRUM /device/harddiskvolumeN/... 형식, …) 또는 SUSPICIOUS(Temp, Downloads, Public, AppData\Local\Temp, Recycle Bin, 이동식 루트, 네트워크 공유)로 분류합니다. 두 분류에 모두 걸친 매칭은 impersonation_alert를 발생시킵니다(≈0.05% 비율, 각각 실제 후보).

정직한 증거 회계 — 명명된 버킷(no_identity_field, normalize_failure, below_threshold_skipped, …)이 있는 창별 드롭 원장과 파이프라인별 요약(확인된 레코드, high/low 출력, no-identity, 드롭 버킷, timeless-feather 조인)을 제공합니다. 모든 레코드는 매칭 또는 명명된 드롭 버킷에 들어갑니다 — "남는 증거 없음"이 로그에서 검증 가능합니다. low_confidence_review_mode는 기본적으로 ON이므로 임계값 미만 그룹은 조용히 사라지지 않고 Low-confidence 매칭이 됩니다.

Timeless-feather 정체성 강화 — 행별 타임스탬프가 없는 feather(AutoStartPrograms, MUICache, SystemServices, TypedPaths)는 더 이상 모든 행에 가짜 생성 시간을 기록하지 않습니다. 대신 시간 기반 매칭이 형성된 후 엔진은 모든 timeless feather의 일치 레코드를 정체성별로 보충 증거로 조인합니다.

통합 정체성 레지스트리 — config/standard_fields/identities.json은 엔진 + Eye가 참조해야 하는 모든 열의 단일 소스입니다: 98개 범주, 1,146개 열 동의어 (앱/프로세스, 파일, 해시, 사용자, 호스트/디바이스, 네트워크, 레지스트리, 서비스/작업, 이벤트, 이메일, 브라우저, 클라우드, Windows 내부, 인증서, 컨테이너, OS 객체). 새 열 동의어를 추가하는 것은 코드 변경이 아니라 JSON 편집입니다.

의미 매핑 오탐 수정 — 다중 지표 게이팅이 이제 실제로 적용됩니다(data-exfiltration-pattern은 지표 2개 이상 필요); 불가능한 AND 규칙(4625 AND 4624)은 OR로 재작성됨; wiper/원격 도구 규칙은 모든 Prefetch 항목에 발화하지 않고 실제 정규식을 사용함; 기준 활동 규칙은 high/critical에서 info/low로 강등됨(wing의 가중 점수는 실제 위협을 상향 조정).

✅ 프로덕션 상태

상관 엔진은 프로덕션 사용 준비가 완료되었으며 조사에 적극적으로 사용되고 있습니다 (Correlation Engine v1.7.0):- ✅ 시간 창 스캔 엔진 — 프로덕션 준비 완료, 시간 기반 분석에 권장 (O(N log N))

• ✅ ID 기반 엔진 — 프로덕션 준비 완료, ID 추적에 권장 (O(N log N))
• ✅ Feather Builder / FeatherWriter — 모든 도구에서 CSV/JSON/SQLite 가져오기, 트랜잭션 일괄 처리 + 스키마 메타데이터
• ✅ Wings 시스템 및 파이프라인 오케스트레이션 — 상관 규칙 생성/관리 및 워크플로 자동화
• ✅ ID 그룹화 — 엔진, 뷰어, 시맨틱 단계 전반에 걸쳐 통합
• ✅ 표준 필드 레지스트리 — 중앙 집중식 필드 동의어 단일 정보 원천
• ✅ 다중 타임스탬프 팬아웃 — 모든 JSON 목록 타임스탬프 상관 처리
• 🔄 병렬 상관 분석 — 기반 완비, 다음은 프로파일링 + 프로세스 풀 디스패치
• 🔄 시맨틱 매핑 및 상관 점수 산정 — 활발한 개선 진행 중

주요 기능

• 🔄 이중 엔진 아키텍처: 시간 창 스캔(O(N log N))과 ID 기반(O(N log N)) 상관 전략 중에서 선택합니다.
• 📊 다중 아티팩트 지원: Prefetch, ShimCache, AmCache, 이벤트 로그, LNK 파일, Jumplists, MFT, USN, SRUM, 레지스트리, 휴지통 등을 상호 연관시킵니다.
• 🔌 범용 가져오기: 모든 포렌식 도구의 CSV/JSON/SQLite 출력을 가져와 Feather 데이터베이스로 변환합니다.
• 🎯 스마트 ID 그룹화: Chrome.exe/chrome.dll/Chrome.EXE 같은 변형은 하나의 버킷으로 통합되고, 버전 및 아키텍처 한정자는 구별된 상태로 유지됩니다.
• 🕒 유연한 타임스탬프: FILETIME, ISO 8601, Unix epoch (s/ms/μs), YYYYMMDD, 미국식 슬래시 표기, 주석이 포함된 문자열이 모두 첫 시도에 올바르게 파싱됩니다.
• 📈 다중 타임스탬프 팬아웃: JSON 타임스탬프 목록(Prefetch run_times)이 확장되어 모든 실행이 자체 상관 이벤트를 갖습니다.
• 🧰 단일 정보 원천: 필드 동의어는 config/standard_fields/*.json에, 테이블별 메타데이터는 correlation_engine/config/feather_schemas.json에 있습니다 — 코드가 아닌 JSON 편집으로 확장하세요.
• ⚡ 스트리밍 + 스레드 안전: O(1) 메모리 query_time_range_iter, 잠금으로 보호된 feather 캐시, 병렬 상관 분석 준비 완료.
• 🔍 유연한 규칙: 구성 가능한 매개변수로 사용자 정의 상관 규칙(Wings)을 정의합니다.
• 📋 정직한 진단: 창별 통계 라인(records_in / no_identity / parse_cache_hits / below_threshold / matches_emitted)으로 증거가 누락되었는지 항상 알 수 있습니다.
• 🧪 보장된 품질: 타임스탬프 파싱, ID 정규화, 팬아웃, writer 계약, Eye 작성(쓰기 측 GEP 거버넌스), 표준 필드 레지스트리를 다루는 pytest 회귀 테스트 스위트.

시스템 아키텍처

상관 엔진은 네 가지 주요 구성 요소로 이루어져 있습니다:

1. 🗄️ Feathers(데이터 정규화)

목적: 원시 포렌식 아티팩트를 표준화된 쿼리 가능 형식으로 변환합니다.

• 정규화된 포렌식 아티팩트 데이터를 포함하는 SQLite 데이터베이스 — 효율적인 쿼리를 위한 표준화된 스키마와 메타데이터를 갖춘 아티팩트 유형별(Prefetch, ShimCache, 이벤트 로그, …) feather 하나.
• 모든 포렌식 도구의 데이터를 수용하는 범용 형식.``` Any Tool Output → Feather Builder → Normalized Feather Database (CSV/JSON/SQLite) (SQLite with standard schema)

Examples:

• Plaso CSV → Feather Builder → timeline.db
• Autopsy JSON → Feather Builder → autopsy_artifacts.db
• Volatility CSV → Feather Builder → memory_artifacts.db
• Custom Output → Feather Builder → custom.db

**지원되는 가져오기 형식:** CSV (헤더가 있는 모든 파일), JSON (평면 또는 중첩), SQLite (직접 가져오기). 자동 열 매핑, 데이터 유형 감지, ISO 타임스탬프 정규화, 유효성 검사 및 최적화된 인덱스.```
prefetch.db (Feather)
├── feather_metadata (artifact type, source, record count)
├── prefetch_data (executable_name, path, last_executed, hash)
└── Indexes (timestamp, name, path)

2. 🎯 Wings (상관 관계 규칙)

목적: 어떤 아티팩트를 어떻게 상호 연관시킬지 정의합니다.

• 상호 연관시킬 시간 창, 최소 일치 수, 앵커 우선순위, 그리고 feathers(가중치 포함)를 지정하는 JSON/YAML 규칙 — 여러 사례에 걸쳐 재사용할 수 있습니다. 모든 Wing은 작성 가능하고 봉인됩니다(누가 작성했는지, 왜 작성했는지, 그리고 그 동기가 된 증거를 기록).```json { "wing_id": "execution-proof", "wing_name": "Execution Proof", "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2, "anchor_priority": ["Prefetch", "SRUM", "AmCache"] }, "feathers": [ {"feather_id": "prefetch", "weight": 0.4}, {"feather_id": "shimcache", "weight": 0.3}, {"feather_id": "amcache", "weight": 0.3} ] }

#### 3. ⚙️ 엔진 (상관관계 전략)

**목적**: 아티팩트 간의 관계를 찾기 위해 상관관계 로직을 실행합니다. 구조적 링크가 **먼저** 오며, 계층 가중 점수는 *해석/순위*로 그 위에 적용됩니다. 일치의 기준이 아닙니다.

**시간 창 스캔 엔진** — 시간 기반 분석 및 체계적인 시간적 상관관계에 가장 적합합니다. 고정 간격으로 시간을 스캔하고, 각 창의 모든 feather에서 레코드를 수집하며, 의미 필드 매칭 + 가중 점수 계산을 적용하고, MatchSet 추적을 통해 중복을 방지합니다. **O(N log N)** (인덱스된 타임스탬프 쿼리); 배치 처리 (~2,567 창/초).

**신원 기반 상관관계 엔진** — 대규모 데이터셋(>1,000 레코드) 및 신원 추적에 가장 적합합니다. 신원을 추출하고 정규화하고, 신원별로 레코드를 그룹화하고, 각 클러스터 내에서 시간적 앵커를 구축하며, 증거를 1차/2차/보조로 분류하고, 매우 큰 집합(>5,000 앵커)에 대해 일정한 메모리로 스트리밍합니다. **O(N log N)**; 유형당 40+ 신원 필드 패턴.

**엔진 선택:** 시간 기반 분석에는 시간 창 엔진을, 신원 추적에는 신원 기반 엔진을 사용하세요. 둘 다 프로덕션 준비가 되어 있으며 인덱스된 쿼리를 통해 대규모 데이터셋에 최적화되어 있습니다.

#### 4. 🔄 파이프라인 (워크플로 오케스트레이션)

**목적**: feather 생성부터 결과 생성까지 완전한 분석 워크플로를 자동화합니다. 파이프라인은 자체 설정(엔진 유형, wing, feather)을 읽고, EngineSelector를 통해 올바른 엔진을 인스턴스화하고, 각 wing을 실행하고, 일치 항목을 집계하고, 결과를 저장하며(DB + JSON), 필터링 및 시각화 기능과 함께 GUI에 표시합니다.```json
{
  "pipeline_name": "Investigation Pipeline",
  "engine_type": "identity_based",
  "wings": [{"wing_id": "execution-proof"}, {"wing_id": "file-access"}],
  "feathers": [
    {"feather_id": "prefetch", "database_path": "data/prefetch.db"},
    {"feather_id": "srum", "database_path": "data/srum.db"},
    {"feather_id": "eventlogs", "database_path": "data/eventlogs.db"}
  ],
  "filters": {
    "time_period_start": "2024-01-01T00:00:00",
    "time_period_end": "2024-12-31T23:59:59"
  }
}

모든 것이 어떻게 함께 작동하는지```

1. Data Preparation Raw Forensic Data → Feather Builder → Feather Databases
2. Configuration Wing Configs + Feather References → Pipeline Config
3. Execution Pipeline Executor → Engine Selector → Correlation Engine
4. Correlation Engine loads Feathers + applies Wing rules → Correlation Results
5. Visualization Results Database → Results Viewer GUI

### 예시 사용 사례: 실행 증거 찾기

**시나리오**: `malware.exe`가 시스템에서 실행되었음을 증명합니다.```json
{
  "wing_id": "malware-execution",
  "correlation_rules": { "time_window_minutes": 5, "minimum_matches": 2 },
  "feathers": ["prefetch", "shimcache", "amcache"]
}

I need to translate a Markdown document from English to Korean. However, the input content is empty—there's no text provided in the "INPUT:" section.

Since there's no content to translate, I should return nothing, or an empty response, rather than inventing content or adding meta-text. The instructions say to return only the translated text with no preamble. With no input, the correct output is an empty response.```python from correlation_engine.pipeline import PipelineExecutor executor = PipelineExecutor(pipeline_config) results = executor.execute()

입력 내용이 비어 있어 번역할 텍스트가 없습니다. 원문 청크를 제공해 주시면 번역해 드리겠습니다.```
Identity: malware.exe
  Anchor 1 (2024-01-15 10:30:00):
    ✓ Prefetch: malware.exe executed at 10:30:00
    ✓ ShimCache: malware.exe modified at 10:30:15
    ✓ AmCache:  malware.exe installed at 10:29:45

  Conclusion: Execution proven with 3 corroborating artifacts

성능 벤치마크

상관 엔진 시작하기

1. 실행: python -m correlation_engine.main
2. Feather 생성: 포렌식 아티팩트(Prefetch, ShimCache 등)를 가져옵니다.
3. Wing 생성: 조사에 맞는 상관 규칙을 정의합니다.
4. 파이프라인 생성: 사용할 Wing과 Feather를 구성합니다.
5. 실행: 파이프라인을 실행하고 상관된 결과를 봅니다.
6. 분석: 결과 뷰어(Results Viewer)를 사용하여 시간적 관계를 탐색합니다.

📚 상관 엔진 문서

• 상관 엔진 개요 — 아키텍처 다이어그램이 포함된 시스템 개요
• 엔진 문서 — 이중 엔진 아키텍처, 엔진 선택, 성능 최적화
• 아키텍처 — 컴포넌트 통합 및 데이터 흐름
• Feather 문서 — 데이터 정규화 시스템
• Wings 문서 — 상관 규칙
• 파이프라인 문서 — 워크플로 오케스트레이션
• 아티팩트 추가 — 새 파서를 엔진에 연결하기 위한 워크플로
• 표준 필드 레지스트리 — 두 엔진과 Eye가 로드하는 정식 컬럼명 동의어
• 기여 가이드 — 엔진에 기여하는 방법
• 빠른 링크: 엔진 선택 · 문제 해결 · 성능 최적화

👁️ Eye — 포렌식 AI 어시스턴트

강력한 어시스턴트이지 대체재가 아닙니다. Eye는 조사관의 가설을 자동화하고 검증합니다 — 결코 당신을 대신해 판단을 내리지 않습니다.

Eye는 Crow-Eye에 내장된 포렌식 AI 어시스턴트입니다. Windows 아티팩트에 대한 실제 지식 베이스를 기반으로 하는 숙련된 포렌식 조사관입니다. Prefetch, MFT, 레지스트리, 이벤트 로그, AmCache, ShimCache, SRUM 등을 포함한 사건의 모든 것을 자연어 인터페이스로 질의, 상관 분석, 문서화할 수 있으면서, 정확히 무엇을 했는지에 대한 감사 가능하고 변조 방지된 기록을 유지합니다. Eye는 (완전한 에어갭 환경을 포함하여) 전적으로 자체 하드웨어에서 실행할 수 있으며, 이는 Crow-Eye의 "0ms 데이터 장비 외 유출 없음" 프라이버시 원칙에 부합합니다. 전체 아키텍처: eye/README.md.

Eye는 대화형 질문("C:\Temp에서 22:00 이후 실행된 것을 보여줘")을 실제 포렌식 작업으로 바꿉니다. 접근 방식을 계획하고, 관련 아티팩트 지식을 검색하고, 사건 데이터베이스에 대해 SQL 및 아티팩트 간 검색을 실행하고, 검증된 답변을 종합합니다. 모든 답변은 동시에 두 곳에서 생성됩니다 — 사용자를 위한 채팅 응답과 라이브 보고서 작업 영역에 기록되는 구조화된 블록. 그래서 조사가 진행됨에 따라 도면(증거 문서)이 스스로 구축됩니다.

Ghassan Elsman 프로토콜 (GEP)

Eye가 하는 모든 일은 Ghassan Elsman 프로토콜 (GEP) — 디지털 포렌식에서 AI를 어떻게 사용해야 하는지에 대한 벤더 중립적이고 도구에 구애받지 않는 표준에 기반합니다. 이는 적합한 시스템이 준수해야 하는 10가지 원칙으로, AI 지원 조사 결과가 진실에 기반하고, 원본 기록으로 추적 가능하며, 감사 가능하고 변조 방지된 체인으로 뒷받침되고, 인간 조사관이 통제권을 갖도록 보장합니다:

Crow-Eye의 Eye는 GEP의 참조 구현이며, 이를 뒷받침하는 제품 내 동작은 **운영 규칙(Operating Rules)**입니다. 📜 표준 읽기: eye/docs/GEP_standard.md.

배포 모드

Eye는 세 가지 배포 모드를 통해 위협 모델에 적응합니다:

CLI 에이전트 모드에서 Crow-Eye는 클라우드 API나 로컬 오프라인 서버 대신 기존 AI 터미널/명령줄 에이전트를 모델로 구동하므로, 이미 사용 중인 에이전트로 조사할 수 있습니다.

조사 루프:

1. 사건을 열거나 생성 — Eye는 해당 사건의 아티팩트 데이터베이스와 기록으로 범위를 한정합니다.
2. 자연어로 질문하거나 원클릭 종합 트리아지를 실행합니다.
3. Eye가 파이프라인을 실행 — 의도 감지 → 지식 검색 → 도구 실행 → 종합.
4. 이중 출력을 받습니다 — 직접적인 채팅 답변 그리고 라이브 보고서의 새 블록.
5. 게이트된 작업 승인 — 내보내기 및 기타 중요한 단계는 승인을 기다립니다.

런타임에 switch_model 도구를 사용하여 모델을 변경할 수 있습니다. 전환은 동일한 백엔드로 제한되므로, 선택한 공급자와 다른 공급자로 증거가 조용히 전송되지 않습니다.

LLM 사고 과정 추적

Eye는 결론에 어떻게 도달했는지 보고 — 나중에 증명할 수 있도록 — 설계되었습니다. Eye가 작업하는 동안 실시간으로 구조화된 ThinkingStep 업데이트를 UI로 스트리밍합니다. 각 업데이트는 step_id, type, 사람이 읽을 수 있는 label, status (active → done 또는 error), 선택적 tool/params/detail을 포함합니다.

일반적인 쿼리는 thinking → rag → thinking → tool_call → synthesis로 전개되며, 모든 사건은 이후에 검사할 수 있는 온디스크 추적 아티팩트를 유지합니다:

도구 실행

Eye는 도구 중심입니다. 모델은 증거를 직접 다루지 않습니다. 도구 호출을 내보내면 Eye가 사건 데이터베이스에 대해 이를 실행하고 결과를 반환합니다. 따라서 모든 작업은 명시적이고, 기록되며, 재현 가능합니다. 도구는 configs/llm_config.json에 정의되고 eye/services/context_manager.py를 통해 디스패치됩니다.

조사 도구 — 증거 읽기 및 분석:

보고 도구는 라이브 보고서 작업 영역을 구축합니다: report_append_section, report_add_data_table, report_add_chart, report_add_timeline, report_add_heatmap, report_add_chain_of_custody, report_add_chat_transcript, report_add_image, report_edit_section, report_delete_section, chat_add_table, export_report (내보내기는 인간 승인 필요).

작성 도구 (관리 대상 — 상관 Wing 및 의미 매핑 구축 참조): correlation_create_wing, correlation_edit_wing, correlation_create_semantic_mapping, correlation_edit_semantic_mapping. 도구 호출은 활성 백엔드가 기대하는 형식으로 변환됩니다 — 클라우드 API 및 로컬 서버의 경우 네이티브 함수 호출, CLI 에이전트의 경우 XML <tool_call> 래퍼.

상관 Wing 및 의미 매핑 구축

Eye는 상관 엔진을 질의할 뿐만 아니라 확장하는 데도 도움을 줄 수 있습니다. Eye가 반복되는 아티팩트 간 패턴을 발견하면 새로운 Wing(상관 규칙)과 의미 매핑(기술-인간 번역)을 제안할 수 있습니다. 이는 관리되는 작성입니다. Eye가 제안하고, 분석가가 저장된 아티팩트를 검토하며, 모든 변경은 근거와 증거로 뒷받침됩니다.

Wing은 Feather를 시간 창과 최소 일치 임계값 내에서 묶어 주장을 증명합니다:

의미 매핑은 원시 기술 값을 사람이 읽을 수 있는 의미로 변환합니다 (예: EventID 4624 → "성공적인 로그온"). 단순 mapping(단일 값/정규식 → 의미 값) 또는 다중 조건 rule(AND/OR로 결합된 조건)의 두 가지 형태가 있습니다. 둘 다 category, severity, confidence, scope를 지원하며, 둘 다 reason + related_evidence가 필요합니다.

거버넌스 — GEP를 준수하는 쓰기 측 규칙:

• 근거 필수 (GEP-9 + GEP-2 준수): 모든 생성 및 편집에는 포렌식 reason이 포함되어야 합니다.
• 증거 연결 (GEP-2 준수): 모든 생성은 최소 하나의 database:table:rowid 참조를 인용해야 합니다.
• Eye 스탬프 / 타인 규칙 읽기 전용 (GEP-7 + GEP-9 준수): Eye는 작성자 + 사유 + 편집 기록을 스탬프하며 Eye가 작성한 것만 편집할 수 있습니다 — 내장 및 인간 작성 규칙은 읽기 전용입니다.

자기 치유 컨텍스트

긴 조사는 모델의 컨텍스트 창을 초과할 수 있습니다. 특히 소규모 오프라인 모델에서 그렇습니다. 충돌하거나 증거를 조용히 삭제하는 대신 Eye는 모델 호출 전마다 자체 컨텍스트를 자동 압축(보호된 생성 경로 내에서, 완전히 감사됨)합니다.

각 호출 전에 Eye는 전체 페이로드를 측정하고 응답을 위한 공간(창의 10%, 최소 512 토큰, 절반을 초과하지 않음)을 예약합니다. 그래도 맞지 않으면 두 가지 순서 있는 패스를 통해 치유하며, 보호된 메시지(고정된 메시지, 자동 감지된 증거, 도구 결과)는 절대 건드리지 않습니다:

1. 요약 패스 (한 번) — 보호되지 않은 기록이 하나의 요약으로 축소되고 SUMMARIZED로 기록됩니다.
2. 삭제 패스 — 가장 오래된 보호되지 않은 메시지가 맞을 때까지 하나씩 제거되고 TRUNCATED로 기록됩니다.

축소 불가능한 증거 코어(고정 + 도구 결과 + 현재 질문)가 여전히 넘치면 Eye는 증거를 자르는 대신 진행을 거부(REFUSED_OVERFLOW)하고 쿼리를 좁히거나 analyze_large_dataset을 사용하도록 요청합니다. 최종적으로 모델에 전달되는 것은 무엇이든 증거 체인을 위해 봉인되는 정확한 페이로드입니다.

🗺️ 내러티브 맵 — Eye의 지속적 사건 메모리

Eye는 턴 사이에 상태가 없습니다 — 그래서 내러티브 맵은 "우리가 알고 있고 결론 내린 것"이 사건에 대해 저장되는 곳입니다. 이는 Eye의 지속적이고, 감사 가능하며, 변조 방지된 작업 메모리이며, 그 내용은 매 턴 Eye의 프롬프트에 주입됩니다(맵은 말 그대로 메모리 그 자체입니다).

• 🧭 판정 → 내러티브 → 증거. 엄격한 계층 구조: 하나의 사건 판정(Verdict), 그 아래 내러티브(각 주장은 상태 포함 — proven · open · negative · needs · absolute), 그 아래 아티팩트로 뒷받침되는 증거.
• 🪟 자체 창. Eye 채팅 창의 "Narrative Map" 버튼에서 열리므로 채팅, 라이브 보고서, 사건 메모리를 나란히 볼 수 있습니다. 변경 사항이 생기면 실시간으로 새로고침됩니다.
• ↔️ 양방향 — 명령할 수 있는 메모리. Eye의 편집과 사용자의 메모 모두 단일 GEP 검증 커밋을 통과하며 해시 체인 감사 로그(narrative_map_audit.jsonl)에 봉인됩니다. 주장과 증거를 추가, 편집, 제거할 수 있어 Eye가 사건을 이해하고 해석하는 방식을 직접 형성할 수 있습니다.
• 🚫 뒷받침되지 않는 것을 단언하지 않습니다. Eye 내러티브는 조사 중에 증거 없이 open 상태로 남을 수 있지만, 증거 없이 proven이 될 수는 없습니다. Eye가 확인했지만 비어 있음을 발견한 테마는 자동으로 negative 로 전환됩니다 — 문서화된 부재 자체가 하나의 발견이기 때문입니다.

규정 준수 작동 방식

규정 준수(Compliance)는 추가된 기능이 아니라 파이프라인에 강제됩니다.

• 🔗 증거 체인 (Evidence Seal). Eye가 LLM에 보내는 모든 페이로드는 봉인됩니다. 정확한 바이트의 SHA-256, 토큰 수, 모델 + 컨텍스트 한도, 각 증거 행의 출처(database:table:rowid, MFT 레코드의 계산된 오프셋 포함). 봉인은 추가 전용이며 해시 체인으로 <case>/EYE_Logs/eye_payload_seal.jsonl에 연결됩니다 — 단일 레코드가 변경되거나 제거되면 체인이 끊어지므로, 로그는 모델이 분석한 바이트가 무엇인지 수학적으로 증명합니다.
• 🚫 조용한 잘림 없음. 컨텍스트가 부족해지면 Eye는 자기 치유하고 엄격한 순서로 예산을 재할당합니다: 우선순위 1 (이동 불가): 원시 증거 + 시스템 프롬프트 › 우선순위 2 (희생 가능): 일상 대화 › 우선순위 3 (유연): RAG 컨텍스트. 증거 코어가 여전히 맞지 않으면 Eye는 조용히 증거를 삭제하기보다 거부합니다.
• 🧾 잘림 감사 추적. 모든 컨텍스트 결정은 <case>/EYE_Logs/truncation_audit.log(SUMMARIZED, TRUNCATED, PRESERVED, PINNED, UNPINNED, BUDGET_REDUCED)에 기록되며 각각 해시가 있습니다. 감지된 증거는 신뢰도 임계값 이상에서 자동 고정되며, 메시지를 수동으로 고정할 수도 있습니다.
• 📑 증거-보고서 의무. Eye는 채팅으로 답변해야 하고 뒷받침 증거를 보고서에 저장해야 합니다. 증거 기록 실패는 프로토콜 위반으로 표시됩니다.
• ⚖️ 상관 거버넌스. Eye가 작성하는 모든 Wing 또는 매핑은 포렌식 reason 및 related_evidence를 포함해야 합니다. Eye 외부에서 작성된 규칙은 읽기 전용이며 조용히 다시 작성될 수 없습니다.
• 🔐 프라이버시 및 에어갭. 오프라인 모드에서 Eye는 외부 호출을 전혀 하지 않습니다. 클라우드 API 키는 OS 네이티브 키체인에 저장되며 — 하드코딩되거나 로그에 기록되지 않습니다.

📖 전체 Eye 아키텍처: eye/README.md.

📖 Eye-Describe — 바이트 수준 아티팩트 지식 베이스

🔗 Eye-Describe 탐색 → crow-eye.com/eye-describe

역사적으로 조사관들은 기본 아티팩트가 어떻게 동작하는지, 또는 도구가 이를 어떻게 파싱했는지 이해하지 못한 채 포렌식 도구를 신뢰하는 함정에 빠지곤 했습니다. 오늘날의 위험은 단순히 *"도구"*에 대한 신뢰를 *"AI"*에 대한 신뢰로 바꾸는 것입니다. AI는 기술적으로 완벽한 정확도로 레코드를 파싱할 수 있지만 여전히 잘못된 맥락에 배치할 수 있습니다 — 증거의 전체 의미를 바꿔버릴 수 있습니다.

Eye-Describe는 인간과 모델 모두 추측할 필요가 없도록 존재합니다. 이는 Windows 아티팩트의 원시 바이너리 구조에 대한 대화형 바이트 수준 참조이며, 동시에 두 가지 역할을 합니다:

AI 레이어를 문서화된 아티팩트 동작에 고정함으로써, Crow-Eye는 모델을 신뢰하라고 요구하는 것이 아니라 모델이 원시 포렌식을 존중하도록 제약하는 것입니다.

도구 신뢰를 AI 신뢰로 대체하지 마십시오. 데이터를 이해하십시오.

🧪 품질 및 검증

포렌식 도구는 그 출력이 방어될 수 있을 때만 유용합니다. Crow-Eye의 정확성 작업은 의도적으로 투명하게 이루어집니다:

• 회귀 테스트 스위트. 상관 엔진은 타임스탬프 파싱, ID 정규화, 다중 타임스탬프 팬아웃, writer 계약, Eye 작성(쓰기 측 GEP 거버넌스), 표준 필드 레지스트리를 다루는 pytest 스위트로 잠겨 있습니다. UBA 엔진은 실제 사건에 대한 종단 간 실행을 포함한 자체 스위트를 제공합니다.
• 검증 하네스. 전체론적 하네스가 실제 약 70만 레코드 Windows 사건에서 두 엔진 모두에 대해 7개 기본 Wing을 모두 실행합니다.
• 공개된 결함 이력. 정확성 회귀 및 측정된 영향은 RELEASE_NOTES.md에 공개적으로 문서화됩니다 — 수정으로 인해 레코드 수가 자릿수 단위로 변경된 경우를 포함합니다. 무엇이 언제 잘못되었는지 아는 것은 결과를 방어 가능하게 만드는 요소 중 하나입니다.
• 검증 가능한 증거 회계. 모든 레코드는 일치 항목 또는 명명된 드롭 버킷에 들어가며, 창별 드롭 원장은 "남은 증거 없음"을 맹신이 아닌 로그에서 확인할 수 있게 합니다.
• 변조 방지 로그. verify_chain()은 내러티브 맵 감사 로그와 증거 봉인 체인을 다시 걸어 수정을 감지합니다 — 사람이 읽을 수 있는 필드의 수정도 포함합니다.

🔬 연구 플랫폼Crow-Eye는 단순한 소프트웨어 그 이상입니다. Windows 포렌식 분야 전체를 가속화하는 오픈 리서치 플랫폼입니다. 이 프로젝트는 다음에 중점을 둡니다:

• 내부 아티팩트 구조에 대한 상세 문서 게시
• 상관관계 로직 및 방법론 공유
• 피어 리뷰, 투명성, 학술 협업 지원
• 포렌식 커뮤니티의 집단 지식에 기여

🛠️ 기술 노트

• 레지스트리 파싱에는 완전한 레지스트리 하이브 파일이 필요합니다.
• 일부 아티팩트는 Windows 파일 잠금 메커니즘으로 인해 특별한 처리가 필요합니다 (Custom registry / locked files 참조).
• LNK 및 Jump List 파싱은 Crow-Eye 자체 전용 파서가 처리합니다.

📸 스크린샷

Crow-Eye의 인터페이스 및 분석 뷰 모음입니다.

🎥 데모 비디오:

🚧 로드맵

계획되었거나 진행 중인 작업 (배포된 변경 사항은 RELEASE_NOTES.md 참조):

• 📊 고급 GUI 뷰 및 보고서 — 더 풍부한 시각화 및 보고.
• 🔄 향상된 검색 대화상자 — 자연어 지원을 포함한 고급 필터링.
• 🎯 향상된 의미 매핑 — 모든 아티팩트 유형에 걸친 포괄적인 필드 매핑.
• 📈 고급 상관관계 점수화 — 정제되고 설명 가능한 신뢰도 점수화.
• ⚡ 병렬 상관관계 — 프로세스 풀 디스패치, 대규모 워크로드에 기본 활성화.

아이디어가 있거나 아티팩트를 추가하고 싶으신가요? 이슈 열기 또는 기여를 참조하세요.

📚 문서

• TECHNICAL_DOCUMENTATION.md — 아키텍처, 구성 요소 및 개발 가이드.
• RELEASE_NOTES.md — 각 릴리스의 새로운 기능 (UBA, Narrative Map, 클라우드 Eye 백엔드, 케이스 관리 강화, …).
• 상관관계 엔진 문서 — 개요, 엔진, feathers, wings, 파이프라인.
• 타임라인 아키텍처 — 타임라인 모듈 내부 구조.
• Eye 아키텍처 및 GEP 표준 — AI 어시스턴트와 이를 규율하는 프로토콜.

🤝 기여

Crow-Eye는 오픈 리서치 플랫폼으로 구축되었으며, 새로운 파서, 상관관계 규칙, 문서 및 아티팩트 리서치 등 기여를 환영합니다.

• 일반 기여: CONTRIBUTING.md
• 상관관계 엔진 (우선 분야): correlation_engine/CONTRIBUTING.md
• 연락처: [email protected] · 또는 이슈 / 풀 리퀘스트를 열어주세요.

🌐 웹사이트 및 커뮤니티

• 🌍 공식 웹사이트: crow-eye.com — 리소스, 문서 및 다운로드.
• 💬 Discord: Crow-Eye Discord 참여하기 — 직접 도움말, 아티팩트 리서치 및 릴리스 공지.

📄 라이선스

Crow-Eye는 GNU General Public License v3.0 (GPL-3.0)에 따라 배포됩니다. 해당 라이선스 조건에 따라 자유롭게 사용, 연구, 공유 및 수정할 수 있습니다.

📝 Crow-Eye 인용

학술 작업, 발표된 연구 또는 사례 보고서에서 Crow-Eye를 사용하는 경우 다음을 인용해 주세요:```bibtex @software{elsman_crow_eye, author = {Elsman, Ghassan}, title = {Crow-Eye: A Windows Forensics Engine}, url = {https://github.com/Ghassan-elsman/Crow-Eye}, license = {GPL-3.0}, year = {2026} }

일반 텍스트: Elsman, G. *Crow-Eye: A Windows Forensics Engine* (GPL-3.0). https://github.com/Ghassan-elsman/Crow-Eye

방법론 인용의 경우, Ghassan Elsman Protocol은 [`eye/docs/GEP_standard.md`](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/eye/docs/GEP_standard.md)에 별도로 문서화되어 있습니다.

## 💖 후원

Crow-Eye는 무료 오픈소스이며, 한 명이 만들고 유지보수하고 있습니다. 작업에 도움이 된다면 후원을 고려해 주세요 — 후원은 새로운 파서와 연구에 직접 자금을 지원합니다: **[SPONSORS.md](https://github.com/ghassan-elsman/crow-eye/blob/HEAD/SPONSORS.md)** · **[GitHub Sponsors](https://github.com/sponsors/Ghassan-elsman)**.

## 크레딧

**Ghassan Elsman**이 만들고 유지보수합니다.