NetbyteSEC показала proof-of-concept: headless-имплант на Go напрямую реализует опубликованный контракт релея Orca от Stably и использует легитимную инфраструктуру вендора как транспорт для управления. Техника не эксплуатирует уязвимость в Orca, и сама Orca на цели не нужна. В тесте 5 ноября на Windows команда whoami вернула desktop-win\winuser, хотя на машине не было ни процесса, ни установки, ни слушателя Orca.
По данным NetbyteSEC, Orca 1.4.249 - десктопное приложение, которое подключается исходящим WSS-соединением на 443 к релею вендора. Схема такая: краткоживущий relay-token на 300 секунд, назначение клетки, обмен host-hello и host-challenge через X25519 sealed box, затем подтверждение host-hello-ack. Релей пересылает кадры, не разбирая их, а E2EE для пересылки не обязателен.
Идентичность хоста - ключ X25519, отдельной регистрации хоста нет. Нужен аккаунт с правом relay.use, а оператор подключается по инвайту на 10 минут с пятью попытками. Имплант поддерживает команды info, exec, read, write, pull, push и интерактивный shell.
Лимиты релея: восемь соединений на хост, кадр до 8 МиБ, полезная нагрузка до 3 МиБ, таймаут простоя 10 минут и аренда клетки около шести часов. На цели не появляется ни слушающего сокета, ни установки Orca, ни отдельной регистрации хоста.
Обнаружение построено на общих признаках: процесс вне каталога Orca обращается к хостам релея вендора, читает файлы ключей Orca или регистрирует relayHostId без установленной Orca. В отчёте опубликованы правила Sigma и Suricata, но домены вендора - легитимная инфраструктура, а не IOC; артефакты импланта дают слабый сигнал и легко переименовываются.
Авторы подчёркивают: это PoC, а не кампания в дикой природе. Практический вывод - релей можно использовать как транспорт, если у атакующего есть аккаунт с нужным правом, а защите стоит смотреть не на домен, а на контекст процесса и корреляцию с установкой Orca.
