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!

Finally, I’m done with the debugging section!
Let me share my experience:

  1. Skipped the second “SandBox Message” (je to jne) to get the message “Connected to C2.”
  2. Didn’t see HTTP traffic on Wireshark, only DNS requests (I ran INetSim properly on my PwnBox).
  3. The Notepad didn’t pop up when executing shell.exe, but I was able to attach the Notepad process in the second instance of x64dbg and retrieved the shellcode-related hex.

Feel free to share your feedback!

1 Like

Was also stuck on this for quite a few days. Could not get the notepad instance to come up, even while following all the instructions exactly.

This is how I managed to complete it (using my own Kali Linux VM for running Inetsim).

  1. Changed the inetsim http port to port 80 in inetsim.conf, after a recommendation from previous poster bladee. All the other lines were the same as the instructions.
    Just added the line - http_bind_port 81

  2. Copied my VM tun0 IP address to the remote machines IPv4 settings DNS server as per instructions.

  3. Ran Inetsim on my VM and it started up without errors.

  4. Edited shell.exe in all 3 locations, as per instructions. Left a breakpoint on kernell32/WriteProcessMemory and Start entry point only. Saved and Patched the shell.exe.

  5. Ran the .exe up to WriteProcessMemory breakpoint. Copied RDX value from here, as per instructions.

  6. Opened up second instance of x64dbg and searched for attached. Notepad was available to be selected.

  7. Searched for the copied RDX value in this notepad x64 instance, as per instructions. It appeared as blank value.

  8. Went back to the shell.exe x64dbg instance and hit Run. This is the important bit - I immediately switched back to the notepad x64 and pressed 'Pause’. The previously blank section immediately filled with the required data, where I could copy the answer from.

I had issues for a while with the notepad x64dbg simply closing completely, after I finished running the shell.exe instance from the WriteProcessMemory breakpoint. Theres probably something I missed that caused this, but the above process worked for me. Hope this helps someone. Most of forum answers are pretty vague. Note - I was using my own Kali VM and not Pwnbox.