[sUBs]

I have attached an old copy of ComboFIx. Thank you for taking a look at this.

[thisisu]

@sUBs
While I cannot provide you a detailed analysis like EP_X0FF, from reviewing some of the logs from other tools that we were able to run (after ComboFix fails), we see an entry like this in the services section:

Code: Select all

2 PEVSystemStart; "C:\32788R22FWJFW\pev.3XE" EXEC /i CSCRIPT.exe //NOLOGO //E:VBSCRIPT //B //T:15 "C:\32788R22FWJFW\KNetSvcs.vbs" [407 2012-05-20]

Maybe this provides some information you seek :?
Anyways, glad to hear you found a workaround in the meantime ;)

[EP_X0FF]

I've disabled both ZeroAccess working threads suspending infection and it still cannot properly start. Then I manually cleaned registry entries responsible for mapping ZeroAccess payload to explorer.exe (HKCR\CLSID\{F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1}\InprocServer32 and {bbd38d41-4b71-40a2-85c6-e2628751e592}), restarted explorer to free from backdoor code and tried Combofix again - without any changes. So I guess since your tool is multicomponent it fails somewhere on installation process, something sets failure marker and cannot work anymore no matter what. You should add detailed logging of startup, because of bunch tools used it is very hard to trace.

[EP_X0FF]

Unpacked x86 "n" attached. Real name of this Sirefef component is "p2p.32.dll", x64 version - "p2p.64.dll", compiled from the same project definitely.

[sUBs]

I've disabled both ZeroAccess working threads suspending infection and it still cannot properly start. Then I manually cleaned registry entries responsible for mapping ZeroAccess payload to explorer.exe (HKCR\CLSID\{F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1}\InprocServer32 and {bbd38d41-4b71-40a2-85c6-e2628751e592}), restarted explorer to free from backdoor code and tried Combofix again - without any changes. So I guess since your tool is multicomponent it fails somewhere on installation process, something sets failure marker and cannot work anymore no matter what. You should add detailed logging of startup, because of bunch tools used it is very hard to trace.

I assume this was tested on an XP machine. Irregardless of how ComboFix works, here's a simple test.

At the root of C:\, there will be a folder named '32788R22FWJFW'. To access/enter the folder, remove the 'System' attribute from the folder's properties.
Once inside, you will see a file named cmd.3XE which is actually a renamed copy of Windows' cmd.exe
Double click cmd.3XE to launch it. It gets terminated almost immediately. That's ZeroAccess'' doing.
Now if one copies cmd.3XE to another folder, for example C:\cmd.3XE, then launching it from there would not be a problem.
So long as it isn't in the 32788R22FWJFW folder, it wont get killed. One can even CD (change working directory) back into the 32788R22FWJFW folder without any issues.
Now if one renames 32788R22FWJFW to another name, e.g. XPEOFF, double clicking cmd.3XE from there, still wont work. So I'm thinking this blockade has to be based on a set of conditions.

[EP_X0FF]

I assume this was tested on an XP machine. Irregardless of how ComboFix works, here's a simple test.

Yes.

At the root of C:\, there will be a folder named '32788R22FWJFW'. To access/enter the folder, remove the 'System' attribute from the folder's properties.
Once inside, you will see a file named cmd.3XE which is actually a renamed copy of Windows' cmd.exe
Double click cmd.3XE to launch it. It gets terminated almost immediately. That's ZeroAccess'' doing.
Now if one copies cmd.3XE to another folder, for example C:\cmd.3XE, then launching it from there would not be a problem.
So long as it isn't in the 32788R22FWJFW folder, it wont get killed. One can even CD (change working directory) back into the 32788R22FWJFW folder without any issues.
Now if one renames 32788R22FWJFW to another name, e.g. XPEOFF, double clicking cmd.3XE from there, still wont work. So I'm thinking this blockade has to be based on a set of conditions.

Cannot reproduce, cmd.3xe working well. But execution of c.bat leads to termination. PEV.3XE thrown STATUS_ACCESS_VIOLATION as second chance exception.

[sUBs]

Lol .. thank you for testing. Guess, I'm just a mess. Hopefully, the workaround will hold for some time.

By the way, I want to take the opportunity to say that you do great work around here.

[EP_X0FF]

Sirefef installation folder UUID prediction algorithm. All credits to Sirefef authors.

Code: Select all

typedef struct {
	ULONG i[2];
	ULONG buf[4];
	unsigned char in[64];
	unsigned char digest[16];
} MD5_CTX;

typedef void (__stdcall *PMD5Init) (MD5_CTX *context);
typedef void (__stdcall *PMD5Update)(MD5_CTX *context, const unsigned char *input, unsigned int inlen);
typedef void (__stdcall *PMD5Final) (MD5_CTX *context);

PMD5Init MD5Init = NULL;
PMD5Update MD5Update = NULL;
PMD5Final MD5Final = NULL;

