About exfiltering data through DNS

Carder

Professional
Messages
2,619
Reputation
9
Reaction score
1,719
Points
113
Two-thirds of information leaks are not due to malice. Otherwise, these are intentional actions of cybercriminals, employees of the organization or its contractors. If we have a blind execution of a command on a server where all outgoing connections are blocked, except for DNS, a bash script called Procrustes will come to the rescue, which automates exfiltration (sending out) of data via DNS.

What is data exfiltration?​

Data exfiltration is a process during which an attacker extracts sensitive data from another computer's system and uses it for personal purposes. Since data exfiltration is simply a transmission of data over a network, it is difficult to detect. Every organization deals with the processing of sensitive data, which makes data exfiltration attacks quite attractive to hackers.

Data exfiltration can be performed both internally and remotely. An internal threat is posed by employees who sell secret company data for profit or accidentally distribute it, while an external threat is a cybercriminal who uses a certain vulnerability to enter the system and then steal the data.

Exfiltering DNS data​

As we already know, DNS is an independent query processing protocol, that is, it was never intended to send or receive data from a client to a server. Even so, the authorized DNS will assume that all requests sent to it are legitimate. And this fact is very often used by cybercriminals: if a request were made to a subdomain, then this request would be processed as data only if it was built correctly.

For example, a crook sends a request to example.target.com and the DNS target.com receives "example" as a string. It will treat the specified string as data, and this will allow access to target.com. Further, this allows an attacker to set up a covert channel using a C2 server between DNS and the client and receive all data using bi-directional communication. Manipulating DNS in such a way as to obtain sensitive data is called exfiltering DNS data.

When data is transferred from one system to another without any direct connection, and this data transfer is done over the DNS protocol, it is called exfiltration of DNS data.

Detection​

Because a DNS exfiltration attack is covert and data travels over the network, it is very difficult to detect. Therefore, in order to detect this attack, it is necessary to regularly analyze network traffic. In order to detect these types of attacks, the user should focus on the processes that use the network, or on the processes that are unusual for the system.

In addition, you need to carefully analyze the network packets and check their behavior for any anomalies. For example, if a client sends more data than it receives, this is suspicious. To detect such attacks, you should also look for fixed-size data packets that are transmitted over a long-term connection.

Procrustes script​

For its operations, the script takes as input the command that we want to run on the target server, and at the output displays filtered DNS queries from the server with the output of the specified command.

The script currently supports sh, bash, and powershell, and is exec-style compatible (for example, java.lang.Runtime.exec).

For its operations, the script takes as input the command we want to run on the target server and transforms it to match the target wrapper so that its output can be sent via DNS. After conversion, the command goes to the "dispatcher".

A dispatcher is a user-provided program that is responsible for entering a command and executing it on the target server by any means necessary (for example, by exploiting a vulnerability).

After executing the command on the target server, it is expected that it will trigger DNS queries to our DNS server containing chunks of our data. The script listens for these requests until the output of the user-supplied command is completely removed.

More details on the tool can be found on its GitHub page.
 

Carding 4 Carders

Professional
Messages
2,731
Reputation
13
Reaction score
1,367
Points
113

Spoofing the DNS server. Be careful!​

I want to share with you a case that recently happened to me. I hope this article can save someone from losing their private data and even money.

Tie-in
It all started with the fact that one of my friends complained that the mobile version of Vkontakte was closed. I was very surprised, because I didn't see any objective reasons for this, and I hurried to check if this was the case. Go to m.vk.com dispelled my doubts — everything worked. In the course of questioning a friend, it turned out that he had m.vk.com notifies that the entire service has moved to the mobile app and offers to download the app. Obviously, this is a virus prank, I thought, and asked a friend to let me take a look at his car.

First of all, I personally looked at this fake, everything looked very plausible: it was well laid out and the URL was exactly m.vk.com. So, you could really think that the mobile version of VK was closed.

Well, what can it be? Of course, hosts! When I opened it, I was ready to save a friend from a terrible misfortune, but... there was nothing in the file except standard comments. There was also no other hidden object, as sometimes happens. A thorough study of the running processes did not yield anything interesting, just like googling the application offered for download. I thought about it.

My thought processes were interrupted by a friend who informed me that the same story happens when you try to log in to VK from your phone. It was a lead. The phone was connected to a home Wi-fi hotspot, the same as the problem computer. After asking a friend to log in to the VK from the mobile Internet, disconnecting from wi — fi, I dismissed the option of infecting the phone-the real version opened. There was only one conclusion — the router was infected.

All the fault of irresponsibility
After switching to 192.168.1.1, I asked a friend for the username and password from the router and heard in response ... admin:admin! What?! How could I not change the password on the router distributing wi-fi?! Amazing irresponsibility! The man shrugged.

After checking the DNS I found the following:

176.102.38.70
8.8.8.8

The second address is well known to me, this is Google's DNS, but I haven't seen the first one before. He wasn't even from our region.

I couldn't think of anything else to do but go to this address. I was presented with a fake QIWI, which, again, is of excellent quality. (By the way, it's still there).

I removed this address from the DNS, replacing it with the standard one for our region, changed the password on the router and restarted it. After that, everything worked as expected. After listening to the thanks of a friend, I decided to take up the fake more closely.

That's the twist
2ip.ru he said that the address is Ukrainian and showed what range it is from. The range was small, so it would be logical to scan it. Said and done. Half an hour of fuss and another interesting address was discovered. Here it is: 176.102.38.39.

Now there is profanity, but when I found it, there was a form called "Fake admin panel" and fields for login and password. What the hell is not joking? I thought, and entered admin:admin. What do you think happened?

I found myself in the admin panel, with logs of all entries to fake scammers! Amazingly, they were caught using their own method of infection.

I admit that at first I thought it was a honeypot, and I tried to log in to one of the QIWI wallets from the log. The data was correct, and the wallet account had about 1,000 rubles in it. So it's not a honeypot. I logged out of my wallet and started studying the admin panel.

Behind enemy lines​

The admin panel was designed with taste

In the Stat section, you could see how many entries were logged in in total. The situation is something like this:

VK ~ 72000
OK ~ 45000
QIWI ~ 9000
BTC ~ 5

Not bad results (not counting btc), right?

Separately, you should note the QIWI log, apparently, for the sake of it all this was done. The QIWI log displayed not only your username, password, and IP, but also your balance at the time of logging in, as well as whether SMS confirmation for payments was enabled (which is amazing, in most accounts it was disabled). This log indicates that after logging in via fake, the person was logged in on a real QIWI, and the poor guy didn't even know about the trick.

The upper-right corner shows the number of records that have not yet been archived (I note that these records were updated very quickly).

And at the bottom (not visible in the picture), there were buttons for easy export of non-archived logs to a txt file and a button for restoring all records from the archive.

Feeling that my time was running out, I restored all the recordings from the QIWI archive and downloaded them to myself. I wanted to do the same with the other services, but I couldn't. Because at the next request, I saw the 403 error, and then what is there now.

Results
I cleared the resulting file of identical entries and checked if my friend's wallet was still there. A friend was lucky, his wallet did not fall into the hands of scammers.
 
Top