Friday, November 24, 2006

Introducing Stealth Malware Taxonomy

At the beginning of this year, at Black Hat Federal Conference, I proposed a simple taxonomy that could be used to classify stealth malware according to how it interacts with the operating system. Since that time I have often referred to this classification as I think it is very useful in designing system integrity verification tools and to talk about malware in general. Now I decided to explain this classification a bit more as well as extend it of a new type of malware - the type III malware.

The article is available as a PDF document here.


Anonymous said...

TPM should detect type 3 malware due to the measured boot process. The TPM registers end up with a hash of all the code that executes during the boot, so they will have different values if you boot straight into the OS vs booting into a virtualized OS. If you have sensitive data locked to the TPM configuration registers, then you get infected with type 3 malware, the OS and apps will not longer be able to access the locked data and you can tell you've been virtualized.

Joanna Rutkowska said...

People’s ignorance is just unbelievable (see the post above)! I already wrote and said so many times that both Blue Pill as well as Vitriol (the two examples of type III malware) are non-persistent and that they do not require any modifications of a boot sequence in order to infect the system. Should they did introduce such changes, they would be classified as a type I (maybe type II at best) malware.

Anonymous said...

Hi Joanna !

Nice work. Thanks for the paper.Keep the good work going on :)


Viraptor said...

Do you know, of any patterns, that can be used in software, to make type II malware impossible / harder to apply?

I'm thinking about using hooks as in:
func_proto hooks[] = { our_func1, our_func2, ... };

Instead of just:
func_proto variable=&our_func1;

(pseudo-code, don't mind syntax)

This would make all pointers easy to verify, so only place for modifications is read-only data, or read-only code. But can any concept like this be applied to plug-in architecture?
I can only think about exchanging hooks[] with a list of hook arrays (every array owned by plugin itself), where every hook array has a hash generated with private key.
This kind of code, could verify it's data on-demand. Have you thought about that kind of designs / have some other ideas already? I think there should be some OS-supported way to get rid of all type II hackable places and change them to only type I hackable (like introducing syscall add_hook_table_to_verifiable_places_list). Would you agree with that?

I'd risk saying, that it could be even automatized in some VM...

Pozdrawiam :)

Viraptor said...

Adding to my previous comment -> proposed model for hashing of hook arrays is of course impossible in OSS software - or at least it has to be turned off for custom builds.
Only solution in that case would be to open some sort of compiled libraries verification / signing centre. Not possible in this reality. said...

Haj Dżoana :)

Szczęśliwego Nowego Roku, trzymaj się ciepło, jestem Twoim fanem :)))

Anonymous said...

your claim that

"I started researching ... and shortly after I created type III malware proof of concept."

appears inappropriate in light of Peter Chen's SubVirt paper:

as it seems that he was the one that did the research. And that he was the one that provided the proof of concept.

Joanna Rutkowska said...

To Dan: if you read my presentation about Blue Pill you would notice that I did a detailed comparison of SubVirt vs. Blue Pill and I pointed out why SubVirt is not type III malware – in fact it’s only a type I malware, as it needs to introduce changes o the booting processes and this is “something which should not be changed” (vide TPM).

Unknown said...

After seeing you initially in the 5 March 2007 edition of "eweek" and enjoying your blog I must say I am very happy and proud of you and your work. I've been in the information technology business since 1980 and at that time the ratio of males-to-females were about 60% to 40%. Today the female force in IT has dropped to almost nothing. Great work! Keep on pushing the envelope.

Anonymous said...

Hello Joanna,

we here at TDO (gov. dpt.) have already taken your work into account in 2006 and want to tell you now that you're indeed on the right track. The problem is the handling of large amounts of data when analyzing a type III malware infected system via an external device. Unfortunately we weren't yet able to handle this as well as the problem with false positives. We're looking forward to see you on CCC 2008 maybe with some new insights.

Yours sincerely TDO / Aq. Denton