INTRODUCTION TO MALWARE ANALYSIS - Debugging

Why on the Debugging Malware feels like when I do the changes when RUN still shows SandBox Detected and all the changes reset?

I do all the changes but still doesn’t work
1 - We can change the comparison value of 0x1 to 0x0 .
2 - We can alter the instruction from je shell.402F09 to jne shell.402F09 .
3 - jne to jmp
4 - Set up breakpoint on the last “SandBox Detected”

I am missing something here? stuck on the same thing for days

2 Likes

I’m also encountering the same issue, I managed to get the pop from inet and the c2 but the notepad is not popping up.

Same here trying to pop up notepad.exe now

VirtualAllocEx , WriteProcessMemory , and CreateRemoteThread

I can help you two solve this. You have to patch it, save as an .exe through the file menu, then debug the new executable. You should see what you’re looking for in the new exe because the sandbox detection will be gone.

1 Like

I did that but still nothing… going to try again today

To be clear: you have to follow the steps on the new exe still but when you do you’ll notice the sandbox is removed as intended. Sorry the author didn’t mention it.

VirtualAllocEx , WriteProcessMemory , and CreateRemoteThread we have to set up a breaktpoint on all 3 is it?

I know the WriteProcessMemory is where notepad.exe is called

thanks this led me to the right direction… still a lot of trial and error by having to reset the pawn a lot of times… it should be done precisely or else it will not work

@jinn @bb0rges I’ve been struggling with this for hours. I was originally able to get rid of the sanbox message, but the inetsim was not working correctly. Once I got that working, now I cannot get rid of the sandbox message, I’m not sure what I’m doing wrong. After I add the breakpoints and make those 3 changes it just doesn’t seem to behave correctly, when I hit Run it will almost immediately pause, then I have to hit run 3 more times and the Sandbox message will come up. Would love a DM is someone thinks they can help.

1 Like

I want to offer two observations which may help in the future:

  • x64dbg by default resets your opcode edits when you rerun the executable (probably due to ASLR since the walkthrough applies them during execution?). Maybe there is an option to prevent this reset, but your safest bet is patching.
  • INetSim DNS is broken on current Kali (PwnBox isn’t Kali, it works fine there). The perl DNS code has been rewritten and now doesn’t want to work properly after forking. You can confirm this by running ss -tuln after launching INetSim, port 53 will not be listed. INetSim will also display an alert that you attempt running the DNS as a subprocess. I got it working on my Kali by overwriting my local /usr/share/perl5/Net/DNS (make a backup) with the version from the PwnBox.
1 Like

For a while I was unable to get past the second sandbox check. The problem I was running into involved INetSim (using PwnBox). When I did “sudo inetsim” everything worked except for:

“http_80_tcp - failed!”

A different process “python2.7” was occupying port 80. I tried just killing the process, but it would always restart. To get it to work, I had to change the default http port in the insetsim config file (to 81). These are all the lines I added to the insetsim.conf:

service_bind_address
dns_default_ip
dns_default_hostname www
dns_default_domainname iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com
http_bind_port 81

How did it work for you? Despite making the changes mentioned in the module and saving the file with patches to a new .exe file, I am still getting sandbox detected. I need help

2 Likes

as of writing. with the second sandbox check, i honestly just let it stay as the original so the only sandbox checks are the first and the third. id chalk it up as the vm acting funky, right now im still trying to figure out how to get to the inet default binary because i can already connect to the c2.

EDIT: i noticed if you just set the dns on the ethernet adapter (as in the tutorial) things won’t work right (because itll still be using the dhcp config with dns set to 1.1.1.1 and 8.8.8.8) and not whatever you set on the adapter → ipv4 config. so you have to set it through Settings: Network 4 → Manual and then copy the rest of the target vm dhcp information (ip, subnet, gateway) and set the dns. itll boot you out the remote session but if you did it correctly youll be able to reconnect. You can then follow all the steps.

I’ve been down that frustrating road too. Debugging malware can feel like chasing shadows sometimes. But hey, hang in there! Have you checked out the discussion over at https://guidedhacking.com/threads/how-to-rebuild-iat-for-malware-analysis.20573/? They’ve got some seriously helpful insights on troubleshooting these exact issues. I remember hitting a wall like this once, and a tip from there cracked it wide open.

Did you make any progress? I’m stuck here too.

Edit: I’ve since discussed my recurring ‘sandbox detection’ issue with HTB support. They replicated the walkthrough and also came up with the sandbox detection despite patching. They informed me they are aware there is an issue and are investigating a fix. I believe the issue is possibly related to iNetSim not functioning properly on port 53, although I am not certain. They also advised at this stage that a workaround is to use a 2022 Kali VM, and not 2023 Kali or PwnBox - although I personally haven’t tested this.

I am done with everything else on hack the box but this one section.

1 Like

For all of you guys that are still struggling, let me share my experience. I made changes to the first and third “Sandbox Detected” messages (I figured this out via trial and error for each one of them).
Also, the notepad.exe did not pop up as I was expecting. However, when I started another instance of the x64dbg and navigated to File > Attach button, the notepad.exe was listed there just like the first screenshot on the " Attaching Another Running Process In x64dbg" section. Hope this helps!