typedef struct _FILE_FS_VOLUME_INFORMATION {
	LARGE_INTEGER VolumeCreationTime;
	ULONG         VolumeSerialNumber;
	ULONG         VolumeLabelLength;
	BOOLEAN       SupportsObjects;
	WCHAR         VolumeLabel[1];
} FILE_FS_VOLUME_INFORMATION, *PFILE_FS_VOLUME_INFORMATION;

typedef struct _SfUUID {
	DWORD value0;
	WORD value1;
	WORD value2;
	BYTE value3;
	BYTE value4;
	BYTE value5;
	BYTE value6;
	BYTE value7;
	BYTE value8;
	BYTE value9;
	BYTE value10;
} SfUUID, *PSfUUID;

BOOLEAN SfCalcVolumeMD5(
	PBYTE MD5Hash
	)
{
	OBJECT_ATTRIBUTES obja;
	IO_STATUS_BLOCK iost;
	UNICODE_STRING str;
	NTSTATUS Status;
	BOOLEAN result = FALSE;
	HANDLE hVolume = NULL;
	
	MD5_CTX ctx;
	FILE_FS_VOLUME_INFORMATION fsVolumeInfo;

	if ( MD5Hash == NULL )
		return result;

	RtlInitUnicodeString(&str, L"\\systemroot"); 
	InitializeObjectAttributes(&obja, &str, OBJ_CASE_INSENSITIVE, NULL, NULL);

	Status = NtOpenFile(&hVolume, FILE_GENERIC_READ, &obja, &iost, 
		FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, FILE_SYNCHRONOUS_IO_NONALERT);
	
	if ( NT_SUCCESS(Status) ) {

		Status = NtQueryVolumeInformationFile(hVolume, &iost, &fsVolumeInfo, 
			sizeof(FILE_FS_VOLUME_INFORMATION), FileFsVolumeInformation);

		if ( ( NT_SUCCESS(Status) || Status == STATUS_BUFFER_OVERFLOW ) ) {

			MD5Init(&ctx);
			MD5Update(&ctx, (unsigned char*)&fsVolumeInfo.VolumeCreationTime, sizeof(LARGE_INTEGER));
			MD5Final(&ctx);
			memcpy(MD5Hash, &ctx.buf, 16);
			result = TRUE;
		}
		NtClose(hVolume);
	}
	return result;
}

VOID SfBuildString(
	PBYTE MD5Hash,
	PWCHAR String
	)
{
	PSfUUID p = (PSfUUID)MD5Hash;

	swprintf(String, L"{%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x}",
		p->value0, p->value1, p->value2, p->value3,
		p->value4, p->value5, p->value6, p->value7,
		p->value8, p->value9, p->value10);
}

BOOLEAN SfInitMD5(
	VOID
	)
{
  HMODULE hLib = LoadLibraryW(L"Cryptdll.dll");
  if ( hLib == NULL )
	  return FALSE;
  
  MD5Init = (PMD5Init) GetProcAddress(hLib, "MD5Init") ;
  MD5Update = (PMD5Update) GetProcAddress(hLib, "MD5Update") ;
  MD5Final = (PMD5Final) GetProcAddress(hLib, "MD5Final") ;
  return TRUE;
}

VOID SfMain()
{
	BYTE Buffer[0x20] = {0};
	WCHAR String[0x100] = {0};

	SfInitMD5();
	SfCalcVolumeMD5(Buffer);
	SfBuildString(Buffer, String);
	OutputDebugStringW(String);
}

[SecConnex]

Hope this may provide assistance, betwixt my recent investigation of Sirefef:

When new DNSChanger is installed, this is dropped:
C:\Windows\Installer\{792f4199-0b73-e2f4-7b46-706eb422a6b8}\L\00000008.@
C:\Windows\Installer\{792f4199-0b73-e2f4-7b46-706eb422a6b8}\L\00000004.@
C:\Windows\Installer\{792f4199-0b73-e2f4-7b46-706eb422a6b8}\U\000000cb.@
C:\Windows\Installer\{792f4199-0b73-e2f4-7b46-706eb422a6b8}\U\00000004.@
C:\Windows\Installer\{792f4199-0b73-e2f4-7b46-706eb422a6b8}\@

Random redirect client: c:\windows\iun6002.exe (could be part of BitCoin Miner)

Which tells me, this apparent new variant of Sirefef is combined with bits of DNSChanger to help secure access. When ComboFix begins to load, and checks explorer.exe or svchost.exe modules, it must be terminated. Hope I'm right about module checking. Last version I saw, it was messing with svchost.exe, placing in its own module svchost:<RANDOM-ADStream>.

Looks like Sirefef is opening files from a device driver...then writing MD5 strings in C...what gives? Changing device driver code?

[EP_X0FF]

Looks like Sirefef is opening files from a device driver...

Current version has no devices drivers.

then writing MD5 strings in C...what gives? Changing device driver code?

No it don't. This is Universally Unique Identifier (UUID) generation for Sirefef folder name. It calcs MD5 for system volume creation time value and converts it in UUID format. It is obvious from code posted above.