◎ 들억가기전에
- AI 기반 보안 자동화의 핵심 과제는 단순히 많은 도구를 연결하는 것이 아닙니다.
- 실제 보안 업무에서는 어떤 도구를 선택할지, 실행 결과를 어떻게 해석할지, 잘못된 판단이 발생했을 때 어떻게 중단할지까지 고려해야 합니다.
- 특히 AI가 외부 명령을 실행할 수 있는 환경에서는 자동화 시스템 자체가 새로운 공격 표면이 될 수 있습니다.
- HexStrike AI는 이러한 문제를 살펴보기에 적합한 오픈소스 프로젝트입니다.
- LLM(Large Language Model, 대규모 언어 모델)을 MCP(Model Context Protocol) 기반으로 실제 보안 도구와 연결하고, 도구 선택부터 결과 수집까지 이어지는 작업을 자동화하도록 설계되었습니다.
- 이번 글에서는 기존의 기능 소개와 설치 절차를 반복하기보다 실행 구조, 도구 호출의 신뢰성, MCP 서버의 권한 경계, 보안 취약점 및 실험적 평가 방법을 중심으로 분석하겠습니다.
- 2026년 10월 16일을 기준으로 공식 저장소와 해외 보안업체의 분석, 공개된 기술 연구를 구분해 살펴보겠습니다.
◎ 배경 및 개요: 도구 통합보다 중요한 실행 통제
- HexStrike AI의 공식 저장소는 0x4m4/hexstrike-ai이며, 프로젝트는 OTT Cybersecurity LLC가 소유·개발하는 것으로 안내되어 있습니다.
- 공식 README는 v6.0을 표기하고 있으며, 150개 이상의 보안 도구와 12개 이상의 특화 AI 에이전트를 주요 특징으로 제시합니다.
- 다만 이 숫자는 프로젝트가 설명하는 통합 규모이지, 모든 도구가 설치되어 정상 동작한다는 독립적인 검증 결과는 아닙니다.
- 일반적인 보안 자동화는 사전에 정한 순서대로 명령을 실행합니다.
- 반면 HexStrike AI가 지향하는 방식은 AI 에이전트가 작업 맥락을 바탕으로 도구를 선택하고, 실행 결과에 따라 후속 작업을 결정하는 것입니다.
- 예를 들어 승인된 웹 애플리케이션을 점검한다고 가정하겠습니다.
- 기술 스택 확인 결과가 다음 단계의 스캐너 선택에 영향을 줄 수 있고, 스캔 결과는 추가 검증이 필요한 항목을 선별하는 데 활용될 수 있습니다.
- 이처럼 여러 도구의 결과를 연결하는 과정이 오케스트레이션(orchestration)입니다.
> 하지만 여기에는 중요한 구분이 있습니다.
- 판단 계층: LLM이 목표와 관측 결과를 바탕으로 다음 작업을 결정합니다.
- 실행 계층: MCP 서버가 요청을 받아 실제 도구나 명령을 실행합니다.
- 검증 계층: 실행 결과가 정확한지, 취약점이 재현되는지, 대상 범위가 적절했는지 확인합니다.
> 앞의 두 계층이 자동화되더라도 세 번째 계층까지 자동으로 신뢰할 수 있는 것은 아닙니다.
- 따라서 HexStrike AI를 평가할 때는 도구의 개수보다 각 단계가 얼마나 정확하고 통제 가능하게 연결되는지를 살펴봐야 합니다.
◎ 주요 변경 사항: v6.0과 실제 유지보수 상태를 구분해야 하는 이유
- 공식 README에서 강조하는 v6.0의 변화는 특화 에이전트, 지능형 도구 선택, 실행 프로세스 관리, 결과 시각화의 결합입니다.
- 그러나 운영 환경에서 중요한 것은 기능 목록뿐 아니라 해당 기능이 어느 코드 버전에서 구현되고 검증되었는지입니다.
- 특히 공식 저장소에는 설치 호환성, 도구 탐지, MCP 연결, 명령 실행 보안과 관련된 변경 요청이 공개되어 있습니다.
- 2026년 9월에는 명령 인자 처리와 관련된 수정 제안도 확인됩니다.
- 이러한 기록은 개발이 진행 중이라는 사실을 보여주지만, 제안된 수정이 모두 기본 브랜치에 병합되었다는 의미는 아닙니다.
> 버전과 관련해서는 다음 세 가지를 구분하는 것이 좋습니다.
- 현재 문서에 명시된 기능: 공식 README의 v6.0 설명을 기준으로 확인합니다.
- 개발 중인 기능: Pull Request나 이슈에 등장하는 개선 사항은 병합 여부를 확인합니다.
- 향후 계획: README의 v7.0 항목은 출시 예정으로 표시되어 있으므로, 실제 배포된 기능과 혼동하지 않습니다.
> 따라서 실무 환경에서는 저장소를 내려받는 것만으로 검증을 끝내지 말고, 사용한 커밋 해시와 의존성 버전을 함께 기록해야 합니다.
- 동일한 프로젝트 이름을 사용하더라도 코드 상태에 따라 실행 결과와 보안 특성이 달라질 수 있기 때문입니다.
◎ 상세 기능 분석: 도구 선택보다 중요한 결과의 연속성
- 도구 오케스트레이션과 상태 관리
HexStrike AI는 네트워크 정찰, 웹 애플리케이션 점검, 클라우드 보안, 바이너리 분석, 포렌식 등의 도구를 하나의 인터페이스에서 호출할 수 있도록 구성합니다.
이 구조의 실질적인 가치는 여러 도구의 결과를 다음 작업의 입력으로 연결하는 데 있습니다.
예를 들어 기술 식별 결과를 웹 점검의 우선순위 결정에 활용하거나, 발견된 취약점 후보를 별도의 검증 작업으로 넘길 수 있습니다.
> 그러나 자동화 체인이 길어질수록 오류가 전파될 가능성도 커집니다.
- 최초 정찰 결과가 부정확하면 잘못된 서비스 정보가 다음 단계로 전달될 수 있습니다.
- 잘못된 파라미터가 전달되면 정상적인 도구도 실패하거나 의도하지 않은 요청을 보낼 수 있습니다.
- 실패한 명령을 자동 재시도하면 불필요한 요청과 부하가 증가할 수 있습니다.
- 결과를 종합하는 과정에서 서로 다른 증거가 하나의 취약점으로 잘못 묶일 수 있습니다.
> 따라서 결과에는 도구 이름, 실행 시각, 대상, 인자, 종료 코드, 표준 출력과 오류 출력, 후속 작업의 근거를 함께 기록하는 것이 바람직합니다.
- 이런 기록이 있어야 최종 보고서에서 어떤 판단이 실제 증거에 기반했는지 역추적할 수 있습니다.
- 브라우저 자동화와 웹 애플리케이션 분석
- 공식 문서는 Headless Chrome 기반 브라우저 자동화, DOM 분석, 네트워크 요청·응답 관찰, 폼 탐지, 보안 헤더 확인 등을 기능으로 소개합니다.
- 브라우저 자동화는 단순한 HTTP 요청만으로 파악하기 어려운 동적 페이지와 JavaScript 기반 기능을 조사하는 데 도움이 됩니다.
- 다만 브라우저에서 확인한 현상과 서버 측 취약점은 동일하지 않습니다.
- 예를 들어 특정 입력값이 화면에 표시된다는 사실만으로 XSS 취약점이 입증되지는 않습니다.
- 출력 문맥, 인코딩, 실제 스크립트 실행 여부를 별도로 확인해야 합니다.
- 마찬가지로 보안 헤더가 없다는 사실만으로 곧바로 공격 성공을 의미하지도 않습니다.
> 웹 점검 결과는 다음처럼 구분해 관리하는 편이 좋습니다.
| 분류 |
판단 기준 |
| 관측 사실 |
응답 코드, 헤더, DOM 변화 등 실제 수집된 증거 |
| 취약점 후보 |
도구 또는 AI가 취약 가능성을 제시한 항목 |
| 검증 완료 |
승인된 환경에서 재현 절차와 영향이 확인된 항목 |
| 미확정 |
응답 부족, 타임아웃, 환경 차이 등으로 판단할 수 없는 항목 |
- 이러한 분류는 AI가 작성한 설명을 검증 결과로 오인하는 문제를 줄여줍니다.
- 지능형 의사결정 엔진의 한계
- HexStrike AI의 특화 에이전트에는 도구 선택, CVE 인텔리전스, 기술 식별, 취약점 상관분석, 오류 복구 등을 담당하도록 설계된 구성 요소가 포함됩니다.
- 여기서 특히 주목할 부분은 도구 선택의 정확도와 실제 취약점 탐지의 정확도를 분리해야 한다는 점입니다.
- AI가 적절한 스캐너를 선택했더라도 대상에 취약점이 없을 수 있습니다.
- 반대로 취약점이 존재하더라도 필요한 도구가 설치되지 않았거나 인증 정보가 부족하면 발견하지 못할 수 있습니다.
- 또한 CVE 정보와 제품 버전이 일치한다는 사실은 취약점 악용 가능성을 판단하는 출발점이지, 실제 취약한 상태라는 확정 증거는 아닙니다.
- 패치 백포트, 구성 차이, 접근 통제, 보완 통제 등의 영향을 추가로 확인해야 합니다.
- 따라서 자동화 시스템의 성능을 측정할 때는 도구 호출 성공률, 작업 완료율, 취약점 후보의 정밀도, 검증된 취약점 탐지율을 각각 별도로 집계해야 합니다.
◎ 기획 의도 및 기술적 개선: 공개 연구에서 확인되는 중요한 사실
- HexStrike AI의 기술적 가치를 검토할 때 참고할 만한 자료는 2026년 공개된 연구인 Determinants and Limits of LLM Security-Tool Orchestration: A Study with HexStrike-AI입니다.
- 이 연구는 도구 통합 자체보다 AI 클라이언트와 실행 체계가 결과에 어떤 영향을 주는지 분석합니다.
- 연구 소개에 따르면 86개 picoCTF 과제를 대상으로 총 774회의 기준 실험을 수행했으며, 같은 DeepSeek 모델을 사용하더라도 클라이언트 구성에 따라 과제 해결률이 59.7%와 27.9%로 차이를 보였습니다.
- 추가 도구와 프롬프트·실행 방식 개선을 결합한 실험에서는 전체 해결률이 55.4%에서 72.0%로 상승했습니다.
> 이 결과는 세 가지 시사점을 제공합니다.
- 첫째, LLM 모델만으로 자동화 성능을 설명할 수 없습니다. 도구 호출 방식, 재시도 정책, 컨텍스트 전달, 명령 제약 등 실행 환경이 결과에 영향을 미칩니다.
- 둘째, 도구 수를 늘리는 것만으로 성능이 비례해서 향상되지는 않습니다. 기존 도구의 호출 오류를 수정하거나 작업을 단계적으로 분해하는 방식도 중요합니다.
- 셋째, 벤치마크 결과를 실제 침투 테스트 성능으로 일반화해서는 안 됩니다. 해당 연구는 CTF 과제를 중심으로 진행됐고, 개선 사항을 동일한 과제 집합에 맞춰 설계하고 평가했다는 한계가 있습니다. 실제 기업 네트워크나 운영 중인 웹 애플리케이션에서 동일한 개선 폭이 나타난다고 단정할 수 없습니다.
> 따라서 HexStrike AI의 개선 효과를 직접 평가하려면 모델, 클라이언트, 저장소 커밋, 설치된 도구, 과제 난이도를 고정하고 비교해야 합니다.
◎ 사용방법 및 가이드: 재현 가능한 검증 환경 만들기
- 이번 절차의 목적은 실제 외부 시스템을 공격하는 것이 아니라, HexStrike AI의 설치 상태와 MCP 연결, 실행 기록을 통제된 환경에서 검증하는 것입니다.
- 저장소와 실행 환경 고정
- 공식 저장소를 내려받고 가상환경을 구성합니다.
git clone https://github.com/0x4m4/hexstrike-ai.git
cd hexstrike-ai
git rev-parse HEAD
python3 -m venv hexstrike-env
source hexstrike-env/bin/activate
python3 -m pip install -r requirements.txt
- git rev-parse HEAD는 현재 체크아웃된 커밋을 확인합니다.
- 해당 값을 실험 기록에 남기면 이후 코드가 변경되더라도 같은 버전을 기준으로 결과를 비교할 수 있습니다.
- Python 의존성 설치는 외부 보안 도구 전체의 설치와 다릅니다. 공식 requirements.txt도 외부 도구 상당수를 별도로 설치해야 한다고 안내하므로, 필요한 도구의 존재 여부와 버전을 개별적으로 확인해야 합니다.
- MCP 서버 실행 및 기본 상태 확인
- 공식 README에서 안내하는 서버 실행 방식은 다음과 같습니다.
python3 hexstrike_server.py --port 8888
curl http://127.0.0.1:8888/health
- 상태 확인이 성공하더라도 모든 보안 도구가 정상 동작한다는 뜻은 아닙니다.
- 헬스 체크 응답과 실제 도구 가용성은 별개의 검사 항목으로 취급해야 합니다.
- 특히 테스트가 끝날 때까지 서버를 외부 인터페이스에 공개하지 말고, 가능하면 전용 VM에서 실행하십시오.
- 호스트 방화벽과 가상 네트워크에서도 허용된 실습 대상 외의 통신을 제한하는 것이 좋습니다.
- MCP 클라이언트 연결
- 공식 README는 Claude Desktop, Cursor, VS Code Copilot 등 여러 MCP 호환 클라이언트의 연결 예제를 제공합니다.
- 클라이언트별 설정 파일과 실행 방식은 다를 수 있으므로 실제 사용 중인 버전에 맞춰야 합니다.
> 연결이 되지 않는다면 다음 순서로 확인합니다.
- 서버 프로세스가 실행 중인지 확인합니다.
- 설정 파일에 지정한 Python 실행 파일과 hexstrike_mcp.py 경로가 올바른지 확인합니다.
- 클라이언트의 MCP 연결 로그를 살펴봅니다.
- 필요한 외부 도구가 설치되어 있고 실행 경로에서 검색되는지 확인합니다.
- 동일한 설정과 커밋에서 문제가 재현되는지 기록합니다.
- 승인된 랩에서 테스트 품질 측정
- 첫 실험부터 광범위한 자동 점검을 실행하기보다, 자체 소유의 의도적으로 취약한 실습 애플리케이션을 대상으로 작은 테스트를 설계하는 것이 좋습니다.
> 각 테스트에서는 다음 항목을 기록합니다.
- 작업 목표와 허용된 대상 범위
- 선택된 도구와 실행 인자
- 정상 종료·오류·타임아웃 여부
- 실제 증거와 AI의 해석
- 동일 조건에서의 재실행 결과
- 사람이 최종 검증한 결론
> 이렇게 수집한 기록을 바탕으로 도구 호출 성공률과 오탐률을 측정하면, 단순히 대시보드가 정상적으로 표시되는지를 넘어 자동화의 실제 품질을 평가할 수 있습니다.
◎ 보안 취약점과 운영상 주의사항
- HexStrike AI를 도입할 때 가장 중요하게 살펴봐야 할 부분은 AI 모델의 판단 오류뿐 아니라, 모델이 연결된 서버 자체의 보안입니다.
- CVE-2025-35028과 명령 주입 위험
- 해외 보안업체 Check Point는 2026년 3월 2일 공개한 보안 권고에서 HexStrike AI MCP Server의 명령 주입 취약점인 CVE-2025-35028을 다뤘습니다.
- 권고에 따르면 특정 커밋 2f3a5512의 기본 구성에서 EnhancedCommandExecutor 클래스가 만든 API 엔드포인트에 세미콜론으로 시작하는 명령행 인자가 전달되면 임의 명령 실행으로 이어질 수 있었습니다.
- 서버가 높은 권한, 특히 root 권한으로 실행되는 환경에서는 영향이 더욱 커질 수 있습니다.
- 이 사례에서 얻을 수 있는 핵심 교훈은 명령을 실행하는 자동화 서버에서는 입력 검증이 부가 기능이 아니라 핵심 보안 통제라는 점입니다.
- 다만 해당 권고는 특정 커밋을 대상으로 합니다.
- 이 내용을 근거로 현재 모든 버전이 취약하다고 단정하거나, 반대로 최신 코드라면 자동으로 안전하다고 판단해서도 안 됩니다.
- 실제 배포하려는 커밋의 수정 여부와 관련 변경 이력을 직접 확인해야 합니다.
- MCP 서버는 단순한 API 서버가 아닙니다
- HexStrike AI의 MCP 서버는 AI 클라이언트의 요청을 실제 보안 도구 실행으로 연결합니다.
- 따라서 서버가 침해되거나 잘못된 요청을 허용하면, 단순한 데이터 유출을 넘어 호스트에서 명령이 실행되거나 내부 네트워크에 접근할 가능성이 생깁니다.
> 운영 전에는 다음 통제를 적용하십시오.
- 전용 VM 또는 격리된 테스트 환경에서 실행합니다.
- 불필요한 관리자 권한을 제거하고 최소 권한을 적용합니다.
- 네트워크 수준에서 허용된 대상과 포트를 제한합니다.
- 인증과 접근 통제를 적용하고, 외부에서 직접 접근할 수 없도록 구성합니다.
- 명령 실행 기록과 프로세스를 모니터링하고, 이상 동작을 중단할 절차를 마련합니다.
- 프롬프트에 적힌 대상 범위만 믿지 말고 방화벽과 실행 계층에서도 범위를 강제합니다.
> 공식 README 역시 격리 환경과 에이전트 활동 감독을 강조하며, 운영 배포 시 인증을 고려하도록 안내합니다.
- 자동화 결과를 검증하는 기준
- AI가 생성한 보고서에는 사실, 추론, 미확인 가설이 함께 포함될 수 있습니다.
- 특히 취약점 탐지율이나 오탐률처럼 숫자로 표현된 프로젝트 자체의 성능 주장은 독립된 시험 조건과 재현 가능한 결과가 있는지 확인해야 합니다.
- 또한 Check Point는 2025년 9월 HexStrike AI가 공개된 Citrix NetScaler 취약점 관련 공격 시도에 활용됐다는 위협 인텔리전스 분석을 발표했습니다.
- 이는 도구의 설계 목적과 실제 사용 목적이 다를 수 있음을 보여줍니다. 다만 위협 행위자의 주장이나 관찰된 시도를 모든 공격의 성공 증거로 해석해서는 안 됩니다.
◎ 기대효과
- HexStrike AI의 가장 큰 장점은 여러 보안 도구를 하나의 AI 기반 실행 흐름으로 연결할 수 있다는 점입니다.
- 반복적인 정찰과 점검을 자동화하고, 서로 다른 도구의 결과를 연결해 분석하며, 보안 담당자가 검토해야 할 항목을 빠르게 선별하는 데 활용할 수 있습니다.
- 반면 자동화 범위가 넓어질수록 잘못된 판단과 실행의 영향도 커집니다.
- 도구 호출이 성공했다는 사실은 취약점이 발견되었다는 뜻이 아니며, AI가 제시한 공격 경로 역시 재현 가능한 증거와 별도로 평가해야 합니다.
> 따라서 실무 도입에서는 다음 세 가지를 우선순위로 두는 것이 좋습니다.
- 실행 통제: 대상 범위, 권한, 네트워크 접근을 기술적으로 제한합니다.
- 재현성: 커밋, 의존성, 모델, 클라이언트, 실행 로그를 기록합니다.
- 결과 검증: 자동화 결과를 후보로 취급하고 사람이 증거를 확인합니다.
◎ 마무리
- HexStrike AI는 AI 기반 보안 자동화의 가능성을 살펴볼 수 있는 유용한 연구 대상입니다.
- 다만 전문적인 보안 운영에 적용하려면 기능의 수보다 실행 통제와 검증 가능성을 먼저 확보해야 합니다.
- 결국 신뢰할 수 있는 자동화란 많은 명령을 빠르게 실행하는 시스템이 아니라, 왜 실행했는지 설명할 수 있고, 잘못된 실행을 제한할 수 있으며, 결과를 재현하고 검증할 수 있는 시스템입니다.
