Bugün kırmızı takım oyuncularının tespit edilmekten kaçınmasına yardımcı olacak yeni bir araç yayınlıyoruz. Kabuk kodu, genellikle bir açıktan yararlanmada yük olarak kullanılan ve genellikle "imzası" veya benzersiz kalıbı ile algılanabilen küçük bir kod parçasıdır. Shellcode Mutator, işlevselliğini etkilemeden, imzasını değiştirmeden ve güvenilir bir şekilde kötü niyetli olarak algılanmasını zorlaştırmadan, yararlanma kaynak kodunu değiştirir.
GitHub: https://github.com/nettitude/ShellcodeMutator
Örneğin, kaynak dosyadaki işlevlerin içeriği ve sırası (elbette) değiştirilebilir ve kod, kabuk kodunuzun yeni bir sürümünü üretmek için derlenebilir. Ancak bu değişikliklerin işlevsel olması gerekmez, kabuk kodu kaynağını değiştirmek için otomatik araçlar kullanabiliriz, böylece onu her derlediğimizde işlevsellik aynı kalır, ancak içerik değişir.
Bu, ortaya çıkan kabuk kodunun farklı bir boyuta, dosya karmasına, bayt sırasına vb. sahip olacağı anlamına gelir ve bu da hem statik hem de bellekte güvenilir bir şekilde algılamayı zorlaştırır.
Bu yetenek, kabuk kodu şifrelemesine vb. dikeydir, çünkü bir noktada şifrelenmiş ve kodlanmış kabuk kodunun gerçekten yürütülebilmesi için şifresinin çözülmesi ve kodunun çözülmesi ve şifresinin çözülmesi gerekir ve bu noktada algılanabilir.
Biraz yapmacık da olsa somut bir örnek kullanalım.
Bu shellcode'u blue teamer olarak çıkaracak olsak ve onu yakalamak için algılamalar yazmak istersek, hash'i not edip, içeriğini ve demontajını inceledikten sonra hafızada veya diskte yakalayabilmek için bir yara kuralı yazabiliriz.
Aşağıda gösterildiği gibi, ikili rafineriyi kullanarak ikiliye hızlı bir göz atabiliriz.
Ayrıca sha256 hash'inin a8fb8c2b46ab00c0c5bc6aa8d9d6d5263a8c4d83ad465a9c50313da17c85fcb3.
Rizin, kabuk kodu çözümlemesini incelemek için kullanılabilir.
Bunun için çok hızlı bir yara kuralı yazacak olursak, bazı kurulumları gerçekleştiren ilk baytlara odaklanmayı seçebiliriz. Ofsetleri (ör. [rbx + 0x113]) joker karakterlerle değiştirerek ve ikinci çağrıya kadar baytları alarak, 0x0000001bbellekteki ve diskteki kabuk koduyla eşleşen hızlı bir yara kuralı yazabiliriz, ancak örn C:\Windows\System32 .
Kural, diskteki ve bellekteki kabuk koduyla eşleşir ve C:\Windows\System32.
Yani güvenilir bir yara kuralımız var ve onu tehdit avlarımıza ekliyoruz, tamam mı?
Betiğin kullanımı yeterince kolaydır, bir 'şablon' kaynak kodu, bir çıkış dosyası, bir morf yüzdesi ve x86vs x64modunu ayarlamak için bir bayrak alır.
x86Bu komut dosyası, kaynak satırlarını kontrol etmek için bazı temel mantıklara sahiptir, ancak esas olarak, biri for ve diğeri for olmak üzere genişletilebilen talimat kümelerine sahiptir x64. Bu komut kümelerindeki her giriş, tüm komutlar yürütüldükten sonra, kabuk kodunun hatasız devam edebilmesini sağlamak için tüm kayıtları ve bayrakları yürütülmeden önceki durumlarında bırakmalıdır.
assembly_instructionsBaşka bir mantığın yanı sıra, komut dosyası bu komut setlerini değişkende belirtilen komutlardan önce rastgele aralıklarla (morf yüzdesi tarafından dikte edilir) yerleştirecektir :
Komut dosyasını MessageBox kabuk kodumuza karşı çalıştırırsak, %15'lik bir biçim değiştirme yüzdesi ayarlayarak, 53 yerine 57 satırlık bir kaynak kod dosyası elde ederiz. Bu kabuk kodunu derlemek ve yara aramasını yürütmek, bunun yakalanmadığını ve yalnızca orijinal kabuk kodunu gösterir. maçlar.
0x90İkili dosyanın demonte edilmesi incelendiğinde, eşleştirdiğimiz baytlara (diğer yerlere ek olarak) bir nop ( ) talimatı eklediği görülüyor . Bu elbette dosya karmasını da değiştirdi.
Tabii şans unsuru da var. Yara kurallarının (veya diğer tespitlerin) ne olduğunu gerçekten bilmeden herhangi bir yara kuralının artık eşleşmeyeceği kadar baytı değiştirdiğimizden emin olmalıyız. Dönüşüm yüzdesini artırmak, yapılan değişikliklerin sayısını ve artan kabuk kodu boyutu pahasına herhangi bir kuralı atlama olasılığını artıracaktır.
Tabii ki asıl soru, kabuk kodumuz hala çalışıyor mu?
Kazanan!
Shellcode Mutator'u İndirin
Arka fon
Kabuk kodunuzu derlemede yazmanın ana faydalarından biri, kabuk kodunun yapısı üzerinde tam kontrole sahip olmanızdır.Örneğin, kaynak dosyadaki işlevlerin içeriği ve sırası (elbette) değiştirilebilir ve kod, kabuk kodunuzun yeni bir sürümünü üretmek için derlenebilir. Ancak bu değişikliklerin işlevsel olması gerekmez, kabuk kodu kaynağını değiştirmek için otomatik araçlar kullanabiliriz, böylece onu her derlediğimizde işlevsellik aynı kalır, ancak içerik değişir.
Bu, ortaya çıkan kabuk kodunun farklı bir boyuta, dosya karmasına, bayt sırasına vb. sahip olacağı anlamına gelir ve bu da hem statik hem de bellekte güvenilir bir şekilde algılamayı zorlaştırır.
Bu yetenek, kabuk kodu şifrelemesine vb. dikeydir, çünkü bir noktada şifrelenmiş ve kodlanmış kabuk kodunun gerçekten yürütülebilmesi için şifresinin çözülmesi ve kodunun çözülmesi ve şifresinin çözülmesi gerekir ve bu noktada algılanabilir.
Biraz yapmacık da olsa somut bir örnek kullanalım.
Test durumu
Didier Stevens'tan bazı MessageBox kabuk kodları için nasm kaynak kodunu alabilir, onun talimatlarına göre derleyebilir ve enjekte edebiliriz ve başarılı bir şekilde bir mesaj kutusu elde edebiliriz – şimdiye kadar çok iyi.
Bu shellcode'u blue teamer olarak çıkaracak olsak ve onu yakalamak için algılamalar yazmak istersek, hash'i not edip, içeriğini ve demontajını inceledikten sonra hafızada veya diskte yakalayabilmek için bir yara kuralı yazabiliriz.
Aşağıda gösterildiği gibi, ikili rafineriyi kullanarak ikiliye hızlı bir göz atabiliriz.
Ayrıca sha256 hash'inin a8fb8c2b46ab00c0c5bc6aa8d9d6d5263a8c4d83ad465a9c50313da17c85fcb3.
Rizin, kabuk kodu çözümlemesini incelemek için kullanılabilir.
Bunun için çok hızlı bir yara kuralı yazacak olursak, bazı kurulumları gerçekleştiren ilk baytlara odaklanmayı seçebiliriz. Ofsetleri (ör. [rbx + 0x113]) joker karakterlerle değiştirerek ve ikinci çağrıya kadar baytları alarak, 0x0000001bbellekteki ve diskteki kabuk koduyla eşleşen hızlı bir yara kuralı yazabiliriz, ancak örn C:\Windows\System32 .
Kural, diskteki ve bellekteki kabuk koduyla eşleşir ve C:\Windows\System32.
Yani güvenilir bir yara kuralımız var ve onu tehdit avlarımıza ekliyoruz, tamam mı?
Shellcode Değiştirici
Shellcode Mutator projesinin devreye girdiği yer burasıdır . Bu basit python betiği, nasm kaynak kodunu ayrıştıracak ve "hiçbir şey yapmayan" rastgele aralıklarla talimat kümeleri ekleyecektir, ancak daha sonra pahasına kabuk kodunun sırasını ve dosya karmasını değiştirecek ve baytlayacaktır. artan boyut.Betiğin kullanımı yeterince kolaydır, bir 'şablon' kaynak kodu, bir çıkış dosyası, bir morf yüzdesi ve x86vs x64modunu ayarlamak için bir bayrak alır.
x86Bu komut dosyası, kaynak satırlarını kontrol etmek için bazı temel mantıklara sahiptir, ancak esas olarak, biri for ve diğeri for olmak üzere genişletilebilen talimat kümelerine sahiptir x64. Bu komut kümelerindeki her giriş, tüm komutlar yürütüldükten sonra, kabuk kodunun hatasız devam edebilmesini sağlamak için tüm kayıtları ve bayrakları yürütülmeden önceki durumlarında bırakmalıdır.
assembly_instructionsBaşka bir mantığın yanı sıra, komut dosyası bu komut setlerini değişkende belirtilen komutlardan önce rastgele aralıklarla (morf yüzdesi tarafından dikte edilir) yerleştirecektir :
Komut dosyasını MessageBox kabuk kodumuza karşı çalıştırırsak, %15'lik bir biçim değiştirme yüzdesi ayarlayarak, 53 yerine 57 satırlık bir kaynak kod dosyası elde ederiz. Bu kabuk kodunu derlemek ve yara aramasını yürütmek, bunun yakalanmadığını ve yalnızca orijinal kabuk kodunu gösterir. maçlar.
0x90İkili dosyanın demonte edilmesi incelendiğinde, eşleştirdiğimiz baytlara (diğer yerlere ek olarak) bir nop ( ) talimatı eklediği görülüyor . Bu elbette dosya karmasını da değiştirdi.
Tabii şans unsuru da var. Yara kurallarının (veya diğer tespitlerin) ne olduğunu gerçekten bilmeden herhangi bir yara kuralının artık eşleşmeyeceği kadar baytı değiştirdiğimizden emin olmalıyız. Dönüşüm yüzdesini artırmak, yapılan değişikliklerin sayısını ve artan kabuk kodu boyutu pahasına herhangi bir kuralı atlama olasılığını artıracaktır.
Tabii ki asıl soru, kabuk kodumuz hala çalışıyor mu?
Kazanan!
