🎯 Пройшов CTF STALKER Novice — ділюсь враженнями

Нещодавно я завершив проходження CTF STALKER Novice від [Morronel](https://github.com/Morronel/stalker_novice).
І хочу поділитись своїми враженнями, бо цей проєкт реально вартий уваги.

---

🛠 Що було всередині:
- Атмосфера справжньої Зони:
Всі інтерфейси стилізовані під S.T.A.L.K.E.R. — починаючи від старого PDA до систем сканування та сейфів. Дуже приємно відчувалося "занурення" в тематику.

- Технічна складова:
Завдання включали роботу з:

  - SQL-запитами (чисті, без ін'єкцій)
  - XSS-атаками (з правильними обмеженнями)
  - Перехопленням прихованого мережевого трафіку
  - Пошуком прихованих директорій через brute-force
  - Аутентифікацією через перебір логінів та паролів

- Рівень складності:
Оптимальний для новачків і середнього рівня. Якщо маєш базові знання у веб-безпеці, будеш отримувати задоволення від проходження без надлишкових фрустрацій. )))

---

🔥 Що особливо сподобалося:
- Дуже добре продумана структура — завдання можна проходити по наростаючій складності або вибирати яке більш подобається
- Атмосферне оформлення кожної сцени: шум, підсвічування, старий інтерфейс, сканування, карта, бандити))
- Реалістичні ситуації — немає надуманих завдань, усе логічно і дужееее атмосферно)



⚡ Декілька дрібних моментів:

- У захисті SQL запитів можна було залишити трохи більше свободи для варіацій синтаксису.
- В сейфі хотілося б бачити ще кілька "фальшивих" логінів для більшого задоволення від правильного підбору.

✅ Підсумок:

STALKER Novice — це чудова пригода для тих, хто хоче відчути атмосферу сталкерства та трохи попрацювати головою над технічними викликами.
Рекомендую всім, хто цікавиться CTF, веб-безпекою або просто любить тематику Зони.

Якщо у когось будуть питання по проходженню або потрібна допомога — звертайтесь!
З радістю допоможу. 🔥


