HUNT(1)

πŸ“¦
version 1.5 Β· 2 versions
, in fedora 43, fedora 44

πŸ‘‘ HUNT(1) β€” the manual page, but make it slay

okay bestie, welcome to the HUNT(1) page from the General Commands Manual πŸ’… this is the Debian version of the docs, and we're gonna go through the whole thing together, no skips, no cap.


✨ NAME ✨

hunt β€” Network security auditing tool. πŸ•΅οΈβ™€οΈ that's the whole vibe. it's giving "I watch packets for a living".


🌸 SYNOPSIS 🌸

hunt [-V] [-v] [-i interface]

three flags, one dream. we'll get to them, don't worry 🫢


πŸ’– DESCRIPTION πŸ’–

so this manual page documents briefly the hunt command, fr fr. it was written for the Debian GNU/Linux distribution because the original program does not have a manual page β€” instead it has documentation in the GNU Info format, see below. πŸ’€ iconic of it tbh.


πŸŽ€ READ FIRST πŸŽ€

okay real talk, bestie: please make sure you KNOW what you are doing before using hunt. 😭 this is not a "vibe check first, read later" situation.

it is recommended that you should test how it behaves on some test connections and then use it wisely. periodt. 🧚


🌈 OVERVIEW 🌈

Hunt is a program for intruding into a connection, watching it and resetting it. it has several features which the author didn't find in any product like Juggernaut or T-sight that inspired the development. the author found Juggernaut not flexible enough for further development, so they started from scratch (see FEATURES and DESIGN OVERVIEW). πŸ’…

note that hunt is operating on Ethernet and is best used for connections which can be watched through it. however, it is possible to do something even for hosts on another segments or hosts that are on switched ports. the hunt doesn't distinguish between local network connections and connections going to/from Internet. it can handle all connections it sees. πŸ‘‘

Connection hijacking is aimed primarily at the telnet or rlogin traffic, but it can be used for another traffic too. the reset, watching, arp, ... features are common to all connections.


πŸ”₯ FEATURES πŸ”₯

