The Romcom malware is a backdoor-based malicious software that utilizes multiple communication protocols, including ICMP, TCP, and WinHttp. This versatile approach allows the malware to establish connections with its Command and Control (C2) server using different network protocols, making it harder to detect and block.
Summary
The malware employs a deceptive tactic by masquerading as legitimate software to gain initial access. What sets this malware apart is its ability to communicate with the Command and Control (C2) server through three different network protocols, adding complexity to its operations and evading detection. Additionally, the malware utilizes a plethora of string obfuscation routines within its final payload, making it difficult to decipher its true intentions.
Reversing Notes
The amount of obfuscation in this is sample is… annoying, like I understand 2 to 4 string decryption routines, not 20+ >_>. 
First Stage
Payload Deployment
The malware sample I possess disguises itself as a PDF file, which contains details about a university tour. Upon execution, the malware proceeds to decode the secondary payload, which is stored in a designated resource section of the binary.
After successfully parsing and decoding the resource, the malware proceeds to drop the payload into the Public User’s library directory. Subsequently, the malware employs the RunDLL32.exe utility to execute the dropped payload, enabling it to carry out the next step in the malware’s execution chain.
“DLL Dropper Routine” 
“Loads the rsrc Section within the Binary and Writes it into the Public Users Library” 
“the rsrc section has a high entropy, suspect to be a encoded payload” 
“Decodes and locates a list of software to host the PDF file (chrome -> Firefox -> Edge -> Internet Explorer)” Payload Execution
Once the malware successfully writes the second payload onto the infected host’s system, it proceeds to execute the DLL using the RunDLL32 utility. The execution command typically follows this format:
rundll32.exe <DLL_Path>,<Module_Name>
Second Stage
The second stage acts as the “Primary Payload Dropper.” Its job is to modify the registry by adding a path to the Final Stage Payload, along with a special ID/Instruction found within the registry path:
\SOFTWARE\Classes\CLSID{00020424-0000-0000-C000-000000000046}\InprocServer32.
Once the registry has been modified, the main payload is dropped onto the disk and executed using the same method as before. However, instead of pointing to a specific module, the Rundll32 command will use the default DLL entrypoint to execute.
“Main Routine for the Second Stage Payload” 
“Resolves target registry address for where the file location will be added onto” 
“Modify the Registry address, possibly for some sort of persistence” Final Stage
Initial Execution
During the execution of the final payload, the malware will create a thread that executes both modules within the current DLL.
“Modules located within the DLL which the malware can execute” 
“Main Entrypoint of the malware calls a function which starts the required modules as threads” 
“Starts the Current DLL where the entrypoint is the two unique modules listed in image 1” Tasking Routine
The malware uses the TCP Protocol to retrieve tasks from the C2. If the TCP communication protocol fails, the malware has the ability to fall back to other protocols, such as HTTP through WinHttp. If that also fails, it will use the ICMP Ping protocol instead.
TCP Task Parsing
The TCP protocol queries the C2 via TCP sockets. If it successfully retrieves a response from the C2, the malware will store the response in a buffer. This buffer is then parsed by the main task subroutine to determine the specific task that needs to be executed.
WinHttp Task Parsing
“WinHttp Setup, getting ready to Retrieve/Send Task/Result from the C2 server” 
“The malware will send the results of a task if a task has just been completed, otherwise it will try to contact the c2 for additional tasks” ICMP Task Parsing
“ICMP Setup, getting ready to Send and retrieve any task from the C2 in case the other two protocols fail” 
“Loads the ICMP functions which are required to send and receive back to the C2” 
“Arg5 determines what is done during the ICMP communication protocol.” Task IDs
Command IDs are identified as hex values ranging from 0x10 to 0x1C.
Please note that the following list should be taken with a grain of salt as I’m too lazy to resolve each string manually, but these are what the IDs do at a glance.
0x10: ?
0x11: Grab Information From C2 again?
0x12: ?
0x13: Create Directory
0x14: ?
0x16: Enumerate System Process Information
0x17: Retrieve Content from Another Website Via TCP 1#
0x19: Retrieve Content from Another Website Via TCP 2#
0x20: Upload File to C2
0x22: Download & Execute
0x23: Delete File
0x26: some sort of move file function?
0x28: Similar to 0x26?
0x29: Run Executable in Memory?
0x1a: Read File Content?
0x1b: Deploy File to Disk?
0x1c: Deploy Executable into memory and run?
0x1d: Another Execute Function?
0x1e: Get System IP Addresses
0x?: Get System Dir Files / Delete Directory
0xd: ?
0xe: ?
0x15: Get IPV4 Address
0x1f: Grab system Processes Information
0xc OR 0xe: Delete File
References
Hash
- 068117b406940ac510ed59efd1d7c7651f645a31bd70db6de16aba12c055aae6