💡Совет Linux

Случайно удалил файл и не понимаешь, что именно пропало?

Попробуй проверить недавние изменения:

find ~/ -type f -mtime -1

Команда покажет файлы в домашней директории, которые менялись за последние 24 часа.

Важно: она не восстановит удалённые файлы. Но поможет быстро понять, что недавно редактировалось, какие файлы могли быть затронуты и где искать следы ошибки.

Полезно, когда нужно разобраться после случайного удаления, неудачного скрипта или странного поведения программы.

Как найти бэкдор на своём ПК: 6 шагов проверки

Бэкдор может месяцами сидеть в системе незаметно. Показываю 6 шагов, как проверить свой ПК самому: автозагрузка, процессы и сеть, службы и планировщик, полное сканирование, удалённый доступ. Если что-то странное, меняй пароли и проверяй систему офлайн.

#бэкдор #кибербезопасность #взлом #безопасность

Нашли готовую виртуальную машину для OSINT-исследований — Trace Labs OSINT VM.

Это не «магическая пробивалка», а отдельная рабочая среда для легального поиска по открытым источникам: CTF, фактчекинг, расследования, поиск цифровых следов и обучение OSINT.

Что внутри:

* Sherlock — поиск аккаунтов по username
* PhoneInfoga — анализ открытых данных по номерам
* SpiderFoot и sn0int — автоматизация OSINT-проверок
* theHarvester и h8mail — работа с email и утечками
* Shodan CLI — поиск по открытым интернет-устройствам
* Sublist3r — поддомены
* exiftool и steghide — метаданные и стеганография
* Obsidian — заметки прямо во время исследования

Главный плюс - всё уже собрано в изолированной VM, не нужно засорять основную систему десятками инструментов.

Подходит для обучения, CTF и легальных расследований по открытым данным.

https://github.com/tracelabs/tlosint-vm

SearchPhone -инструмент для анализа телефонных номеров

Полезная находка для легальных расследований, threat intelligence и проверки цифровых следов по открытым источникам.

SearchPhone автоматизирует сбор данных по номеру телефона и собирает результат в отчёт.

Что умеет:

* проверка и форматирование номера
* поиск оператора и геоданных через Numverify
* поиск упоминаний через Google, Bing и DuckDuckGo
* поиск номера в GitHub-коде
* поиск обсуждений на Reddit
* генерация JSON и PDF-отчётов
* параллельный поиск по нескольким источникам
* простой CLI-интерфейс на Python

Важно: это инструмент для работы с открытыми данными и легальных проверок, а не для сталкинга или «пробива» людей.

🔗 https://github.com/HackUnderway/SearchPhone

#OSINT #CyberSecurity #Python #OpenSource #GitHub #ThreatIntelligence #InfoSec

Trusted Publishing звучит так, будто пакет стал безопасным.

На деле это не так.

Trusted Publishing убирает долгоживущий токен из CI и заменяет его коротким OIDC-токеном. Это сильнее, чем хранить секрет в GitHub Actions, но доверие никуда не исчезает. Оно просто переезжает в другое место.

Теперь критичны:

* кто имеет доступ к репозиторию
* кто может менять workflow
* какие third-party actions подключены
* защищены ли tags и release branches
* используется ли protected environment
* зафиксированы ли actions по SHA

Если атакующий получил возможность изменить release workflow, registry увидит “правильный” OIDC-запрос и выдаст токен на публикацию. С точки зрения системы всё будет выглядеть легитимно.

Она защищает от украденных PyPI/npm токенов, но не защищает от скомпрометированного CI, слабых permissions и дырявого release process.

Для нормального supply chain security нужны ещё protected environments, минимальные права, pinning зависимостей, контроль workflow, подписи артефактов и provenance.

Не надо путать “опубликовано через trusted workflow” с “этому пакету можно доверять”.

https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing

⚡️ Mail.ru и Одноклассники тоже удалили из Google Play вслед за VK. Max тоже пропал из российского Google Play

