I believe the issue was related to the fact that the user running Jenkins was a full passwordless sudo user.

Maybe the attacker used the groovy console too...

No the author seems to indicate that it was on their application code and an attacker was able to get OS access, and the attacker subsequently replaced the ssh service with one that instead ignores login attempts and harvests the username/password pairs.

It seems to have been a coincidence that their Jenkins service was not secured.