Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
Инструменты/GitHubGitHub/ivancabrera02/hashsiphon
Оборонительные ИнструментыАтаки на ПаролиСбор информацииПост-эксплуатацияТестирование на ПроникновениеRed Teaming
GitHubivancabrera02/hashsiphon

HashSiphon

Извлекает NetNTLMv2-хеш текущего пользователя через проксирование HTTP-аутентификации, избегая прямых вызовов SSPI; v2 делегирует аутентификацию службе BITS, чтобы разорвать атрибуцию процесса.

Репозиторий
32567 дней назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

HashSiphon

Извлечение NTLM-хэша через проксирование аутентификации на уровне HTTP, без вызовов SSPI из процесса атакующего.

HashSiphon извлекает NetNTLMv2-хэш текущего пользователя, манипулируя потоками HTTP-аутентификации вместо прямого вызова SSPI API. Инструмент поставляется в двух вариантах: v1 направляет NTLM-аутентификацию через HTTP-стек .NET в рамках того же процесса, а v2 полностью делегирует аутентификацию службе BITS (svchost.exe) в другом PID, полностью разрывая атрибуцию на уровне процесса.

Почему это важно

Все известные инструменты самостоятельного извлечения NTLM-хэша — Internal Monologue, ручные скрипты на SSPI и их производные — вызывают AcquireCredentialsHandle → InitializeSecurityContext → AcceptSecurityContext из собственного процесса атакующего. EDR перехватывают эти функции SSPI и помечают цепочку вызовов.

HashSiphon идёт принципиально иным путём:

АспектInternal MonologueHashSiphon v1HashSiphon v2
Вызовы SSPI из PID атакующего4+ прямых вызова0 прямых (WinHTTP вызывает внутри)0 в любом нашем процессе
Процесс аутентификацииPID атакующегоPID атакующего (через HTTP-стек)svchost.exe (служба BITS)
Импорты security APIТребуются импорты DLL SSPIОтсутствуют в нашем кодеОтсутствуют в нашем коде
Поверхность обнаруженияХуки SSPI, паттерны вызовов APIHTTP-трафик на loopbackЗадание BITS + трафик на loopback
Атрибуция процессаPID атакующегоPID атакующегоРазорвана, совершенно другой PID

Как это работает

Оба варианта используют одно ядро: минимальный TCP-сервер на 127.0.0.1, который говорит на ровно достаточном объёме HTTP для выполнения обмена NTLM challenge-response, с контролируемым 8-байтовым challenge, чтобы перехваченный хэш можно было взломать офлайн.

v1 — HTTP-самоаутентификация (HashSiphon.ps1)

