Sandbox ortamları c++

[Captainati]

Merhaba forum üyeleri,


Bu başlık altında zararlı yazılım geliştirme sürecinde öğrendiğim bazı bilgileri ve deneyimlerimi paylaşmak istiyorum.


Yaptığım araştırmalara göre, bazı sandbox ortamları zararlıları analiz ederken belirli teknikleri kullanarak programları izole etmeye çalışır. Örneğin, Sleep() gibi fonksiyonlar programı uyutmak için kullanılırken, bu tür fonksiyonlar bazen sandbox ortamlarında hooklanarak devre dışı bırakılabilir. Bu gibi durumlar, zararlı yazılımın asıl niyetlerinin açığa çıkmasına yol açabilir.


Aşağıda, araştırmalarım sonucunda yazmış olduğum C++ kodu vardır . Bu kod, sandbox ortamlarını tespit edebilmek ve sandbox hızlandırmalarını analiz etmek amacıyla kullanılır. Kod, çeşitli yöntemler kullanarak analiz ortamlarının varlığını ve hızlandırmalarını algılayabilmektedir.

#include <iostream>
#include<windows.h>
bool debuger();
bool timer();
int main()
{
    SetConsoleOutputCP(CP_UTF8);
    SetConsoleCP(CP_UTF8);
    std::cout << "Ortam Test Ediliyor...\n";
    bool task1 = timer();
    bool task2 = debuger();
    if (task1 || task2)
    {
        std::cout << "analiz ortamı olabilir\n";
    }
    else
    {
        std::cout << "temiz";
    }
    system("pause");
}

bool debuger()
{
    if (IsDebuggerPresent())
    {
        return true; /*debuger var*/
    }
    else
    {
        return false; /*debuger yok*/
    }
}

bool timer()
{
    unsigned __int64 start = __rdtsc();
    Sleep(60000); // 60 saniye
    unsigned __int64 end = __rdtsc();

    unsigned __int64 cycles = end - start;
   

    // 1 GHz CPU için 60 saniyede ~60,000,000,000 cycles olur
    if (cycles < 30000000000) {
        return true; /*sandbox hızlandırması var*/
    }
    else {
        return false; /*sandbox hızlandırması yok*/
    }
}

Not: bu yöntemler gerçek zararlı yazılım analiz ortamlarından kaçamayabilir misal bakınız sandboxie api devre dışı bırakıyor.

 

[Hacknology]

Eline sağlık, koda birkaç refactor ekledim:

1 -