πŸ’« Connection Management

  • Setting what connections you are interested in.
  • Detecting an ongoing connection (not only SYN started).
  • Normal active hijacking with the detection of the ACK storm.
  • ARP spoofed/Normal hijacking with the detection of successful ARP spoof.
  • Synchronization of the true client with the server after hijacking (so that the connection don't have to be reset).
  • Resetting connection.
  • Watching connection.

🌸 Daemons

  • Reset daemon for automatic connection resetting.
  • ARP spoof/relayer daemon for ARP spoofing of hosts with the ability to relay all packets from spoofed hosts.
  • MAC discovery daemon for collecting MAC addresses.
  • Sniff daemon for logging TCP traffic with the ability to search for a particular string.

πŸ¦‹ Host Resolving

  • Deferred host resolving through dedicated DNS helper servers.

⭐ Packet Engine

  • Extensible packet engine for watching TCP, UDP, ICMP and ARP traffic.
  • Collecting TCP connections with sequence numbers and the ACK storm detection.

πŸ“ Misc

  • Determining which hosts are up.

πŸ’œ Switched Environment

  • Hosts on switched ports can be spoofed, sniffed and hijacked too.

πŸ’… COMMAND LINE PARAMETERS πŸ’…

  • -V β€” Print Version. simple. clean. iconic.
  • -v β€” Verbose (print pids of created threads). πŸ‘€ it's gonna tell you everything.
  • -i interface β€” Listen on this interface. Default is eth0.

🧚 TECHNICAL EXPLANATION 🧚

let me explain some technical issues which are used in hunt and which are essential for understanding how it works and what you should expect. the important terms are IP spoofing, ARP spoofing and ACK storm. even if you are familiar with them, you can get some new information. 🫢

πŸ•΅οΈβ™€οΈ IP spoofing

You set the packet source address to the IP address of the host you pretend to be.

πŸŽ€ ARP spoofing

You set the packet source hardware address (source MAC address) to the address of the host you pretend to be.

πŸ’€ Simple Active Attack against TCP connections

It is a well known type of attack in which you send a packet with spoofed IP addresses and possibly also with spoofed ARP addresses (true MAC addresses of client and server β€” not fake ones as explained further). in this way, you can force a command to the stream, but you are likely to receive the ACK storm (as explained further) unless the original client host of the connection is running Linux. 😭

🌸 ARP spoofing

I use this term also for forcing the remote host to think that the host I want to be has a different MAC address, so the remote host sends replies to that MAC address and the original client host is not able to receive them (but hunt is watching carefully and handles all consequences). (Explaining how to force a host on the network to think that the other host has a different MAC I leave as an exercise β€” I encourage you to read the source code.) πŸ“–

please note that I use the term ARP spoofing instead of the term ARP forcing or something like that. so don't be confused, if I say ARP spoofing, I mean using some MAC address of a host or just some fake MAC address. πŸ‘‘

note that ARP spoofing (with my meaning to force some MAC) doesn't work on Solaris2.5 because it has expiration timers on ARP entries so you can't easily force Solaris to drop an ARP entry. the entry usually expires after 20min or less (but you have a chance to force it and hunt supports this mode). the expiration timers on Solaris are set by:

ndd -set /dev/ip ip_ire_flush_interval 60000 /* 1 min */
ndd -set /dev/arp arp_cleanup_interval 60 /* 1 min */

I encourage you to ask your netadmin to set the above values on all Solaris machines. 😌 the Win95/NT4sp3, Linux2.0, OSF1 V4.0, HP-UX10.20 are not protected in this way so you can easily use the described technique on them (actually, they have timers, but they are not operating like in Solaris; in fact, only Solaris is the exception).

actually, hunt uses this technique such that it wants to force a fake MAC of the server to the client and a fake MAC of the client to the server. then both the server and the client are sending packets to that faked MACs (and hunt can of course handle them). however, it is sufficient that only one host has a fake MAC of the other host. the ACK storm can't occur in this situation either. so you can use this technique even if one end is Solaris and the other isn't. you will just succeed in the other host and that is enough. ✨

so the only problem is when the connection is between two Solaris machines. however, if there is any root connection ongoing you can easily push the commands suggested above without ARP spoofing to the connection and alter the expiration timers of the ARP cache. 🫢

🌈 ACK Storm

the ACK storm is caused by majority of TCP stacks (!!! Linux2.0 is an exception !!!). let's imagine that you send some data to an ongoing connection to the server (as if sent by the client β€” with expected seq. numbers, ...). the server responds with the acknowledgment of the data you sent, but this acknowledgment is received by the original client too. but from the original client point of view, the server has acknowledged data that doesn't exist on the client. so something strange occurred and the original client sends the "right" sequence number with ACK to the server. 😭

but the TCP rules say that it is required to generate an immediate acknowledgment when an out-of-order segment is received. this ACK should not be delayed. so the server sends the acknowledgment of non-existent data to the client again. and the client responses, ... πŸ’€πŸ’€πŸ’€

only if the source host of the connection is Linux then the ACK storm doesn't occur. note that if you use ARP spoofing (forcing) then the ACK storm can't come because one or both ends will send packets with fake MACs and those packets are received by hunt rather than by the other host. πŸ‘‘

πŸ”₯ Connection Reset

with a single properly constructed packet you can reset the connection (RST flag in TCP header). of course, you have to know the sequence number, but it is not a problem for hunt which is watching all the time. you can reset server, client, or both. when you reset only one end, the other end is reset when it tries to send data to the first host which will response with RST because of the connection reset on it.

πŸ¦‹ Connection sniffing/watching

the simplest thing you can do is to silently sit in you chair and watch hunt output about any connection which you choose from the list. 🍿 main character energy, honestly.

πŸ’– Connection Synchronization

well, that's one of the main features of hunt. if you put some data to the TCP stream (through simple active attack or ARP spoofing), you desynchronize the stream from the server/original client point of view. after some work done on that connection you can just reset it or you can try to synchronize both original ends again. that is not an easy task. 😭 the user on the client is prompted to type some chars and some chars are sent to the client and server. the main goal of all stuff is to synchronize the sequence numbers on both client and server again.

⭐ Switch/Segment traffic rerouting

with ARP spoofing you can even force switch so that it will send you the traffic for hosts on another segment/switched port. this is because a switch will think that the MAC belongs to your port. be careful if your switch has some security policy and MACs have been explicitly set up on a per port basis β€” but in fact I don't ever see such a configuration on "ordinary" network. πŸ’…

🌸 ARP-relay daemon

don't be confused. I use this term for hunt daemon which is responsible for inserting packets to the network (rerouting) of all data it receives from ARP spoofed hosts.

πŸ’œ Switched environment

well, the hunt is now capable of watching and hijacking hosts that are on switched ports. in common you can't watch the hosts traffic on switched ports, but if you first ARP spoof them (with ARP spoof daemon menu) you are able to look at the connections that are between that hosts. first you do arp spoof and the hosts will send you the traffic, and from that time you can list the connections between them, then you can watch and hijack them. πŸŽ€

it is commonly accepted that the switches protect your connections again inside intruders and spoofers. well, that is still true for carefully setuped switches. the switches that are plugged to the LAN without any port security configuration are useless in the job to protect your LAN. πŸ’€


πŸ’… DESIGN OVERVIEW πŸ’…

okay bestie so the whole dev model? it's built around a packet engine (hunt.c) that runs in its own thread and captures packets straight off the network. no cap.

That packet engine is collecting all the tea: info about TCP connections β€” when they start, when they end β€” plus sequence numbers and MAC addresses. And here's the cute part: it grabs the MACs and seq. numbers from the server's point of view and separately from the client's point of view. So yeah, it's fully prepared for hijacking. This information (seq. num., MAC,

Modules can register functions with the packet engine. Those get invoked when new packets arrive. A module function decides if the module is interested in a packet or not, and can drop it into a module-specific list of packets. It can also send a packet to the network if it needs to happen fast. Then the module β€” usually in some other thread, so it needs to be scheduled to be run β€” pulls packets from that list and analyzes them. That's how you can easily build modules that do all kinds of stuff.

Packets you wanna send as a response? They're described by structures, so you don't have to stress about some default fields or checksums. Right now, functions for TCP, ICMP, and ARP traffic are already prepared. (UDP is missing because the author doesn't use it in any module β€” their words, not mine.)

Then a whole separate set of daemons handles host resolving (DNS). Why? Because gethostbyname/gethostbyname_r is protected by a mutex (as far as the author knows β€” it was like that two years ago, they didn't try it recently), so you can't run it truly parallel in a multithreaded environment. So the common workaround: fork off some helper daemons that will run gethostbyname.


🌸 USER ENVIRONMENT 🌸

So the user environment isn't graphical, but the author believes you'll like it. πŸ’–

In the title of all menus there's some status info about hunt. First: an indication of which menu you're working in. Second: the number of packets received by hunt. Hunt pre-allocates some buffers for packets; the status of free and allocated buffers is the third value. The number of free buffers gets low if the network is heavily loaded, or there's an ACK storm, or your hardware is just struggling. In the author's case, for example, 63/64 was normal β€” meaning only one buffer was used β€” but after an ACK storm, it looked more like 322/323. Note that buffers, once allocated, are not freed. A low number of free buffers could also mean some bug in hunt, but the author thinks they carefully debugged all modules against that kind of bug. The last indicator reports which daemons (actually threads) are running. They are: R β€” reset daemon, Y β€” arp relayer, S β€” sniffer, M β€” MAC discoverer. If you switch on the verbose option, you get extra info: how many packets were dropped (they were fragments β€” see the bugs β€” or malformed), and how many packets belong to protocols other than TCP, UDP, ICMP, and ARP. And in the prompt for user input there's an indicator that tells you through the '*' char that hunt added new connection(s) to the connection list since the last connection listening.

✨ General interface ✨

In all menus the x key works as escape. The network mask is denoted by the ip_address/mask notation, where mask is the number of 1's on the left side of the network mask. For example, 0.0.0.0/0 means everything, and 192.168.32.10/32 means only that host.

For most modules, this is used:

l) list items
a) add item
m) modify item
d) delete item

