Remote Rogue Network Detection 
Techniques and Implementations

http://metasploit.com/research/projects/rogue_network/

The Purpose

Unauthorized network links are one of the biggest problems facing large 
enterprise networks. Users intent on bypassing corporate proxies will 
often use cable modems, wireless networks, or even full-fledged T1s to 
access the internet. These network links can have a drastic affect on 
organizational security; any perimeter access controls are completely 
bypassed, making it nearly impossible for the administrators to 
effectively concentrate their monitoring and intrusion prevention 
efforts. This document attempts to describe different approaches and 
techniques that can be used to detect these rogue network links.

The Limitations

The techniques listed in this document will not be able to find all rogue 
network connections with anything near perfect accuracy. Workstations 
that block all incoming traffic from the corporate network would not be 
possible to identify through any active detection methods. Systems that 
are not used to access corporate web sites or email are immune to the web 
tracking techniques. VPN traffic that is tunneled through an outbound SSL 
connection would be very difficult to detect without a man-in-the-middle 
interceptor or private key compromise. Network anomaly detection is only 
valid when you have a known good baseline to compare against.

Three Approaches

There are three distinct approaches covered in this document. They each 
have different requirements, levels of accuracy, and user-impact levels. 
The actual effectiveness of each approach will heavily depend on the 
configuration of the network and the way that users interact with it.

User Tracking

This approach attempts to detect an authorized network connection that is 
being used as the default route for the targeted user. It assumes that 
all connections to the internal corporate resources will travel across 
the authorized network, but all outbound Internet connections will be 
sent across the rogue network link. This approach requires that a 
monitoring station be placed on the internet that watches for any 
connections or tracking packets that do not originate from an authorized 
corporate address range.

NetLogon Scripts

This technique requires that the domain administrators place a script into 
the NetLogon share of each domain. This script would execute a custom 
tool that sends a single tracking packet containing the username and 
workstation to the external monitoring address. The tool could be written 
in such a way that there would be no visibility on the part of the user. 
This would only work for workstations that directly login to the domain 
and do not have a local firewall preventing unknown outbound traffic. A 
local firewall could be bypassed by disguising the tracking connection or 
packet as a standard internet protocol (web request, DNS lookup, etc).

HTML Image Bugs

If the majority of the users of the organization access an internal web 
service or use HTML-enabled email clients, this technique may be very 
effective. It involves placing an invisible image link into a web page or 
email that requests an image file from the external monitoring station, 
using a file name that corresponds to a unique user ID. The address of 
the monitoring station could be concealed by creating a DNS entry for it 
within the internal corporate domain. This technique has the advantage of 
working with all workstations that access the bugged web site or email. 
The email method may cause a number of false positives, especially if the 
bugged email is forward to a home account or accessed from a laptop on a 
non-corporate network. There should be no visible notification to the 
user that anything is wrong with the web page or email content until the 
actual HTML source is viewed. The source can be obfuscated easily using a 
combination of decoy images and self-modifying JavaScript. Active 
Detection

This approach uses a combination of different techniques to actively query 
every node on the network. Some of the techniques would make use of an 
external monitoring station, while others simply gather the required 
information through exposed network services or management interfaces. 
This would have the same requirements for the monitoring station as the 
"User Tracking" approach as well as software development and hardware 
deployment costs for the actual scanning engine.

Remote Interface Discovery

There are a number of network services that will expose the configured 
network interfaces of a system. These include the Windows DCE Locator 
service, SNMP, DHCP, and a variety of less common network services. While 
firewalls may prevent discovery of the actual workstations, most of the 
equipment used to facilitate the rogue network link could be identified 
in this manner.

Network Service Query Bouncing

Many network services can be queried in such a fashion that they make an 
outbound request to a user-defined address. These queries would take 
advantage of the external monitoring station to determine whether the 
system in question has an alternate internet routing path. Examples of 
such services include DNS and Universal Plug and Play.

Spoofed Network Requests

This technique involves sending various probes to each device using the 
source address of the external monitoring server. Each request would be 
received on the internal corporate network, but the response would be 
sent out through the default routing interface. This would only work if 
no source address filtering is performed across the path the query is 
sent. If routing ACL's prevent this type of spoofing, multiple scanning 
devices could be installed at each regional network center or an allow 
rule could be added for that specific source address. This would work 
equally well against all network nodes and does not require a specific 
network service to be running on the target to succeed.

