👾 Вышли новые версии свободных загрузочных прошивок Libreboot 25.04 и Canoeboot 25.04. Эти проекты предоставляют полностью открытую альтернативу проприетарным BIOS/UEFI, исключая закрытые компоненты, такие как Intel ME.

В последнем релизе Libreboot появилась поддержка плат Acer Q45T-AM/G43T-AM3, обновлены инструменты сборки (Debian 12.10, GCC 15) и другие компоненты. Canoeboot, являясь более строгой версией, убирает все бинарные вставки и поддерживает лишь ограниченный список устройств — от старых ThinkPad до PlayStation 1.

🔗 Ссылка - *клик* (https://libreboot.org/news/libreboot2504.html)

@linux_education

# 🔐 Современный алгоритм шифрования: AES

В наше время защита данных — это не просто дополнительная опция, а обязательное условие. От безопасности банковских операций до сохранения паролей — всё основано на надёжных алгоритмах.

Одним из самых распространённых и надёжных стандартов сегодня является AES (Advanced Encryption Standard).

💡 Что собой представляет AES?

AES — это симметричный блочный алгоритм шифрования.

- Для шифрования и расшифровки используется один и тот же ключ.
- Информация обрабатывается блоками фиксированной длины (обычно 128 бит).

Стандарт AES был принят в 2001 году и по-прежнему считается надёжным при корректном применении.

📏 Размер ключа

AES поддерживает ключи следующих размеров:

- 128 бит (16 байт)
- 192 бит (24 байта)
- 256 бит (32 байта)

Чем длиннее ключ, тем выше уровень защиты от взлома.

Как работает AES?

1. Информация разбивается на блоки по 128 бит.
2. Каждый блок проходит через несколько этапов шифрования:
- Замена байтов
- Перемешивание строк
- Перемешивание столбцов
- Наложение ключа
3. Количество таких этапов зависит от длины ключа:
- 128 бит — 10 раундов
- 192 бит — 12 раундов
- 256 бит — 14 раундов

В отличие от DES, AES не применяет перестановку бит, а работает с байтами и матрицами.

🐍 Пример использования AES на Python

Для работы с AES можно использовать библиотеку PyCryptodome:

```python
from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes
from Crypto.Util.Padding import pad, unpad

# Создаём случайный ключ длиной 16 байт
key = get_random_bytes(16)

# Инициализируем AES в режиме CBC (Cipher Block Chaining)
cipher = AES.new(key, AES.MODE_CBC)

# Данные для шифрования
data = b"Hello, this is a secret message!"

# Дополняем данные до размера, кратного 16
padded_data = pad(data, AES.block_size)

# Шифруем данные
encrypted_data = cipher.encrypt(padded_data)

print("Зашифрованные данные:", encrypted_data)

# Для расшифровки нужно сохранить IV (инициализационный вектор)
iv = cipher.iv

# Расшифровка
cipher_dec = AES.new(key, AES.MODE_CBC, iv)
decrypted_data = unpad(cipher_dec.decrypt(encrypted_data), AES.block_size)

print("Расшифрованные данные:", decrypted_data.decode())
```

✅ Важно помнить:

key — это секретный ключ, который надо хранить в тайне.

iv (инициализационный вектор) необходим для расшифровки и может передаваться открыто.

Используется дополнение (padding), чтобы длина текста была кратной размеру блока.

🔍 Почему стоит выбрать AES?
Он надёжен — на данный момент не существует известных эффективных атак.

Работает быстрее, чем DES и 3DES.

Поддерживается во всех современных протоколах (TLS, SSH, VPN, ZIP, WhatsApp).

⚠️ Рекомендации по безопасности
Никогда не применяйте один и тот же ключ и IV для разных сообщений.

Храните ключи в надёжных местах.

При передаче данных используйте безопасные протоколы.

➡️ AES — это эталон симметричного шифрования. Его используют повсеместно: от HTTPS и VPN до мессенджеров. С помощью Python и библиотеки PyCryptodome его легко внедрить в свои проекты.

@linux_education

🧩 Задача для Linux-администраторов: "Исчезающий процесс"

📖 Описание задачи

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

Особенности:

- Бинарный файл процесса каждый раз появляется в разной папке внутри /tmp.
- Имя процесса каждый раз меняется (например, a1b2c3, d4e5f6).
- При запуске процесс слушает TCP-порт на случайном высоком порту (больше или равен 1024).
- Порт выбирается динамически и кодируется в base64, чтобы усложнить прямое определение.
- Бинарный файл зашифрован и расшифровывается процессом в оперативной памяти до запуска.
- После удаления файла и завершения процесса через 10 минут процесс появляется снова.

📝 Ваша задача:

1. Определить источник "возрождения" процесса.
2. Найти механизм автозапуска и способ зашифрованного хранения бинарного файла.
3. Остановить автоматический запуск навсегда без перезагрузки системы.
4. Описать шаги поиска и устранения проблемы.

🕵️ Решение (поэтапный разбор)

1️⃣ Найти процесс и порт

Поскольку порт зашифрован в base64, стандартные команды ss или netstat покажут открытый порт, но не его исходное имя:

ss -tulpn | grep LISTEN

Запомнить PID и порт. Для проверки порта в base64 можно использовать:

echo | base64

(зашифрованный порт в коде процесса может совпадать)

2️⃣ Посмотреть открытые файлы и дескрипторы

Чтобы определить, где находится исполняемый файл:

lsof -p

Обратить внимание на дескрипторы в /tmp/, /dev/shm/, /proc/self/fd/.

Если исполняемый файл удалён, но процесс его держит открытым, можно восстановить его из /proc//exe:

cp /proc//exe ./restored_binary

3️⃣ Отследить родительский процесс

Проверить родительский процесс:

ps -o pid,ppid,cmd -p
pstree -p

➡️ Нужно выяснить, кто создаёт зашифрованный бинарник и запускает процесс.

4️⃣ Отследить создание файла в /tmp

Использовать auditd или inotifywait для фиксации момента создания файла:

auditctl -w /tmp -p wa
ausearch -f /tmp

или

inotifywait -m /tmp

Когда файл появится, посмотреть, какой процесс его записал:

lsof | grep /tmp/

5️⃣ Проверить автозагрузку

Проверить cron:

crontab -l
cat /etc/crontab
ls -l /etc/cron.*

Проверить systemd:

systemctl list-timers --all
systemctl list-units --type=service
systemctl list-units --type=timer

Проверить init.d, rc.local, profile.d:

ls -l /etc/init.d/
cat /etc/rc.local
ls -l /etc/profile.d/

6️⃣ Проанализировать процесс запуска

Поскольку шифрование происходит в памяти:

- Проверить аргументы запуска процесса через ps aux
- Использовать strace для отслеживания системных вызовов:

strace -f -p

- Проверить, не использует ли процесс memfd_create, shm_open, mmap для хранения бинарника в памяти:

lsof -p | grep memfd

📝 Возможное объяснение

- Основной процесс шифрует бинарник и хранит его, например, в `/etc/.hidden/enc.bin`.
- Через cron или systemd timer каждые 10 минут запускается дешифровщик, который:
- Расшифровывает бинарник в /tmp
- Запускает процесс
- Запущенный процесс открывает порт, кодирует его номер в base64 и хранит только в своих аргументах или переменных окружения.
- Процесс удаляет бинарник сразу после запуска, оставляя только дескриптор в памяти.

✅ Как остановить навсегда (без перезагрузки):

1. Найти и завершить родительский процесс (watchdog/дешифровщик):

kill -9

2. Удалить механизм автозапуска:

- Удалить запись из cron.
- Выполнить systemctl disable
- Удалить файлы-инициаторы из /etc/systemd/system/, /etc/init.d/, /etc/rc.d/.

3. Найти и удалить зашифрованный бинарник:

find / -type f -name '*.bin' -exec file {} \; | grep 'data'

или поиск по дате изменения:

find / -type f -mtime -1

4. Очистить /tmp, /dev/shm, /run от временных файлов.

@linux_education

🔍 Linkook — это инструмент OSINT для поиска связанных аккаунтов

Linkook представляет собой мощный инструмент, который автоматически находит связанные аккаунты в социальных сетях и связанные email по одному username. Он полезен для OSINT-расследований, аудита и мониторинга цифрового следа.

▪ Основные функции
• Поиск аккаунтов по заданному username на большом количестве популярных платформ
• Рекурсивное выявление альтернативных никнеймов и связанных аккаунтов
• Проверка email на утечки через базу данных HudsonRock’s Cybercrime Intelligence или API Have I Been Pwned
• Экспорт данных в формате JSON (поддерживается Neo4j для визуализации графа связей)

▪ Установка

# Быстрая установка через pipx
pipx install linkook

# Либо установка из исходников
git clone https://github.com/JackJuly/linkook
cd linkook
python setup.py install

▪ Быстрый старт и основные опции



linkook
• --show-summary — показывает сводку после завершения сканирования
• --concise — выводит краткую информацию
• --check-breach — проверяет email через базу HudsonRock (отмечает «(breach detected)»)
• --hibp — проверка через Have I Been Pwned (требуется API-ключ)
• --neo4j — экспортирует данные в neo4j_export.json для Neo4j
• Другие: --silent, --scan-all, --print-all, --no-color, --browse, --debug, --output, --local, --version, --update

▪ Чем Linkook отличается от Sherlock?
В отличие от Sherlock, который ищет аккаунты только по точному совпадению username, Linkook:
• Автоматически находит связанные аккаунты даже при изменении никнеймов
• Собирает взаимосвязи между аккаунтами и email
• Поддерживает экспорт в Neo4j для создания графов связей и глубокого анализа

▪ Технические детали
• Язык: Python (100%)
• Лицензия: MIT
• Текущая версия: v1.1.2 (5 марта 2025)
• GitHub: ★ 693 Форков 69

🔗 GitHub (https://github.com/JackJuly/linkook)

@linux_education

🐧 Задача-ловушка: Почему служба не видит обновлённый файл?

Условие:

Вы изменили конфигурационный файл для популярного сервиса (например, `nginx`), поменяв несколько параметров. После этого вы перезапустили сервис:

systemctl restart nginx

Но, несмотря на рестарт, сервис продолжает использовать старые настройки из прежнего конфига, хотя при проверке:

cat /etc/nginx/nginx.conf

видно, что файл действительно обновлён.

Вы проверили права доступа, синтаксис конфигурации (команда `nginx -t` показывает OK), SELinux, AppArmor — всё в порядке.

❓ Вопрос:
Что могло произойти? Почему сервис использует старый конфиг, хотя файл обновлён и процесс был перезапущен?

---

🔍 Подсказка:

Недавно на сервере был выполнен атомарный деплой конфигурации с помощью команды:

mv /tmp/new_nginx.conf /etc/nginx/nginx.conf

---

✅ Разбор:

💥 Ловушка:

На первый взгляд всё кажется правильным, но важный момент в следующем:

Linux (и systemd) работают с inode, а не напрямую с именами файлов.

Когда вы выполняете:

```bash
mv /tmp/new_nginx.conf /etc/nginx/nginx.conf
```

это не заменяет содержимое файла. Вместо этого создаётся новый файл с новым inode под тем же именем, а старый файл с таким же именем удаляется.

Если сервис (например, `nginx`) запущен под контролем systemd с включёнными параметрами ProtectSystem или другими механизмами безопасности (или даже через старый init-скрипт), при перезапуске сервис может продолжать использовать открытый файловый дескриптор на старый файл или работать в chroot-окружении, где старый inode остаётся связанным.

В итоге:

- cat показывает новый файл (новый inode под тем же именем).
- Сервис же фактически читает старый файл, который всё ещё «жив» для ядра через старый дескриптор.

---

🔧 Как проверить:

1️⃣ Посмотрите inode текущего файла:

```bash
ls -li /etc/nginx/nginx.conf
```

2️⃣ Посмотрите, какой inode открыт у сервиса:

```bash
lsof -p $(pidof nginx) | grep nginx.conf
```

Вы увидите, что процесс всё ещё держит дескриптор на старый inode.

---

🛠 Как исправить:

• После замены файла через mv рекомендуется не просто перезапускать сервис, а полностью его остановить и затем запустить заново:

```bash
systemctl stop nginx
systemctl start nginx
```

или использовать reload, если сервис это поддерживает:

```bash
nginx -s reload
```

Это гарантирует закрытие старых дескрипторов и открытие новых с актуальным inode.

---

✅ Вывод:

• В Linux имя файла — это просто ссылка на inode.
• Замена файла через mv не обновляет содержимое для уже запущенных процессов «на лету».
• Даже после restart systemd или init-скрипты могут не закрыть старые дескрипторы, особенно при использовании специальных модулей, overlayfs и других особенностей.

💡 Бонус-вопрос:
Почему команда tail -f /etc/nginx/nginx.conf после mv может перестать работать корректно и как сделать так, чтобы отслеживание файла продолжалось после замены?

@linux_education

🫡 Без обид, Линус Торвальдс… но этот человек — величайший гик нашего времени.

📟 В 1971 году, когда ему было 28 лет, он создал UNIX — систему, на которой основан весь современный интернет.

🦫 В 2009 году, уже в 66 лет, он стал соавтором языка Go — одного из самых востребованных языков в мире DevOps и микросервисов.

💥 Но это только начало:

▪ Он разработал язык B, который послужил основой для языка C.
▪ Создал UTF-8 — кодировку, благодаря которой мы можем видеть текст на любом языке в интернете.
▪ Придумал grep — команду, без которой не обходится ни один программист.
▪ Работал над Multics, Plan 9, Inferno — это четыре операционные системы, созданные одним человеком.

🧠 Большинство людей в своей жизни используют не более двух операционных систем. А он — создал четыре.

И при этом...
О нём почти никто не знает.

Запомни это имя: Кен Томпсон.
🛠 Один из тех, кто буквально построил цифровой мир, в котором мы живём.

🏛 Рим не строился за один день... а grep — практически за одну ночь 😎

История создания grep — действительно увлекательная.

Один из создателей операционной системы UNIX, Кен Томпсон, разработал grep буквально «за ночь».

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

«Знаешь, было бы здорово уметь искать нужное в файлах».

Томпсон ответил:

«Хорошо, подумаю об этом ночью.»

Он пришёл домой, доработал свой старый код, исправил ошибки — и всё это заняло не более часа.

На следующий день он показал результат МакИлрою.
Тот воскликнул:

«Это именно то, что мне было нужно!»

А дальше — это уже история.

🤔 Если тебе интересно, почему инструмент называется grep, а не просто search — на это есть вполне разумное объяснение 👇

❤️ Ставьте лайк, и я расскажу про историю названия Grep.

@linux_education

🧠 Задание для опытных Linux-администраторов: «Служба-зомби и ловушка systemd»

📘 Суть задачи

У тебя есть unit-файл systemd по адресу /etc/systemd/system/fake-backup.service:

[Unit]
Description=Fake Backup Daemon
After=network.target

[Service]
ExecStart=/usr/local/bin/fake-backup.sh
Type=forking
PIDFile=/var/run/fake-backup.pid
Restart=always

[Install]
WantedBy=multi-user.target

А вот сам скрипт fake-backup.sh:

#!/bin/bash
echo $$ > /var/run/fake-backup.pid
sleep 300

Ты выполняешь команды:

systemctl daemon-reload
systemctl enable fake-backup
systemctl start fake-backup

И через несколько секунд запускаешь:

systemctl status fake-backup

В ответ видишь:

• active (exited)
• или в логах: Main PID exited, but service still running.
• или PID не совпадает с реальным процессом.

❓ Вопросы

1) Почему systemd считает, что служба завершилась?
2) Что не так в этом скрипте и unit-файле?
3) Как исправить ситуацию, чтобы служба правильно отслеживалась и автоматически перезапускалась?