They'll be referred to in this text as l) a) m) d) β€” cute, right? πŸŽ€

πŸ‘€ List/Watch/Reset connection πŸ‘€

You can get the list of connections tracked by the hunt packet engine. Which connections are tracked is specified in the options menu. You can interactively watch or reset these connections. You can also perform hijacking on them (that's the next two menu items).

πŸŽ€ ARP/Simple hijack πŸŽ€

ARP/Simple hijack gives you an interactive interface for the insertion of data into the selected connection. You can do ARP spoofing for both connection ends, for only one end, or not at all. If you don't do ARP spoofing, you'll probably receive the ACK storm right after typing the first char. When you do ARP spoofing, it checks if it succeeds. If not, you're prompted whether you want to wait until it succeeds (you can interrupt this waiting with CTRL-C, of course). After inserting some data into the connection, you type CTRL-] and then you can synchronize or reset the connection. If you choose synchronization, the user is prompted to type some chars, and after they do so, the connection will be in the synchronous state. You can interrupt the synchronization process with CTRL-C and then reset the connection. Note that CTRL-C is used widely for interrupting an ongoing process. The CTRL-] (like telnet) is used for finishing the interactive insertion of data into the connection. The ARP/Simple hijack doesn't automatically reset the connection after it detects the ACK storm, so you have to do it yourself. Also note that ARP/Simple hijack works with the ARP relayer (as described further) so that other connections are not affected. Normally, if you ARP spoof two servers, then the ARP/Simple hijack handles only one selected connection between those two hosts, but other connections between those two hosts look like they freeze. If you start the ARP relayer, then these other connections are handled and rerouted through. So other connections from one spoofed host to the other are not affected at all. It is recommended to run the ARP relayer if you do ARP hijacking of two servers. Note that if you ARP spoof (force) some client MAC to the server, then only connections going from the server to that client are affected. Other connections from the server to other machines are untouched.

πŸ¦‹ Simple hijack πŸ¦‹

Simple hijack allows you to insert a command into the data stream of the connection. When you insert the command, hunt waits for it to complete up to a certain timeout, and if the ACK storm doesn't occur, you are prompted for the next command. After that, you can synchronize or reset the connection. Note that you can use the interactive interface to simple hijack when you use ARP/simple hijack without ARP spoofing β€” but if you use the full interactive interface of ARP/simple hijack without ARP spoofing, you are likely to get the ACK storm immediately after typing the first char. So this mode of hijacking is useful when you have to deal with the ACK storm, because it sends your data to the connection in a single packet. When the ACK storm is in progress, it is very hard to deliver other packets from hunt to the server, as the network and server are congested.

🧚 DAEMONS 🧚

Okay so I call these little guys daemons but bestie, lowkey they're actually threads. All daemons can be started and stopped. So do NOT be surprised when you insert or modify some rule in a daemon and nothing happens β€” the daemon isn't running, you literally have to start it yourself. All daemons are by default stopped, even though you can totally still alter the configuration. The common commands in the daemons menu are:

s) start the daemon
k) stop the daemon
l) list configuration items
a) add config. item
m) modify config. item
d) delete config. item