--- if (cycles < 30000000000) { // bu sayıyı okumak çok zor, C++ dilinde büyük sayılar tırnak ile ayırılabilir.
+++ if (cycles < 30'000'000'000) { // yeni hali

2 -
Bazı uygulamaların kendi init fonksiyonları yeterince zaman alabiliyor, bu durumda senkron bir CPU kontrolü tüm thread'leri (zaten tek thread var) 60 saniye bekletip performans kaybına yol açıyor. Hayali bir init fonksiyonumuz olsun ve bu fonksiyonu işlemek de başlı başına 30 saniye sürsün, tüm işlemler bittikten sonra bir de onu çağırıp 30 saniye beklemektense işlemleri önce hazırlayıp temizse programa devam edebiliriz. Bunun asenkron kontrolünü gerçekleştirmek için fonksiyonlara girerken ve çıkarken birer mesaj ekledim. Full Kod:

#include <iostream>
#include <windows.h>
#include <future>
#include <chrono>
#include <thread>
namespace MyApp {
bool debuger();
bool timer();
void init();
} //namespace MyApp
int main()
{
    SetConsoleOutputCP(CP_UTF8);
    SetConsoleCP(CP_UTF8);
    std::cout << "Ortam Test Ediliyor...\n";
    
    auto future_timer = std::async(std::launch::async, MyApp::timer);
    auto future_debugger = std::async(std::launch::async, MyApp::debuger);
    auto future_init = std::async(std::launch::async, MyApp::init);
    
    bool task1 = future_timer.get();
    bool task2 = future_debugger.get();
    if (task1 || task2)
    {
        std::cout << "analiz ortamı olabilir\n";
    }
    else
    {
        std::cout << "temiz";
        future_init.get();
    }
    system("pause");
}
bool MyApp::debuger()
{
    std::cout << "Debugger()" << "\n";
    if (IsDebuggerPresent())
    {
        std::cout << "~Debugger()" << "\n";
        return true; /*debuger var*/
    }
    else
    {
        std::cout << "~Debugger()" << "\n";
        return false; /*debuger yok*/
    }
    
}
bool MyApp::timer()
{
    std::cout << "Timer()" << "\n";
    unsigned __int64 start = __rdtsc();
    std::this_thread::sleep_for(std::chrono::seconds(60)); // 60 saniye
    unsigned __int64 end = __rdtsc();
    unsigned __int64 cycles = end - start;
   
    // 1 GHz CPU için 60 saniyede ~60,000,000,000 cycles olur
    if (cycles < 30'000'000'000) {
        std::cout << "~Timer()" << "\n";
        return true; /*sandbox hızlandırması var*/
    }
    else {
        std::cout << "~Timer()" << "\n";
        return false; /*sandbox hızlandırması yok*/
    }
}
void MyApp::init()
{
    std::cout << "Init()" << "\n";
    std::this_thread::sleep_for(std::chrono::seconds(30)); // 30 saniye
    std::cout << "~Init()" << "\n";
}

Çıktı:

PS C:\Users\Utku\accenture> .\sandbox_detect.exe
Ortam Test Ediliyor...
Timer()
Debugger()
~Debugger()
Init()
~Init()
~Timer()
temiz

Görüldüğü üzere Init() in çağırılması için Timer ve debuggerın bitmesi beklenmedi

 

[sametghack]

Eline saglik

 

[Jusstthe]

Eline sağlık, koda birkaç refactor ekledim:

1 -

--- if (cycles < 30000000000) { // bu sayıyı okumak çok zor, C++ dilinde büyük sayılar tırnak ile ayırılabilir.
+++ if (cycles < 30'000'000'000) { // yeni hali

2 -
Bazı uygulamaların kendi init fonksiyonları yeterince zaman alabiliyor, bu durumda senkron bir CPU kontrolü tüm thread'leri (zaten tek thread var) 60 saniye bekletip performans kaybına yol açıyor. Hayali bir init fonksiyonumuz olsun ve bu fonksiyonu işlemek de başlı başına 30 saniye sürsün, tüm işlemler bittikten sonra bir de onu çağırıp 30 saniye beklemektense işlemleri önce hazırlayıp temizse programa devam edebiliriz. Bunun asenkron kontrolünü gerçekleştirmek için fonksiyonlara girerken ve çıkarken birer mesaj ekledim. Full Kod:

#include <iostream>
#include <windows.h>
#include <future>
#include <chrono>
#include <thread>
namespace MyApp {
bool debuger();
bool timer();
void init();
} //namespace MyApp
int main()
{
    SetConsoleOutputCP(CP_UTF8);
    SetConsoleCP(CP_UTF8);
    std::cout << "Ortam Test Ediliyor...\n";
    
    auto future_timer = std::async(std::launch::async, MyApp::timer);
    auto future_debugger = std::async(std::launch::async, MyApp::debuger);
    auto future_init = std::async(std::launch::async, MyApp::init);
    
    bool task1 = future_timer.get();
    bool task2 = future_debugger.get();
    if (task1 || task2)
    {
        std::cout << "analiz ortamı olabilir\n";
    }
    else
    {
        std::cout << "temiz";
        future_init.get();
    }
    system("pause");
}
bool MyApp::debuger()
{
    std::cout << "Debugger()" << "\n";
    if (IsDebuggerPresent())
    {
        std::cout << "~Debugger()" << "\n";
        return true; /*debuger var*/
    }
    else
    {
        std::cout << "~Debugger()" << "\n";
        return false; /*debuger yok*/
    }
    
}
bool MyApp::timer()
{
    std::cout << "Timer()" << "\n";
    unsigned __int64 start = __rdtsc();
    std::this_thread::sleep_for(std::chrono::seconds(60)); // 60 saniye
    unsigned __int64 end = __rdtsc();
    unsigned __int64 cycles = end - start;
   
    // 1 GHz CPU için 60 saniyede ~60,000,000,000 cycles olur
    if (cycles < 30'000'000'000) {
        std::cout << "~Timer()" << "\n";
        return true; /*sandbox hızlandırması var*/
    }
    else {
        std::cout << "~Timer()" << "\n";
        return false; /*sandbox hızlandırması yok*/
    }
}
void MyApp::init()
{
    std::cout << "Init()" << "\n";
    std::this_thread::sleep_for(std::chrono::seconds(30)); // 30 saniye
    std::cout << "~Init()" << "\n";
}

Çıktı:

PS C:\Users\Utku\accenture> .\sandbox_detect.exe
Ortam Test Ediliyor...
Timer()
Debugger()
~Debugger()
Init()
~Init()
~Timer()
temiz

Görüldüğü üzere Init() in çağırılması için Timer ve debuggerın bitmesi beklenmedi

Kod için teşekkürler ama global bir lock mekanizması kullanılsa ya da o ön hazırlıkların yapıldığı kod parçası bir başka fonksiyon içine alınsa daha iyi olmaz mı okunaklık açısından. Bir de o init fonksiyonundaki kod parçası sandbox analizi için şüpheli sonuçlar üretiyorsa, bu yaklaşım pek de mantıklı olmaz. Program o sürenin bitmesini beklemek zorunda kalır.

Eğer malware, sandbox'ları atlatmak zorunda ise ve bekleme gibi bir lüksü yoksa sandbox ortamını işaret eden belirtileri kontrol ederse daha iyi olur

 

[Hacknology]

Kod için teşekkürler ama global bir lock mekanizması kullanılsa ya da o ön hazırlıkların yapıldığı kod parçası bir başka fonksiyon içine alınsa daha iyi olmaz mı okunaklık açısından. Bir de o init fonksiyonundaki kod parçası sandbox analizi için şüpheli sonuçlar üretiyorsa, bu yaklaşım pek de mantıklı olmaz. Program o sürenin bitmesini beklemek zorunda kalır.

Eğer malware, sandbox'ları atlatmak zorunda ise ve bekleme gibi bir lüksü yoksa sandbox ortamını işaret eden belirtileri kontrol ederse daha iyi olur

Dediklerinizde tamamen haklısınız. Bu yüzden ben de koda refactor geçerken yazmalı mıyım diye üç dört kez düşündüm. Pratikten pratiğe değişeceğine karar verdim bu yapının, ama eğer Init() fonksiyonu gerçekten çok zaman alıyorsa sanırım en mantıklı yaklaşım bu, çünkü eğer sandbox ortamında değilsek hızlıca malware'i çalıştırmak isteriz, Init'in önceden hazırlanması bir avantaj sağlıyor. Eğer init çok zaman almıyorsa bu uygulama pek işe yaramaz, sandbox'a takılınca zaten çıkıyorsak ve overhead'in tamamı timer'da ise concurrent olmak zorunda değil. Bu ikilemin farkındaydım ama sadece farklı bir pratik olması açısından düzenledim

Edit: benim kodum da çok hoş değil bu arada, Jr. Developer bu kodu verse review'dan geçirmezdim. Aynı kodda iki farklı asenkron kodu kullanmak doğru değil, hem async/future hem de thread içe aktarma yaklaşımı hoş gelmedi gözüme yazarken. Sleep() daha çok hoşuma gitmediği için böyle yazdım

 

[Jusstthe]

Dediklerinizde tamamen haklısınız. Bu yüzden ben de koda refactor geçerken yazmalı mıyım diye üç dört kez düşündüm. Pratikten pratiğe değişeceğine karar verdim bu yapının, ama eğer Init() fonksiyonu gerçekten çok zaman alıyorsa sanırım en mantıklı yaklaşım bu, çünkü eğer sandbox ortamında değilsek hızlıca malware'i çalıştırmak isteriz, Init'in önceden hazırlanması bir avantaj sağlıyor. Eğer init çok zaman almıyorsa bu uygulama pek işe yaramaz, sandbox'a takılınca zaten çıkıyorsak ve overhead'in tamamı timer'da ise concurrent olmak zorunda değil. Bu ikilemin farkındaydım ama sadece farklı bir pratik olması açısından düzenledim

Edit: benim kodum da çok hoş değil bu arada, Jr. Developer bu kodu verse review'dan geçirmezdim. Aynı kodda iki farklı asenkron kodu kullanmak doğru değil, hem async/future hem de thread içe aktarma yaklaşımı hoş gelmedi gözüme yazarken. Sleep() daha çok hoşuma gitmediği için böyle yazdım

Anti sandbox tekniklerinin de yer aldığı evasion tekniklerine değindiğim bir post'u buraya bırakayım o zaman

Konu içindeki mesaj 'crypteri olan varmı ?'

12 Eki 2024

Üstad crypter artık çok da aşırı işe yaramaz. Bildiğim kadarı ile ESET ile Avast artık memory snapshot alıyor düzenli, yani senin program hafızada decrypt edildikten sonra gene yakalanır. Diğer virüs tarama programları da aynı akımı izleyecektir. Windows defender da aynı haltı yaptığı anda kurban sayınız sıfıra inecektir.

Senelerdir dediğim gibi, trojan yedirmek istiyorsan üşenmeyip, tek bir satırı bile copy paste etmeden kendin yazarsın. Benim 7-8 sene önce zevk için yazdığım trojan, sadece payload'u scan ettirdiğimde bile hala 0 çekiyor. Vakit alır mı? Alır. Ama en mantıklı yol...

• Jusstthe

• 

 

[Hacknology]

Anti sandbox tekniklerinin de yer aldığı evasion tekniklerine değindiğim bir post'u buraya bırakayım o zaman

Konu içindeki mesaj 'crypteri olan varmı ?'

12 Eki 2024

Üstad crypter artık çok da aşırı işe yaramaz. Bildiğim kadarı ile ESET ile Avast artık memory snapshot alıyor düzenli, yani senin program hafızada decrypt edildikten sonra gene yakalanır. Diğer virüs tarama programları da aynı akımı izleyecektir. Windows defender da aynı haltı yaptığı anda kurban sayınız sıfıra inecektir.

Senelerdir dediğim gibi, trojan yedirmek istiyorsan üşenmeyip, tek bir satırı bile copy paste etmeden kendin yazarsın. Benim 7-8 sene önce zevk için yazdığım trojan, sadece payload'u scan ettirdiğimde bile hala 0 çekiyor. Vakit alır mı? Alır. Ama en mantıklı yol...

• Jusstthe

• 

Post da dahil olmak üzere mükemmel bir topic, elinize sağlık hepinizin

 

[Jusstthe]

Not: bu yöntemler gerçek zararlı yazılım analiz ortamlarından kaçamayabilir misal bakınız sandboxie api devre dışı bırakıyor.

Sandboxie'yi indirip baktım, C:\Program Files\Sandboxie\32\SbieDll.dll yolundan kendi kitaplığını izole alandayken çalıştırılan programa yüklüyor. Bu tespit edilirse programdan çıkış yapılabilir. Programdaki modülleri gezmek için yine WINAPI'daki fonksiyonlar kullanılabilir. MSDN açıklamış burada: Enumerating All Modules For a Process - Win32 apps

 

[Ecstasy07]

Merhaba forum üyeleri,


Bu başlık altında zararlı yazılım geliştirme sürecinde öğrendiğim bazı bilgileri ve deneyimlerimi paylaşmak istiyorum.


Yaptığım araştırmalara göre, bazı sandbox ortamları zararlıları analiz ederken belirli teknikleri kullanarak programları izole etmeye çalışır. Örneğin, Sleep() gibi fonksiyonlar programı uyutmak için kullanılırken, bu tür fonksiyonlar bazen sandbox ortamlarında hooklanarak devre dışı bırakılabilir. Bu gibi durumlar, zararlı yazılımın asıl niyetlerinin açığa çıkmasına yol açabilir.


Aşağıda, araştırmalarım sonucunda yazmış olduğum C++ kodu vardır . Bu kod, sandbox ortamlarını tespit edebilmek ve sandbox hızlandırmalarını analiz etmek amacıyla kullanılır. Kod, çeşitli yöntemler kullanarak analiz ortamlarının varlığını ve hızlandırmalarını algılayabilmektedir.

#include <iostream>
#include<windows.h>
bool debuger();
bool timer();
int main()
{
    SetConsoleOutputCP(CP_UTF8);
    SetConsoleCP(CP_UTF8);
    std::cout << "Ortam Test Ediliyor...\n";
    bool task1 = timer();
    bool task2 = debuger();
    if (task1 || task2)
    {
        std::cout << "analiz ortamı olabilir\n";
    }
    else
    {
        std::cout << "temiz";
    }
    system("pause");
}

bool debuger()
{
    if (IsDebuggerPresent())
    {
        return true; /*debuger var*/
    }
    else
    {
        return false; /*debuger yok*/
    }
}

bool timer()
{
    unsigned __int64 start = __rdtsc();
    Sleep(60000); // 60 saniye
    unsigned __int64 end = __rdtsc();

    unsigned __int64 cycles = end - start;
  

    // 1 GHz CPU için 60 saniyede ~60,000,000,000 cycles olur
    if (cycles < 30000000000) {
        return true; /*sandbox hızlandırması var*/
    }
    else {
        return false; /*sandbox hızlandırması yok*/
    }
}

Not: bu yöntemler gerçek zararlı yazılım analiz ortamlarından kaçamayabilir misal bakınız sandboxie api devre dışı bırakıyor.

Eline sağlık

 

[Captainati]

Sandboxie'yi indirip baktım, C:\Program Files\Sandboxie\32\SbieDll.dll yolundan kendi kitaplığını izole alandayken çalıştırılan programa yüklüyor. Bu tespit edilirse programdan çıkış yapılabilir. Programdaki modülleri gezmek için yine WINAPI'daki fonksiyonlar kullanılabilir. MSDN açıklamış burada: Enumerating All Modules For a Process - Win32 apps

Hepinize teşekkür ederim, yine beyin fırtınasının döndüğü, eski usul bir konu olmuş. Ayrıca Just’ın söylediklerini de detaylıca inceleyeceğim. Eskilerden @zztri reis'i de görmek isterdim ama sanırım artık aktif değil.


@Hacknology, kodu optimize ettiğin için sana da ayrıca teşekkür ederim.


Son olarak, yaptığım incelemelere göre bazı antivirüs yazılımları API'leri hook'layarak devre dışı bırakabiliyor gibi görünüyor. Bundan tam olarak emin değilim ama tersine mühendislik yoluyla daha detaylı inceleyeceğim.

 

[Jusstthe]

Hepinize teşekkür ederim, yine beyin fırtınasının döndüğü, eski usul bir konu olmuş. Ayrıca Just’ın söylediklerini de detaylıca inceleyeceğim. Eskilerden @zztri reis'i de görmek isterdim ama sanırım artık aktif değil.


@Hacknology, kodu optimize ettiğin için sana da ayrıca teşekkür ederim.


Son olarak, yaptığım incelemelere göre bazı antivirüs yazılımları API'leri hook'layarak devre dışı bırakabiliyor gibi görünüyor. Bundan tam olarak emin değilim ama tersine mühendislik yoluyla daha detaylı inceleyeceğim.

Kesin olarak hook'luyorlar hocam. Özellikle Avast, Kaspersky, ESET, Bitdefender