Blogs involving different aspects of the I.T. world

Category: Networking

Blogs containing networking/network tools

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.

Creating disinformation and bypassing Shadow Z118’s Paypal phishing security measures

     This title may be a handful from just looking at it, but today I will go about discussing my interaction with Shadow Z118’s Paypal phishing website, certain measures it implemented to avoid bot discovery/web spiders, certain enumeration methods, as well as creating a tool to deliver false information to the host.

     This whole situation began at the start of February, in which I received a phishing email from an unknown source. The email itself was poorly thrown together and should raise red flags for anyone who knows about these types of emails.

Email Received

     Having not received a phishing email in such a long time, I felt the need to satisfy my curiosity and see what was going on with this link.

Initial View:

     Clicking the link, it sent me to a well put together PayPal login form. Nothing overall that would raise flags other than the URL in the address bar. Hell, the website even had SSL configured so it was using HTTPS and had the lock-pad icon to show it was secure. Moving forward, there were two things that I wanted to look into further.

1. What is at the root of this web-server, if anything?
2. What security measures are in place if any?
3. What happens after you send login credentials?

Finding and Analyzing the Phishing Source Code:

     So following my first step on how I want to approach this website, I went ahead and stripped the directories and any extensions from the main URL, just to see what was waiting for us at the root level. Surprisingly enough, we hit the jackpot and found the hosted files.

     The file that interested me the most was, of course, Wanting to be safe, I booted up my Linux VM and downloaded the file so I can see what exactly what we were working with.

Security Measures In Place:

     There are three specific security measures that this website has implemented to avoid detection from spiders/bots, but also measures to throw off users not using a Windows machine. Looking at the measures forbidding bots from accessing any part of the website, we see a list of forbidden IP addresses. Specific hostnames were also barred from accessing the website. Hostnames such as Google, AmazonAWS, Cyveillance, and Phishtank. As seen in the screenshot below, select user-agents are also barred from accessing the website.

AntiBots.php from

     Moving to the next measure in place, we will deal with the User-Agent header within the web requests being sent to the website. When I initially started checking out everything, I was using my Windows machine. So naturally, each web request I had sent contained a User-Agent header of: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64). Nothing seemed out of place until I continued my recon over to my Linux VM. Here, when I tried to request the exact website as I did from my host machine, I got this strange response.

Web Response From Linux VM

     Curious about what was going on, I went and opened up Burp Suite. Setting the proxy up, I went ahead and resent my request to the website one more time. Comparing my requests from my VM and my host machine, the only different thing was my User-Agent header. Here it read: User-Agent: Mozilla/5.0 (X11; Linux x86_64). Taking a guess, I decided to change the header to match what was used with my Windows machine, and sure enough, the normal login page appeared.

     Moving to the last known security measure in place, we need to take a look at the index.php for our main login page. Something is interesting with how this website checks if the information is valid or not. The way it addresses this issue is by assigning a session and dispatch value, appending it to the end of the URL if the phished info is in valid format, as well as certain headers.

Session and Dispatch randomization

     Taking a look at how session and dispatch is created, we can see that if valid information is passed, it will create a session and dispatch value and apply it to a 303 redirect to continue their process. We can test if our values are valid and being passed if we generate a new session and dispatch value each request. With all these measures in mind, I felt I was able to move to my next step. Making a script to render the data received useless by sending false information so the phishers cannot sort which data was from valid sources and which were not.

Moving To Python:

     Before starting this part, I feel I need to make this situation very clear. While I do feel that phishers collecting information like this should not be protected in any way, and face consequences for their actions; I do not believe it is my place to attack or act as a vigilante and take matters in my own hands. This is why I cloned the website to the best of my abilities and conducted the next process on my local machine. Following procedures, I reported the website to ‘’ following this link.  

     Starting off, I needed to figure out what data will be sent to the webserver. Using Burp Suite, I gathered the following parameters: email, password, address, city, state, zipCode, nameoncard, cardnumber, expdate, csc, day, month, year, ssn, and phonenumber.
     Next, I will need to grab the URLs for each of the webpages used. There are 3 key differences between the different pages, all of which are at the end of the URL. The first request is simple, it grabs the users country and language. Next, we encounter the first verification check. This check contains the session and dispatch parameters seen earlier. The last URL uses the session and dispatch parameters as well, but requesting it as from ‘?secure_code=’ vs ‘?verify_account=’. To bypass this measure, we can send the website valid information, grab the redirect URL, and use the tokens on the next URL.

Grab and Append Tokens

Using this method, I was able to grab the tokens for the verification URLs, and  use them to send data to the next webpages available. To ensure data was being collected and sent, I used Wireshark to monitor the network to see if any emails were being sent containing the data within. As suspected, the information was being sent to the email set in one of the php files.

Script Grabbing Session and Dispatch Tokens

If you want to see how the false information is sent, as well as how the data is generated randomly, I recommend checking out my repository for this project on GitHub.

Identifiers For Z118 PayPal Phishing Campaigns:


  1. URL May Contain:
    1. /home/signin/Security/myaccount/signin/?country.x=US&locale.x=en_US
    2. /home/signin/Security/myaccount/settings/?verify_account=session=US&{}&dispatch={}
    3. /home/signin/Security/myaccount/security/?secure_code=session=US&{}&dispatch={}
  2. Login HTML ID:
    1. html id="x_21056351"


© 2022 RomanRIIs Blogs

Theme by Anders NorenUp ↑