Логічна бомба: що це, як працює і реальні приклади атак
Логічна бомба — це фрагмент шкідливого коду, який може роками непомітно лежати всередині цілком робочої програми і спрацьовує лише тоді, коли виконується закладена умова: настає певна дата, зникає обліковий запис розробника або пристрій опиняється в заданому місці. Саме ця тиша до моменту спрацювання робить логічні бомби небезпечними: антивіруси їх рідко помічають, а шкода часто зʼявляється тоді, коли автора вже давно немає в компанії.
Головне
Логічна бомба — шкідливий код із прихованою умовою спрацювання. На відміну від вірусів і хробаків, сама вона не поширюється.
Часова бомба — різновид логічної, який спрацьовує в заданий день і час.
Найчастіше логічні бомби закладають інсайдери, але дедалі частіше їх ховають у бібліотеках з відкритим кодом і використовують у державних кібератаках.
Захист тримається на контролі доступу, перевірці коду й залежностей, коректному звільненні працівників і резервних копіях.
Що таке логічна бомба
Логічна бомба складається з двох частин: умови, або тригера, і корисного навантаження — дії, яку код виконує після спрацювання. Поки умова не виконана, програма працює як звичайно, тож ні користувачі, ні адміністратори не бачать жодних ознак проблеми.
Головна відмінність від інших видів шкідливого ПЗ полягає в тому, що логічна бомба не розмножується. Вірус заражає файли, хробак поширюється мережею, а бомба просто чекає. Водночас вона може бути частиною іншої загрози: трояни і вайпери — програми для знищення даних — часто містять вбудований таймер чи іншу умову запуску.
Ще одна обовʼязкова ознака — прихованість від власника системи. Пробна версія застосунку, яка відкрито перестає працювати через 30 днів, логічною бомбою не є: користувача про це попереджають заздалегідь. Бомбу ж закладають таємно і з наміром завдати шкоди.
Логічна бомба, часова бомба і kill switch: у чому різниця
Ці терміни часто вживають як синоніми, хоча вони означають різне.
Логічна бомба у широкому сенсі — будь-який прихований шкідливий код з умовою спрацювання: дата, подія в системі, відсутність очікуваної події, місцезнаходження пристрою.
Часова бомба (time bomb) — логічна бомба, умовою якої є дата або час. Саме так називають шкідливі програми з відкладеним у часі запуском.
Kill switch («аварійний вимикач») у легітимному значенні — механізм, що зупиняє систему в надзвичайній ситуації. У справах про саботаж так називають бомбу, яка спрацьовує, коли її автора відключають від системи, наприклад після звільнення.
Як спрацьовує логічна бомба
Умовою може стати майже будь-що, що здатна перевірити програма. На практиці найчастіше трапляються такі тригери:
Дата і час. Бомба «прокидається» в конкретний день, іноді — у визначену хвилину.
Подія з обліковим записом. Видалення користувача з каталогу, блокування доступу, відсутність входу протягом певного часу.
Відсутність дії. Код не отримав очікуваного підтвердження — наприклад, ніхто не ввів «код розблокування».
Стан пристрою або середовища. GPS-координати, наявність певного файлу, мережа, до якої підключений компʼютер.
Випадковість. Шкідлива дія виконується лише з певною ймовірністю, щоб збої виглядали як звичайні програмні помилки.
Після спрацювання бомба може видаляти файли й бази даних, перезаписувати завантажувальні записи дисків, блокувати вхід до системи, непомітно псувати дані або просто аварійно завершувати роботу програми.
Хто і навіщо закладає логічні бомби
Класичний автор логічної бомби — інсайдер: програміст, адміністратор чи підрядник, який має доступ до коду та інфраструктури. Мотиви різні: помста за звільнення чи пониження, бажання заробити на падінні акцій компанії або гарантувати собі подальші замовлення.
Останніми роками до інсайдерів додалися ще дві групи. Кіберзлочинці ховають бомби з відкладеним запуском у пакетах з відкритим кодом, які розробники самі встановлюють у свої проєкти. Державні хакерські угруповання використовують таймери у вайперах, щоб синхронно знищити дані одразу в багатьох системах.
Відомі випадки атак із логічними бомбами
UBS PaineWebber, 2002
Системний адміністратор Роджер Дуроніо, незадоволений розміром річної премії, звільнився з UBS PaineWebber і заклав логічну бомбу приблизно в 1000 із 1500 компʼютерів у філіях компанії. 4 березня 2002 року о 9:30, на відкритті торгів, код почав видаляти файли. Паралельно Дуроніо купив опціони, розраховуючи заробити на падінні акцій UBS, але курс не змінився. Збитки компанії перевищили 3 млн доларів, а суд призначив Дуроніо 97 місяців увʼязнення.
Fannie Mae, 2008
UNIX-інженера Раджендрасінха Маквану, який як підрядник обслуговував мережу іпотечного агентства Fannie Mae, звільнили 24 жовтня 2008 року — і того ж дня він передав шкідливий скрипт на сервери компанії. Код мав спрацювати 31 січня 2009 року, поширитися мережею майже з 5000 серверів і знищити всі дані, зокрема фінансову та іпотечну інформацію. Через пʼять днів після звільнення скрипт помітив старший інженер агентства. Маквану засудили до 41 місяця увʼязнення.
Південна Корея, 2013
20 березня 2013 року приблизно о 14:00 майже одночасно вийшли з ладу мережі трьох банків — Shinhan, NongHyup і Jeju — та трьох телемовників — KBS, MBC і YTN. Синхронність пояснювалася логічною бомбою у вайпері: шкідлива програма чекала заданого часу, а потім перезаписувала завантажувальні записи дисків. За оцінкою південнокорейського регулятора, дані було знищено приблизно на 32 тис. систем під керуванням Windows, Unix і Linux. Влада Південної Кореї звинуватила в атаці КНДР.
Siemens, 2014–2016
Підрядник Siemens Девід Тінлі з 2014 по травень 2016 року вбудовував логічні бомби у програми, які сам розробляв для компанії: після певної дати вони починали збоїти. Не знаючи причини, Siemens щоразу зверталася до автора, щоб той усе виправив. У 2019 році Тінлі отримав шість місяців увʼязнення і штраф 7500 доларів.
Eaton, 2019
Розробник Девіс Лу понад десять років працював у компанії Eaton, а після реорганізації 2018 року, яка урізала його обовʼязки й доступ до систем, почав саботувати інфраструктуру роботодавця. Серед іншого він створив kill switch під назвою IsDLEnabledinAD — скорочення від «Is Davis Lu enabled in Active Directory». Код спрацював автоматично 9 вересня 2019 року, коли Лу відправили у відпустку й попросили здати ноутбук, і заблокував доступ тисячам користувачів по всьому світу. У серпні 2025 року суд засудив його до чотирьох років увʼязнення. Мінʼюст США в офіційному повідомленні компанію не назвав — її ідентифікували журналісти.
Україна, 2022: Industroyer2
8 квітня 2022 року угруповання Sandworm, повʼязане з російською військовою розвідкою, спробувало знеструмити один із регіонів України. За даними ESET, яка розслідувала інцидент разом із CERT-UA, шкідливу програму Industroyer2 мали запустити за розкладом о 16:10 UTC, а через десять хвилин на тому самому компʼютері — вайпер CaddyWiper, щоб знищити сліди. Файл Industroyer2 скомпілювали ще 23 березня, тобто атаку готували щонайменше два тижні. Формально це запланована задача, а не бомба, вбудована в легітимний код, але принцип той самий: шкідлива дія чекає заданого часу.
Newag, 2023
Польська група дослідників Dragon Sector, яку найняла незалежна ремонтна компанія SPS, виявила в програмному забезпеченні поїздів Newag Impuls систему «виявлення сторонніх майстерень»: після виконання певних умов потяги переставали рушати, а два з них навіть містили список точних GPS-координат майстерень конкурентів. Дослідники знайшли й недокументований «код розблокування», який вводився з пульта машиніста і миттєво повертав поїзд до роботи. Newag із висновками не погодився і звернувся до суду проти дослідників. Цей випадок показує, що механіку логічної бомби можна використати не лише для саботажу, а й для тиску на конкурентів.
NuGet, 2025: таймер до 2027–2028 років
У листопаді 2025 року компанія Socket повідомила про девʼять шкідливих пакетів у репозиторії NuGet для .NET-розробників. Їх публікував користувач shanhai666 у 2023–2024 роках, а загалом пакети завантажили майже 10 тис. разів. Близько 99 % коду в них були справними й корисними, що допомагало пройти перевірку. Пакети для роботи з SQL Server, PostgreSQL і SQLite після 8 серпня 2027 року або 29 листопада 2028 року мають з імовірністю 20 % аварійно завершувати застосунок під час запиту до бази даних.
Найнебезпечніший пакет, Sharp7Extend, маскувався під розширення бібліотеки Sharp7 для звʼязку з промисловими контролерами Siemens S7. Він починав шкодити одразу після встановлення: випадково обривав роботу застосунку, а через 30–90 хвилин змушував до 80 % команд запису на контролер завершуватися збоєм. На виробництві це може означати, що захисні системи не спрацюють вчасно. Усі пакети вже видалено з NuGet, але проєкти, куди їх встановили раніше, потрібно перевіряти окремо.
Як виявити логічну бомбу
Універсального інструмента немає: до спрацювання бомба поводиться як звичайний код, а готових сигнатур для неї зазвичай не існує, бо кожну пишуть під конкретну ціль. Тому виявлення спирається на кілька практик.
Рецензування коду. Підозрілими є перевірки поточної дати, умови, привʼязані до конкретних облікових записів чи імен, обфускація в невеликих фрагментах, випадкові гілки виконання та виклики, що примусово завершують процес.
Аналіз залежностей. Інструменти аналізу складу ПЗ (SCA) і перелік компонентів (SBOM) допомагають помітити пакети з назвами-двійниками популярних бібліотек і неочікувані зміни у сторонньому коді.
Аудит запланованих задач. Регулярна перевірка Планувальника завдань Windows, cron у Linux і групових політик Active Directory — саме через такі механізми запускали вайпери під час атаки на українську енергетику.
Моніторинг поведінки. Раптові збої без видимої причини, масове видалення файлів, неочікувані зміни прав доступу — привід шукати шкідливий код, а не лише апаратну несправність.
Як захиститися від логічних бомб
Більшість відомих випадків повʼязані з людьми, які мали легальний доступ до систем, тому захист починається з організаційних заходів.
Мінімальні привілеї. Працівник або підрядник отримує лише той доступ, який потрібен для роботи, а адміністративні права перебувають під окремим контролем.
Правило чотирьох очей. Жодна зміна в робочому коді чи скриптах інфраструктури не потрапляє в систему без перевірки іншою людиною.
Коректне звільнення. Доступ відкликають до повідомлення про звільнення або одночасно з ним, а не наприкінці дня: справа Fannie Mae показує, що шкідливий код можна закласти в день звільнення, поки доступ ще активний. Після цього варто переглянути зміни, які людина вносила останнім часом.
Гігієна залежностей. Версії пакетів фіксують, видавців перевіряють, а маловідомих «розширень» популярних бібліотек уникають.
Резервні копії. Регулярні копії, принаймні одна з яких зберігається окремо від основної мережі, дають змогу відновитися навіть після знищення даних.
Для звичайних користувачів ризик здебільшого непрямий: логічна бомба може ховатися в програмі, сервісі чи пристрої, яким вони користуються. Тут допомагають базові правила — встановлювати застосунки лише з офіційних джерел, вчасно оновлювати систему і регулярно робити резервні копії важливих файлів.
Висновок
Логічна бомба — одна з найстаріших кіберзагроз, але застарілою її не назвеш. Змінився лише масштаб: від скриптів, які ображені адміністратори ховали на серверах роботодавців, до пакетів з таймером, що чекають 2027–2028 років у чужих проєктах, і запланованих атак на енергосистему. Захист від неї тримається на тих самих принципах, що й кібербезпека загалом: обмеженому доступі, перевірці коду і резервному копіюванні.
Ця стаття Логічна бомба: що це, як працює і реальні приклади атак раніше була опублікована на сайті CyberCalm, її автор — Наталя Зарудня
