Part Four
Malware Detonation Devices
A new security device lacks a name, so I call it "Malware Detonation Device (MDD)." No vendors use this term, so it's neutral. Other names used are Advanced Threat Prevention, Advanced Malware Prevention, and Breach Detection Systems.
The device's goal is to analyze files, like JARs, before sending them to the target. It checks if the file is safe or harmful by running it first.
MDDs are impressive and can find 0-day exploits, but they don't replace other security measures.
MDD Capabilities
Malware Detonation Devices focus on automatically running files or analyzing them before sending them, or just giving a report.
MDD is a tool that automatically analyzes behavior, similar to methods used in forensics for years. Lenny Zeltser has shared a list of tools for automated malware analysis.
MDD is cool because it can automatically analyze behavior to detect serious threats without needing user interaction.
Cuckoo Sandbox
Cuckoo Sandbox is an open-source platform for dynamic analysis. It existed before big vendors and can analyze files and generate reports. Unlike other free services, you can host Cuckoo in your organization.
Adversary Deception Devices
Obscurity can help improve security. Though "security through obscurity" is often criticized, when used wisely, it can be effective—and even fun to trick your adversaries.
Honeypots/Honeynets
The Honeynet Project is a leading group in using honeypots and honeynets, which are traps for attackers. These systems have no business purpose and are set up to catch harmful activity.
Any interaction with a honeypot is suspicious, as it's not meant for legitimate use. Even if it's a mistake, it's still considered suspicious.
Traditional Honeypots
Honeypots used to be set up next to public systems. Now, you can have a hidden honeypot web server alongside your real web server that doesn't provide any real services.
Public honeypots are useful but often attract many automated scans for specific problems. While they can provide some helpful information, most of the data comes from less skilled attackers. To benefit from the honeypot data, one needs to actively analyze it, which can be quite challenging.
Internal Listening Honeypots
Can we bring some of our deception tools back in-house instead of using them only publicly? How would an internal honeypot work, and what would it look like? What would our goals be?
Internal honeypots can be useful but aren't commonly used. They aim to spot insider threats and post-exploitation activities. However, use them cautiously and consult HR, legal, and union representatives first.
Another approach is to find compromised assets by detecting post-exploitation activities. Simple, low-interaction honeypots can be set up on all internal networks. If this is manageable, consider using more advanced honeypots or focusing on protecting valuable assets.
High-Value Deception
Using simple low-interaction honeypots on internal networks helps improve security by detecting basic scanning and pivoting. However, we can get even more benefits by deploying them strategically.
Tactical internal honeypots can take time to manage, but they offer unique value. Think about what your organization wants to protect and how someone might try to access that data or system. Then, consider ways to catch them before they get too far.
Let's look at some simple examples. The aim is to make it harder for your opponents to succeed by spotting their moves before they can achieve their goals.
Tactical Honeypots
Here are examples of tactical honeypots that can help frustrate attackers and detect internal mischief.
HoneyUsers/HoneyAdmins: Create accounts that look like admin accounts in Windows, AD, and other apps. Be careful about how secure these accounts are. Consider using weak passwords or having an account that shares its information (HoneySAT) with remote systems while keeping it monitored and secure.
HoneyShares/HoneyFiles: These are files and shares designed to attract attackers, with access closely monitored and alerts set up.
Switches/(P)VLAN Security
Switches
Switches aren't primarily security devices, but they can help with security in businesses. In the past, we only monitored port statistics, but now many switches offer better monitoring options. This improved monitoring helps provide important visibility that is often missing.
Switches enhance security by using VLANs to create more secure network segments instead of flat networks. They also help with endpoint authorization through NAC and 802.1x, but we won't cover that in detail.
IPFIX/NetFlow
IPFIX/NetFlow was talked about before (see “Routers”), but it's now also becoming a feature in switches, not just routers.
NetFlow settings, types, and versions can differ even among the same vendor. Cisco is a major provider, offering NetFlow on nearly all IOS devices since version 11.1. NetFlow data from switches improves security monitoring in networks.
VLAN ACLs (VACLs)
Completely separating networks would be safer but could lead to many self-made service disruptions. Although air gaps are a top method for network segmentation, they're often too expensive for most networks.
VLAN ACLs offer a cost-effective way to improve security without the high expense of air gaps. They can be added to existing VLAN setups, which many organizations already use for performance. However, they should also be used for better security. Improving internal security is essential, and VLAN ACLs are a simple and affordable solution.
Private VLANs (PVLANs)
WatchGuard describes station isolation:
When setting up an SSID on your AP device, you can turn on station isolation. This feature stops wireless clients on the same SSID and radio from talking to each other. However, it does not block communication between clients on different AP devices or different radios.
Some wireless solutions have a guest mode where clients can only connect to the access point and access the internet, but not to other devices. This is good for places like hotels and coffee shops, but not for businesses that need to connect to local servers.
Potential Issues with Private VLANs
All network switches will use Private VLANs to separate workstation networks. This will prevent devices from directly talking to each other, making it harder for attackers to move between systems.
The problems often occur when testing private VLANs. Most can be easily fixed by setting up video and voice chat systems to use gateways, making them work in client-server mode.
Reconfigure poorly designed networks that mix clients and servers on the same Layer 2 LAN before setting up private VLANs. Windows 10 has a feature called "delivery optimization" for peer-to-peer patching in casual networks, which we'll discuss next.
Internal SI Firewalls
VLAN ACLs improve internal security and are cost-effective, but for sensitive parts of the network, internal firewalls are necessary. VACLs and IOS ACLs cannot replace a firewall.
I prefer using a full stateful inspection firewall if possible. This firewall might be part of an enterprise switch. While it isn't a stronger firewall, using it as a service module is better because it’s more scalable and can be applied to more VLANs over time.
Switch/Internal SI Firewall and Pivoting
The Switch, Firewall Service Module, or internal SI firewall are powerful security tools that help organizations detect and stop pivoted attacks. Lateral movement is crucial for advanced attackers, so improving defenses against it is a significant advantage.
VACLs can stop insiders from accessing certain VLANs, making it harder for attackers to pivot. While it's not possible to stop all pivots, their first attempts would trigger VACL drops and logs, helping us detect the attempts. These logs are important and should be reviewed and acted upon quickly.
DNS Architecture and Encryption
The following types of DNS traffic should be monitored:
Requests to thousands of hosts or subdomains in one domain
Large DNS queries with high entropy
Large TXT record responses
Attempts to resolve NULL records
High volumes of DNS resolution failures
Requests to "baby" domains (registered very recently)
Split Namespace DNS and DNS Server Roles
A DNS zone is a name database for a domain or subdomain. Organizations should keep separate zones for internal and external use, known as a "split namespace."
Originally, DNS gave the same data to all clients from all servers. Later, the idea of split namespaces was added to BIND through "views." Views help keep internal devices separate from external ones. For example, lab01printer.example.com may be seen from inside the network or through a VPN, but you likely don't want it visible from the outside.
Using internal and external DNS zones is common today. By separating them, you clearly and safely manage your DNS. Internal names stay in int.example.com and its sub-zones, while external servers have no access to the int zone.
Outbound Recursive/Caching DNS Architectural Diagram
The diagram shows a basic DNS setup with one internal and one DMZ recursive server. In real situations, there are usually many of each for backup and performance. Local clients connect to these DNS servers, which in Windows environments are often Active Directory servers that also handle DNS.
These servers shouldn't connect directly to potentially unsafe DNS servers on the Internet. They should use secure DNS servers in the DMZ instead. These DMZ servers can't be accessed by Internet clients; only local clients can use them.
In a Windows setup, it’s good to use a different OS and DNS software, like Bind 9 on Linux, for DMZ servers. Why? If both server types use Windows and the same DNS software, a single flaw could affect all. You need to balance the security benefits of using different systems with the costs and skills needed to manage them properly.
Public Authoritative DNS Architectural Diagram
The diagram above shows a simple version of a public authoritative DNS setup with one server. In reality, there are usually many servers located in different places. This server is different from the one in the DMZ on the previous slide. It only answers authoritative queries and does not do recursion.
DNS Best Practices
The best practices are:
Use a dedicated server for BIND DNS only.
The DNS server should not provide other services like web or FTP.
Have separate servers for authoritative and recursive DNS.
Select suitable software and hardware.
Keep operating systems and software updated with patches.
Subscribe to security update notifications for software like BIND.
Design to prevent external access to internal data.
Implement split namespaces.
Follow basic security practices.
Run DNS software as a low-privilege user and disable recursion on authoritative servers.
Prepare for potential abuse of external servers.
Use DNS Response Rate Limiting (RRL).
Monitor the service for issues like high CPU or memory usage
Detect DNS service failures automatically.
Get ready for troubleshooting.
Use the right DNS diagnostic tools and set up logging.
Take extra steps for high availability.
Consider asking your ISP for secondary zone service for your domains.
DNS Firewalls
Blocking access to known bad host/domain names is a basic feature of any DNS firewall. Blocklists for suspicious domains have been used for years, often through web filters or newer next-generation firewalls (NGFWs). Unlike these, a DNS firewall filters at the DNS resolution stage. While the end result is the same—traffic gets blocked—using a DNS firewall offers important security benefits.
A key difference between URL filtering and DNS filtering is seen with HTTPS traffic that can't be decrypted. If filtering happens only at the HTTP level, harmful traffic can get through undetected. If your organization inspects HTTPS traffic, this might not seem like a big deal. But if DNS is used for command and control or data theft, regular web filters won't be able to see or block that traffic.
DNS firewalling sounds better than DNS filtering, but a DNS firewall can do more than just block domains.
DNS Response Policy Zones (RPZ)
Many organizations still often block IP addresses, even though attackers use host and domain names more. Blocking IPs can work sometimes, so it continues. A better method is to block domains instead of IPs. While we do this using vendor reputation feeds, it can be too rigid and lack information on what was blocked and why.
Using our current DNS setup can be a good idea. DNS Response Policy Zones let us give fake answers to clients trying to access known bad domain names.
This feature was created to protect users from online threats related to known harmful identifiers like host names, domain names, IP addresses, or nameservers. Criminals often reuse the same identifiers until they're removed. However, the security industry can't always take down these threats quickly enough. With RPZ, network or DNS admins can set up their own protection policies using reputation data from security providers almost in real-time.
Response Policy Zones vs. Sinkholes
Honeypots and sinkholes are about deception. DNS Firewalls and Response Policy Zones also involve deception, but we didn’t explore the details. The way we deceive is important and affects our security and analysis abilities.
The paper "Sink Holes: A Swiss Army Knife ISP Security Tool" explains sinkholes as similar to honeypots, which are traps for attackers. Just like honeypots, sinkholes can be customized in many ways to serve different purposes.
It doesn't really matter if you call it a DNS Firewall, RPZ, or DNS Sinkhole. The key point is to know that we are manipulating our DNS responses and what that means. "DNS Firewall" is a general term that doesn't explain how it works. "RPZ" refers to the method of filtering through the DNS service, but it's specific to BIND-based DNS systems.
DNS Sinkholes: Lying as a Service
To block a request, you can simply say the DNS resolution failed with an NXDOMAIN record or redirect the client to the loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6). This prevents the client from connecting to the suspected malicious target. However, if the requester is a DNS proxy, it can be hard to identify the real client since the DNS firewall only shows that a request was made, not who made it. This often happens when a Next-Generation Firewall (NGFW) is used for DNS blocking but is not the client's main DNS server.
To gain better insight into the client that made the request, we can direct it to an unused IP address. This will make the client try to connect through our DNS firewall. Our Next-Generation Firewall (NGFW) will then track and block attempts to reach this unused IP, helping us see details about the client and the initial communication.
We can increase the intelligence by directing the client to a traditional honeypot or malware analysis sandbox. These are online and let the client interact with them in different ways.
DNS Encryption
Many organizations are looking into HTTPS decryption, but outbound traffic encryption is growing. Recently, there has been a lot of interest in encrypting DNS. This isn't about DNSSEC, which doesn’t address the privacy of DNS communications; instead, it's focused on encrypting the authenticity and integrity of responses.
Big changes in DNS are happening quickly to improve the privacy of DNS queries, which support more encrypted internet connections.
DNS over TLS (DoT)
When CloudFlare launched 1.1.1.1, a free public DNS resolver, it made DNS privacy easier to access by supporting DoT and DoH. More DNS privacy is generally good, but it can reduce monitoring because there’s less visibility into DNS. Also, it might allow users to bypass DNS filtering services used in homes.
DNS over HTTPS (DoH)
DNS over HTTPS (DoH) is more alarming for analysts because it makes web browsers act as DNS clients. You can think of DoH as combining encryption with hidden messages, while DNS over TLS (DoT) is just traditional encryption. With both, you can't see the full DNS details like in old DNS over UDP, but DoH makes it hard to even know if a DNS request happened.
Firefox (version 62+) and Chrome (version 78+) support DoH. Whether it's on by default isn't simple. Browser makers know DoH can bypass monitoring tools, so their decisions about enabling or disabling it vary and can change quickly. Fortunately, major browsers provide ways to turn off DoH completely.
If endpoints are well-managed, companies can easily turn off DoH in browsers, which is good for monitoring DNS on internal devices. However, if users can change their browser settings—either because they have access on company devices or use personal devices—they can usually turn DoH back on. Without proper management, Firefox lets users set a special domain called use-application-dns.net.
If DoH isn’t turned on, Firefox checks the system’s DNS settings to decide whether to enable it. If a user turns on DoH manually, the check is skipped. Chrome, on the other hand, checks if the system uses a public DNS that supports DoH and upgrades the DNS request if it does. Both browsers have settings that let businesses disable DoH.
Facing Reality
The authors support encrypted DNS, like DoH, but value the threat detection DNS provides. Organizations should create a DNS encryption policy, which we'll cover soon. Traditional DNS is now referred to as Do53, which is simpler than saying "unencrypted DNS sent via UDP port 53."
How DoT and DoH Relate to DNSSEC
DNSSEC growth has been very slow, while DoH is growing rapidly. As of June 2020, less than 5% of DNS domains used DNSSEC, according to NIST.
Here's a screenshot of a DNSSEC packet, showing the plaintext query and response:
DoH and DoT
DNS over HTTPS (DoH) is becoming popular because Firefox and Chrome use it. DNS over TLS (DoT) is also growing since Android uses it by default. The debate between DoH and DoT is about privacy versus control and monitoring. It's easy to block DoT by blocking TCP port 853 on a firewall, which makes devices use unencrypted DNS instead. However, blocking DoH is harder because it looks like regular HTTPS traffic.
DoH Status Update
Firefox changes the local DNS settings to use Cloudflare, unless the client was already using Cloudflare.
Drew Hjelm’s paper from SANS Institute, “A New Needle and Haystack: Detecting DNS over HTTPS Usage,” explains DNS over HTTPS and its impact on Firefox and Zeek. The following commands from his paper will set up Firefox to log DNS requests locally, including those over HTTPS:
DoH in Firefox and Chrome
Chrome handles DoH resolution carefully. If the OS uses a listed DNS provider, Chrome will switch to DoH with that provider. If not, it will continue using regular DNS with the current provider.
Chrome will have a short table linking regular DNS servers to their DoH versions.
If the system's resolver supports DoH, Chrome will switch to it.
In some cases, Chrome will use its own DNS instead of the OS DNS resolution APIs for DoH.
Administrators can disable this feature with a group policy.
Users can opt out of the experiment in Chrome 78 by turning off the flag at chrome://flags/#dns-over-https.
What Is Your Organization's Encrypted DNS Policy?
If you're using Firefox in the U.S. with default settings and not doing TLS inspection, your DNS settings will:
Ignore local DNS settings
Switch to Cloudflare as the DNS provider
Use DoH instead of regular DNS
Avoid logging requests from local DNS servers
Bypass local DNS inspection tools like Zeek
Did you choose that policy, or did Firefox set it for you? Firefox’s DoH settings can be changed but need some know-how. Most users and organizations stick with the defaults.
The authors aren't saying Firefox's default is wrong. They're just suggesting you decide what's best for you and your organization, then create and apply a DNS encryption policy.
Traditional Do53 Architectural Diagram
Here is a traditional DNS architecture using a local outbound recursive/caching DNS server.
A recursive nameserver gets answers by asking other nameservers. If it has the answer in its cache, it uses that; otherwise, it asks around, starting from the root, until it finds the answer and gives it to the client.
This design makes it easy to log or sniff DNS queries and replies. Since Do53 is widely used, it can be sniffed anywhere from the client to the final DNS server.
Third-Party DoH Architectural Diagram
This diagram shows a Third-Party DoH setup used by browsers like Firefox in the U.S., making it hard to log DNS requests or replies locally.
Custom DoH Architectural Diagram
The diagram shows a custom DoH setup where clients send encrypted DNS requests to a local server, which uses regular DNS (Do53) to handle requests on the Internet.
The local DoH server logs requests/replies, but the site can only inspect traffic between the DoH server and the Internet. Tools like Zeek will only see the DoH server as the source, not the client's IP address.
Disabling DoH in Firefox
Here is Firefox's guidance on disabling DoH:
Network admins can modify DNS requests for the special domain "use-application-dns.net" to show their network doesn't support DoH. This only affects users with DoH enabled by default, not those who turn it on manually.
Firefox checks the domain with the device's DNS server. The result is negative if:
The response isn’t NOERROR (e.g., NXDOMAIN or SERVFAIL)
It’s NOERROR, but there are no A or AAAA records.
Disabling DoH in Chrome
The Chromium Project addresses the canary domain issue:
Do you plan to support a canary domain like Mozilla's use-application-dns.net? A: No, we don't plan to do that. Our setup is different from Mozilla's, so we don’t need canary domains. Our model aims to keep the user experience the same by automatically upgrading to the current DNS provider's DoH server with similar features.
Setting Up Your Own DoH Server
This article(https://www.aaflalo.me/2018/10/tutorial-setup-dns-over-https-server/) explains how to quickly set up a DNS-over-HTTPS (DoH) server with Pi-hole in the cloud, taking under 10 minutes. Pi-hole blocks ads on the entire network.
Detection: DoH Is HTTPS
From a network view, DoH is just a web app that uses HTTPS. You can't detect DoH traffic to an unknown server without decrypting TLS.
Next, we'll see that it's easy to spot or block known DoH servers like Google's at 8.8.8.8:443 using simple router or firewall rules. However, this method doesn't work for unknown DoH.
Network-Based DoH Prevention
Curl has a long list of public DoH servers. DoH support started in version 7.62.0, making it easy to test DoH. Here’s the syntax:
Here are some of the more popular DoH servers (all use port 443):
AdGuard: 176.103.130.130, 176.103.130.131, 176.103.130.132, 176.103.130.133, 176.103.130.134
Cisco umbrella/OpenDNS: 146.112.41.2, 146.112.41.3
CleanBrowsing: 185.228.168.10, 185.228.168.168
Cloudflare: 1.1.1.1, 1.0.0.1
Comcast: 96.113.151.147, 96.113.151.148, 96.113.151.149, 96.113.151.150
Cox: 174.68.248.77
Google: 8.8.8.8, 8.8.4.4
Quad9: 9.9.9.9,9.9.9.10
Network-Based DoH Detection
Signature-based analysis can't find DoH traffic to unknown servers without decrypting TLS, but behavioral methods can. Firefox resolves many domains during browsing, leading to numerous quick TCP handshakes and certificate exchanges. This looks like beaconing, which tools like RITA can detect.
This screenshot shows the first SYN packets from Firefox connecting to the DoH server at 206.189.185.210 after visiting news sites like nytimes.com and washingtonpost.com.
Lab 2.4 - HoneyTokens for Leak Detection
Objectives:
Gain experience using Honeytokens/Honeyrecords.
Learn to embed a HoneyToken/HoneyRecord in MySQL to discover database leaks.
Understand how to build custom ModSecurity rules to detect HoneyToken exfiltration.
Become familiar with custom Snort rules to detect the HoneyToken exfiltration.
Capture and query PCAPs using dumpcap, ngrep, tshark, or Wireshark to detect HoneyToken exfiltration.
Challenges:
Perform a SQL Injection attack against the pilot search page to dump all records.
Insert a HoneyToken value of EXFILEXFIL into the Pilots table of the sqli MySQL database
Create a ModSecurity rule to detect the exfiltration of the HoneyToken.
Ensure ModSecurity will leverage the newly created rule for detection.
Create a Snort rule to detect the exfiltration of the HoneyToken via any means.
Start a packet capture to record the exfiltration of data.
Again, perform a SQL Injection attack against the pilot search page to dump all records.
Run /labs/honeytokens/exfil.sh, which simulates an attacker stealing an unmanaged copy of the data via the payloads of ICMP, TCP SYN, and TCP RST ACK packet.
Stop the exfiltration packet capture.
Review the ModSecurity logs to determine if the HoneyToken rule was triggered.
Search the PCAP for the HoneyToken from the command line.
Run Snort against the PCAP to determine if the created HoneyToken rule changes were triggered.
Let's start by opening Firefox and navigate to https://localhost:8443/scanners/pilots.php
Now, let's perform a SQL Injection attack against the pilot search page to dump all records.
Next, we'll insert the HoneyToken "EXFILEXFIL" into the Pilots table in the sqli MySQL database using the MySQL console. Let's start the MySQL console with this command:
Now, at the mysql prompt, let's connect to the sqli database:
Now at the mysql prompt, let's inject a HoneyToken into the table.
Next, let's run the following query to confirm that the HoneyToken was successfully injected:
Now, let's create a ModSecurity rule to detect when the HoneyToken is exfiltrated. We'll use the file /etc/modsecurity/modsecurity_crs_50_outbound.conf because the rule will monitor HTTP responses for the HoneyToken.
Let's add the following two lines to the new file:
Here’s a brief explanation of the components:
SecRule RESPONSE_BODY "EXFILEXFIL":This rule checks the HTTP response body for the string "EXFILEXFIL", which seems to be a marker (possibly a honeytoken) indicating potential data exfiltration.
phase:4:The rule operates in Phase 4, which means it processes after the server sends its response to the client (post-response processing).
id:511:This is the unique ID of the rule, used for identifying and managing the rule.
msg:'Pilots HoneyToken Exfil Detected':If the rule matches, it logs the message "Pilots HoneyToken Exfil Detected", indicating potential data exfiltration based on the honeytoken.
tag:'HONEYTOKEN EXFILTRATION':The rule is tagged with 'HONEYTOKEN EXFILTRATION', categorizing the rule for exfiltration events involving honeytokens.
We'll save the file and restart Apache so ModSecurity can use the new rule for detection.
Then, let's create a few Snort rules to detect the exfiltration. Start by opening the local.rules file, where we will add our HoneyToken rule.
Now, we'll start a packet capture to record data exfiltration using Wireshark's dumpcap tool. Let's run this command to capture all packets on the loopback interface and save them in a file called exfil.pcap:
Now let's leave dumpcap running while we perform the next steps.
Let's go back to https://localhost:8443/scanners/pilots.php in Firefox. We'll perform the SQL Injection again on the pilot search page:
Now let's open a new terminal and run /labs/honeytokens/exfil.sh. This simulates an attacker stealing an unmanaged data copy, including the HoneyToken, using ICMP, TCP SYN, and TCP RST ACK packets. We need to make sure the dumpcap command is still running.
Next, let's stop the packet capture we started earlier.
Check the ModSecurity logs to see if the HoneyToken rule was activated. Also, we'll look in the Apache error.log file for signs of this rule being triggered. We can quickly do this by using the grep command to search for the HoneyToken value in the logs.
Next, let's search the PCAP for the HoneyToken using the command line. We'll use a simple tool called ngrep, which helps search for content in PCAPs and can also monitor live data for specific patterns. To find the HoneyToken in the PCAP, we use the following command:
Although the packet capture was done on the system with both the server and client, the use of HTTPS means that Snort won't be able to detect the exfiltration of the HoneyToken through SQL Injection. Let's use this command to run Snort on the captured traffic:
Let's break it down:
-c /etc/snort/snort.conf: Specifies the configuration file to use, located at/etc/snort/snort.conf.-r /labs/honeytokens/exfil.pcap: Reads packets from a specified capture file (exfil.pcap) instead of live network traffic.-k none: Disables checksum validation, allowing Snort to process packets without checking their integrity.
Next, we'll check the alert file to see if our rules were activated. The alert file is in /var/log/snort/alert. We can easily find what we need by searching for the term "HoneyToken," which is part of our rule message.
The -A5 switch in grep makes it show the next five lines after it finds a match for the pattern (HoneyToken).
Last updated
