Ghost Eye: a menu-driven recon script for a first pass on a target

Fifteen actions behind a numbered menu

Ghost Eye presents itself as an information gathering, footprinting, scanner and recon tool written in Python 3, and the interface is a plain numbered menu. The options are listed in the README with a plus sign for the tool entries and an x for the exit entry, and the tool asks for your choice.

The list is worth reading in full because it defines what the tool actually is. The entries are EtherApe as a graphical network monitor, DNS lookup, whois lookup, nmap port scan, HTTP header grabber, clickjacking test via the X-Frame-Options header, robots.txt scanner, Cloudflare cookie scraper, link grabber, IP location finder, CMS detection with Identified Technologies, traceroute, a crawler that follows the target URL and its robots.txt, and a certificate transparency log monitor, with exit as the fifteenth.

The design intent is stated in the README as a game of options, so that together you get a complete overview of your target. That is a fair description of the shape, though it is worth being clear that the fifteen actions are mostly wrappers around tools that already exist. DNS lookup, whois, nmap and traceroute are standard command line programs. The link grabber, the header grabber and the clickjacking check are things an HTTP client can do directly. What Ghost Eye adds is the menu, the sequencing, and the fact that the same target string is reused across all of them.

That is a real contribution for a learner, because the thing that stops people gathering information is not the difficulty of any single step, it is not knowing which steps exist. A menu makes the whole first pass visible in one screen.

The options that are genuinely distinct from a shell one-liner

Some of the fifteen entries are the tool's own code and some are thin wrappers, and the difference matters when you judge what you are running.

The clickjacking test is the clearest example of a check you could write yourself but rarely do. It looks at the X-Frame-Options header, which is what tells a browser whether a page may be embedded in a frame, and a page that does not set it is a candidate for clickjacking. The tool lists it as a distinct entry, which is the right instinct, because the fix is a one-line deployment change and the check is easy to forget.

The CMS detection entry uses what the README calls Identified Technologies, and the requirements list shows the library behind it, webtech, alongside beautifulsoup4. Fingerprinting a content management system from response headers and page markup is the sort of thing where the library choice is the whole implementation, so this entry is mostly the library plus a print statement.

The Cloudflare cookie scraper is the one entry that deserves scrutiny rather than admiration. Scraping a Cloudflare-protected site is a workaround for an anti-bot mechanism, and the same package, cloudscraper, appears in the requirements next to requests and urllib3. The legitimate use is checking what a scraper sees instead of what a browser sees, which is how you find out whether your own site is protected. The illegitimate use is the other one.

The certificate transparency log monitor is the most interesting of the set from a defensive point of view, because CT logs are public by design and searching them for a domain reveals subdomains and certificates that an attacker would find the same way.

So the tool is best read as a curated list of first-pass checks with one row per row of the menu, some of which are its own code and some of which are a call to a library or a binary.

Installing it: system tools first, then a virtual environment

The installation section leads with a point that is easy to skim past. You have to install Nmap and EtherApe too, because the menu entries that call them will not work otherwise.

On Arch Linux and its distros the packages are installed with pacman, pulling in etherape, nmap, dnsutils, gnome-terminal, httpie and mtr. On Debian and its distros, which the README names as Kali Linux and Parrot Security OS, the equivalent is apt with the same package list:

sudo apt install etherape nmap dnsutils gnome-terminal httpie mtr

That package list tells you exactly which external tools the script shells out to. dnsutils is the DNS lookup, mtr is the traceroute, httpie is an HTTP client, gnome-terminal is there so the graphical EtherApe monitor has somewhere to open, and nmap is the port scanner.

There is also a documented workaround for a specific failure. After installing EtherApe, a GNOME error can occur, for which you install libgnomeui-0:amd64, and the README says this solves the common error.

The repository itself is then cloned and set up in a virtual environment, which the README marks as recommended:

git clone https://github.com/BullsEye0/ghost_eye.git
cd ghost_eye

python3 -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate

pip3 install -r requirements.txt

The Python dependencies are six lines: beautifulsoup4, cloudscraper, python-nmap, requests, urllib3 and webtech. python-nmap is the Python binding for the port scanner, requests and urllib3 are the HTTP layer, beautifulsoup4 is the HTML parsing behind the link grabber and the crawler, and cloudscraper and webtech are the two specialised ones.

Running it is a single command:

python3 ghost_eye.py

And the author closes with a note about a target being needed: to run Ghost Eye, it only needs a domain or an IP.

What the single-file layout tells you