✅ Анализ и подвох

💣 Проблема №1: Type=forking требует форка

Параметр Type=forking говорит systemd:
> «Я ожидаю, что процесс, запущенный через ExecStart, создаст дочерний процесс (форкнется), а родительский процесс завершится. Я буду отслеживать PID дочернего процесса.»

Но здесь fake-backup.sh не создает форк, он просто записывает свой PID и засыпает.

Что происходит:
• systemd запускает скрипт
• скрипт не делает форк → родительский процесс завершается → systemd считает службу завершённой.

💥 Проблема №2: PIDFile не помогает

Даже если указан PIDFile, systemd не сможет точно следить за процессом, если:

• PID-файл создается слишком поздно,
• процесс не демонтизируется должным образом,
• отсутствует настоящий двойной форк и setsid.

✅ Правильные решения

🔧 Вариант 1: изменить тип службы

Самый простой способ:

```ini
[Service]
Type=simple
ExecStart=/usr/local/bin/fake-backup.sh
Restart=always
```

В этом случае systemd будет считать службу активной, пока скрипт запущен.

🔧 Вариант 2: сделать настоящий демон

Перепиши скрипт, чтобы он корректно демонизировался, например:

```bash
#!/bin/bash
(
echo $$ > /var/run/fake-backup.pid
exec sleep 300
) &
```

