The technique of observing syscalls has clear benefits. However might there be ways of evading this simply by setting up a some kind of delayed process so the syscall doesn't happen during the observation window or is only triggered rarely or on certain combinations that might not typically be tested (meaning it could still be caught in theory but the chances are much lower)?
1) The “observable window” is the entire installation time. If they make installs take forever, that’ll affect everyone which should raise alarms pretty quick.
2) The conditional execution is possible but the installation is done using a vanilla alpine container which will match many legitimate hosts too. And any fingerprinting activities that involve syscalls would be detected in the process.
All this to say, there’s always room to continue raising the bar!
On a dev machine though... diabolical. That might show up in a syscall, but perhaps not obviously enough that it sets off alarms.
That's the thing. If we're watching syscalls, we see these checks. These would be things like attempted file-reads. Would they be enough to set off alarms? Maybe, maybe not.
This is generally the cat/mouse game of malware detonation in general. There are attempts to make sandboxes appear realistic, but I'd argue that our use case is even simpler since running commands or making network connections during installation is not a normal thing. It might be benign, but it's abnormal enough to warrant investigation.
There will always be ways to try and get around the system, but I'm pretty firm that this will significantly raise the bar which is a Good Thing.