From dankwiki
Three omphalos processes, 2011-12-01

A tool for network enumeration, protection, observation and domination. Omphalos makes use of passive and active portscanning, DNS/DHCP/Zeroconf server interrogation, portknock detection, covert channel detection and establishment, ARP scanning, automatic WEP cracking, man-in-the-middling, and a whole host of other tricks. GPS integration? Oh yes. Coordination across multiple interfaces? Of course. Use of Linux's MMAP_RX_SOCKET and MMAP_TX_SOCKET? Wouldn't have it any other way. Userspace networking is made visible to the host via a TUN/TAP device. While designed as an offensive tool, omphalos has proven useful for network debugging and troubleshooting, as well as experimentation.

Omphalos is not a "point-and-click" tool so much as "pull the pin" or perhaps "spray the area". Default behavior is to redirect and seize all traffic, attack weak cryptosystems, archive authentication materials, and learn everything that can be learned. Ideally, a tiny microprocessor would be paired with power and a network device, stealthily physically inserted into a network, and left there; omphalos and liburine would then combine to provide complete network dominance. I hope to combine network programming and the techniques of high-performance computing to create a tool capable of much havoc.

Omphalos: Because one layer is never enough. Code is hosted on GitHub, as are modern issues. Old bugs are still available at bugzilla. There's a mailing list at Google Groups.

Similar Tools


We want to defeat systems like:

  • ArpON by Andrea Di Pasquale et al

Subsumed Tools

Omphalos implements all or portions of the functionality of the following tools:


Version Release date Features
0.98 (initial alpha) 2011-10-07 (actual)

2011-09-23 (planned)

  • Detection of network entities at layers 2 and 3.
  • Dynamic handling of devices, routes, neighbors and addresses
  • Full netlink, ethtool, nl80211 and wireless extensions support
  • TTY and ncurses-based UI's
  • ARP- and DNS-based probing
0.99.0β (initial beta) 2011-12-01 (actual)

2011-11-11 (planned)

  • Routing/iptables configuration capabilities
  • Hostapd and AP-spoofing support
  • Spoofing support at layers 2 and 3
  • Zeroconf- and WINS-based probing
1.0 2011-12-25 (planned)
  • Automated selection and execution of previous capabilities
  • GPS support
  • Logging support
  • LLTD and some NetBIOS support

General Features

Some planned, some implemented...

  • Modes of operation governing automatic behavior, from "Silent" to "Hostile":
Mode Summary Operating characteristics
Silent Take no actions, only watch.
  • TX ringbuffers/sockets are not automatically created
  • No packets will be issued by omphalos unless requested
  • No automatic modifications to host networking state
Stealthy Take only the actions of a normally-configured host.
  • ARP queries will be automatically issued
  • DNS and Zeroconf queries will be issued, but only as the host is configured
  • No automatic modifications to host networking state
Active Learn what we can, possibly standing out from the crowd.
  • Make free use of detected information for further recon
  • No automatic modifications to host networking state
Aggressive Learn things quickly, in ways that will be noticed.
  • "Active", plus...
  • Periodic and triggered wide-spectrum active scanning
  • Omphalos will freely manipulate host networking state
Forceful Actively disrupt the network, rerouting traffic through us.
  • Continuous scanning of the network
  • MitM automatically effected wherever possible
  • DoS will be employed to make MitM more effective
  • Omphalos will freely manipulate host networking state
Hostile Attempt to make the network unusable.
  • Same as "Forceful", but don't pass traffic along once MitM'd.
  • Actively employ null routing.
  • DoS employed upon network infrastructure, carrier, and and egress.
  • GPS coordination and tagging
  • Fully dynamic behavior viz the networking stack. Add and remove cards, routes, addresses...
  • Audiovisual plugins (FIXME detail! lots of good ideas here)
  • Event/scripting engine
    • Fine-grained MitM packet manipulation, filtering and generation via Parvenu and domain-specific languages
    • Fine-grained, one-click identity theft at any desired layer(s) (assumption of MAC, IP, cookies, etc)
  • Full integration with POSIX capabilities for fine-grained security (nothing runs as the superuser)
  • Covert channel detection at all layers via Zetetic
  • Opportunistic, secure remote control via liburine

Network Analysis

  • Network analysis and debugging ought be spun out into Dr. Benway
