Check out my first novel, midnight's simulacra!


From dankwiki
Revision as of 20:25, 3 January 2020 by Dank (talk | contribs) (→‎Portability)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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.


<include src="" />

Data Organization

<include src="" />

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