Blogs involving different aspects of the I.T. world

Category: Malware

Blogs dealing with malware

Using ICMP to deliver shellcode

While researching different methods of exfiltration, I came across a technique that utilized DNS. While writing up the proof of concept code, I noticed something interesting with the ping function I had implemented. What had caught my eye was the fact that you can supply a buffer that can hold 65,500 bytes. With a size limit that large, we can easily smuggle shellcode into our ICMP request and then inject it into a process on the listener’s end.

Starting off with the shellcode delivery, only a C# console application within Visual Studio is needed. Here, we must import our dependencies. The only one being needed is System.Net.NetworkInformation.

Importing System.Net.NetworkInformation

Next we need to create a public static void function and then call that from within Main().

Creating the function sendShellcode() and calling it from main().

Next, we create a local variable and use that to initialize an instance of the ping class, while also assigning a value to our timeout var.

Our next step will require us to move to a Kali VM instance. Within here we’re going to generate shellcode to open up a message box. we’re going to select a payload For Windows 64 bit. (payload/windows/x64/messagebox). after selecting the payload we can customize the title and the message body. After the customization, we need to generate our payload. To do this, type: generate -f csharp. We can copy the output and move it back to our Windows machine.

Crafting our shellcode
Pasting the shellcode and formatting it to fit one line.

Our last step is to assign our TTL, tell our request not to fragment, and then send the request. Our code should now look as such.
pingOptions(TTL, dontFragmentBool)
pingSender.Send(IP/Hostname, timeoutInt, shellcodeBuf, options)

Now that we can deliver the payload, we need to create a listener. Let’s move to our victim VM.

On the victim VM, we open another C# console application and import these four dependencies:

Next, we need to create two functions. One that will return shellcode from the ICMP request, as well as one that will inject it into a local process.

Imports + Skeleton functions

We need to start by creating a socket that will listen for raw data from IPv4 addresses using the ICMP protocol. This is done within the getShellcode function.


Next, we bind our local address to the socket with a port value of 0.


Next, we need to set the IOControl for the socket. To do this, we supply a control code (first arg) of ReceiveAll as well as two identical byte arrays containing {1, 0, 0, 0} as the value.


Our next three lines are straight forward. First, we assign a buffer, allocating 4096 bytes. Then we create a remote endpoint that will listen for transmissions from any IP address from no specific port. Finally, we  initialize our shellcode byte array with the byte size of 4068.

My reasoning behind the shellcode size of 4068, is because when we receive the ICMP buffer, the user inputted data starts at the 28 byte. Hence, 4096 – 28 gives us 4068.

Buffer + remoteEndPoint + Shellcode allocation

To finish off this function, we start the listener, then copy the received buffer from the request into our shellcode array. After copying the buffer to our array, we can return the value.

Receive the bytes, copy the buffer into the array, then return the value

Our last step is to the pass our shellcode to our injection function. This process is the same method used within this article, and is explained in greater detail there. However, the key point here is that we are utilizing notepad as our injection point, so all we need to grab that process ID. Checking within task manager, we get the process ID of 5588, so let’s add this to our code


Following the instructions in my last article, our code should look like this.


All that is left to do, is to run both applications. First, we start the listener, then we launch the injector. Going in that order, let’s check out our Notepad process.


Final source code can be found here:

Base64 to 0 detections

After finishing up with my certification training/exams, I finally had free time to dive more in depth with an interest of mine, malware development. I wanted to get a better understanding of how to be able to get a meterpreter against a system that had an active AV/AM solution running. One source of inspiration was from’s article about remote process shellcode injection.

I am not great enough at C++ to hit this goal just yet, so I wrote this out in C#. Source can be found here, and I’ll explain the steps needed here.

As seen in the ired write up, the main 4 functions we need to utilize are OpenProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. So let’s import them from kernel32.dll.

Importing the needed DLL Functions

We can now focus on our main function. I commented on what each portion does to give everyone an idea of the flow, as well so I can remember what it does in the future. Running this just like this does work, but if you do so with just Microsoft Defender running, the shellcode will be detected and stop the execution.

We all know if there’s a will, there is a way. So let’s find a way to get past the defense and get our shellcode executed. One method of evasion is to obfuscate certain values and build them later, whether this is done by encoding, encryption, or web requests, the goal is the same. Hide the initial and deal with it later. I wanted to start simple and work my way up and find as many methods as I could, and to my surprise the first run was the golden ticket. While it isn’t hard to make your malware undetected if it’s home built, I found it intriguing that something as simple as Base64 encoding a value would throw off not only static scans, but as well as real time scans.


To get the base64 value, all we need to do is set a breakpoint on the WritePorcessMemory function. (Do this on a VM without AV/AM running).