Layer Subdivisions What's tracked Notes
Layer 2 From both packets and netlink:
  • VLANs
  • ESSs
  • Nodes from packets:
    • All source hardware addresses seen in packets
    • All destination hardware multicast addresses
  • Nodes from netlink:
    • All hardware addresses in the kernel neighbor cache
    • Our hardware addresses
    • Hardware broadcast addresses
  • Node allocation is backed by a mainly-static VLHU
    • At the point an attacker can overwhelm our VLHU, there's effectively nothing on the network but junk packets.
  • If something's a source, it's being claimed as present here on the network. A destination means nothing, except in the case of multicast.
  • Someone else sending with our MAC address ought be noted, unless we stole their MAC address
  • We can't generally differentiate between two other physical hosts using the same MAC
    • Multiple interfaces might actually be sharing a MAC intentionally for low-latency failover
    • Upshot: we don't/can't care. We only care if someone else uses *our* MAC (unless told it's ok).
  • We can't detect a spoofed MAC, but we can send our own ARP probes and at least determine whether the MAC's being serviced
Layer 3 From both packets and netlink:
  • Networks

We don't want to track network addresses beyond our broadcast domain. That's difficult to determine, however, without a working routing configuration (ie, an address). We'll thus assume that RFC1918 membership or service of an L2-restricted service (like DHCP or Zeroconf) indicates local presence (if it doesn't, it indicates misconfiguration). This means that

  • Hosts from netlink:
    • All network addresses in the kernel neighbor cache
    • Configured router addresses
    • Our configured network addresses
    • Configured broadcast addresses
  • Hosts from packets:
    • All source network addresses from the RFC1918 networks
    • All source network addresses to which we have a configured route
    • All source network addresses observed offering L2-restricted services
      • All routers and nameservers named in a DHCP packet
    • All destination network multicast addresses
  • Host allocation is backed by a dynamic VLHU.
  • More dynamic and larger VLHU than that for layer 2, since we can have more hosts than nodes -- imagine a /0 route configuration sitting on an internet backbone. Small implementations of ARP tables and CAMs in nodes/switches means, say, 4k nodes ought almost always be sufficient for any interface.
  • Multiple nodes can share a host address, but it can also indicate a problem
  • Other nodes using *our* host addresses is a problem unless told otherwise
  • Seeing an L3 address on a MAC means either:
    • There's another network present locally (if we have no route to the L3, and the MAC responds to an ARP query for the L3), or
    • That MAC is routing to that address (if the MAC is associated with a route to the L3), or
    • That MAC serves that address (if we have a local route to the address)
      • Perhaps only temporarily, and perhaps without service provision (eg DHCP requests), or
    • There's any variety of misconfiguration/failure/adversary at work (le sigh)
  • Upshot: we can discover the local network(s) without relying on any configuration, even those which don't advertise (ie with DHCP)
Layer 4 From packets:
  • DNS and DHCP servers
