Simplest Trick To Capture Non-Proxy Aware Traffic (Flutter/Xamarin) | DNS Spoofing

Network Traffic Interception Diagram

Introduction

Mobile application security testing has evolved significantly with the introduction of modern frameworks like Flutter and Xamarin. These frameworks often implement sophisticated networking mechanisms that bypass traditional proxy-based traffic interception methods, creating challenges for security professionals attempting to analyze application traffic.

Click here to jump right to practical guide.

Understanding the Problem

What is Non-Proxy Aware Traffic?

Non-proxy aware traffic refers to network communications that bypass system-level proxy configurations. Unlike traditional applications that respect operating system proxy settings, modern mobile applications often implement custom networking stacks that create direct socket connections to their target servers.

For example here is the sample flutter application.

image

In image, we are using following sample ios flutter application (https://mas.owasp.org/MASTG/apps/ios/MASTG-APP-0027/). As observed in image above, even after configuring burp proxy and Certificate pinning not being implemented, the application still ignores the proxy and traffic does not appear in burp suite.

Why Traditional Proxy Interception Fails

When you configure a device to route traffic through a proxy server like Burp Suite, the expectation is that all HTTP/HTTPS traffic will be intercepted and displayed in the proxy tool. However, several factors can cause this approach to fail:

1. Direct Socket Connections

  • Applications create raw TCP/UDP socket connections directly to target servers
  • These connections completely bypass the system's HTTP proxy settings
  • The traffic flows directly from the application to the server without proxy intervention

2. Custom HTTP Clients

  • Many modern frameworks use specialized HTTP clients that ignore system proxy configurations
  • These clients are designed for performance and may not implement standard proxy protocols
  • They often use native libraries that operate at a lower network level

3. Proxy Detection Mechanisms

  • Applications may actively detect the presence of proxy servers
  • They can implement fallback mechanisms that switch to direct connections when proxies are detected
  • Some applications check for common proxy indicators and modify their behavior accordingly

Framework-Specific Challenges

Flutter Applications

Flutter applications present unique challenges due to their architecture:

  • Dart Runtime: Flutter uses the Dart programming language, which has its own networking libraries
  • dart:io HttpClient: The standard HTTP client in Dart doesn't always respect system proxy settings
  • Native Plugins: Flutter applications often use native plugins that bypass Flutter's networking layer
  • Custom Networking: Developers can implement custom networking solutions that ignore proxy settings

Xamarin Applications

Xamarin applications also exhibit non-proxy aware behavior:

  • HttpClientHandler: The default HTTP client handler may not respect proxy settings
  • SocketsHttpHandler: Modern Xamarin applications use handlers that can bypass proxies
  • Native Libraries: Integration with native iOS/Android networking libraries
  • Custom TCP Clients: Direct implementation of TCP/UDP communication protocols

Technical Background

DNS Resolution Process

To understand how DNS spoofing works, it's essential to understand the normal DNS resolution process:

  1. Application Request: The application needs to connect to a domain (e.g., api.example.com)
  2. DNS Query: The device sends a DNS query to the configured DNS server
  3. DNS Response: The DNS server responds with the IP address of the domain
  4. Connection Establishment: The application establishes a connection to the resolved IP address

How DNS Spoofing Works

DNS spoofing intercepts this process by:

  1. Intercepting DNS Queries: The attacker's machine acts as a DNS server
  2. Returning Malicious Responses: Instead of the legitimate IP address, the DNS server returns the attacker's IP
  3. Traffic Redirection: The application connects to the attacker's machine instead of the legitimate server
  4. Proxy Forwarding: The attacker's machine forwards the traffic to a proxy for analysis

Key Components

DNSMasq

DNSMasq is a lightweight DNS forwarder and DHCP server that provides:

  • DNS caching and forwarding
  • Custom DNS record configuration
  • Logging capabilities for DNS queries
  • Integration with system networking

Burp Suite Invisible Proxy

The invisible proxy feature in Burp Suite allows:

  • Interception of traffic without explicit proxy configuration
  • Transparent handling of HTTP and HTTPS traffic
  • Support for various protocols and connection types
  • Minimal application-side configuration requirements

Demo

For the demonstration of this trick, we are going to use the following ios flutter application https://mas.owasp.org/MASTG/apps/ios/MASTG-APP-0027/

In general this trick has following steps:

  1. Configure DNS in mobile device
  2. Configure kali linux to act as an DNS server
  3. Capture the DNS traffic in logs
  4. Spoof target domain's IP as kali's IP and disable IPv6 Addresses
  5. In Burp Suite listen on port 443 and 80 on 0.0.0.0 interface (all interface)
  6. In Burp Suite enable invisible proxy for 443 and 80 proxies
  7. In mobile device set wifi proxy to kali IP
  8. In mobile device set DNS server to kali IP
  9. Launch the application and capture the traffic

1. Configure DNS in mobile device

In you mobile device, configure the wifi settings to send DNS queries to kali linux machine.

img

2. Configure kali linux to act as an DNS server

In kali's terminal, run the following command:

sudo nano /etc/dnsmasq.conf

After this the configuration file for dnsmasq will be opened, You can replace the nano with any text editor you (i.e. mousepad, vi), for example - sudo mousepad /etc/dnsmasq.conf

In the configuration file, add the following entries:

server=1.1.1.1
log-queries
log-facility=/var/log/dnsmasq.log
img

Save and exit. Then run the following command to start the dnsmasq server.

sudo systemctl restart dnsmasq

3. Capture DNS queries

Open the target application and navigate around the application. For example, in the sample application, we will be clicking the request buttons to generate some traffic.

img

Open the dnsmasq log file to analyze the logs and found out for which domain the flutter app is sending DNS queries for.

sudo mousepad /var/log/dnsmasq.log
img

From the logs, try to find the domain names application tries to reach out, for example the sample flutter application sends DNS queries for two domains.

  1. neverssl.com
  2. www.nviso.com

So we have to spoof IP of this two domains with the IP of our kali machine where burp suite proxy is running.

4. Spoof target domain's IP as kali's IP and disable IPv6 Addresses

Add entries for the domains found in logs in dnsmasq config file:

address=/<domain>/<kali-ip>
local=/<domain>/
sudo nano /etc/dnsmasq.conf

For example, for our sample flutter application we have to spoof the addresses as following:

img

After doing this, restart the DNS server using following command:

sudo systemctl restart dnsmasq

5. Configure The Burp Suite

In Burp Suite listen on port 443 and 80 on 0.0.0.0 interface (all interface). For example:

img

And make sure this proxy are invisible proxy as highlighted in image. You can create invisible proxy using Edit/Add proxy options. We have to configure these two proxies because once we spoof the IP of the server, the application will try to connect with kali machine on port 80 or 443. At that moment, we will be able to capture the traffic.

6. Launch the application and capture the traffic

After this configuration has been made, You will be able to see the non-proxy aware traffic in burp suite.

img
Note: You still have to bypass the SSL pinning if implemented as this will just now capture the traffic, this will not bypass the SSL Pinning protection.

Troubleshooting Common Issues

Issue 1: No Traffic in Burp Suite

Symptoms: DNS spoofing appears to work, but no traffic appears in Burp Suite

Solutions:

  • Verify invisible proxy configuration
  • Check port listeners are active
  • Ensure firewall allows traffic on ports 80/443
  • Verify DNS resolution is working correctly

Issue 2: DNS Resolution Failures

Symptoms: Application cannot resolve domains or shows network errors

Solutions:

  • Check DNSMasq configuration syntax
  • Verify upstream DNS server is accessible
  • Ensure DNSMasq service is running
  • Check mobile device DNS configuration

Issue 3: Certificate Errors

Symptoms: Application shows SSL/TLS errors or certificate warnings

Solutions:

  • Verify Burp CA certificate is installed on device
  • Check certificate generation settings in Burp
  • Ensure proper certificate chain configuration
  • Consider SSL pinning bypass if implemented

Issue 4: Application Detects Spoofing

Symptoms: Application behaves differently or stops working when DNS spoofing is active

Solutions:

  • Analyze application's network detection mechanisms
  • Implement more sophisticated spoofing techniques
  • Consider using legitimate certificates
  • Analyze application's security controls

Conclusion

DNS spoofing provides a powerful technique for capturing traffic from non-proxy aware applications, particularly those built with modern frameworks like Flutter and Xamarin. By understanding the underlying networking mechanisms and implementing proper DNS redirection, security professionals can effectively analyze application traffic that would otherwise be invisible to traditional proxy-based tools.

The demonstration with MASTG-APP-0027 illustrates the practical application of these techniques in real-world scenarios. However, it's important to remember that this approach is just one tool in the mobile application security testing toolkit. Modern applications may implement additional security measures such as SSL pinning, certificate transparency, or advanced network monitoring that require specialized bypass techniques.

This guide is intended for education and authorized security testing purpose only.