Reset daemon

This one does automatic resets of ongoing connections that hunt can see. ✨ You describe which connections should be terminated by giving src/dst host/mask and src/dst ports. Here's the vibe:

  • SYN flag off β€” all the specified connections get terminated, even the ongoing ones. πŸ’€
  • SYN flag on β€” only newly started connections get reset, so the ones already in progress are untouched. 🫢

Don't forget to start the daemon!! Fr fr.

ARP daemon

Here you can do ARP spoofing of hosts. 🌈 You enter src and dst</purge> addresses and the desired srcMAC. The dst is then forced to think that src has srcMAC. You can use some fake MAC or, better, the MAC of a host that is currently down. You just want the hosts to send you all the data β€” so you can even look at packets that are on a different segment or switched port that you wouldn't normally see. πŸ‘‘

The ARP module looks carefully for packets which will break ARP spoofing of hosts and handles them, but you can even specify the refresh interval for ARP spoofing β€” though it is not necessary to do it. Set the refresh interval only if you are experienced with some bad or strange behavior of spoofed hosts. There's also the possibility to test the hosts for successful spoof, with the ability to force that spoof. It is recommended to test the ARP spoof if something looks like it is wrong or the computer doesn't send the traffic to the hunt. The force option is handy if the first spoofing packets are discarded with a switch β€” so if you're running hunt against hosts on switched ports, you can try running the force mode by example for 10s and then break it with CTRL-C if the spoof continues to fail. πŸŽ€