Network Monitoring

This approach depends on being able to capture and analyze the network 
traffic at each egress point. The differences between expected and 
recorded network traffic are used to determine the likelihood of a rogue 
network link. Multiple network sensors would need to be deployed and 
software would have to be developed to perform anomaly detection and 
implementation hooks for each technique.

DNS Deltas

This technique is designed to catch any systems which use the corporate 
DNS server but a different provider for internet access. Each DNS request 
is cached and the subsequent traffic is analyzed for connections to the 
resolved address in the response. Any system that constantly resolves 
external addresses but never makes an actual connection is more than 
likely using a separate provider. The network sensor would need to view 
and parse the DNS requests, responses, and all outbound network traffic 
for that node.

Usage Monitoring

It may be possible to simply look at the web usage for a given network and 
determine whether a rogue link is being utilized based on the traffic. 
The traffic pattern differences between similar networks can be compared 
to find usage anomalies. This would require establishing some form of 
baseline depending on the number of workstations and employees in each 
network.

Virtual Network Detection

There are many software products and services available that allow a 
system to gain direct access to a firewalled system through the internet. 
While some of these services simply create a virtual network adaptor and 
assign it an external address (America Online), others must be accessed 
through a third-party proxy service (www.GoToMyPC.com). The outbound 
connections used to initiate this service can be captured through a 
standard network monitor at each egress point.

Recommendations

While each of the approaches and sets of techniques have merits, many of 
the resource requirements may simply be too high to implement for the 
project. The following recommendation is based on minimal resource usage 
with high degree of accuracy and coverage.

A combination of HTML-based web bugs an active detection scanner that uses 
spoofed requests would provide the most accurate results with the least 
overhead. Both techniques would allow for checks to be performed as 
needed and would not significantly impact the users, the network, or the 
time of the administrators. A possible implementation plan is outline 
below.

1)Create an external monitoring station. Install a server (preferably 
Linux-based) on an external segment that is not related to the company. 
This network should not have any filters in place and be extremely 
stable. A collocation provider with multiple peering points is an 
excellent choice. Many dedicated server providers will filter one or more 
TCP ports.

2)Design the software. The web tracking will require a HTTP service that 
responds back with the same invisible image for any file name requested. 
The service should log all requests, but flag any that do not original 
from the external corporate address ranges. The spoofed connection 
requests can be tracked using an application that sniffs the raw packets 
and extracts identifying information from each response type. The target 
network address can be placed into the ICMP echo request data section or 
even encoded into the sequence number of a TCP connection request (the 
reset + ack packet coming back will include the original value plus one). 
The spoofed request scanner needs to be designed and tested in 
conjunction with the service running on the monitoring station.

3)Determine any network changes that need to be made to allow for spoofed 
ICMP and TCP requests to each of the target subnets. This may involve 
placing multiple scanners in each regional network or modifying the ACL's 
of any routers in the path from the central administrative network.

4)Determine the delivery method of the web bugs. If there is a HTML-based 
corporate newsletter or intranet web site that people must access, 
determine where and how the bug should be inserted. Implement any 
obfuscation that is required to make the bug less obvious to the end 
user. Spoofing a MTA bounce message is an easy method of targeting 
specific users with the bug in a fashion that is not immediately obvious.

5)Test the setup. Use a laptop or workstation that has an alternate 
network connection (cable modem, dialup, etc) and verify that the spoofed 
request scanner and the web bugs are working as designed. Verify that 
there is no impact on the system and see whether common workstation 
firewalls prevent it from functioning (install ZoneAlarm, PGPNet, etc).

6)Plan the first corporate-wide test. You may want to start logging ALL 
network traffic received by the monitoring station to debug any software 
issues that come up. Verify that the router ACL's allow the spoofed 
connections through and do not trigger any internal IDS deployments.

The first enterprise test will potentially produce an overwhelming amount 
of data. Home users who access the network over a VPN, sales people on 
the road, and anyone reading a forwarded email tagged with a web bug will 
trigger false positives. You may wish to consult your VPN logs to 
determine what source addresses should be ignored from the result set.