> Each sample of the malware contains a hardcoded name of the victim organization.<p>> Apart from encrypting the files and leaving ransom notes, the sample has none of the additional functionality that other threat actors tend to use in their Trojans: no C&C communication, no termination of running processes, no anti-analysis tricks, etc.<p>> Curiously, the ELF binary contains some debug information, including names of functions, global variables and source code files used by the malware developers.<p>Seems pretty amateurish...
Rule #1 -- Always be backing up.<p>Rule #2 -- Never download and execute binaries from the Internet if you can't track it to reputable source. Linux will not help if you execute it.<p>Rule #3 -- If you can't track it but need to run anyway, jail the heck out of it. Create a VM and run it inside, disabling also its ability to use network for anything else than reaching the Internet. Make sure it can't reach any other machine in your network or ports on your PC through loopback.
Mbedtls is small code size configurable build library. I am not surprised they’re using it, it embeds with applications or firmwares easily and has a decent API. Which cannot be said for openssl.
As somebody who has switched to Linux-only (desktop+servers) years ago, seeing how ransomeware gets "ported" to Linux makes me overthinking my backup system.<p>Has anybody experience with immutable backups? This is so important, because many ransomeware codes attacks backups first.<p>I think offline backups on write-once media are the safest. A DVD-RW is the only thing I can think of, but this is quite elaborate and doesn't seem contemprary in 2020. Do I miss something?