This is probably not going to be that satisfactory a response.
For the first question, to find out more about any IP address, you can use standard IP network tools like nslookup, dig, and whois. When I use nslookup like in the first attached screenshot, with "set type=PTR" so I can convert an IP address to a DNS name instead of the other way around, and with "set debug" so I get more complete information, it tells me that the PTR record for 211.185.77.45.in-addr.arpa resolves to 45.77.185.211.vultrusercontent.com. Then when I did an SOA search in nslookup for vultrusercontent.com. (the . at the end is important to include actually, see the 2nd screenshot), it told me the authoritative name server was ns1.vultr.com among other things. Anyway, I don't get anything when I try to connect to the IP address and port using a browser or openssl, so my guess is that (a) this isn't a legitimate server, and (b) this is part of a way for an attacker to collect data from your server and send it back to the attacker.
The second question I can't answer, as I don't have that file in front of me. So, it appears not to be part of the standard Windows 10 OS install. But the command line you posted is a bit questionable even though I obviously can't run it. You might want to do a couple of things here. First, right-click on the file in Windows Explorer to see what it says in there - where it came from, when it was put there, who signed it if anyone. I would hope that it's signed. Second, can you provide some context for that command line you copied came from? Was it part of a larger program?
Anyway, in the meantime I would try to quarantine this server and use a fresh one that doesn't have the auditd64.bin file on it and ideally can't connect to arbitrary HTTPS listeners. (Your server should ideally have a whitelist that allows it to connect to only allowed servers. This is kind of a pain to set up, but your Palo Alto people might be able to set it up if they're handling outbound traffic.) If you can't easily replace the server, at least get the whitelist in place so the attacker can't exfiltrate data. Then, figure out a replacement approach.
Dave Watts, Eidolon LLC