До этого он также исчез из магазинов других регионов.

UPD. Исчез теперь и VK.

VK экстренно переходит на домен .ru — пользователям массово приходят уведомления.

По данным СМИ, одной из причин стали риски, связанные с доменом vk.com, который находится в международной доменной зоне и потенциально может попасть под ограничения или быть недоступен для компании из-за санкций.

Линус Торвальдс не поддержал запрет AI-кода в Linux.

ИИ - это инструмент. Такой же, как компилятор, статический анализатор или IDE. Неважно, писал разработчик код вручную или использовал ассистента. Важно, что получилось в итоге.

Плохой патч отклонят, даже если его написал человек.
Хороший патч могут принять, даже если помогала модель.

Но ответственность переложить на AI не получится.

Разработчик должен сам проверить сгенерированный код, убедиться в соблюдении лицензий и поставить собственный Signed-off-by. AI-агент не имеет права делать это за человека. Использование модели также рекомендуется отмечать через Assisted-by.

Правило осталось прежним: присылай качественный код и будь готов за него отвечать.

https://opennet.ru/65913/

C2 без сервера, домена и открытых портов - теперь прямо внутри GitHub

Появился OctoC2 - GitHub-native C2 framework, где весь трафик идёт через api.github.com по HTTPS. Без VPS, кастомных доменов и listening server. Для сети это может выглядеть как обычная активность разработчика или CI/CD.

По README, OctoC2 использует несколько каналов внутри возможностей GitHub, поддерживает fallback между ними и шифрование payload’ов. Проект прямо помечен как инструмент только для authorized red-team и security research.

GitHub-трафик нельзя считать безопасным просто потому, что это GitHub.

Что стоит мониторить:

* странные паттерны запросов к GitHub API
* неожиданные GitHub tokens на машинах
* необычную активность private repos
* подозрительную CI/CD-активность
* долгоживущие процессы, которые постоян

github.com/dstours/OctoC2

#redteam #infosec #C2 #Hacking

`O_DIRECT`: когда база данных обходит page cache

В Linux флаг O_DIRECT позволяет читать и писать файл почти напрямую, минуя page cache ядра.

Зачем это нужно базам данных?

У PostgreSQL, MySQL, RocksDB и других систем часто уже есть свой buffer pool.
Если ещё и ядро будет кэшировать те же страницы, получится двойное кэширование и лишняя трата памяти.

Но у O_DIRECT есть неприятное условие: всё должно быть выровнено по блоку.

• buffer
• file offset
• размер чтения / записи

Например, под 4 KB блоки нельзя просто так прочитать 123 байта в любой `malloc`-буфер.
Промахнулся с alignment — read() вернёт EINVAL.

Именно поэтому низкоуровневый I/O в базах выглядит таким странным: там важны не только данные, но и то, как они лежат в памяти.

Автономный ИИ-агент взломал Hugging Face, а закрытые модели не смогли помочь расследованию

Hugging Face раскрыла инцидент, который хорошо показывает будущую асимметрию кибербезопасности.

Атака началась с вредоносного датасета, эксплуатировавшего два пути выполнения кода в системе обработки данных. Затем автономный агент получил доступ к нодам, собрал облачные и кластерные учётные данные и перемещался между внутренними кластерами.

За одни выходные система выполнила тысячи действий через краткоживущие sandbox-среды. В журналах осталось более 17 000 событий.

Самая показательная часть началась во время расследования. Команда Hugging Face попыталась анализировать реальные эксплойты, команды и C2-артефакты с помощью передовых моделей через коммерческие API, но safety-фильтры блокировали запросы.

Модели не смогли отличить работу специалиста по реагированию на инциденты от действий атакующего.

В итоге анализ перенесли на самостоятельно размещённую open-weight модель GLM 5.2. Это позволило изучать вредоносный код без блокировок и не отправлять журналы, данные атакующего и упомянутые credentials внешнему провайдеру.

Возникает опасная асимметрия:

- атакующие запускают агентов без ограничений;
- защитники могут столкнуться с блокировками именно в критический момент;
- чувствительная телеметрия не всегда должна покидать инфраструктуру компании.

У команды безопасности должна быть заранее подготовленная модель, которую можно запустить локально и использовать во время реального инцидента.

Автономные кибератаки уже перестали быть сценарием из презентаций. Теперь вопрос в том, готовы ли защитные инструменты работать с той же скоростью.

https://huggingface.co/blog/security-incident-july-2026

#ai #cybersecurity #opensource #llm #huggingface

@linuxkalii

Fugu-Cyber: ИИ-оркестратор для задач киберзащиты

Sakana AI представила обновление своей системы Fugu - специализированную модель Fugu-Cyber для анализа реальных задач информационной безопасности.

По данным компании, модель показала:

- 86,9% успешных решений на CyberGym
- 72,1% на CTI-REALM
- результаты на уровне GPT-5.5-Cyber и Mythos Preview

CyberGym проверяет способность находить и подтверждать уязвимости в сложных кодовых базах, а CTI-REALM — превращать отчёты об угрозах в рабочие правила обнаружения.

Fugu-Cyber работает как одна модель, но внутри динамически координирует несколько специализированных ИИ-агентов. Пользователь отправляет запрос в единый API, а система сама распределяет многоэтапную задачу между агентами.

При этом Sakana AI подчёркивает: высокая оценка на бенчмарке ещё не делает модель готовой системой защиты. Для работы в реальной инфраструктуре нужны эксперты, интеграция с внутренним кодом и обязательная проверка результатов человеком.

https://sakana.ai/fugu-cyber-release

#ai #cybersecurity #llm #agents #sakanaai

BPFDoor: бэкдор, который может обойти firewall

BPFDoor - скрытный Linux-бэкдор, который связывают с китайскими APT-группами и атаками на телеком-инфраструктуру.

Он подключается к raw-сокету и анализирует входящие пакеты до того, как их обработают правила iptables или nftables. Поэтому корректно настроенный firewall сам по себе не гарантирует защиту.

Бэкдор не открывает постоянный порт и большую часть времени никак себя не выдаёт. Для активации атакующий отправляет специально сформированный пакет, после чего BPFDoor может установить обратное соединение и предоставить удалённый доступ к системе.

Обычный скан портов здесь мало поможет. При проверке стоит обращать внимание на подозрительные raw-сокеты, активные BPF-фильтры, замаскированные процессы и необычные исходящие соединения.

В статье разобраны устройство BPFDoor и способы его обнаружения:

https://hackers-arise.com/compromising-telecom-systems-deploying-and-detecting-the-bpfdoor-backdoor/

#cybersecurity #linux #infosec #telecom

Kimi K3 за 27 минут нашла RCE в Redis и собрала рабочий эксплойт 😨

Рой из 32 ИИ-агентов обнаружил уязвимость, которая после авторизации позволяла выполнять произвольный код на сервере.

Через несколько часов система якобы нашла ещё и цепочку атаки на Telegram Desktop и iOS без действий пользователя: через повреждённый видеофайл с автозагрузкой. До полноценного RCE оставался один шаг.

Если результаты подтвердятся, поиск критических уязвимостей ускорился до пугающего уровня.

github.com/berabuddies/redis-poc

@data_analysis_ml

TIME_WAIT в Linux годами объясняют неправильно

Я полез в исходники Linux TCP и снова наткнулся на старый сетевой миф.

В коде TIME_WAIT фактически зафиксирован на 60 секунд:
#define TCP_TIMEWAIT_LEN (60 * HZ)
Его нельзя настроить отдельно для сокета.

И да, tcp_fin_timeout, который часто советуют крутить в блогах, не управляет TIME_WAIT.

Он относится к состоянию FIN_WAIT2.

TIME_WAIT задан в исходниках ядра и не вынесен в отдельный sysctl.

Вот так появляются мифы: один параметр звучит похоже, его копируют из статьи в статью, а потом годами лечат не то состояние TCP.