The ARP relayer daemon is used to perform ARP relaying of ARP spoofed connections. When you insert some ARP spoof of hosts, the ARP spoofing is performed immediately β€” even if the relayer isn't running!!! But if the ARP spoofing succeeds, the connections will look like they freeze. πŸ₯Ά For rerouting (not IP routing !) these connections through your hunt, you need to start the ARP relayer. The relayer works well with ARP/simple hijack, so once you have hosts ARP spoofed with ARP relaying you can easily do ARP/simple hijack, which will detect that the hosts are already ARP spoofed and takes over the connection immediately. With this technique you can easily become man in the middle from the beginning of the connection even though your host with hunt isn't an IP gateway. I encourage you to write other application specific protocol handlers for the man in the middle attack, as it is really simple with this framework. πŸ’…

Sniff daemon

The purpose of the sniff daemon is to log specified packets. The sniff daemon can also search for a simple pattern (string) in the data stream (see the bugs section). You can specify which connection you are interested in, where to search (src, dst, both), what you want to search, how many bytes you want to log, from what direction (src, dst, both), and to what file the daemon should write. All logged files are stored in the .sniff directory.

The default file name for logging is composed of the host and port n,0e(asInew-linesiorsasuhexnnum.).can set how to log new lines ( β€” yes bestie, that bit is genuinely scrambled in the source, so it stays exactly like that. Keeping it 1:1. 🫠

MAC discovery daemon

This daemon collects MAC addresses corresponding to the specified IP range. πŸ¦‹ You can enter the time after which the daemon will try collecting again β€” the default is 5min.

Host up menu

The host up module determines which hosts are up (with TCP/IP stack). You just specify the IP range and that space is then searched for running hosts. It's capable of determining which hosts have a network interface in promiscuous mode. πŸ‘€ The promiscuous mode usually shows that the host is running some kind of sniffer/network analyzer.

Options menu

In the options menu you can tune different things:

  • l) a) m) d) β€” List/Add/Mod/Del Connection Policy Entry. First of all you can select which connections should be tracked. The default setting is to look at telnet connections from all hosts, but you can adjust this behavior by the specification of src/dst address/mask src/dst port pairs. With the commands l) a) m) d) you set what you are interested in.
  • c) β€” Connection Listening Properties. You can set whether the sequence numbers and MACs of ongoing connections will be displayed during connection listening.
  • h) β€” Host Resolving. You can turn on resolving of hosts to their names. As the resolving is deferred, you don't get the names of hosts immediately. Just try to list connections several times and you will see the hosts names. (I used this deferred approach because I didn't want any delay of interface that the resolving can cause.)
  • r) β€” Reset ACK Storm Timeout. This timeout is used in simple hijack to automatically reset the connection after the ACK storm is detected. Note that you can receive the ACK storm even in arp/simple hijack in case you don't perform ACK spoofing of any host.
  • s) β€” Simple Hijack Timeout For Next cmd. Simple hijack does not have an interactive connection interface. That means you write the whole command which will be inserted into the connection data stream. If no data is transferred through the connection up to this timeout, you are prompted for the next command.
  • q) β€” ARP Request/Reply Packets. Number of request or reply packets hunt will send when it is doing arp spoofing.
  • t) β€” ARP Request Spoof Through Request. Option whether hunt will send ARP spoof request or ARP spoof reply when it receives a broadcasted ARP request which will break ARP spoof.
  • w) β€” Switched Environment. Some optimization for switched environment. It works perfectly for non switched environment also.
  • y) β€” ARP Spoof With My MAC. Set the originating MAC address of sent spoofed ARP to my (hunt) ethernet MAC β€” sometimes helps in switched environment.
  • e) β€” Learn MAC From IP Traffic. You can enable that MAC addresses will be learned from all IP traffic, not just from ARP.
  • p) β€” Number Of Printed Lines Per Page In Listening. Self explanatory.
  • v) β€” Verbose On/Off. Self explanatory.

