HN Reader

Huh so new antimalware tactic: Buy passively cooled PC :)

And also set up a Russian keyboard: https://krebsonsecurity.com/2021/05/try-this-one-weird-trick...

I wonder if this could be used to throttle vms, like I'd like to set something like "this vm can only use at most x% of a cpu" measured over y time.

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.

Lovely writeup! 10/10

> But that’s smol pp way of thinking. We can do better.

Can we remove casual body shaming from our language please?

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.

There are moments where I consider myself a good engineer and then I read posts like this and realize im a very little fish in a very big ocean

I haven't bought a computer cooled by a fan in over 13 years.

What's up with the body shaming in this article?

> But that’s smol pp way of thinking

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.

> Your first impulse might be to use DLL hooking and patch the cimwin32. But that’s smol pp way of thinking.

i hate every last thing about what people in this world have become. i would like to ask for an asteroid the size of the one that killed the dinosaurs to strike the earth at the same velocity and at the same angle as that one. immediately. our species is an enormous failure.

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.

What an arcane piece of tech. Why not use EFI?

> 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.

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.

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.

Fascinating article. It prompted two questions for me:

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?

> Your first impulse might be to use DLL hooking and patch the cimwin32. But that’s smol pp way of thinking. We can do better.

What's wrong with DLL hooking though?

That’s nothing. I make my VMs think they have dust.

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.

I guess that's a gap for a new tool to be developed. Emulate as much hardware as possible, to make a VM look like a real PC. Maybe also faking the CPU ID, to fake another CPU type with less performance (from the same series), so malware can't even detect the lower performance caused by virtualization, or lower core count.

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.

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

Hang on, does this mean the MacBook Air is less vulnerable to some malware?

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.

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.

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.

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?

> smol pp way of thinking

apt install laugh

> 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.