[Brookit]

Seems like ZeroAccess has a TDL3 disabling routine.

Interesting blog post: http://blog.webroot.com/2011/08/08/tdl3 ... -the-same/

[EP_X0FF]

Yeah, funny that they used this trick only now. The same stuff were working great for about 1.5 years.
Below is pseudo code from the mentioned in article TDL3 killer plugin.

Code: Select all

TDL_cfg = wcsstr(v6, L"cfg.ini");
 if ( TDL_cfg )
 {
       InitializeObjectAttributes(&attr, (LPWSTR)&TDL_path);
       fnKillTDLFile(&attr);

       wcscpy(TDL_cmd, L"cmd.dll");

       InitializeObjectAttributes(&attr, (LPWSTR)&TDL_cmd);
       fnKillTDLFile(&attr);

Code: Select all

NTSTATUS NTAPI fnKillTDLFile(OBJECT_ATTRIBUTES *pattr)
{
  NTSTATUS status;
  HANDLE hObject;
  IO_STATUS_BLOCK iost; 
   
  status = ZwCreateFile(&hObject, SYNCHRONIZE | FILE_WRITE_DATA | FILE_APPEND_DATA, pattr, &iost, 0, 0, 0, FILE_OVERWRITE_IF, FILE_SYNCHRONOUS_IO_NONALERT, 0, 0);
  if ( NT_SUCCESS(status) )
  {
    ZwWriteFile(hObject, 0, 0, 0, &iost, fnKillTDLFile, PAGE_SIZE, 0, 0);
    status = ZwClose(a1);
  }
  return status;
}

Killing performed by a special dll injected in the same processes, which were used by TDL3/4 cmd.dll.
It looks for TDL specific data in memory and analyzes it, then overwrite config, C&C dll, and finally doing hard reboot by using - NtRaiseHardError. After reboot - rootkit still active, but totally unworkable. TDL killing scheme is known since October 2009.

[rkhunter]

I tried to check this with sample of ZeroAccess from http://www.virustotal.com/file-scan/rep ... 1311072754 and TDL3 3.273 and result is negative: config and dll of tdl was not modified.

[EP_X0FF]

If you look above on code from this plugin you will notice file naming in TDL4 style. So it affects only TDL3 mod and TDL4. Aside from other bugs Eraser mislabeled his "article". Nobody not interested in preventing dead TDL3/3+ version from work.

[USForce]

I tried to check this with sample of ZeroAccess from http://www.virustotal.com/file-scan/rep ... 1311072754 and TDL3 3.273 and result is negative: config and dll of tdl was not modified.

You have to wait for the plugin being downloaded by the rootkit, it will take some time after you've installed ZeroAccess. Moreover the TDL3 variant must be the one that is using cmd.dll and cfg.ini naming conventions.

BTW that TDL3 routine is used by ZeroAccess since June '11

[rkhunter]

I tried to check this with sample of ZeroAccess from http://www.virustotal.com/file-scan/rep ... 1311072754 and TDL3 3.273 and result is negative: config and dll of tdl was not modified.

You have to wait for the plugin being downloaded by the rootkit, it will take some time after you've installed ZeroAccess. Moreover the TDL3 variant must be the one that is using cmd.dll and cfg.ini naming conventions.

BTW that TDL3 routine is used by ZeroAccess since June '11

Ok; as I know and as EP_XOFF wrote, this scheme of naming uses TDL4, TDL3 uses names tdlcmd.dll and config.ini.

[rkhunter]

I noticed a strange thing. Why almost all vendors detect dropper of MaxPlus as TDL dropper??

http://www.virustotal.com/file-scan/rep ... 1313392793

Although MS detect it as MaxPlus dropper,
http://www.microsoft.com/security/porta ... FSirefef.B

[EP_X0FF]

Even without looking on this sample, it is obvious that most patients copied Kaspersky detection which was originally likely based on the same crypter used.

[rkhunter]

From Kaspersky told that rename it in Trojan-Dropper.Win32.ZAccess.c.

[rough_spear]

Hi All, :D
i hv got dropper of Trojan.ZAccess.C.

MD5 : 9ac50c5125de30c50fe622a9ef53906f
SHA1 : 498431818e215bb0d0242ad744a6ab187281f7cb
SHA256: 49d4e98397e8824ab775fab82c896738c9b86f5d8b09ed0790c73d0b5fbfcd40

Regards,


rough_spear.