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
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?
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.
It seems that this user had the same issue (usign a different debugger):
Found a workaround (described in the answer bellow)