Malware analysis - Debugger hangs at HttpSendRequestA

Question

I'm reverse engineering a malware that at some point tries to connect to http://api.ipify.org in order to get the IP address of the infected PC.

I was able to replicate this behaviour with a small Python script, but for some reason, I can't get the same result when debugging the malware (in my dynamic-analysis VM using x32dbg), due to the fact that execution hangs indefinitely inside HttpSendRequestA.

I tried to trace the execution flow inside that API, and the reason of the hang is a call to WaitForSingleObjectEx in wininet.dll (so, nothing to do with the malware itself).

If I try to patch the dwMilliseconds param of WaitForSingleObjectEx (causing a timeout) I can get further to the execution, but eventually I get stuck another time when the malware tries to perform another http request.

I tried to run this sample on another dynamic-analysis VM with Fakenet-ng installed and I can't even see the attempt to perform the http requests from the log.

In both VMs the network is online.

Am I missing something obvious here?

EDIT:

I tried to run the malware outside the debugger (still in a VM with fakenet) and I see the http requests from the log! So the issue described here only happens when running INSIDE the debugger. Still, I don't think that this is an anti-debugging trick: I have reverse-engineered and documented EVERY function of this malware and I haven't found any anti-debugging stuff.

EDIT2:

It seems that this user had the same issue (usign a different debugger):

OllyDbg "runs away" when stepping over wininet.HttpSendRequestW

EDIT3:

Found a workaround (described in the answer bellow)

Answer 1

Ok after hours of struggle, I found a solution (sort of).

First of all, I still don't know what causes the deadlock, but I found that this happend only when debugging the malware as a dll.

How I came to this conclusion? Because I've written a little app (exe, NOT dll) to simulate exacly what the malware is doing, using the same windows apis and in this case I got no deadlock. So I started to suspect that the issue was indeed the fact that I was debugging a dll.

So this is what I did:

1. Using dll_to_exe I've convert the malware from dll to exe (thanks @hasherezade for this great tool) [https://github.com/hasherezade/dll_to_exe]
2. Since the malware uses a custom entry point, I loaded the new executable in x32dbg, reached the real entry point, then fired up Scylla and produced a new dump with the EP set to the real entry point (I know that this can be done without Scylla at all by simply using a PE editor, but I was lacking any PE editor in that VM and the network was intercepted by Fakenet-NG).
3. Loaded this new executable (with the correct EP) in the debugger and executed it. It reached HttpSendRequestA call and I was able to step over it without any deadlock.

Still, if you know why the deadlock happens in the dll version please tell me. I also tried to use OllyDBG just to make sure that this wasn't a bug of x32dbg, but I was able to repliace the same issue there too.

Answer 2

I don't know if it's still a problem for you, but it might be related to this:

https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices

and more particularly this sentence:

"Improper synchronization within DllMain can cause an application to deadlock or access data or code in an uninitialized DLL. Calling certain functions from within DllMain causes such problems."

So my guess is that the malware you're debugging is trying to call HttpSendRequestA before it exits DllMain ?