We don't use the local configuration because there's no unified API to access it, nor track changes to it. We'll detect DNS quickly enough if anything's actually using the network, and can partially detect host DNS servers simply by kicking off a query through the standard resolver library (even if we don't use the provided result).

Analysis and Attack Capabilities

Physical Layer Support

Protocol Standard libpcap linktype Linux ARP type Analyzed?
BSD Loopback ? DLT_NULL N/A No
Linux Cooked Capture packet(7) DLT_LINUX_SLL N/A Yes
  • Ethernet II/DIX
  • Novell 802.3
  • IEEE 802.2 LLC
  • SNAP
  • 802.1Q VLAN/802.1p QoS (IEEE 802.3ac)
Token Ring IEEE 802.5 DLT_IEEE802 ARPHRD_IEEE802_TR No

(Serial Line Internet Protocol)

  • RFC 1055 (SLIP)
  • RFC 1154 (CSLIP)
PPP (Point-to-Point Protocol)
  • PPP over serial
  • PPPoE (PPP over Ethernet)
  • PPPoA (PPP over ATM)
  • Cisco PPP/HDLC
RFC 1661
  • ?
  • RFC 1662
  • RFC 2516
  • RFC 2364
  • RFC 1547
  • ?
  • No
  • No
  • No
  • No
  • Yes

(Fiber Distributed Data Interface)

  • MAC: ANSI X3.139-1987 / ISO 9314-2
  • PHY: ANSI X3.148-1988 / ISO 9314-1
Fibre Channel RFC 2625 DLT_IP_OVER_FC

(Infrared Data Association)

  • IrDA PHY Spec v1.5
  • IrDA Link Access Protocol v1.1
Radiotap De facto DLT_IEEE802_11_RADIO ARPHRD_IEEE80211_RADIOTAP Yes
Firewire IEEE 1394 N/A ARPHRD_IEEE1394 Yes

(Link Access Protocol - D Channel)


Layer 2

Topology Discovery

For more information, see the Topology Discovery page.

Protocol Standard Support
LLTDP Microsoft
  • Extraction of data from HELLO packets
  • Enumeration via DISCOVERY requests
LLDP IEEE 802.1AB-2005
  • None yet
CDP Cisco
  • None yet
  • Minimal analysis of BDPUs

802.3/Ethernet II

  • Detect physical hosts on the network via MAC analysis
    • Classify as locally-generated, multicast, etc
  • Flood a network with spoofed MAC addresses, in the hope of forcing fail-open behavior to facilitate attacks (see macof from dsniff and Hacking Layer 2: Fun with Ethernet Switches from BlackHat 2002)
  • Probe and autodetect CAM sizes and hash functions, allowing for minimal CAM overflows
  • Autodetect host ARP timings and replacement policies, allowing for stealthy man-in-the-middling
  • Reverse and direct man-in-the-middling (answer all queries for an address, from an address, or both)
  • Gratuitous ARP ("enclosure")
  • Controlled SNAT of outgoing traffic at layer 2, to create multiple realistic hosts ("Capgras delusions")
  • Automated ARP jamming and man-in-the-middling
  • Arpwatch-like layer 2 monitoring
  • VLAN hopping


  • Passively attack weak cryptosystems (especially WEP), or do so actively if configured
  • Channel hopping or locked operation
  • Spectrum and noise analysis plugin
  • Respond as master to probed networks, on a to-order basis
  • Ability to run omphalos in as an AP client via userspace networking atop radiotap (Monitor mode) and WPA/EAPOL support
    • Or, more likely, some kind of hostapd control using Master mode
  • "Hole 196" injection
  • Viehbock's WPS EAP-NACK brute-force attack (US-CERT #723755)

Layer 3

  • ICMP redirects
    • We're closer than the remote server; jam ours in, and let the real one be tossed as duplicate
  • A whole world of IPv6 mischief
  • Rogue DHCP service
  • SNAT for routing enbondaged neighbors
  • ...much more

Layer 4

  • TCP assassination (via RST) / arbitrary corruption
    • Most TCP implementations will (usually) deliver the first bytes received for a given window
  • UDP assassination (via ICMP) / insertion
  • Cryptographic downgrade attacks on HTTPS etc

Layer 5

  • FireSheep- and BEAST-like session hijacking
  • Progressive user identity/demographic discovery aka "maximum creepy" (heuristics on machine name, web pages visited, accounts revealed, mails sent etc)
    • Watch for and aggregate probed wireless networks, DHCP lease renewals, etc
  • Rogue DNS service
  • File-and-signature association for insecure checksums + csums updated-to-order


Omphalos currently only runs or indeed builds on fairly recent Linux systems, due to extensive use of advanced capabilities of the Linux networking stack (and the small fact that I don't run anything else). I doubt that I would accept patches to add Windows/MacOSX support, but you're certainly welcome to maintain them yourself. Once the main functionality set is complete (0.98 release), I'll add support for falling back to plain old PF_PACKET sockets without ringbuffers; that ought add support for any UNIX-based OS with a basic rtnetlink implementation.

User Interfaces

  • omphalos-tty: line-based console output with readline-based input
  • omphalos-ncurses: screen-based terminal output with ncurses-based input
  • GTK: I'd like to add a GTK UI, but it's not a major priority
    • If you'd like to contribute freely-licensed, original artwork to this effort, please contact me!
  • WxWidgets, QT: Dubious that I'll add one, but I'd take patches.
  • Java: nope

Project documentation

Transcluded from top of my git repository at GitHub.


ERROR in secure-include.php: could not read the given src URL

Data Organization

Data Organization and Entry Points

Our input sources include packet sockets, the operating system's netlink
infrastructure, filesystem events, and UI events.

Actions invoked by the UI and service interrogations performed automatically by
omphalos will most often operate naturally at layer 3 or above: a port scan
cannot be run against a MAC, nor can a DNS request be issued to one. Inputs
from the packet socket, however, are most naturally keyed off of layer 2
(especially since a given layer 3 address can show up on multiple layer 2
networks, which MAC addresses' global uniqueness property makes less common).
The netlink layer, meanwhile, refers almost exclusively to logical interfaces,
and various device properties are associated with physical interfaces.

It must be remembered that misconfigured and adversarial peers can violate the
expected properties at any layer save the physical. Other cases to consider,
with definite effects on network modeling, include:

 - multipath routing
 - line bonding
 - proxy ARP
 - disconnected IP networks (local overload of global IP space)
 - multiple cards on the same medium
 - multihoming
 - fail-over/load-balancing
 - unconfigured local networking
 - movement among physical networks without local networking changes
 - same mac address on different networks
 - overeager dhcp
 - etc. ...

Furthermore, omphalos might run in an environment not meaningfully
supported on a typical networking stack, for instance one where two interfaces
are connected to two distinct media which happen to use the same RFC 1938 or
RFC 4193 addresses (Linux would treat this as the same network, and freely
route from either interface). Since we present an interface-centric UI to the
user, and retain knowledge of routes as implied by observed traffic, we can
meaningfully distinguish across destination network addresses seen on multiple
media or from multiple hardware addresses (using this information, of course,
represents a deviation from configured routing policy).This is an explicit
objective: a fundamental goal of omphalos is to discover routes beyond the
local network, even when no configuration exists. Otherwise, we could simply
make use of the kernel routing and neighbor caches, and be done with it.

Knowledge Forward

Upon receipt of a packet, we know ab initio:

 - the interface on which it was received, *if* we use sockaddr_ll (sll_ifindex
	field), or we're binding a SOCK_RAW socket to each interface. We're
	doing the latter.
 - whether it was ours or not, *if* we use sockaddr_ll (sll_pkttype field).
	we're using SOCK_RAW with our AF_PACKETs, though, since SOCK_DGRAM
	doesn't provide us with the destination address.
 - source hardware address (sll_addr, or look at the physical header) and
	address length *if* we use sockaddr_ll (sll_halen field) or we're
	binding a SOCK_RAW socket to each interface, after discovering its
	hardware address length. Note that this assumed all hardware on a given
	medium have the same hardware length.
 - destination hardware address *iff* we're using SOCK_RAW.
 - physical layer protocol (sll_protocol field, or look at the physical header).
 - length of the frame

Of these, the addresses and protocol are set by the sender. Everything else can
be trusted as objectively "accurate". There's a fine line between an adversarial
deception and reality, however. If an adversary spoofs a MAC address and IP
address, and provides service on it, treating this as another host is not a
problem. If an adversary successfully takes over a router's IP via ARP hijack,
but faithfully forwards all traffic, not knowing the router's true MAC is not a
problem. Real issues we must concern ourselves with include:

 - traffic randomized across the address space in an attempt to starve us of
	resources. a meaningful attack must uniquely exploit our operation, or
	else the attacker is simply DoS'ing the network.
  - we defend against this with algorithms and bounded resource allocation
 - traffic designed to mislead our network analysis. this would include
	advertisement of false routes, hijacking of addresses without
	subsequent forwarding, simulation of dns service from whence it is not
	offered, etc.
  - we defend against this by supporting and testing contradictory information
 - traffic designed to be amplified by our automated actions.
  - we defend against this by ensuring only a finite number (preferably 1) of
	packets (including potential replies) are issued. this is most easily
	done by never automatically transmitting to non-unicast addresses,
	and never automatically triggering stateful reconnaissance. this is by
	no means a complete solution, but it seems the best we can do.

It would be useful if logical interfaces could determine that they share a
medium, but this seems impossible in the general case. Seeing the same hardware
address on multiple interfaces could be the result of generated addresses,
misconfigurations, adversaries, or use of well-known addresses (primarily
multicast and broadcast). Seeing the other card's generated packets could be
the result of misconfiguration, adversarial routing/bridging, adversarial
packet generation (a node with connections to both distinct media could
replicate packets from one to another), etc.


We need be able to index by logical interface, hardware address, and network
address. Network addresses need be indexed by range, with the ranges organized
by routes. Interfaces contain many hardware addresses; these hardware addresses
may be shared between interfaces, and up to two entities ('ourselves' and
'others') may shared a hardware address on any given interface (this indicates
a misconfiguration, our seizure of another address, or seizure by some other
entity of our own. We cannot generally differentiate between two hosts sharing
a MAC address). Hardware addresses may contain many local network addresses and
many routes. Network addresses are associated with some number of hardware
addresses, potentially on different interfaces. Routes are associated with a
single network address and a single interface. Note that the network address is
not necessary to actually route through the hardware address; routing only
requires the router's network address if the corresponding hardware address is
missing from the neighbor cache.

An l2node is a hardware address. An l3host is an address which some local
machine claims via ARP, an address in which we are interested, or the set of
addresses seen from some local machine which it does *not* claim via ARP. Note
that while routers are specified via network addresses (and discovered thusly
using netlink), their *hardware* addresses are necessary and sufficient to use
them. The union of all interfaces' l3hosts provide complete information
regarding both routes and neighbors as known to omphalos.

Packet Transmission

If targeting a layer 2 address (as in ARP), we can simply construct the packet
and put it on the wire -- no indexing is necessary. Normally, we're targeting a
layer 3 address. This requires a corresponding layer 2 hardware address. If the
transmission is taken in immediate response to some received packet, we have
all this info, and can proceed directly. Otherwise, we find the l3host via
keying into the global l3host table on destination address. This provides us
with a (possibly local) route. The route object knows its associated interface
in O(1), and thus our proper source hardware address (also in O(1)). The route
object also knows the next hop, if one exists; otherwise the destination is
considered the next hop. Routes don't typically specify the destination
hardware address, but we will usually know it. Since we need it to actually
route, whether we know it or not, stash a reference in the route object as soon
as it's learned (and actively try to learn it upon gatewayed route discovery).
This provides us with all necessary destination information.

Packet Receipt

What information can we glean from a packet on the wire? Ignore trust for the
moment. Assume an IPv4 or IPv6 header. This header will have a source and
destination address. We usually ought be able to route to these addresses on
the receiving interface -- if we can't, it's probably due to one of:

 - any number of misconfigurations/failures in any number of places
 - spoofing of source address
 - one-way route
 - our lack of configuration (a special case of misconfiguration)

None of these are particularly interesting, or even necessarily
distinguishable, save the last; if we're lacking configuration, it ought
usually be possible to infer it  -- so far as is necessary to communicate with
entities we've seen -- via active analysis. ARP can be used to determine
whether a hardware address claims a given IP address; a router will not (Proxy
ARP, as mentioned before, can complicate this). An ARP probe requires an IP
address, which we might not have (or might not be in the same network as the
address seen due to misconfiguration etc), but we can spoof someone else's and
gather information that way (indeed, it might be possible to use the target's
own IP address (which we must know) as our source, so long as we supply our
hardware address as a source, and receive the reply). We run the risk in this
case, however, of upsetting other nodes' own ARP caches, and thus ought be
prepared to forward traffic in the case of an unintentional MitM.

Since packet transmission must often be keyed off a layer 3 address, we'd like
full knowledge of the route, interface, and hardware address relations
directly accessible from the l3 objects. Since we're using packet reception to
learn many of these details, that's a natural place to perform the binding.
It further facilitates detection of addresses duplicated across interfaces and
hardware addresses, should that ever prove useful. Finally, this allows
automatic reconfiguration of the routing database based on what we really see
in the network (and thus it can be abused by adversaries if we're not careful).

So, on packet receipt:

 - Ensure a reference to the interface
 - Find the l2 address within the interface's neighbor LRU, or insert it
 - Find the l3 address within the global table
 - If it is found, compare the route info to this data, possibly updating it.
 - If it is not found, and it corresponds to a local route we know, add an
	l3host for the address, and store a reference in our neighbor table.
 - If it is not found, and it corresponds to a non-local route we know, exit.
 - If it is not found, and does not correspond to a route we know, hit the
	source MAC address with an ARP for the network address. A positive
	reply indicates a local address, Proxy ARP, or an adversary. A negative
	reply cannot indicate much, but suggests the possibility of a route at
	the source hardware address to at least the source network address.

One of her sisterhood lugged me squealing into life. Creation from nothing. What has she in the bag? A misbirth with a trailing navelcord, hushed in ruddy wool. The cords of all link back, strandentwining cable of all flesh. That is why mystic monks. Will you be as gods? Gaze in your omphalos. -- James Joyce, Ulysses

See Also