How to recognize if this code is dangerous [closed]

Question

I just received some obfuscated code and would like to de-obfuscate it. Could someone explain which encryption method is being used?
And how I could reverse it.
The code is:

On error resume next
Data="}èŝŸȠɩʽ̟ͪρФШҘӔղ׏ܦݷބߢࡳ࢏ࣜ"
Container1=""
id="4d9fdb14-d482-4fc5-a910-9af261a17650"
random1=0
random2=0
do until random1=len(Data)
random1=random1+1
random2=random2+1
if random2=len(id) then random2=1
Container1=Container1 & ChrW(AscW(Mid(Data, random1, 1)) - random2 * 86)
loop
if len(Container1) > 282 then
execute Container1
end if

The complete code in pastebin: https://pastebin.com/WJTgKmP1

Answer 1

Print instead of executing

In this case, you have the deobfuscation code right in front of you. While it may be interesting to understand how it works, that's not necessary - it's obvious that the process flow is that it deobfuscates some payload to variable Container1 which then gets executed.

What you can do is replace the execute Container1 with something like (assuming this is VBA) MsgBox Container1 and just run the code. Of course, it's safer to run any potentially malicious code in a sandbox virtual machine and not on a computer that you care about, even if you believe that you know what it does and doesn't do - as anyone can make a mistake in evaluating that.

It's quite plausible that this will just reveal some 'second stage' that will still need further analysis and deobfuscation, but that's a different learning exercise.

Answer 2

A more general answer to your question (in addition to the answer to replace exec with print from PeteriS which is very handy for quick analysis).

The dangerous parts of code include methods or calls which have side effects on the system. This especially includes system calls to execute commands, IPC, open files or do network communication. While not all code who does that is dangerous, it should be at least suspicious.

But keep in mind, only because you can't see that kind of code, it might not be absent. More generally having some form of memory manipulation and then jumping or setting up handlers to other places might do the same.

In your sample code the execute is however the only part which stands out as dangerous (and the fact the VBA is not used by sane people ,).