Координированная модуляция нагрузки 1 000 GPU в локальной энергосети мощностью 1 МВт с 90% DER - и total harmonic distortion тока улетает до 46.8%, а коэффициент демпфирования проваливается до -0.27. Система входит в нестабильный режим. Это синхронизированная модель наихудшего случая - но цифры получены не на салфетке: импедансный анализ, моделирование энергосистем, натурные эксперименты на реальных GPU и сетевых инверторах. Препринт исследователей из Zhejiang University (arXiv ID не верифицирован: указанный идентификатор 2607.05993 не соответствует формату YYMM.NNNNN с валидной датой) формализует новый класс кибер-физических атак - Bit2Watt: злоумышленник, работающий как легитимный облачный тенант, раскачивает GPU-нагрузку, чтобы дестабилизировать энергосеть ЦОД. При этом ни одно устройство на стороне энергоинфраструктуры не скомпрометировано. Ни один русскоязычный источник эту атаку не разбирал - ниже первый детальный анализ механики, ограничений и контрмер.
Бизнес-логика атаки: зачем модулировать энергопотребление GPU
Industroyer/CrashOverride (Украина, 2016), TRITON/Trisis (Саудовская Аравия, 2017) - классика кибератак на энергетику. Обе требовали компрометации OT-устройств: контроллеров RTU, HMI-панелей, SCADA-серверов. Атакующий преодолевал периметр, получал доступ к промышленной сети, разбирался в протоколах. Bit2Watt атака работает иначе: воздействие идёт не через сетевой протокол, а через физику - через управляемые скачки энергопотребления вычислительного оборудования.Зачем это атакующему? Вариантов несколько. Саботаж конкурирующей инфраструктуры: каскадный отказ энергосистемы прерывает тренировку моделей, разрушает SLA. Скрытый denial-of-service: срабатывание UPS bypass, автоматических выключателей, ATS - сброс вычислительной нагрузки. Hours-long training checkpoint откатывается, финансовые потери измеряются сотнями тысяч долларов GPU-часов. Энергосистема дата-центра - часть инфраструктуры, а число cloud intrusion случаев выросло на 26% год к году (CrowdStrike Global Threat Report 2025). Поверхность для атак, требующих лишь облачного доступа, расширяется.
И вот что неприятно: Bit2Watt не оставляет следов на уровне файловой системы, не использует малварь, не требует повышения привилегий. Атакующий работает через штатный API облачной платформы - CUDA Runtime API, PyTorch distributed training, стандартный job scheduler. Кибер-физические атаки на дата-центры этого класса не подпадают ни под один существующий сигнатурный детект.
Модель угрозы Bit2Watt: облачный тенант как кибер-физическое оружие
Согласно препринту Zhou et al. (arXiv ID не верифицирован), противник арендует GPU-мощности через стандартный интерфейс облачного провайдера. Никаких программных уязвимостей, никакого lateral movement, никакой компрометации BMC/IPMI. Вместо этого - легитимные user-level API для запуска CUDA-ядер или обучающих пайплайнов, структурированных так, чтобы паттерн энергопотребления GPU-кластера вносил управляемые возмущения в энергосеть ЦОД.
Это принципиально новая поверхность атаки для безопасности электропитания ЦОД. Облачный мониторинг отслеживает утилизацию GPU, сетевой трафик, объём памяти - но не анализирует частотный спектр вызванных вычислениями колебаний мощности. Facility-мониторинг (DCIM-платформы типа Nlyte или Sunbird, PDU-телеметрия через SNMP) фиксирует средневзвешенное потребление, но стандартная частота опроса SNMP-based PDU от Raritan, APC, Vertiv - 1-5 секунд. Это на три-четыре порядка грубее, чем частота модуляции SWMA (до 6 000 Гц по заявленным данным авторов). Между cloud-side и facility-side мониторингом - мёртвая зона. Именно в ней и работает Bit2Watt.
Контекст масштаба: прогнозируемый рост потребления электроэнергии дата-центрами - с 415 ТВтч в 2024 году до более чем 945 ТВтч к 2030 (данные OPAL-RT со ссылкой на Goldman Sachs Research). Объём вычислительных мощностей, доступных атакующему, будет только расти.
Место в цепочке атаки
В терминах MITRE ATT&CK Enterprise matrix цепочка Bit2Watt выглядит так:- Discovery - System Information Discovery (T1082): атакующий определяет топологию GPU-кластера, количество SM (streaming multiprocessors), тактовые частоты, модель GPU. Через стандартные вызовы CUDA API или
nvidia-smi- ничего необычного. - Execution - запуск CUDA-ядер через легитимный user-level API. Формально отдельная ATT&CK-техника не требуется: выполнение CUDA-кода - штатная функция арендуемого ресурса. При использовании Python-обёрток (PyTorch, TensorFlow) формально применима T1059.006 - Python, хотя в этом контексте это легитимный код.
- Impact - результирующее воздействие: Compute Hijacking (T1496.001) - использование ресурсов для задач атакующего; Service Stop (T1489) - каскадный отказ при срабатывании защит; Runtime Data Manipulation (T1565.003) - структурированная манипуляция паттерном выполнения вычислений для кибер-физического эффекта.
Два вектора манипуляции GPU нагрузкой
По заявленным данным авторов, SWMA достигает частоты модуляции мощности до 6 000 Гц - на три порядка выше колебаний от бытовых нагрузок (единицы герц для кондиционеров, десятки для промышленного оборудования). Высокочастотные модуляции наиболее опасны для инверторов DER, где петли управления работают на сопоставимых частотах.
LTMA: манипуляция GPU нагрузкой под маской обучения LLM
LTMA (LLM Training Modulation Attack) - более изощрённый вектор. Вместо явного чередования нагрузки атакующий встраивает модуляционную логику в стандартный пайплайн обучения нейросети. Distributed training по своей природе создаёт колебания: вычислительно-интенсивная фаза (forward/backward pass) сменяется фазой синхронизации градиентов (all-reduce), где GPU ждут данных от сети. Этот паттерн описан и в исследовании Microsoft Research "Power Stabilization for AI Training Datacenters": десятки тысяч GPU в синхронном тренировочном задании создают значительные колебания мощности.Атакующий усиливает естественный паттерн, подбирая размер мини-батча, количество GPU в distributed training и параметры синхронизации так, чтобы результирующая частота колебаний мощности попала в резонансный диапазон энергоинфраструктуры. С точки зрения облачного провайдера нагрузка выглядит как обычная тренировка - ни аномальных системных вызовов, ни подозрительных паттернов утилизации. Малозаметность LTMA значительно выше, чем у SWMA: легитимный тренировочный workload неотличим от атаки без анализа частотного спектра энергопотребления.
Требования к окружению для воспроизведения обоих векторов: минимум 2 GPU (NVIDIA Volta и новее, compute capability >= 7.0, включая Turing/Ampere/Hopper) с поддержкой
__nanosleep, введённой в PTX ISA 6.3 / CUDA 10 для sm_70+; CUDA Toolkit >= 10.0 (рекомендуется 11+ для Ampere/Hopper); для LTMA дополнительно PyTorch >= 2.0 с NCCL backend; мониторинг потребления через nvidia-smi --query-gpu=power.draw --format=csv -l 1 или NVML API.Дестабилизация энергосети ЦОД: от гармоник до каскадного отказа
Чтобы понять, как вычислительная модуляция транслируется в физический ущерб, стоит проследить путь тока от utility до GPU.
Электричество от grid поступает через трансформаторную подстанцию, проходит через UPS двойного преобразования (AC-DC-AC), распределяется через PDU по стойкам. Каждый GPU-сервер содержит импульсные блоки питания (PSU) - финальное AC-DC преобразование. Параллельно всё больше ЦОД используют on-site renewable energy - солнечные панели и ветрогенераторы, подключённые через инверторы. По данным OPAL-RT, DER-инверторы оперируют на частотах, критичных для grid stability, и их взаимодействие с нелинейными нагрузками GPU-кластеров создаёт потенциал для резонанса.
Согласно импедансному анализу в препринте Zhou et al. (arXiv ID не верифицирован), при высокой доле DER (90%) в локальной сети ЦОД модуляция нагрузки GPU-кластера взаимодействует с петлями управления инверторов. Заявленные результаты для синхронизированной модели наихудшего случая: при модуляции 1 000 GPU в сети 1 МВт current THD достигает 46.8% - RMS гармонических составляющих тока составляет ~47% от фундаментальной. Это увеличивает потери I^2R в проводниках примерно на 22% и вызывает дополнительный нагрев трансформаторов. Коэффициент демпфирования падает до -0.27 - нестабильная мода.
Цепочка физических последствий: повышенный THD -> перегрев трансформаторов и нейтральных проводников -> отрицательное демпфирование -> автоколебания напряжения -> выход параметров за допуск IEEE 519 -> срабатывание защитных автоматов -> сброс нагрузки -> скачок обратной мощности. В экстремальном смоделированном сценарии - каскадный отказ в распределительной сети. Авторы отмечают, что блэкаут может затронуть более 80% системы передачи, но подчёркивают: это симулированный наихудший случай, не полевой эксперимент.
Чем OT-инфраструктура питания ЦОД отличается от IT-среды
Энергосистема ЦОД - OT-среда со всеми вытекающими ограничениями. Системы управления питанием используют Modbus RTU/TCP: FC03 (Read Holding Registers) для чтения показаний напряжения, тока и мощности; FC06/FC16 (Write Single/Multiple Registers) для управления порогами переключения ATS и параметрами UPS. SNMP v2c/v3 - для опроса PDU. DCIM-платформы агрегируют телеметрию, но типичная частота опроса - секунды, не миллисекунды.В IT-инфраструктуре патчинг - рутина. В OT - совсем другая история. Среднее время между публикацией CVE и устранением составляет 29 месяцев (IBM X-Force 2025). Для OT-оборудования ЦОД этот срок зачастую ещё больше. Показательный пример - CVE-2024-2617 в контроллерах Hitachi RTU500 (серия версий прошивки 12.6.6.0–13.5.2.0): обход механизма secure update позволяет загрузить неподписанную прошивку при наличии аутентифицированного доступа с высокими привилегиями (CVSS 7.2, HIGH; вектор CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H; CWE-358 - Improperly Implemented Security Check for Standard). Аутентифицированный доступ к OT-оборудованию - и можно лить неподписанную прошивку через штатные интерфейсы.
Стандартные IT-средства защиты - EDR, SIEM, сетевые файрволы - не видят высокочастотные колебания мощности на шине питания. OT-мониторинг, даже через Modbus FC03 опрос регистров, работает на частотах, недостаточных для детектирования SWMA-модуляций. UPS дестабилизация дата-центра через workload-модуляцию попадает в мёртвую зону между IT и OT мониторингом. Это фундаментальная проблема безопасности электропитания ЦОД.
Обратная связь Watt2Bit: отказ вычислений и утечка данных
Авторы описывают потенциальный механизм обратной связи - Watt2Bit. Если модуляция нагрузки вызывает колебания напряжения на шине питания, эти колебания бьют по вычислительному оборудованию в том же ЦОД.Скачки напряжения приводят к ошибкам в GPU-памяти (ECC-ошибки, bit-flips), прерывают тренировку моделей, запускают перезагрузку серверов и переход UPS в bypass-режим. Для крупных AI-тренировок потеря синхронизации даже одного GPU-узла может откатить десятки минут обучения. При каскадном сбое - часы вычислительного времени и потеря checkpoint-данных. Получается самоусиливающаяся петля: начальная модуляция вызывает нестабильность, нестабильность вызывает дополнительные сбросы нагрузки, сбросы создают новые скачки - цикл нарастает до срабатывания аварийной защиты.
Второй аспект - covert exfiltration через EMI side channel. Колебания тока создают электромагнитное излучение, которое теоретически может быть считано за пределами ЦОД. Канал крайне низкоскоростной, но для экс-фильтрации криптографических ключей или коротких токенов его может хватить. Энергопотребление GPU превращается в уязвимость двойного назначения: и вектор атаки на инфраструктуру, и потенциальный канал утечки.
Ограничения атаки Bit2Watt и факторы эффективности
Результаты Zhou et al. получены в синхронизированной модели наихудшего случая. Между моделью и реальностью - дистанция, и её стоит оценить трезво.Синхронизация. Для максимального эффекта все модулируемые GPU должны переключать нагрузку синфазно. В распределённом облачном окружении timing jitter между узлами (десятки-сотни микросекунд на уровне NIC-to-NIC latency) частично десинхронизирует модуляцию и снижает амплитуду колебаний. Авторы анализируют эффект jitter (Appendix C препринта), но количественное снижение эффективности зависит от конкретной сетевой инфраструктуры и топологии размещения.
Доля DER. THD 46.8% и отрицательное демпфирование получены при 90% DER - сценарий, пока не типичный для большинства ЦОД. При доминировании utility grid (синхронные генераторы) демпфирование системы значительно выше, и эффект модуляции ослабевает. Но тренд на увеличение on-site solar и battery storage в ЦОД гиперскейлеров движется именно к повышению DER-доли.
Масштаб доступных ресурсов. 1 000 GPU в рамках одного 1-МВт сегмента - несколько десятков стоек при нагрузке 50-70 кВт на стойку для AI-кластеров. Атакующему нужно арендовать существенную долю мощности одного физического сегмента энергосети. Политики размещения провайдера (tenant isolation, spread placement groups) могут распределить GPU атакующего по разным PDU-фидерам, снижая когерентность воздействия.
Warp scheduling. Механизм
__nanosleep работает на уровне warp. Если на GPU одновременно крутятся задачи других тенантов (MIG partition, time-sliced sharing), планировщик заполнит освободившиеся SM чужими warps. В shared-tenancy окружениях эффективность SWMA деградирует пропорционально объёму посторонней нагрузки.Эволюция мониторинга. Стандартный cloud-side мониторинг Bit2Watt не детектирует, но некоторые провайдеры начинают внедрять power telemetry на уровне GPU через NVML API. Аномальный периодический паттерн
power.draw с устойчивой частотой > 10 Гц на группе GPU - потенциальный IoC для этого класса атак.Контрмеры: кросс-слойная защита безопасности электропитания ЦОД
Авторы Bit2Watt прямо указывают на необходимость cross-layer defenses - защитных мер, объединяющих облачный, facility и grid уровни. Ниже - чеклист для передачи инженерным командам.Уровень облака (Compute/Cloud):
- Внедрить мониторинг частотного спектра энергопотребления GPU через NVML (
nvmlDeviceGetPowerUsage) с семплированием не реже 100 Гц - стандартный DCIM этого не обеспечивает - Настроить детектирующее правило: периодические осцилляции мощности с устойчивой частотой > 10 Гц на кластере > 100 GPU - индикатор SWMA
- Ввести политику размещения: не допускать co-location GPU одного тенанта на > 50% мощности одного PDU-сегмента (на уровне orchestrator / placement groups)
- Активировать GPU Power Capping (
nvidia-smi -pl <watts>) для ограничения амплитуды возможной модуляции на managed кластерах
- Установить power quality analyzer на входе каждого PDU-фидера с частотой дискретизации >= 10 кГц (Dranetz, Fluke 1770 или аналоги)
- Настроить алерты на THD напряжения > 5% по PDU-фидеру для систем <1 кВ (IEEE 519-2014, Table 1) и на TDD тока > 5-20% в зависимости от Isc/IL ratio (IEEE 519-2014, Table 2)
- Мониторить power factor в реальном времени: падение PF ниже 0.9 при стабильной заявленной нагрузке - индикатор гармонических искажений
- Для ЦОД с DER > 30%: провести impedance scan в диапазоне 100 Гц - 10 кГц для выявления резонансных частот локальной сети
- Внедрить active harmonic filtering на инверторах DER
- Рассмотреть battery energy storage systems (BESS) как буфер между DER и нагрузкой - сглаживает высокочастотные колебания
Bit2Watt высвечивает проблему, о которой пока мало кто говорит вслух: современные ЦОД - это кибер-физические системы, где вычислительный и энергетический слои связаны физической петлёй обратной связи, а не только сетевыми протоколами. Ни SOC, ни инженеры электроснабжения не мониторят частотный спектр тока на PDU-шине. Для SOC это "не их зона ответственности", для facility-инженеров стандартный инструментарий слишком медленный. Между двумя картинами мира - мёртвая зона шириной в несколько порядков частоты.
Самое неприятное в Bit2Watt - не конкретные цифры THD и damping из модели наихудшего случая (в реальности они неизбежно ниже). Неприятно другое: атака использует штатный API облачной платформы, формально не нарушает условий пользовательского соглашения и невидима для всех существующих систем мониторинга одновременно. GPU-кластеры растут до десятков тысяч GPU на сайт, доля on-site renewable energy увеличивается - и вопрос "кто отвечает за THD на PDU-шине - cloud team, facility team или security?" перейдёт из академической плоскости в плоскость инцидент-респонса. Пока на него нет ответа, эта поверхность атаки будет расширяться.
Последнее редактирование модератором:
