Analyzing a Reverse Shell Part II: Parent-Child Process Analysis

We can discover malware by taking a look at the process tree

Every interactive element is most likely to be a child of the explorer.exe process, then the malware has cmd as a child with a command as params which then has the command binary as a child

Malware writers always try to decorrelate this process tree to make the malware less detectable

Then we can filter, taking the executable as the parent ID and look for any child process

Analyzing a Reverse Shell Part I: Correlating IOCs

RAT.Unkown2.exe.malz

strings

• Its ok to have nothing in the string, it is even more likely than the opposite, it may be due to build on runtime configuration

• Here, we can first take a look at the Wireshark result after execution

• We do not find any TCP connection but some DNS requests to aaaaaaaaaaaaaaaaaaaa.kadusus.local

  

  <aside> 📌 NOTE : Here, the request receives a response. This is because I left inetsim on, but you’d better try once with it off to see this request clearer. Moreover, it’s not without a reason that we restart the VM between detonations, it may execute different code but we may also miss some request like this DNS one

  

  </aside>

• A technique is to say the host related to the URL is the aquarium itself. To do so, simply edit the C:\\Windows\\System32\\drivers\\etc\\hosts

• We know the malware is trying to connect to a DNS address, but how can we find the target? the file or the port?

  • Using Procmon we can filter by TCP operations (with inetsim or with hardcoded host)

    

  • Using Wireshark, we can rerun the program using InetSim enabled (less readable tho)

    

• From this analysis, we can suppose that the malware try to connect to port https aka 443. Yet it doesn’t seems to create any file so we can use netcat to find out what’s happening. We can either do that using ncat -nlvp 443 on

  • Localhost and custom host registry

    

  • Inetsim (need to disabled https serving in /etc/inetsim/inetsim.conf

• While interacting with this connection, we can assume that it is a kind of reverse shell

Dynamic Analysis of Unknown Binaries Part II: Host-Based Indicators

• We have static and network-based signatures, now lets try to use those to unravel other capabilities

• For instance, we found @AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup , msdcorelib.exe and mscordll.exe

  • Startup is often abuse by malware, juicy indicator

• So let’s check with procmon → Find smthg; interesting since we might have found the persistence mechanism