Frankenstein Malware

Frankenstein Malware Extra Credit Blog Post

Crystal Hansen for CIS 127

                Frankenstein Malware is a method of malware creation deliberately designed to slip past anti-virus/anti-malware software.  The intention, I believe, is to discover and create a new and stronger potential threat so that we can find the tools to combat it, and secure our systems. 

                It’s built upon past obfuscation methods, and pieced together using prior work, but in a different way, with differing results.   There’s more to it than that, as Vishwath Mohan and Kevin W. Hamlen, from the University of Dallas, Texas, School of Electrical and Computer Science, explain in their paper.  This research was funded in part by the Air Force and National Science Foundation.  There is a footnote included though, that the contents of their paper in no way expressed the views of either of these institutions.

                In very simple terms, Frankenstein uses code, binaries, and “gadgets” already on a computer (legitimate programs) to piece together malware that goes undetected.  If a program is considered benign, Frankenstein can use pieces of it and others like it to stitch together a mutant.  This technique relies primarily on return-oriented programming for gadget discovery.  Their definition of a gadget here is “any sequence of bytes that are interpretable as valid x86 instructions” ( (Mohan and Hamlen 2).

They found that only a very small number of binaries from sys32 folder in Windows was enough to yield a diverse amount of gadgets.  Diversity is key since the point is to blend in with as many benign codes as possible. 

For each successful gadget assignment, Frankenstein masks
all external calls in the code by converting them into computed
jumps. As a result, Frankenstein’s mutants have no noteworthy
system calls in their import address tables, concealing them
from detectors that rely upon such features for fingerprinting.
The last step is injecting the finished code into a correctly
formatted binary so it can be propagated. Frankenstein has a
binary parsing component and a seed binary that it uses as a
template. For each mutant, it injects the code into the template
file and updates all relevant metadata in the header. At this
point the new mutants are natively executable programs (5).

The size of these mutant programs ends up being almost double the original versions but if they can still go undetected, I suppose that would be worth it.  That is, if you think creating a mutant malware is worth it.  I assumed they called it Frankenstein because it’s an attention grabber even for people who have never read the actual book.  The scientist who created the creature (in this case our mutant malware), was Frankenstein, and the creature was nameless.  He was stitched together as well from harmless parts.  At first, he was harmless himself, but enormous and frightening.  The fear, I suppose it that this, too, can get out of hand and become yet another security threat that we might have trouble combatting. 

Hamlen and Vishwath would be the Frankenstein scientists here, and their malware formula would be the creature we’ll just have to wait and see about.  I do doubt that it will take over.  If you can make it, you can unmake it, and assessing security threats and how to combat them, especially potential security threats, to get ahead of the game, is a work worth pursuing. 

Works Cited

Mohan, Vishwath and Kevin W. Hamlen. Frankenstein: Stiching Malware from Benign Binaries. Paper. Berkeley: USENIX, 2012. PDF. 25 Oct 2015. <https://www.usenix.org/conference/woot12/workshop-program/presentation/Mohan>.