[kerng]

What comes after is the interesting part. Because that's where the attacker will try to gain access to production and the clock for response and blue team for detection and eviction starts ticking.

Assume Breach mindset that Microsoft developed for instance - in case you are intersted to learn more. There is an entire domain/world of security engineering that starts when the initial compromise has happened. And it does/should not mean the adversary won, just because they have code execution on one host.

[swinglock]

If a malicious user gained access to your machine, how SSH is configured isn't interesting. If you use that machine to connect to other machines, the attacker will be able to as well, regardless of how SSH was configured at the time.

Heck, the attacker prefers a certain SSH config, the attacker could just change it. Even if you disabled the feature at compile time, the attacker could just replace the SSH command in your shell with their preferred version.

This is just disabling useful features to maybe cause minor inconvenience. I find it about as interesting as telling someone to pull out the power cord of their monitor to increase security of their login prompt screen.

[kerng]

How machines are configured is very interesting, as adversaries make mistakes, and cam trigger detection for suspicious behavior. There is an entire security field that is concerned about what happens after a breach.

Coinbase recently had a very interesting article/blog post about something similar, how adversaries gained access to engineering hosts and how they detected it.

Of course how much you lock something down depends on the critically of an asset and so forth. E.g. in certain high security facilities slight variations of your monitor example are applicable.

[swinglock]

That's a good point. If the attacker changes configuration or drops binaries, they make noise instead of living off the land care free, which make them easier to detect. I see.