Shared publicly  - 
 
Odd files that showed up on a fresh Windows 8 install on an airgapped Thinkpad, which then unusually dissappeared from a CD burned on another airgapped fresh Windows 8.1 install on a random laptop a friend brought over from his office.
http://goo.gl/3pQbeZ kit.tgz
949437030 bytes - md5 7a64f35c2db85cc1f5cc1f5eefebb924e081b

TGZ archive with files individually compressed with unix compress inside. Be careful uncompressing them, they may cause side effects.
23
3
Glenn Hancock's profile photoRui Marques's profile photoJustin Gronholz's profile photoDragos Ruiu's profile photo
13 comments
 
I'm curious, when you said that packets were flowing even without the wifi and bluetooth cards being installed.  What were you using to see the packets since they would not have been going over a normal network path?  Or were they?

Thanks,
 
Just thinking here. If I had developed this malware and wanted to sell it. Infecting a known security analyst would be a nice demo for buyers.
Jamaa L
 
+Glenn Hancock The article states ""The airgapped machine is acting like it's connected to the Internet," which means its some how at least rebuilding Layer 2, and Layer 3 connectivity.  If the alien like level of sophistication described in the article is true and this malware was able to rebuild connectivity without using its typical hardware components, I am almost certain it would have the capabilities to record and replay previously used credentials to authenticate itself to a wireless network in which those packets the malware is transmitting can be seen.  That being said, how its actually doing this without the proper hardware is the true mystery.    

+Dragos Ruiu Can a mother fugger at least get a pcap please?
 
 Are we assuming there is a zero-day/unpublished exploit that provides a "listener" for said transmissions on an uninfected comp/hw? Also, what manufacturer's microphone and speakers are capable of reaching those high frequencies at a discernible db level for said "listener"? What am I missing here? 
Jamaa L
 
Its all post infection. Most likely a driver is dropped and it functions as the listening service for the ultrasound/highFeq signal from the machine disconnected/turned off. The listening service most likely functions as a proxy server and sends data back to the other host using the same method of ultrasound or highFeq signals
Jamaa L
 
+Dragos Ruiu is the malware infecting any virtual machines like vmware/virtualbox?
 
The monitoring tool was Procmon, and we didn't test virtualization, just real metal.
 
We will extract more from USB keys and hopefully provide more data after we put these on a USB analyzer. In the meanwhile I'm also posting more details here and on the ISC forums in the comment thread on their "haloween" diary entry. 
 
+Dragos Ruiu downloading the kit.tgz now; why is it so big out of curiosity? Normally virus files are not very big...... 
 
+Dragos Ruiu  -- I'm running on a Windows 8.1 VM and have opened the TTF files, even installed them, but am unable to find any virus-like behavior. Have any attempts been made to actually "test" these files for virus-like behavior? If so; what steps can re-produce such behavior?
 
Is it possible to read the BIOS and disassemble it, perhaps desolder the chip and fit a socket so you can read it on trusted hardware ?
 
+Andrew Daviel +Dragos Ruiu  Well I think the BIOS itself is the wrong place to look for - as manipulating the BIOS in such a way, that it still does what it is supposed to do and get own code within and fit that all into the flash - well, maybe possible - as usually there is space left too to do that.

As mentioned in another comment - the much easier way to get code within the pipeline at system initialisation would be the usage of extension bios images within hardware attached to the bus systems.

What happens at systems initialisation?

The bios gets awake and initialises the core system, than it scans the bus (certain rom->ram memory locations) for extinsion bios images. Usually this is used for custom code to initilise hardware like grafic cards or network interfaces with special functionality. The bios checks within the extension bios header for the hardware ids and a checksum and length of the image. Of those matches - the code gets control. After it is finished it returns to the bios.

So building a valid extension bios image and dropping that on a eeprom/flash of maybe the network card - which may have that but usually don't use it - is easy and you don't even have to touch a bit within the bios image to get that up and running - straight forward.

So it would be more quite interesting to have a look at those locations too or in the first place. As like it looks right now, this get's ignored easely... and therefore missed out.

In 2000 we used that within an intel eepro 100 network interface card, that provided 64k of space - for your own code, (with packing the code this could most probably scale up to 128 or more in space for the image).

Second note: It is also possible to have more than one of such images within one flash to get called by the bios during system startup. Therefore you set a pointer to the next image within the header of the first one fix the checksum and are done (yes you have to push that back on the chip but that is a solved problem, look at nowadays gfx special bios updates - that just run while your on windows -> that shows also possible infection paths) next boot and your done

TCP/IP Stacks are available with reduced functionality within a few kbytes - so that easily fits on beside still quite some space for other functionality.

So I'm keen to see those extension bios images droped and analyzed of the affected systems - are they clean? is there fancy code hidden?

Regards,
Add a comment...