Malware Removal Information

Oudere varianten van TDSS gebruikten een driver (service) om zich na een herstart te activeren. Met de huidige variant is dit niet meer het geval en dat maakt het ook een stuk moeilijker om de infectie op te sporen.
De infectie wijzigt ook voortdurend en probeert zich op allerlei manieren onvindbaar te maken voor de diverse scanners.


Hoe werkt deze infectie?
De installer of de dropper die uitgevoerd wordt, kopieert zichzelf naar de Print Processor directory met een door het systeem gekozen willekeurige naam.
Er wordt een ander nieuw bestand aangemaakt en de kenmerken van dit bestand worden gewijzigd zodat het bestand wordt geconverteerd naar een .dll-bestand.
De installer (dropper) registreert dit dll-bestand als een Print Processor. Deze .dll wordt dan geladen door/onder spoolsv.exe.
Spoolsv.exe is een vertrouwd proces waarop firewalls nauwelijks of niet reageren en er wordt dus door ook geen alarm gegeven.
Het dll-bestand kan dus eigenlijk doen op de computer wat het wil zonder dat de computergebruiker gealarmeerd wordt.
Nu start de kernelmode fase en die bestaat uit 2 delen.

In fase 1 zal het .dll-bestand een nieuwe driver droppen en deze wordt geladen op kernelniveau.
Deze nieuwe driver dient eigenlijk om andere kernelcodes aan te roepen met als resultaat dat de eigenlijke rootkitdriver wordt uitgepakt.

Daarna start fase 2. De rookit achterhaalt wat de miniport driver is en de naam van het bijbehorende bestand. Dit bestand wordt dan geïnfecteerd.
Het infecteren van deze driver gebeurt door een bepaald aantal bytes (824) van de driver te overschrijven. Hierdoor blijft de bestandsgrootte van het bestand (driver) dus ongewijzigd.
vb: atapi met het bestand %systemroot%\system32\drivers\atapi.sys. In dit geval zal atapi.sys geïnfecteerd worden. (Afhankelijk van wat de miniport driver is)
De data die overschreven werd, wordt op de harde schijf opgeslagen.

Ook het entrypoint van de geïnfecteerde driver wordt gewijzigd. Dit gebeurt om te kunnen verwijzen naar de bytes met overschreven code van de driver.
De eigenlijke rootkitcode wordt niet meer opgeslagen in een bestand maar wordt rechtstreeks opgeslagen in de laatste sectoren van de harde schijf.

Na een herstart wordt de geïnfecteerde driver geladen en ook de 'overschreven 824 bytes code'.
Deze code zorgt dat de rootkitcode, opgeslagen in de laatste sectors van de harde schijf, geladen wordt.


Kenmerken in de logjes.
Gmer toont momenteel sporen van de infectie en ook de MBR-log in de ComboFixlog kan een indicatie zijn.
Het interpreteren van deze logjes is niet altijd evident en ze kunnen ook voor heel wat verwarring zorgen.
Opletten geblazen dus!

Wanneer je merkt bij de analyse dat er CD-emulators gebruikt worden, laat je deze best deïnstalleren.
Dit zal de analyse van de logs vergemakkelijken.  CD Emulators maken gebruik van rootkittechnologie. Deze 'hooken' in disc controller drivers en dit wordt gerapporteerd door GMER en mbr.exe.

Bij TDL3 infectie gaat Gmer in de log iets tonen zoals dit:

   ---- Kernel code sections - GMER 1.0.15 ----

   .rsrc C:\WINDOWS\system32\drivers\atapi.sys entry point in ".rsrc" section [0xF74CB3AC]

   ---- Devices - GMER 1.0.15 ----

   Device \Driver\00000404 -> \Driver\atapi \Device\Harddisk0\DR0 85F2C50C

   ---- Files - GMER 1.0.15 ----

   File C:\WINDOWS\system32\drivers\atapi.sys suspicious modification

   ---- EOF - GMER 1.0.15 ----


De mbr.exe log geeft zoiets bij een infectie:

  Stealth MBR rootkit/Mebroot/Sinowal detector 0.3.7 by Gmer, http://www.gmer.net

   device: opened successfully
   user: MBR read successfully
   called modules: ntkrnlpa.exe catchme.sys CLASSPNP.SYS disk.sys >>UNKNOWN [0x82EDB170]<<
   kernel: MBR read successfully
   detected MBR rootkit hooks:
   \Driver\Disk -> CLASSPNP.SYS @ 0xf760bf28
   \Driver\ACPI -> ACPI.sys @ 0xf749ecb8
   \Driver\iaStor -> iaStor.sys @ 0xf7430852
   IoDeviceObjectType -> DeleteProcedure -> ntkrnlpa.exe @ 0x80579022
   ParseProcedure -> ntkrnlpa.exe @ 0x80577c84
   \Device\Harddisk0\DR0 -> DeleteProcedure -> ntkrnlpa.exe @ 0x80579022
   ParseProcedure -> ntkrnlpa.exe @ 0x80577c84
   NDIS: VMware Accelerated AMD PCNet Adapter #2 -> SendCompleteHandler -> NDIS.sys @ 0xf7324bb0
   PacketIndicateHandler -> NDIS.sys @ 0xf7331a21
   SendHandler -> NDIS.sys @ 0xf730f87b
   user & kernel MBR OK


(wanneer je mbr.exe start met de optie -i)
 
   called modules: ntkrnlpa.exe catchme.sys CLASSPNP.SYS disk.sys >>UNKNOWN [0x82EDB170]<<


Deze lijn toont ons geen disc controller, maar een ongekend iets (unknown). Dit wijst er op dat de driver gehooked is. Iets heeft zich vastgehecht aan de driver.
Welke driver dit is vind je in deze lijn:

   \Driver\iaStor -> iaStor.sys @ 0xf7430852

Hier gaat om iaStor.sys, maar dit kan evengoed een andere disc controller zijn (bv atapi.sys), afhankelijk van de computer.


Hoe kan je de infectie neutraliseren?
De geïnfecteerde disc controller driver moet je vervangen door een clean kopie.

Opsporen van een niet geïnfecteerd kopie?
Zoals hierboven beschreven kan je niet kijken naar de bestandsgrootte van de driver aangezien is deze voor en na de infectie ongewijzigd blijft.
In sommige gevallen kan je een MD5-check uitvoeren.
De MD5 checksum van een geïnfecteerd bestand is niet gelijk aan deze van een niet-geïnfecteerd bestand.

Maar altijd volstaat ook de MD5-check niet en ook de bestanden laten scannen op virustotal levert niet het gewenste resultaat.
Indien de rootkit actief is, toont het ons wat het ons wil laten zien of beter wat wij willen zien: een niet geïnfecteerde driver.
Dit maakt het moeilijk om de infectie op te sporen.
Goeie indicaties voor aanwezigheid van de infectie zijn browser redirects.

Verwijdertools:

• Kaspersky heeft een tool (TDSSKiller) die de gekende varianten kan opsporenen verwijderen. Meer info op deze site.
  

• Eset Removaltool: Olmarik cleaner.
• Bitdefender: TDSS / TDL4 Removal Tool 32-bit.
• Bitdefender: TDSS / TDL4 Removal Tool 64-bit.
• Norman: TDSS Cleaner.