The top-level repository is five entries: LICENSE, README.md, featured-image.png, ghost_eye.py and requirements.txt. There is no src/ directory, no package metadata, no test directory and no configuration file.

That shape is a script, not a tool you install. There is no entry point to import, so you cannot call Ghost Eye's functions from your own code, and there is no way to feed it a list of targets from a file and get structured output back. Everything happens through the interactive menu, and the results are printed to the terminal for a human to read.

It also means the whole implementation is one file you can read. For a learning tool that is a feature rather than a limitation, because there is no structure to navigate before you understand the code. You can see the whole of a given check at once, which is exactly what a course wants.

The other end of the same coin is that there is no way to extend it cleanly. A new check means editing the single file, and the menu numbering shifts as entries are added. The README describes this release as tweaking, removing and adding features, which is the natural consequence of the layout.

The project metadata gives the rest of the picture. The primary language is Python, the licence is GPL-3.0, the default branch is master, and the repository publishes no GitHub releases. The last push was on 2026-10-01 and the project is not archived, so work continues on the script. The topic list names the individual checks, etherape, nmap, whois-lookup, dns-lookup, cms-detector, link-grabber, location-finder, cookie-scraper, clickjacking-vulnerability and information-gathering, which confirms that the menu entries and the tool's purpose line up.

Where this sits in the reconnaissance toolbox

The honest comparison is with a shell script you would write yourself, and with the specialist tools it wraps.

Against your own script, Ghost Eye wins on breadth of options and on discoverability. A first-pass assessment of a domain involves at least a DNS lookup, a whois, a port scan, a header grab, a robots.txt check and a certificate transparency search, and knowing that list up front is the difference between a systematic pass and a lucky one. Against your own script it loses on everything else, because there is no parallelism, no output format, no scripting interface and no way to run it against a list of hosts.

Against the specialist tools, it wins on convenience and loses on capability. nmap alone does far more than the nmap menu entry, and it has a scripting interface, a scan database and output formats. The same is true of other tools. What Ghost Eye adds is the fact that they are all in one place and the same target is threaded through them.

The real alternative for a professional is a proper scanning platform with a scheduled job, machine readable output and a reporting layer, none of which this is. For a learner or for a single manual check, a menu is the right interface, because it forces you to make a decision at each step and that decision is the thing being learned.

The context matters too. The README links a course on ethical hacking, and a Facebook group for ethical hacking, and the tool is presented as part of that teaching. The people most likely to run Ghost Eye are the people for whom a single machine and a domain and a fifteen item menu is exactly the right amount of tooling.

And the last thing to weigh is that several entries are active probes. A port scan, a crawler and a Cloudflare cookie scraper all send traffic to the target and some of them will show up in the target's logs. That is why the authorisation question comes before the tool question.

The gap between the menu and a repeatable assessment

Two limits are worth naming explicitly for anyone thinking of using this beyond a course.

The first is that nothing is recorded. There is no log file, no report, no export. The results exist in your scrollback after the run, and a later session starts from nothing. If you need to compare a scan before and after a change, or hand the findings to someone else, you are copying text out of a terminal by hand.

The second is that the results are not interpreted. A header grabber prints headers, a clickjacking test tells you whether a header is present, and the CMS detector tells you what it thinks the site runs. None of them tell you whether that is a problem, and none of them prioritise the fifteen checks by what matters for this particular target. That prioritisation is the analyst's job, and it is the part a menu cannot do for you.

The tool is also opinionated in a way that is worth noticing: the list of fifteen is the author's opinion about what a first pass looks like. It includes the certificate transparency monitor, which many first passes skip, and it does not include a subdomain enumeration step, which most first passes consider essential. Neither is a criticism so much as a reminder that a fixed menu is a starting point and not a methodology.

If you take the tool and extend it, the natural direction is a script that runs the same checks non-interactively, in order, and writes the output somewhere durable. The building blocks are all there. The menu is a teaching interface over what could be a pipeline.

Editorial conclusion

Adopt Ghost Eye if you are learning reconnaissance on systems you are authorised to test and want one menu that walks the first hour of a target assessment, because that is exactly what it is and the fifteen actions are individually recognisable. Do not adopt it as an automated scanning component, since it is a single script with an interactive menu, no scheduling, no output format you can parse, and no exit status that reflects findings, so it belongs in front of a person. Before you run it, install the system tools it shells out to, nmap, etherape, dnsutils, httpie and mtr, and remember that several of its options, the port scan, the Cloudflare cookie scraper and the crawler, send traffic to the target and need permission.

Frequently asked questions

Official sources

1. BullsEye0/ghost_eye on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README