Или используй утилиты `daemon`, `start-stop-daemon` или напиши демон на C с двойным форком.

🎯 Проверка

```bash
systemctl status fake-backup
ps aux | grep fake-backup
```

Если systemd правильно отслеживает PID — всё работает корректно.
Если служба переходит в состояние `exited`, значит systemd считает, что она завершилась.

⚠️ Подвох

Многие думают, что `Type=forking` означает просто «запуск в фоне».
На самом деле этот тип требует **правильного поведения демона**, иначе systemd не сможет понять состояние службы.

Поэтому:

• не применяй `forking` без настоящей демонизации,
• `simple` — более безопасный тип для большинства скриптов.

@linux_education

‍🕵️‍♂️ API-s-for-OSINT — каталог API для разведки по открытым источникам

Если ты занимаешься OSINT, кибербезопасностью или просто хочешь автоматизировать сбор данных — этот репозиторий (https://github.com/cipher387) станет для тебя настоящей сокровищницей.

📦 Что внутри:
Каталог разбит по тематикам, в каждой — список полезных API с описанием и ссылками. Вот лишь малая часть:

• Поиск устройств и IP: Shodan, Censys, Netlas
• Проверка email и доменов: WhoisXML, Kickbox
• Телефонные API: Numverify, Twilio
• Геолокация: Google Geocoding, Zipcodebase
• Даркнет и утечки: Onion Lookup, Darksearch
• Социальные сети, блокчейн, хэши, Wi-Fi и многое другое

🧠 Как использовать:
• Автоматизация с Python, Bash, Telegram-ботами
• Проверка подозрительных email и IP
• Интеграция в OSINT-дашборды или Google Sheets
• Быстрый доступ к API через curl или Postman

📎 Полезно каждому, кто хочет собирать, проверять и кросс-референсить данные в интернете — от хактивиста до журналиста.

🔗 Ссылка (https://github.com/cipher387/API-s-for-OSINT)



@linux_education

💥 В даркнете появилась база с данными 89 млн аккаунтов Steam — возможная утечка из Twilio

На одной из даркнет-площадок выставлен на продажу файл, содержащий якобы 89 миллионов записей пользователей Steam — это около двух третей всех аккаунтов на платформе.

Продавец с ником Machine1337 запросил $5000 за доступ к базе и опубликовал примерку из 3000 строк в качестве доказательства.

Содержимое файла включает:

- SMS-сообщения с одноразовыми кодами Steam Guard

- номера телефонов, на которые были отправлены эти коды

По оценкам экспертов, утечка вряд ли произошла со стороны Valve — куда более вероятной выглядит компрометация облачного провайдера Twilio, который занимается отправкой SMS для двухфакторной аутентификации.

📌 Если у вас включён Steam Guard через мобильное приложение, серьёзных причин для беспокойства нет — коды, отправленные по SMS, считаются менее защищённым методом.



@linux_education

👾 Новые атаки Spectre-v2: Training Solo обходит защиту Intel. Исследователи из Амстердамского свободного университета обнаружили серию уязвимостей в процессорах Intel, связанных с атаками Spectre-v2. Метод, получивший название Training Solo, позволяет обходить механизмы изоляции памяти, такие как IBPB и eIBRS, и извлекать данные из ядра или гипервизора со скоростью до 17 КБ/с**.

В отличие от классических атак Spectre, Training Solo использует не подконтрольный злоумышленнику код, а уже существующие фрагменты в привилегированных областях. Эксплуатация возможна благодаря аппаратным уязвимостям CVE-2024-28956 и CVE-2025-24495, затрагивающим процессоры Intel от Coffee Lake до Lunar Lake.

Intel уже выпустила обновление микрокода с новой инструкцией IBHF, а в Linux добавлены патчи для блокировки атак через cBPF. AMD и ARM заявили, что их современные процессоры не подвержены угрозе.

🔗 Ссылка - *клик* (https://download.vusec.net/papers/trainingsolo_sp25.pdf)



@linux_education

👁️ Nmap 7.96: легендарный сетевой сканер получил крупное обновление после года разработки. Теперь сканирование миллионов хостов занимает в 50 раз меньше времени благодаря параллельной обработке DNS-запросов — там, где раньше требовалось двое суток, теперь хватает часа.

Среди любопытных нововведений: тёмная тема для Zenmap, скрипты для работы с MikroTik и генерация IPv6-адресов по MAC-адресу. При этом проект сохранил свой фирменный баланс между мощью и гибкостью, оставаясь инструментом как для пентестеров, так и для системных администраторов.

🔗 Ссылка - *клик* (https://nmap.org/)



@linux_education

Auditor.codes — это интерактивная платформа для прокачки навыков в аудите исходного кода и кибербезопасности.

🔍 Что предлагает:

🧠 8 000+ задач на поиск реальных уязвимостей в C/C++ (буферные переполнения, UAF, integer overflow и др.)

📚 Обучение безопасному кодингу и методам аудита

🏆 Таблица лидеров и соревновательная среда

Подходит и новичкам, и профессионалам. Учись искать уязвимости — как настоящий white-hat!

https://auditor.codes/



@linux_education

‍🛡️ DDoSecrets опубликовали 410 ГБ дампов памяти с сервера TeleMessage

Что произошло:
Киберактивисты из Distributed Denial of Secrets обнародовали около 410 ГБ файлов heap dump, которые были получены хакерами с архива сервера TeleMessage — компании, предоставляющей “модифицированные” версии Signal, WhatsApp, Telegram и WeChat с централизованным архивированием сообщений :contentReference[oaicite:0]{index=0}.

Кто такая DDoSecrets:
Это некоммерческая организация, действующая с 2018 года. Как своего рода "преемник WikiLeaks", она публикует утечки каналов властей, компаний и общественных институтов, часто в сотрудничестве с расследователями и журналистами :contentReference[oaicite:1]{index=1}.

Хронология инцидента:
1. 1 мая — бывший советник по нацбезопасности (Mike Waltz) используют TeleMessage вместо обычного Signal при общении с чиновниками и политиками.
2. 3–5 мая — вскрыты исходники TM SGNL и случаи с утечкой данных.
3. 4 мая — произошла компрометация архива TeleMessage через endpoint /heapdump, доступный публично, что позволило скачать дампы памяти с личными и служебными данными.
4. 19 мая — DDoSecrets публикуют эти дампы (переданные журналистам и исследователям) с объемом ~410 ГБ :contentReference[oaicite:2]{index=2}.

Что содержат дампы:
- Текстовые сообщения (plain-text chats)
- Метаданные: отправители/получатели, временные метки, названия групп
- Часть архива содержит только metadata :contentReference[oaicite:3]{index=3}

Зачем это важно:
- Подтверждается, что TeleMessage обещает “end-to-end encryption”, но на самом деле реализует централизованный архив. Архивы доступны в открытом виде — без шифрования.
- Потенциально скомпрометированы и госслужащие (в том числе из США), и криптокомпании — включая Coinbase :contentReference[oaicite:4]{index=4}.
- Проблема носит системный характер: endpoint Spring Boot Actuator (`/heapdump`) экспортирует чувствительные данные, что является классической и давно известной ошибкой конфигурации :contentReference[oaicite:5]{index=5}.

Как это работает (технически):
TeleMessage-разработчики оставили endpoint /heapdump доступным в продакшн-среде. Spring Boot по умолчанию включал этот endpoint до версии 1.5, когда он ещё требовал аутентификации — но в проде этот механизм был отключён или не настроен :contentReference[oaicite:6]{index=6}.

Риски и выводы:
- Утечка персональных и корпоративных сообщений через незащищённый endpoint.
- Масштабный компромисс доверия: официальное ПО использовалось государственными служащими, но оказалось уязвимым.
- Опасность misconfiguration в production: включённые debug-инструменты, забытые эндпойнты приводят к масштабным утечкам.

🧠 Итог:
Данный инцидент — наглядный пример того, как даже простая конфигурационная ошибка может привести к раскрытию сотен гигабайт конфиденциальных данных. А обнародование дампов организацией DDoSecrets повышает прозрачность и ставит под вопрос безопасность TeleMessage как платформы, заявляющей о надёжной защите переписок.



@linux_education

‍🛠 Backdoor — Python Reverse Shell & Listener Tool

Проект [ceodaniyal/Backdoor](https://github.com/ceodaniyal/Backdoor) — это обучающий инструмент на Python, сочетающий сервер-листенер и обратную шелл-связь. Он создан для практики в этическом хакинге и работе с обратными

🔧 Структура проекта

- server.py — слушает входящие соединения, выполняет команды на целевой машине и обрабатывает файлы
- backdoor.py — клиент на стороне «жертвы»: подключается к серверу и ждёт команд
- README.md — объясняет, как настроить IP и порты и показывает список команд

🚀 Ключевые возможности

- Reverse shell — удалённое выполнение команд
- File transfer — upload и download между машинами
- Реество JSON-коммуникации — структуры сообщений для надёжности
- Автоматическая переподключаемость — клиент пытается заново соединиться
- CLI-интерфейс — команды: cd, upload, download, clear, quit, другие
:contentReference[oaicite:1]{index=1}

🧠 Зачем это нужно?

- Учебные цели: лучший способ разобраться, как устроена обратная шелл-связь и socket-программирование
- Pentest / CTF-практика: отработка навыков удалённого доступа и передачи файлов
- Этичный хакинг: понимание механики и защиты подобных инструментов

⚠️ Важно: этический аспект

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

👨‍💻 Быстрый старт

1. Настройте IP в server.py, запустите:

python server.py

2. Настройте IP в backdoor.py, запустите на целевой машине:

python backdoor.py

3. Управляйте:
- cd — смена директории
- upload / download
- clear, quit или выполнить системную команду

🧭 Возможности для прокачки

- Добавить TLS-шифрование — для безопасности канала
- Реализовать аутентификацию, чтобы фильтровать подключающиеся клиенты
- Перевести на асинхронный asyncio для масштабируемости
- Добавить односторонний канал контроля через HTTP/WebSocket (C2 командный центр)
- Интегрировать в CI для учёбы — автоматически развёртывать sandbox и отрабатывать команды

📌 Github (https://github.com/ceodaniyal/Backdoor)



@linux_education

‍🛡️ Утечка 184 миллионов логинов: открытая база с данными пользователей Apple, Google, Facebook и даже госслужб

Исследователь Jeremiah Fowler обнаружил огромную незащищённую базу Elastic — 184+ миллионов записей (~47 ГБ), свободно доступных в интернете. Данные включали логины, пароли, адреса и ключевые слова вроде "wallet", "bank", "PayPal", "Netflix", "Discord".

🌍 Кто пострадал:
• Аккаунты пользователей из 29+ стран
• 220+ адресов .gov — включая США, Канаду, Австралию, Индию и Китай
• Учётные записи: Google, Facebook, Instagram, Apple, Amazon, PayPal и др.

🔎 Что произошло:
• Сервер находился у провайдера World Host Group, но владелец не установлен
• Судя по данным — это сборка из вредоносного ПО-инфостилера или логов скомпрометированных машин
• После уведомления — база была оперативно отключена

⚠️ Почему это важно:
• Утечка включает учётки правительств, что может представлять угрозу нацбезопасности
• Доступ был открыт публично — неизвестно, кто успел воспользоваться
• Это напоминает, насколько важна защита серверов и баз данных

🔐 Что делать:
✅ Смените пароли в ключевых сервисах
✅ Включите 2FA (двухфакторную авторизацию)
✅ Используйте менеджеры паролей и не повторяйте один пароль на разных сайтах
✅ Не храните API-ключи или токены в незашифрованных файлах

📎 Источник (https://www.wired.com/story/mysterious-database-logins-governments-social-media/)

#CyberSecurity #DataLeak #Infostealer #Elastic #SecurityBreach #GovLeak #DigitalPrivacy #JeremiahFowler

@linux_education

🕵️‍♂️ Pinkerton — инструмент для поиска секретов в JavaScript

Это мощный open-source сканер, созданный для автоматического поиска чувствительных данных (API-ключей, токенов, паролей) в JavaScript-файлах на веб-сайтах.

🔍 Что делает Pinkerton:
• Краулит сайт, собирая все JS-файлы
• Ищет утечки с помощью регулярных выражений
• Находит API-ключи, JWT, access tokens, пароли и многое другое

⚙️ Как использовать:

git clone https://github.com/000pp/Pinkerton.git
pip3 install -r requirements.txt
python3 main.py -u https://example.com

🧠 Кому подойдёт:
• Пентестерам и багхантером
• DevSecOps специалистам
• Любому, кто хочет проверить, не утекли ли ключи в фронт-коде

📦 Поддерживается в BlackArch Linux
🔓 Лицензия: MIT
🌟 300+ звёзд на GitHub

💬 Pinkerton — отличный инструмент для тех, кто хочет автоматизировать безопасность своего фронта и не допустить утечек ключей.

#pentest #security #bugbounty #opensource #js #infosec #Pinkerton

https://github.com/000pp/Pinkerton

@linux_education

‍✅ Beelzebub Honeypot - платформа для анализа киберугроз, специализирующуюся на выявлении и изучении криптоджекинга — скрытого майнинга криптовалюты на чужих устройствах без ведома владельцев.

🔍 Как работает Beelzebub Honeypot (https://beelzebub-honeypot.com/blog/how-cybercriminals-make-money-with-cryptojacking/)
Beelzebub — это низкокодовая honeypot-фреймворк, позволяющая быстро развернуть ловушки для киберпреступников. Особенность проекта — интеграция с моделью GPT-4o, что обеспечивает реалистичное поведение системы и привлекает злоумышленников для более глубокого анализа их действий.

💰 Исследование криптоджекинга
В рамках одного из экспериментов Beelzebub была зафиксирована атака, при которой злоумышленник использовал вредоносное ПО для:

- Удаления конкурирующих майнеров с системы жертвы.

- Установки собственного майнера xmrig через скрипт с сервера c3pool.org.
beelzebub-honeypot.com

- Майнинга криптовалюты Monero (XMR) на свой кошелек.


За короткий период злоумышленнику удалось добыть 20 XMR, что эквивалентно примерно $4126.

🛡️ Противодействие угрозам
После обнаружения атаки команда Beelzebub:

- Заблокировала вредоносный кошелек в пуле c3pool.
beelzebub-honeypot.com

- Удалили все связанные с ним майнеры, предотвращая дальнейшее распространение угрозы.

📌 Основные преимущества Beelzebub
Быстрая настройка honeypot-серверов через YAML-конфигурации.

- Интеграция с LLM (GPT-4o) для реалистичного взаимодействия с атакующими.

- Открытый исходный код и активное сообщество разработчиков.

- Поддержка различных протоколов (SSH, HTTP, TCP) и интеграция с Docker и Kubernetes.

Beelzebub Honeypot — мощный инструмент для специалистов по кибербезопасности, позволяющий не только выявлять, но и глубоко анализировать современные угрозы, такие как криптоджекинг, и эффективно им противодействовать.

https://beelzebub-honeypot.com/blog/how-cybercriminals-make-money-with-cryptojacking/

@linux_education