🚀 Посилання на репозиторій:
[github.com/Morronel/stalker_novice](https://github.com/Morronel/stalker_novice)

Проходження TryHackMe — b3dr0ck
🎯 Тема: TLS-сертифікати, небезпеки sudo і секрети кам'яної епохи безпеки
Уявіть собі світ, де замість Wi-Fi — кам'яні планшети, а замість фаєрволів — палиці.
Оце і є Bedrock, де Фред Флінстоун і Барні Рабл вирішили стати першими DevOps-інженерами кам'яного століття.
Барні так старався впровадити TLS, що забув найголовніше правило кібербезпеки: "Не видавай ключі від печери всім підряд."
А ми, сучасні мисливці на вразливості, вирушили в експедицію в цей доісторичний світ.
🎯 Початок атаки: знайти шлях до печери
Все почалося класично — ми застукали відкритий TCP-сервіс на порту 9009:І що ми побачили? Красивий ASCII-банер і сервіс, який сам пропонує:
"Шукаєш сертифікат? Без проблем, тримай!" 😎

Ми попросили:
help
get cerf
Барні люб'язно дав нам сертифікат клієнта і приватний ключ.

(У реальному світі це все одно що повісити ключ від квартири на дверях.)
🚪 Вхід через TLS-службу як свої
Отримавши доступ, ми використали чарівне заклинання:І магічно потрапили у закриту TLS-службу.
Барні нас люб'язно привітав:На прохання показати вміст (ls) сервер лише пробурмотів:
"Я не вмію таку команду..."
Але підказав пароль у вигляді MD5-хешу:🔓 Розблокування першої печери

Розшифрувавши хеш, ми дістали пароль і зайшли на сервер через SSH:Там у печері Барні лежав перший скарб:THM{f05780f08f0eb1de65023069d0e4c90c}🔥 Нехитрий sudo та сертифікаційна фабрика

Барні, щоби полегшити собі життя, дав собі право виконувати:

sudo certutil 

І ми не зволікали — переглянули список сертифікатів:
Бачимо серед іншого сертифікати Фреда. Мабуть, Фред вважав:
"Якщо сертифікати зберігаються в одній папці з налаштуваннями... то вони точно безпечні."
Ми хитро скористалися можливістю створити нові ключі:(Це як зробити копію ключа від печери сусіда, але через офіційний сервіс.)
🗝️ Нове з'єднання — нові привілеї
Підключаємося тепер як "новий користувач":І отримуємо новий пароль:🧩 Перехід до нового користувача

Міняємо особистість:І виявляємо другий скарб:THM{08da34e619da839b154521da7323559d}🔥 Розпечений фінал: доступ до root

Фред мав право без введення пароля читати /root/pass.txt через base32 і base64.User fred may run the following commands on b3dr0ck:
    (ALL : ALL) NOPASSWD: /usr/bin/base32 /root/pass.txt
    (ALL : ALL) NOPASSWD: /usr/bin/base64 /root/pass.txt

(Типу: "Ти не можеш відкрити сейф напряму, але можеш сканувати документи в ньому".)
Ми просто використали:Розшифрували текст у CyberChef та отримали hash md5 (https://crackstation.net/) — і вуаля — пароль у нас!
Пароль до root:(Барні, серйозно? Пароль про вітаміни в кам'яному світі?)
🏆 Завершення подорожі

Входимо в root і забираємо головний трофей:cat root.txt
THM{de4043c009214b56279982bf10a661b7}📚 Що ми тут навчилися?

TLS — це не чарівний амулет. Якщо приватний ключ можна добути через простий TCP-сервіс — система вже програна.
Не довіряй sudo без обмежень. Навіть добра людина з кам'яної епохи може не знати, що робить.
Base64 — це не захист, це просто упаковка. Справжній захист вимагає шифрування і контролю доступу.
Motto для майбутніх дослідників:"Не залишай ключі від своєї печери у руках динозаврів."
#TryHackMe #b3dr0ck #CTF #TLSHacking #CyberStoneAge #FlintstonesCTF #PrivilegeEscalation #HackThePlanet #socatMagic #Base64IsNotSecurity #PwnedWithStyle #BedrockBreach #CyberSecurityFun #UkraineCyber #UkrainianCTF #CyberStrongUA

DevSecOps: Безпека в IT без зайвих клопотів 🚀
Що це таке? 🏗️
Уявіть, що ви будуєте будинок 🏠. Можна:
1️⃣ Спочатку звести стіни, а потім думати, куди поставити двері та вікна ❌
2️⃣ Відразу планувати, де вони будуть – так простіше і дешевше! ✅
DevSecOps – це так само, але для програм! 💻
📌 Замість того, щоб "латати діри" в безпеці в кінці 🩹, ми вбудовуємо її в процес з самого початку!
Чому це важливо? 🔍
💸 Дешевше: Виправити помилку на етапі кодування в 100 разів дешевше, ніж після запуску! (Це не шутка – дані від IBM!)
⚡ Швидше: Автоматичні перевірки не затримують роботу – вони просто не пропустять небезпечний код!
🛡️ Надійніше: Коли всі в команді (розробники 👨💻, тестувальники 🧪, адміністраторы 🖥️) думають про безпеку – ризиків значно менше!
Як це працює на практиці? 🛠️
1️⃣ Рання перевірка коду (Shift Left) ⬅️
Що це?
"Shift Left" означає переносити перевірки безпеки якомога раніше – ще до того, як код потрапить у робочу програму!
Приклад:
👨💻 Розробник пише код → 🤖 автоматична система (наприклад, SonarQube) перевіряє його на типові помилки (наприклад, можливість хакерської атаки через неправильне зберігання паролів 🔑).
🚨 Якщо щось не так – система одразу повідомляє йому, а не чекає місяць!
2️⃣ Автоматичний захист на кожному кроці 🤖
CI/CD – це як конвеєр, де код автоматично тестується, збирається і розгортається. DevSecOps додає сюди безпеку!
Етап=Що=перевіряється=Інструменти 🛠️;

Код ✍️ = Помилки безпеки в рядках коду = SonarQube, Checkmarx;

Бібліотеки 📚= Чи немає в них відомих дір? = Snyk, Dependabot

Налаштування ⚙️ = Чи правильно налаштовані сервери? = Terrascan, Kube-bench

Запуск 🚀= Чи не відбуваються підозрілі дії? = Falco, Wazuh

Приклад:
Ви додаєте нову функцію → система сама знаходить, що ви використали небезпечну бібліотеку!
Вам кажуть: "❌ Ця бібліотека має вразливість! Ось як її замінити ✅"
Ви виправляєте → код йде далі! 🎉
Як це зробити в команді? 👥
1️⃣ Почати з простих кроків
Для розробників 👨💻: Встановити плагіни для IDE (наприклад, GitGuardian – шукає паролі у коді!)
Для DevOps 🛠️: Додати автоматичні сканери в CI/CD (наприклад, OWASP ZAP для тестування вебдодатків)
2️⃣ Змінити підхід до безпеки
Не бути "поліцією" 👮, а помічником 🤝:
❌ "Це не можна робити!"
✅ "Ось як зробити безпечніше!"
Навчання 🎓: Міні-лекції типу "Як уникнути 5 найпоширеніших вразливостей?"
3️⃣ Використовувати "пісочниці" 🏖️
Це ізольовані середовища, де можна тестувати нові рішення без ризику для основної системи!
Висновок: Чому це вигідно? 💡
😌 Менше стресу: Менше шансів, що після запуску з'явиться критична діра!
🚀 Швидший випуск продуктів: Автоматизація економить час на ручних перевірках!
🤝 Довіра клієнтів: Ніхто не хоче чути, що його дані витікли через просту помилку!
Хочете спробувати? 🔥
🔹 Безкоштовні інструменти для початку (https://owasp.org/www-project-devsecops-guideline/)
🔹 Приклади DevSecOps у реальних компаніях(https://www.appknox.com/blog/history-of-devops)
🔹 Безпечна розробка ПЗ на TryHackMe (https://tryhackme.com/module/secure-software-development) – інтерактивний курс з основами DevSecOps! 🎮
DevSecOps — це не про складні технології. Це про те, щоб робити безпеку простою частиною роботи! 🛡️💻
#DevSecOps #CyberSecurity #AppSec #SecureCoding
#LearnToCode #CyberSecurityAwareness #TechEducation
#ITвУкраїні #КіберБезпека #ТехнологіїУкраїна

SDLC: Як забезпечити безпеку на кожному етапі розробки 🛡️💻
SDLC (Software Development Life Cycle) — це план, який допомагає створити програму від початку до кінця. Він не тільки забезпечує високу якість, а й вбудовує безпеку на кожному етапі, щоб не зустріти неприємних сюрпризів після запуску. Безпека має бути частиною процесу, а не "останнім штрихом"!
SDLC — це набір практик, які визначають порядок виконання завдань під час розробки програмного забезпечення. І це не просто про те, як написати код: важливо також, як організувати процес, щоб все працювало як годинник.
Забезпечення якості: завдяки чітко визначеному плану можна уникнути помилок і підвищити якість продукту.
Управління ризиками: ретельне планування знижує ймовірність критичних проблем, включаючи загрози безпеці.
Безпека: без цього навіть найкраще спланований продукт може стати вразливим до атак.
Етапи SDLC та безпека на кожному з них
1. Планування: з чого все починається? 🚦
На цьому етапі ви визначаєте цілі і ресурси проекту. Важливо встановити не лише часові рамки і бюджет, а й врахувати, які саме загрози можуть виникнути під час розробки.
Безпека на етапі планування:
Визначення стандартів безпеки: шифрування, автентифікація, захист від атак.
Оцінка ризиків: з якими загрозами ми можемо зіткнутися?
2. Визначення вимог: що ми будуємо? 💡
Тут команда збирає всі вимоги до програми. Як працюватиме система? Які її функції повинні бути реалізовані?
Безпека на етапі вимог:
Визначення вимог до захисту даних: наприклад, багатофакторна автентифікація для додатків, які працюють з чутливими даними.
Розробка документації для забезпечення безпеки протягом усього життєвого циклу.
3. Дизайн та прототипування: закладаємо основу 🏛️
Це момент, коли формується структура програми. Не тільки інтерфейс, а й архітектура, яка повинна бути захищеною від потенційних атак.
Безпека на етапі дизайну:
Використання архітектурних рішень, що забезпечують захист даних і підтримку безпеки.
Планування, як програма буде взаємодіяти з іншими системами, щоб уникнути уразливостей.
4. Розробка: реалізуємо ідеї в код 💻
Програмісти пишуть код, створюючи функціонал. Але важливо пам'ятати, що цей код повинен бути захищений від атак.
Безпека на етапі розробки:
Дотримання стандартів безпеки при написанні коду (захист від SQL-ін’єкцій, перевірка введених даних).
Використання статичних інструментів для аналізу коду на наявність вразливостей.
5. Тестування: чи все працює? 🧪
На етапі тестування ми перевіряємо, чи працює програма згідно з вимогами, і чи є вона безпечною. Це не лише про виявлення багів, а й про перевірку на наявність уразливостей.
Безпека на етапі тестування:
Проведення penetration testing) для виявлення вразливостей у програмі.
Тестування на захищеність від атак типу XSS, CSRF, SQL-ін’єкції.
6. Розгортання: готово до користувачів 🌐
Програма готова до запуску, але важливо зробити так, щоб вона була захищена і на етапі розгортання.
Безпека на етапі розгортання:
Захист каналів зв’язку через шифрування (SSL/TLS).
Налаштування фаєрволів і використання інструментів для виявлення атак.
7. Обслуговування: не забуваємо про безпеку після запуску 🛠️
Програма працює, але важливо постійно моніторити її безпеку і оновлювати для виправлення вразливостей.
Безпека на етапі обслуговування:
Оновлення і виправлення помилок, виявлених після запуску.
Постійний моніторинг для виявлення нових загроз.
Як DevSecOps змінює гру?
Уявіть, що ви не чекаєте на останній момент, щоб додати безпеку, а враховуєте її на кожному етапі. Це і є принцип DevSecOps — інтеграція безпеки в кожну фазу SDLC, що дозволяє швидко виявляти та усувати загрози, також він заставляє тебе думати про безпеку на кожному етапі твоєї роботи, покращувати свої знання, вдосконалювати код і постійно автоматизувати процеси для підвищення захищеності.
Корисні ресурси для вивчення DevSecOps:
https://owasp.org/www-project-devsecops-guideline/
https://www.devsecops.org/
https://www.atlassian.com/devops/devops-tools
https://www.atlassian.com/agile/software-development/sdlc

Є такий люто крутий дядько - Orange Tsai 🍊. Лютий кбшник і геній. І от я вирішив крім читання його статей клянути на його вибрані CTF. І почав з малого Babyfirst. Пройти - х?йня, а зрозуміти - виклик. До суті:

<?php
  
    $dir = 'sandbox/' . $_SERVER['REMOTE_ADDR'];
    if ( !file_exists($dir) )
        mkdir($dir);
    chdir($dir);

    $args = $_GET['args'];
    for ( $i=0; $i<count($args); $i++ ){
        if ( !preg_match('/^\w+$/', $args[$i]) )
            exit();
    }
//Замість орандж можна будь який файл,але віддам 
//дань автору
    exec("/bin/orange " . implode(" ", $args));
?>

Запуск -

sudo php -S 0.0.0.0:80

І відвідати в браузері http://0.0.0.0:80/index.php
А задача банальна - байпас фільтру.

!preg_match('/^\w+$/', $args[$i]

Ця регулярка перевіряє: ^ - початок рядка, \w+ будь яку кількість букв або цифр і _ і $ - кінець рядка.
Проходження до болю банальне
http://0.0.0.0/index.php?args[]=%0a&args[]=touch&args[]=pwned
Але цікаво зрозуміти як це працює. В документації php розказується, що вони використовується PCRE - Perl Compatible Regular Expressions. В часи коли перл тільки розвивався, виникла проблема, підчас читання з файлу і перевірки чи його вміст підходить під регулярку, кінець рядка(\n) треба було прописувати в кожну регулярку, бо кожен рядок закінчується в файлі \n, коли ви натискаєте Enter. І це лютий гемор, тому ввели правило: $ означає кінець рядка і дозволяє далі не перевіряти, бо там або \0 або \n\0.
Відповідно ми спокійно додаємо %0A( закодований \n), що для exec означає виконувати наші команди в другому рядку, що в шелі - нові команди, все що ми захочемо.
І в шел приходить

/bin/orange 
touch pwned

Оревуар, Шошана!

Там пів інета лежить, бо хтось в cloudflare хуйово робить свою роботу. Якщо що, це днс провайдер і пів світу юзає його. В них навіть айпі 1.1.1.1

Наїбнулася гілка aws us-east 1
Для всіх в світі)
І Сігнал десктоп не працює. Як же класно коли все в хмарі, як же хуйово, коли хмара не працює)

AWS втомивсь. Якщо якийсь ваш любимий сервіс не працює, або працює в обмеженому режимі - не треба поки на нього сваритись

Btw воскрес

Сьогодні на порядку денному підготовка до OSCP за допомогою вирішення HTB машин.
Aero
https://checklister.github.io/bezpc.github.io/2025/12/05/HTB-Aero.html

Новий день, нова машина
HTB Busqueda


https://checklister.github.io/bezpc.github.io/2025/12/06/HTB-Busqueda.html

Цією статтею я хочу почати цикл про Active Directory. Сам я - готуюсь до OSCP і буду ділитися своїми записами і техніками, які можуть знадобитися. Стаття може бути душна, навіть фоточок нема, але від душі. Я намагався пояснити доступно, без шарів абстракції. Тож
Пірнаючи в AD ч1

Продовжую писати про AD. Частина 2 присвячена концепції Kerberoasting - найвідоміша атака на Active Directory.
Пірнаючи в AD ч2

Репо з симуляціями атак різних груп APT
У ворога краще вчитися)

https://github.com/S3N4T0R-0X0/APTs-Adversary-Simulation

Кхе кхе)