🌸 TESTED ENVIRONMENT 🌸

HUNT program requirements:

  • Linux >= 2.2
  • Glibc with linuxthreads
  • Ethernet

Tested hosts:

Linux 2.0, Linux 2.1, Linux 2.2, Solaris 2.5.1, NT4sp3/4, Win95, OSF V4.0D, HPUX 10.20, IRIX 6.2

Tested network equipment:

BayNetworks 28115, 28200, 300 switches, 3Com SuperStack II 3000, 1000 switches


πŸ’œ SECURITY NOTES πŸ’œ

Please note the already known truth that telnet and similar programs which send passwords in clear text are vulnerable to the described attacks. 🚨 Programs using one time passwords are also easily attacked, and in fact they are useless if someone can run a program like hunt. Only full encrypted traffic isn't vulnerable to these attacks β€” but note that you can become a man in the middle if you use ARP spoofing (forcing) without the ACK storm and you can try to do something. Also, an unconfigured switch doesn't protect you from sniffing or hijacking. It is necessary to carefully configure port security on the switches in order to protect the computers on the switched ports. 😭

Detecting attacks isn't an easy task. For ARP spoofing there are tools which can detect it. The ACK storm is detectable by some sophisticated network analyzers (you can detect the pattern of the ACK storm or the statistics of ACKs without data). If you run hunt on your network you can detect the ACK storm because hunt can detect the ACK storm pattern. πŸ”


⚑ PERFORMANCE NOTE ⚑

Make sure you are running hunt on an idle machine with sufficient power (I used PII-233 with 128MB RAM) and without any other packet analyzer, because if you use advanced features like arp spoofing or hijacking, hunt needs to reply fast with its own packets inserted into the traffic on the network. πŸƒβ™€οΈπŸ’¨


πŸ¦‹ DOWNLOAD πŸ¦‹

This software can be found at http://www.gncz.cz/kra/index.html or at ftp://ftp.gncz.cz/pub/linux/hunt/


πŸ’€ KNOWN BUGS πŸ’€

  • some structures are poorly locked through mutexes
  • if you watch connection then some escape sequences from that connection can influent your terminal. Note that your terminal is named "Linux" ("xterm" β€” if you run it from X, ...) but the escape sequences are for the client side terminal which may or may not be Linux, so you can get some mess.
  • sniff is not capable to search for a pattern which crosses the packet boundary. That means it can't search for a pattern of the user typed input, as this input is usually transferred with 1B data long packets.
  • hunt doesn't support defragmentation, so the IP fragments have to be dropped.

🫢 BUG FIXES, SUGGESTIONS 🫢

Please send bug descriptions, patches, suggestions, new modules or successful stories to kra@gncz.cz


πŸŽ€ ACKNOWLEDGMENTS πŸŽ€

I would like to thank Sven Ubik < ubik@fsid.cvut.cz > for his invaluable input and feedback.


πŸ‘‘ FINAL WORD πŸ‘‘

Note that this software was written only for my fun in my free time and it was a great exercise of TCP/IP protocols. I am now familiar with seq. numbers, ACKs, timeouts, MACs, checksums, ... to the finest level. As I have some pretty good background, this "hunt" challenge made me think that I hadn't known TCP/IP as great as I had thought. You are welcome to read the source code and to try to modify it or write your own modules. ✨


🌈 DEBIAN 🌈

This manpage was converted from internal documentation by Jon Marler < jmarler@debian.org > for the Debian GNU/Linux operating system.


and that's the whole HUNT(1) page bestie!! πŸŽ‰ this is the Debian-packaged hunt manpage, rendered for your terminal on the date stamped in its footer β€” go forth, stay curious, and pls only ever use this on networks you're allowed to touch. πŸ’–

πŸ“¦ where this page comes from