Bypassing Network Filters
In previous modules we discussed various command and control (C2) techniques.
In this module, we will discuss the various defense solutions we may encounter
in an enterprise environment
and address the challenges these solutions pose to our C2 network traffic.
We will discuss the strengths, weaknesses, and important details of a variety of
solutions and examine their monitoring and blocking strategies.
Since each of these solutions can affect the outcome of a penetration test,
we will also discuss a variety of strategies to bypass these solutions.
Let’s begin with an overview of the various solutions we may encounter,
each of which is typically deployed in an enterprise as part of the Internet Edge
network architecture.
Although this model considers both ingress and egress traffic,
in this case we will focus on the latter,
since it is assumed that we have already compromised the target network
and control one or more systems within it.
Commonly, outbound traffic is routed through a series of systems
where it is inspected and processed before routing it to the Internet
or blocking it due to a violation.
The tools included in this model may include simple IP address filters
or more complex Intrusion Detection Systems (IDS) and web proxy filters.
These advanced tools may perform deep packet inspection,
analyzing the entirety of the network application layer’s content.
In addition, a packet capture device, which is typically not inline
with the traffic, may copy the entirety of a network’s data
for use in digital forensic investigation activities.
Although this type of solution can not block traffic,
it may alert system administrators or incident response teams,
who may in turn block our traffic.
Consider this figure, which shows a rather comprehensive
Internet edge architecture installation.
Let’s discuss this configuration in more detail,
tracing egress traffic sourced from the internal devices.
First, if the egress traffic relies on name resolution,
some edge DNS servers may perform domain filtering,
which can deny disallowed domains.
Next, allowed egress traffic will pass through an internal firewall,
which will generally limit traffic based on IP address and port number.
Specifically, most solutions rely on a blocklist,
which acts as a first-pass protection mechanism
but also reduces the load on downstream devices.
As an example, if an organization doesn’t allow egress SMB traffic,
it can be filtered out early, at this stage.
Next, the traffic may pass through an SSL inspection device,
which essentially performs SSL decryption
allowing the device to inspect SSL-encrypted traffic.
The traffic is typically re-encrypted when it leaves this zone.
If the traffic is still allowed, it may next pass through a traffic filter,
like a proxy server or an IDS,
and the data may be copied to a full packet capture device.
Next, the traffic may pass through an external firewall
that may filter egress traffic,
in addition to filtering ingress traffic as expected.
If the traffic passes these inspection points, it is then routed to the Internet.
Since this type of comprehensive solution is costly and complicated,
some organizations may simplify, excluding certain functionality
or relying on multi-function devices that combine some of this functionality
into a single unit.
For example, a proxy server may serve as not only a proxy but may also perform IDS,
SSL inspection, and domain filtering.
As penetration testers,
we are not necessarily concerned with the actual devices.
Instead, we must know how to identify the deployed defensive tactics
and understand how to evade them well enough
to successfully complete our assessment.
Inevitably, in many cases our traffic will be logged.
Our goal in this module will often be to normalize our traffic,
“hiding within the noise”, such that our activity
will fall below the detection threshold.
Before we proceed, let’s take a moment to discuss the lab configuration
for this module, which is configured as follows:
The lab includes a Windows 10 machine named client,
and an Ubuntu machine named ubuntu.
The Ubuntu system serves as an edge defense machine
and will handle all defensive tasks.
It’s running DNS for name resolution, an Nginx web server, and Snort,
which is set to monitor all network traffic.
Most of the Snort rules are turned off for now,
but a few custom rules that enable basic filtering are installed.
From an external perspective,
we can SSH to the Ubuntu system from our Kali machine.
The Windows 10 machine is behind the Ubuntu machine,
which means we can’t access it directly.
However, a port forwarding rule forwards RDP requests so we can RDP to the
Windows client by connecting to the Ubuntu machine on TCP port 3389.
Note that in our previous modules,
we relied on IP addresses when connecting to our listeners.
However, in the real world, domain names are more practical
and flexible for several reasons.
First, we can easily move our C2 listening server to another location
by simply updating the DNS record.
In addition, since direct-to-IP connections are often considered
anomalous, we’ll perform a DNS lookup to connect to our C2 server
and adopt a more typical network pattern.
Given these benefits, we will only connect to reverse shells by domain name
to assist in various filter bypasses.
Armed with basic knowledge of defense systems and a properly configured lab,
we’ll cover the various system components in more detail
and demonstrate various bypass techniques.
Later in this module, we’ll also examine domain fronting and DNS tunneling
and discuss how they relate to network filter evasion.