Well, at present that's my guess, but I am still pretty much in the dark here.
"tempAdministrator" is a username I would hardly use for any reason, and I can't really remember creating it.
However, while my home server may be for weeks or months sitting there alone, reliably doing its many jobs, occasionally I am on it testing and experimenting, and I did entertain the idea that it could've been me to create such user; maybe I forgot, right? But what makes this unlikely, though, is that Windows Server usually creates only two users that are marked as "built-in": Adminstrator and Guest (the latter being disabled by default). As I always do, I renamed the built-in administrator account to something entirely different (not tempAdministrator), and that account is still there, unchanged. I use it occasionally for this or that (which is possibly not entirely wise in itself...). Guest is also still there, still disabled.
Interestingly, this other "tempAdministrator" was also described as "built-in", which is unexpected in my experience. No reason to have a second built-in Admin account in the server. If I created a second admin account, it would not be marked as "built-in", because it would not be such.
Hence, I am guessing that tempAdministrator is the product of some hacking.

Now, I have seen few exploits that ended up producing an admin-level command prompt being produced BEFORE LOGIN, in the past. I tested one myself and it did work.
Yes, pretty scary. AFAIK all those exploits have been fixed (some of them go back quite a few years, others not so many). But, that's the only thing I can imagine. If the hacker, when presented by the RDP login screen, managed to use some zero-day exploit to pull up a cmd.exe session, admin level, then it is going to be very easy to generate a new administrator-level account from scratch, and then use that to logon and implant the ransomware.
My guess is that all the errors I see in the logs claiming the RemoteDD security layer disconnected him, were his attempt at pulling up an admin-level cmd.exe session. Maybe a specific string entered in the username or password field would cause this (buffer overflow), or a more complicated sequence of events that can be initiated by the hacker somehow.

But, I am not even sure I am making sense here. This is just my best guess.

There's a lot of interesting info I did not share yet.

The logs, funny enough, show that my server returned an error for not having drivers for a printer named something in russian. This happens after the first successful rdp logon of Mr. tempAdministrator. So, that's the name of this guy's printer, which, as it happens, the server was trying to connect to upon rdp logon. In other words, if your client is so configured, once your rdp a remote machine your printer gets connected to the remote server, so you can print from there to your local printer. Pretty nice and convenient feature. So, that gave away the most likely nationality of the attacker. That, and three IP addresses he connected from (which I am sure are not precisely his, but still...):
46.161.40.180
188.19.127.194
185.61.148.250

This one, instead, is a US IP, the only one among them:
38.95.108.244

The first IP I listed is the one used more than once, and the one the final attack was carried on from.

Of course, as far as I know, the guy could be my beyond suspicion old lady neighbour in Rome. Who knows.

I did not have the time to investigate the logs for the machine name the attack came from, which *should* be in there.

Having, I think, now a possibly complete list of all the attempts in terms of date and time, there's a much narrower search I can make on all the many other system logs to find out more.

Not sure how useful this is going to be, but at least I now know more. Enough to have some peace of mind. And, as I rebuild my next server, I can do things to prevent this, as much as I can.