Re: If it is in memory
Probably not, the malicious payload probably exists in either the bootloader or the UEFI partition. The way these sort of things work is when the OS is booted, a driver is injected before the OS is loaded...that way, when the OS itself is screened for possible backdoors and malware, you find nothing...these things can be introduced further up the supply chain (like at the board manufacturer) and on devices that are only ever meant to run a single OS, it's much easier to hide the malware because it can be smaller due to not having to be interoperable with more than one OS.
This is how a lot of those cheap Chinese router boards are infected...simply erasing the pre-installed OS and installing your own is not enough. They know you're probably buying them for OPNSense or pfSense or something and can hide a payload specific to those operating systems that gets redeployed, even if you do a clean install.
You also need to re-flash the firmware / BIOS with versions known to be clean, or versions that came straight from the developer (if you trust them) that can't have been tampered with in the supply chain.
Trouble is, even though it's fairly simple to find these dodgy payloads, the methods used to get there are still seen as something of a black art...but once you know, you know and it becomes trivial to check for these things...
1. You dump the BIOS (either via a command line tool or a chip reader, the latter is more reliable but the former is a lot easier).
2. You extract it and analyse it with binwalk...essentially, extract the drivers and custom binaries then binwalk those as well. These binaries typically tend to be fairly generic across different products so some rough file size comparisons etc can be made...anything that is dramatically bigger (or even smaller), probably has a sus payload in it.
3. Find a published copy of the firmware / BIOS on the internet (where possible) and do the same thing, compare what has been dumped from the device to what you see in the "legit" release.
It's difficult to be specific on what you're looking for, because sometimes you uncover things that haven't been seen before and therefore it's not really possible to say "look for exactly this" because that would lead you to write off the possibility of a backdoor if you find nothing that meets a specific criteria...which is just as dangerous (if not more dangerous) than not checking at all.
You could also do a checksum check, but that is very limited in what it tells you...all that tells you is that you're getting the binary that the developer intended to give you, it doesn't really tell you whether a binary is compromised or not...the developer themselves might not be immediately aware of supply chain tampering etc. like the SSH issue recently.
Biting the hand that feeds IT