root@kitploit:~
┌──────────────────────────┐
│     PowerShell (PID X)   │
│                          │
│  ┌────────────────────┐  │          ┌──────────────────────┐
│  │ TCP Server (C#)    │◄─┼──────────┤ HttpWebRequest +     │
│  │ Loopback :random   │  │  HTTP    │ DefaultCredentials   │
│  │                    │──┼──────────►                      │
│  │ 1. Send 401+NTLM   │  │  NTLM    │ WinHTTP auto-auths   │
│  │ 2. Send Type 2     │  │  Type    │ using current user's │
│  │ 3. Capture Type 3  │  │  1/2/3   │ credentials          │
│  │ 4. Extract hash    │  │          │                      │
│  └────────────────────┘  │          └──────────────────────┘
└──────────────────────────┘
  1. Компилирует C# TCP-сервер через Add-Type, привязывается к 127.0.0.1:0 (порт назначает ОС)
  2. Клиент подключается через HttpWebRequest + CredentialCache.DefaultCredentials
  3. Сервер отвечает HTTP 401 с WWW-Authenticate: NTLM, чтобы запустить согласование
  4. WinHTTP отправляет NTLM Type 1 → сервер отвечает сформированным Type 2 (контролируемый challenge) → WinHTTP отправляет Type 3
  5. Сервер разбирает Type 3 и извлекает NetNTLMv2-хэш

Компромисс: WinHTTP внутри вызывает SSPI в том же PID — прямых импортов нет, но стек вызовов всё равно ведёт к нам.

v2 — Прокси через службу BITS (HashSiphonV2.ps1)

root@kitploit:~
┌─────────────────────┐         ┌───────────────────────────┐
│  PowerShell (PID X) │         │  svchost.exe (PID Y)      │
│                     │         │  BITS Service             │
│  ┌───────────────┐  │  HTTP   │                           │
│  │ TCP Server    │◄─┼─────────┤  BITS downloads from our  │
│  │ (Background   │  │  NTLM   │  server, auto-authenticates│
│  │  Runspace)    │──┼─────────►  using job owner's creds   │
│  └───────────────┘  │  Type   │                           │
│                     │  1/2/3  │  SSPI calls happen HERE,  │
│  Start-BitsTransfer─┼────────►│  not in PID X             │
│  (Trigger only)     │  COM    │                           │
└─────────────────────┘         └───────────────────────────┘
          │
          └── Our process: TcpListener + Start-BitsTransfer
              Zero SSPI. Zero security API imports.
  1. Тот же C# TCP-сервер запускается в фоновом Runspace PowerShell
  2. Start-BitsTransfer создаёт задание загрузки, указывающее на http://127.0.0.1:<port>/hashsiphon.bin
  3. Служба BITS (svchost.exe, совершенно другой PID) подключается к нашему серверу
  4. BITS аутентифицируется с учётными данными владельца задания, обмен NTLM перехватывается нашим сервером
  5. Сервер возвращает HTTP 200 с телом, чтобы BITS счёл передачу успешной
  6. Хэш извлекается из сообщения Type 3

Прорыв: Наш процесс никогда не вызывает SSPI — ни напрямую, ни через WinHTTP, никак. Все вычисления NTLM происходят в svchost.exe. Хуки SSPI в EDR видят стек вызовов в процессе службы BITS, а не в нашем.

Использование

Требования

  • Windows 10/11
  • PowerShell 5.1+
  • Привилегии обычного пользователя (администратор не требуется)
  • Запущенная служба BITS (по умолчанию в Windows)

Запуск v1

root@kitploit:~
powershell -ExecutionPolicy Bypass -File HashSiphon.ps1

Запуск v2

root@kitploit:~
powershell -ExecutionPolicy Bypass -File HashSiphonV2.ps1

Ожидаемый вывод (v2)

root@kitploit:~
  [*] Compiling HashSiphon v2 server...
  [+] Server compiled

  HashSiphon v2.0 - BITS Service Proxy Authentication
  Auth by svchost.exe (BITS), not our process

  [1] NTLM HTTP server ready on 127.0.0.1:52847
  [2] Controlled challenge: 1122334455667788
  [3] Triggering BITS transfer to our server...
  [4] BITS transfer initiated

  [+] User:        ivan
  [+] Domain:      DESKTOP-ABCDEF
  [+] NT response: 280 bytes (NTLMv2)

  +----------------------------------------------------------+
  |     NetNTLMv2 HASH - Extracted via BITS service proxy!   |
  +----------------------------------------------------------+
  |  hashcat -m 5600 | john --format=netntlmv2               |
  +----------------------------------------------------------+

  ivan::DESKTOP-ABCDEF:1122334455667788:<NTProofStr>:<ClientBlob>

  +----------------------------------------------------------+
  |  ATTRIBUTION ANALYSIS                                    |
  +----------------------------------------------------------+
  |  Our PID:      844  (PowerShell)                         |
  |  Auth by:      BITS service (svchost.exe, PID 5500)      |
  |  SSPI calls:   Zero from PID 844                         |
  |  Our APIs:     TcpListener + Start-BitsTransfer only     |
  +----------------------------------------------------------+

Поведение при отказе

Если BITS не работает (служба отключена, модуль недоступен), v2 автоматически переключается на запуск дочернего процесса powershell.exe с Invoke-WebRequest -UseDefaultCredentials. Это всё ещё обеспечивает разделение PID, хотя дочерний процесс более заметен, чем BITS.

Скачать инструмент