Setting a breakpoint at WriteProcessMemory and get the b64 value (Visual Studio 19)

Now that we have this value copy it, stop the current execution, edit a few lines. We can start off by removing our shellcode portion completely, un-commenting the b64DecodeMe line and the one below it, and lastly remove/comment out getB64FromByteArray.

The end result should look similar to this
Evading BitDefender
Evading Defender

Analyzing the Dark Comet RAT

Quick Overview:
     Dark Comet is a RAT (Remote Access Trojan) created around 2008. While not taking off until around 2012, it gained popularity pretty quick. In 2012, this tool was deployed during the Syrian conflict for spying purposes.[1] The creator was quick to denounce the way his tool was used, eventually pulling the project entirely. Dark Comet’s creator did leave a final message on his website confirming the closure and gives precaution to people still looking for the RAT.

Starting Off:
     There are 3 areas that we want to cover while looking at this piece of malware. I am going to look at what network traffic it generates, what processes it opens, and an overview of its static information.

Network Analysis:
     For my lab environment, I have my testing machine run its traffic through an Ubuntu VM acting as the router. With this setup, I will be able to capture all requests coming from the application as well as responses from the C2.
     With everything in place, I went ahead and executed the malware. Moving to my Ubuntu VM, I can see WireShark lighting up with requests. Initially, the only request I was getting from the application was a DNS request for a DDNS. Looking at the response, it was clear that this domain was no longer active. Other information from the response allowed us to uncover who hosted the original DDNS

Dark Comet trying to reach ‘’ through

Checking out, we can see that they provide dynamic DNS names free for anyone. Curious to see what will happen if the malware was able to receive a response from an IP, I went ahead and registered for the name ‘’.
     Right after the DDNS was registered, I noticed a change in requests and responses in WireShark. The application finally received a response from the DDNS and started up SYN-ACK traffic with my IP address.

SYN-ACK traffic with my IP and Dark Comet

Behavior analysis:
     Moving to how this RAT behaves, its time to open up Process Hacker and ProcMon.
     Starting with Process Hacker, we can go ahead and execute the Dark Comet binary. Process wise, it is pretty straight forward on what this malware wants to accomplish in its first execution. At the start, we have one main process, “backdoor.win32.darkkomet”. This would be the main process from the binary that you initially clicked. Once opened, it does some system checks and then executes “vbc.exe”, which is Visual Basic Compiler. Lastly, the original main process will create an identical process under a different name, “xp.e.exe” and then close itself.  To make visualization easier, I went ahead and created this flow chart.

Behavior of the Dark Comet RAT

Now that we have an idea of what processes are created and terminated, let’s open up ProcMon to see if there is anything else going on that we do not see.
     Executing the original binary, ProcMon lights up with processes, many of which are registry queries and loading up of DLLs. There are a few processes that stick out to me though. The first being the creation of a directory named ‘wind’ in the root of the C drive. Looking into why we see this, we uncover that this is where ‘xp.exe’ is placed and executed before the original process is terminated.

‘C:\wind’ being created and ‘xp.exe’ being dropped

Continuing down ProcMon, there is nothing else that catches my eye. The only thing that raises my curiosity would be whether the original binary and ‘xp.e.exe’ are identical, or whether they differ in any way.

Static Analysis:
     To analyze the static portion of this binary, we are going to use a tool called ‘PE-Bear‘. Here we can go ahead and pop both ‘backdoor.win32.darkkomet.exe’ and ‘xp.e.exe’ in and check out their MD5 to see if they are identical or if they differ.

MD5 and SHA1 of ‘Backdoor.Win32.DarkKomet.exe’
MD5 and SHA1 of ‘xp.e.exe’

Looking at the MD5 and SHA1 of both files, we can infer that these are the same files, containing the same information in both, just under different names and locations.

     Dark Comet holds a special place in my heart as it was one of the first pieces of malware I interacted with when I first expanded my interest in IT. From being 12 years old and trying to maneuver my way around the original tool, creating stubs and infecting myself, to being able to look at what this tool does in behavior and network traffic is amazing. While this is just a bare-bones stub with no extra features enabled, like original stub deletion or stub binding, it still is an interesting piece of malware to take a look at.  I would love to shout out the VX-Underground for hosting their wide selection of malware and allowing me to have access to said files.

MD5: a3cd89b386bb1890b778ef22fb7392a
SHA1: 265719f850de6a2a8e97fdfdff323a7bbcc13a9d

1. McMillan, Robert. “How the Boy Next Door Accidentally Built a Syrian Spy Tool“. Wired.

© 2022 RomanRIIs Blogs

Theme by Anders NorenUp ↑