Using such tricks might seem like a cute way for malware to make analysis difficult, but often times calling these obscure system APIs can be detected statically, and you bet that it will flagged as suspicious by AV software. If the malware binary is not obfuscated to hide such calls, I'd even call them "counterproductive" for the malware authors!
The legit programs interested in these APIs are almost always binaries signed by well known (and trusted) CAs - making it sensible for the analysis to report sus behavior.
I worked as a junior in this field, and one of my tasks was to implement regex pattern matching to detect usages of similar APIs. Surprisingly effective at catching low hanging fruit distributed en masse.
Malware is signed surprisingly often these days, you can't rely on malware companies not to sign their binaries anymore. Hacked code signing certificates seem to be all over the place and Microsoft seems very reluctant to revoke trust out of fear of actually breaking their original customers' software.
Same goes for the common vulnerable drivers that malware likes to load so they can get into the kernel. A weird tiny binary making WMI calls may stand out, but a five year old overclocking utility full of vulnerabilities doing the same queries wouldn't.
From the research I've read, this doesn't seem to be about avoiding detection as much as it's about not detonating the real payload on a malware analyst's machine. If the AV flags the binary or the detection trips, the second stage isn't downloaded and the malware that does stuff that makes the news doesn't execute (yet).
Anti virus software just guessing what is and isn’t malware by analysing static calls is actually really annoying. If you’re doing that then why not just make an allow list of trusted software and mark any software not in that list as being malware. It’ll work just about the same.
The trick is to become a company like "CrowdStrike", get your crappy software that runs at kernel level signed, then you can run all of the "suspicious" calls to sys apis all you want. Forget determining if it’s a VM or not.
Just push untested code/releases on production machines across all of your customers. Then watch the world burn, flights get delayed, critical infrastructure gets hammered, _real_ people get impacted.
_Legitimate_ companies have done more damage to American companies than black hat hackers or state actors can ever dream of.
The folks behind xz util within libzma aspire to cause the amount of damage companies like ClownStrike and SolarWinds have caused.
I am yet to see _any_ consumer-oriented motherboard where SMBIOS descriptions have even a passing relationship to the actual hardware. I would not be surprised if this malware would also fail in 50% of real hardware out there. But I also guess malware can afford this failure rate; as long as it guarantees it also fails on 100% of VMs/debuggers, it is worth it.
But if these assumptions are true then I'd presume malware authors would do timing checks rather than the trivially "emulable" SMBIOS.
> I am yet to see _any_ consumer-oriented motherboard where SMBIOS descriptions have even a passing relationship to the actual hardware.
This seems to be especially true for cheap chineese boxes. If I had a dollar for every time I saw "to be filled in by OEM" strings in "live/production" BIOS images ... i'd be retired :).
Malware has bugs. In fact some viruses have done far more damage than the author intended due to bugs.
There was a substantially effective virus years ago that made it around the world in 90 minutes, and it turns out a bug in its networking code caused it to spread half as fast as it should have. Meaning it should have been everywhere in 45 minutes. You can still do a lot of damage without hitting every machine in existence.
Writing this from a passively cooled (Streacom FC8 Evo) Linux PC with a Russian keyboard.
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x002C, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0029
Type: <OUT OF SPEC>
Status: <OUT OF SPEC>
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Cooling Dev 1
Handle 0x002F, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0029
Type: <OUT OF SPEC>
Status: <OUT OF SPEC>
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Not Specified
Handle 0x0037, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0036
Type: Power Supply Fan
Status: OK
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Cooling Dev 1
Pretty funny that a blog post talking about complex and innovative ways to help investigate malware has a block of the lowest quality, scummiest ads that probably lead to malware.
I wonder if making a user endpoint actually look like a VM could help? Maybe adding some VM like flags to throw off some malware?
I feel that bad actors would catch on, but it might offer some protection for some low hanging vulnerabilities?
Mitre ATT&CK's T1497.001 (VM Detection) lists SMBIOS checks as a known vector means its open for injection anyways.
i did one little expirement on faking VM's powersupply. done it with 'HotReplaceable=Yes' and 'Status=OK', and you suddenly look like a $5k baremetal server.
This has always striked me as a weird choice, out of all places, one would think the generally computer savvy and technical "forum" would respect formatting as inputted, specially with how often code is discussed
Misread the title as "I made my VM think it WAS a CPU fan" and was a bit disappointed to find the actual article was not about a VM with an identity crisis.
If you don't mind sharing, what's your exact setup? Fanless laptop (having read many of your previous comments - and found them very inspring -, I'm aware of your modest/text-only needs) or something really spartan like a USB-booting OS, etc? Many thanks.
This reminds me of how having the right SMBIOS was necessary to create a working Hackintosh. There are so many of these relatively obscure APIs which have been added to the PC over the years, which are often overlooked by those writing virtualisation software, and malware and other VM detection software often tries to poke at them to see how real they look.
A next step to making the VM look real is having simulated temperature sensors that actually change in response to CPU load.
> Or maybe just increments to absurd numbers or negative values. Or locks up when probed.
unironically that would mimick a bunch of existing hardware out there. I owned a PC motherboard that always reported a -65535c in a non existing sensor.
my guess is some sensor described but non existing, probably reporting an infinite value of resistance of some unused pin...
I friend of mine in the infosec business spends most of their time (it seems to me) to make their malware honeypots super representative of their respective hardware. Whether its a windows XP based thermostat, a Siemen's PLC controller, or a banker's desktop PC, its kind of amazing the things they do.
> Frankly, I did not miss this at first. I just hoped that what I was trying to do was not “overriding” the predefined structure.
> Because Xen (or rather hvmloader) does not define it.
> So, before defining it myself, I tried to find out if there was any other poor soul who tried to do the same thing before me. And to my disappointment, there was. Right in the xen-devel patch archive.
> Why it was my disappointment, you may ask? Because after reading the response to the patch, I felt the frustration of the author.
Specifically, the patch is annotated "SMBIOS tables like 7,8,9,26,27,28 are ne[c]essary to prevent sandbox detection by malware using WMI-queries."
And the rejection is in two points:
(1) Why is that valuable?
(2) What if there were other tables that also helped with that goal? Your patch doesn't include them.
There's lots of interesting things in dmidecode, including the asset tag of the machine. If anyone is interested, on both Lenovo and Super micro servers you can set the asset tag. Lenovos do it with Redfish, with Supermicros, you have to use their "sum" tool.
Using it, you can also modify the model name and serial number of your Super micro motherboard. Which cam be useful when your idiot system integrator can't be assed to set them correctly themselves.
> Some malware samples are known to do various checks to determine if they are running in a virtual machine.
Not just malware, but some apps are known to do this too, e.g. WeChat.
There needs to be a better virtual machine that tries to emulate everything, including random walks for GPS, IMU noise, barometric noise, temperature fluctuations etc.
I feel like we could make our operating system more secure and make things easier for researchers by simply making a normal OS look like a virtual machine. Any program that needs to access resources in a non-virtualized way would have to ask for permission first. If granted, it could then see the relevant information or access the necessary APIs.
This way, malware authors would have to choose between making things easier for researchers or targeting far fewer people.
Either way, everyone except the malware creators wins.
Anti-cheat software vendors would lose as well. I prefer the software I run to know its place, but there are enough people who enjoy multiplayer games that hate cheaters more than they hate what amounts to spyware.
This is a huge, huge, huge amount of work. Even the most obvious things -- like "can you run a VM?" -- can require huge support, in that case even from the hardware, when you want to do them within a VM.
Genode / SculptOS[0] go this direction. Before starting any process, you craft a view of the hardware resources it will see. Applications come with resource request definitions which you can satisfy by attaching real, virtual, or null resource.
It's a pretty neat system; runs Doom, so we know it's production ready; and the source is meticulously organized.
The docs try to be overly general, IMHO, clouding the core ideas. If you're interested, I recommend just spinning up a VM and mucking about, along with the user guide.
I found that jarring as well. I'm all for mixing in a jovial, even immature tone to keep technical blog posts interesting but at the very least I'd prefer to keep it non-vulgar.
The large majority of humans adapt our language to the context and the audience every time we open our mouths or put our hands on the keyboard. I’d like the author to do a little more of that.
This forum needs a code of conduct. We need to be civil and productive. But I think a blog post should have more freedom. If the author made an ignorant choice of phrase, then a comment about it would be appropriate. But choice of dark/crass humor should not be reprimanded. I don't want to be posh and well mannered in my own home. No masks; let me be as disgusting and pathetic as I can be.
It may feel harmless to you, but research consistently shows a large proportion of men feel insecure about their penis size [1].
Let’s assume those studies are off by an order of magnitude and it’s only 1% of men who feel insecure about their penis. In the US, that’s still 1.7 million men.
If I had to choose between vulgar jokes and two million people having a better relationship with their bodies, I know where my priorities lie.
Personal sites are like the last bastions of free speech on the internet, you really want to censor that because it may offend someone who is voluntarily reading it?
Of everything going on at the moment, like senseless wars, countries plagued by mass child abuse or forced organ harvesting, you chose to question the humanity's worth because of a smol pp joke?
This has applications for other kinds of malware. I used to work in ads, to put it mildly, and all this stuff about blocking the trackers at the DNS level or something? Very silly stuff.
If you want to fuck up surveillance capitalism, you send plausible but wrong information to the trackers. There are a zillion ways to do this: let one through now and again and replay it, do a P2P browser extension that proxies you and someone near you through each other, subtly corrupt it, bounce it off a mullvad node. The possibilities are endless.
If you got a fair number of people doing it, you could even have some collective bargaining, like let some of the extreme value conversion stuff through in return for concessions on the more egregious tracking-for-the-sake-of-tracking.
Sure they'll checksum and shit, but that's a cat-and-mouse game they lose: the typical tracker cookie fire isn't worth shit, it's Superman 2 fractions of a basis point, so even modest effort playing smart against it drives the effective CPM negative.
When I was a teen and made a malware for the Apple II : I could inoculate disks by putting the hex value $50 in an unused place of the VTOC that was stored on disk. $50 is P which stands for Parasite. This was before the word virus had taken hold and I called my program a parasite. I could prevent the parasite from infecting my and my friends DOS disks with this benign change.
80 comments
[ 3.9 ms ] story [ 60.6 ms ] threadThe legit programs interested in these APIs are almost always binaries signed by well known (and trusted) CAs - making it sensible for the analysis to report sus behavior.
I worked as a junior in this field, and one of my tasks was to implement regex pattern matching to detect usages of similar APIs. Surprisingly effective at catching low hanging fruit distributed en masse.
Same goes for the common vulnerable drivers that malware likes to load so they can get into the kernel. A weird tiny binary making WMI calls may stand out, but a five year old overclocking utility full of vulnerabilities doing the same queries wouldn't.
From the research I've read, this doesn't seem to be about avoiding detection as much as it's about not detonating the real payload on a malware analyst's machine. If the AV flags the binary or the detection trips, the second stage isn't downloaded and the malware that does stuff that makes the news doesn't execute (yet).
Just push untested code/releases on production machines across all of your customers. Then watch the world burn, flights get delayed, critical infrastructure gets hammered, _real_ people get impacted.
_Legitimate_ companies have done more damage to American companies than black hat hackers or state actors can ever dream of.
The folks behind xz util within libzma aspire to cause the amount of damage companies like ClownStrike and SolarWinds have caused.
But if these assumptions are true then I'd presume malware authors would do timing checks rather than the trivially "emulable" SMBIOS.
This seems to be especially true for cheap chineese boxes. If I had a dollar for every time I saw "to be filled in by OEM" strings in "live/production" BIOS images ... i'd be retired :).
There was a substantially effective virus years ago that made it around the world in 90 minutes, and it turns out a bug in its networking code caused it to spread half as fast as it should have. Meaning it should have been everywhere in 45 minutes. You can still do a lot of damage without hitting every machine in existence.
And also set up a Russian keyboard: https://krebsonsecurity.com/2021/05/try-this-one-weird-trick...
Sensor data:
i did one little expirement on faking VM's powersupply. done it with 'HotReplaceable=Yes' and 'Status=OK', and you suddenly look like a $5k baremetal server.
cmd used
pip install dmigen dmigen -o smbios.bin \
--type0 vendor="American Megatrends",version="F.1" \
--type1 manufacturer="Dell Inc.",product="PowerEdge T630" \
--type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1
> But that’s smol pp way of thinking
https://news.ycombinator.com/newsguidelines.html
1) With the level of expertise, would it be as easy, or easier, to modify the check in the malware itself?
2) How much work would it be for a something like KVM to fake absolutely everything about a PC so it was impossible to tell it was a VM?
A next step to making the VM look real is having simulated temperature sensors that actually change in response to CPU load.
Or maybe just increments to absurd numbers or negative values. Or locks up when probed. Either way could be fun.
unironically that would mimick a bunch of existing hardware out there. I owned a PC motherboard that always reported a -65535c in a non existing sensor.
my guess is some sensor described but non existing, probably reporting an infinite value of resistance of some unused pin...
> Because Xen (or rather hvmloader) does not define it.
> So, before defining it myself, I tried to find out if there was any other poor soul who tried to do the same thing before me. And to my disappointment, there was. Right in the xen-devel patch archive.
> Why it was my disappointment, you may ask? Because after reading the response to the patch, I felt the frustration of the author.
Specifically, the patch is annotated "SMBIOS tables like 7,8,9,26,27,28 are ne[c]essary to prevent sandbox detection by malware using WMI-queries."
And the rejection is in two points:
(1) Why is that valuable?
(2) What if there were other tables that also helped with that goal? Your patch doesn't include them.
If there's anything I've painfully learned in my career, is to not let perfect get in the way of good enough.
Using it, you can also modify the model name and serial number of your Super micro motherboard. Which cam be useful when your idiot system integrator can't be assed to set them correctly themselves.
Not just malware, but some apps are known to do this too, e.g. WeChat.
There needs to be a better virtual machine that tries to emulate everything, including random walks for GPS, IMU noise, barometric noise, temperature fluctuations etc.
This way, malware authors would have to choose between making things easier for researchers or targeting far fewer people.
Either way, everyone except the malware creators wins.
Or perhaps the other way around?
That is making VMs totally unaware they've been virtualised, as I believe IBM's lpars work…
This is a huge, huge, huge amount of work. Even the most obvious things -- like "can you run a VM?" -- can require huge support, in that case even from the hardware, when you want to do them within a VM.
It's a pretty neat system; runs Doom, so we know it's production ready; and the source is meticulously organized.
The docs try to be overly general, IMHO, clouding the core ideas. If you're interested, I recommend just spinning up a VM and mucking about, along with the user guide.
[0]:https://genode.org/download/sculpt
The large majority of humans adapt our language to the context and the audience every time we open our mouths or put our hands on the keyboard. I’d like the author to do a little more of that.
Let’s assume those studies are off by an order of magnitude and it’s only 1% of men who feel insecure about their penis. In the US, that’s still 1.7 million men.
If I had to choose between vulgar jokes and two million people having a better relationship with their bodies, I know where my priorities lie.
[1]: https://www.issm.info/sexual-health-qa/what-percentage-of-me...
https://news.ycombinator.com/newsguidelines.html
When where we different?
If you want to fuck up surveillance capitalism, you send plausible but wrong information to the trackers. There are a zillion ways to do this: let one through now and again and replay it, do a P2P browser extension that proxies you and someone near you through each other, subtly corrupt it, bounce it off a mullvad node. The possibilities are endless.
If you got a fair number of people doing it, you could even have some collective bargaining, like let some of the extreme value conversion stuff through in return for concessions on the more egregious tracking-for-the-sake-of-tracking.
Sure they'll checksum and shit, but that's a cat-and-mouse game they lose: the typical tracker cookie fire isn't worth shit, it's Superman 2 fractions of a basis point, so even modest effort playing smart against it drives the effective CPM negative.