The file you’ve dropped is not a native Win32 exe at all but a thin native stub (CorExeMain) that boots into the .NET CLR. All of the “meat” lives in managed code—Ghidra’s decompiler is just trying (and failing) to turn JIT-ted .NET code back into C.

From the list of methods:

• RenameFiles, RenameFilesInDirectory, RenameFile
• CopyAndRenameRftFiles
• GenerateRandomString, GenerateRandomPassword
• EncryptFile, DecryptFile
• RenameAndEncryptFilesInDirectory
• RestoreFiles, RestoreFilesInDirectory
• button1_Click, button2_Click, Timer_Tick, etc._

…and the fact that there are functions to
• walk a directory,
• rename files,
• generate random strings/passwords,
• encrypt (and later decrypt/restore) files,

this strongly smells like a simple file-encryption utility—or outright ransomware. GUI event handlers (button1_Click, button2_Click) imply a two-button WinForms app (probably “Encrypt” and “Decrypt” or “Start”/“Restore”).

At this level we see no network routines or phone-home code, so it may simply be a “DIY” file-encryptor rather than a fully-blown botnet client. But if you run it and point it at your documents folder it will almost certainly rename your files (to some new extension) and encrypt their contents with a random key.

Next steps:

1. Grab a .NET decompiler (ILSpy, dnSpy, dotPeek) and load the EXE.
2. Look at the bodies of EncryptFile and DecryptFile in IL to see which algorithm (AES? RC4?…) and how the key is derived/stored.
3. Check for any hard-coded C2 URLs, SMTP addresses or embedded public keys.
4. If you really just want to confirm whether it’s “safe,” run it in a sandbox (VM) on some dummy files and see exactly what it does.

Bottom line: this is almost certainly a file-encryption tool—very likely ransomware-style. Treat it as untrusted.