Termux ID: Snort -->

WhatWeb identifies websites. Its goal is to answer the question, “What is that Website?”. WhatWeb recognises web technologies including content management systems (CMS), blogging platforms, statistic/analytics packages, JavaScript libraries, web servers, and embedded devices. WhatWeb has over 1700 plugins, each to recognise something different. WhatWeb also identifies version numbers, email addresses, account IDs, web framework modules, SQL errors, and more.

WhatWeb can be stealthy and fast, or thorough but slow. WhatWeb supports an aggression level to control the trade off between speed and reliability. When you visit a website in your browser, the transaction includes many hints of what web technologies are powering that website. Sometimes a single webpage visit contains enough information to identify a website but when it does not, WhatWeb can interrogate the website further. The default level of aggression, called ‘stealthy’, is the fastest and requires only one HTTP request of a website. This is suitable for scanning public websites. More aggressive modes were developed for use in penetration tests.

Most WhatWeb plugins are thorough and recognise a range of cues from subtle to obvious. For example, most WordPress websites can be identified by the meta HTML tag, e.g. ”, but a minority of WordPress websites remove this identifying tag but this does not thwart WhatWeb. The WordPress WhatWeb plugin has over 15 tests, which include checking the favicon, default installation files, login pages, and checking for “/wp-content/” within relative links.


Features:
  • Over 1700 plugins
  • Control the trade off between speed/stealth and reliability
  • Plugins include example URLs
  • Performance tuning. Control how many websites to scan concurrently.
  • Multiple log formats: Brief (greppable), Verbose (human readable), XML, JSON, MagicTree, RubyObject, MongoDB, SQL, and ElasticSearch.
  • Proxy support including TOR
  • Custom HTTP headers
  • Basic HTTP authentication
  • Control over webpage redirection
  • Nmap-style IP ranges
  • Fuzzy matching
  • Result certainty awareness
  • Custom plugins defined on the command line


Example Usage

Using WhatWeb on a couple of websites:

Using a higher aggression level to identify the version of Joomla in use.

Help

.$$$     $.                                   .$$$     $.
$$$$ $$. .$$$ $$$ .$$$$$$. .$$$$$$$$$$. $$$$ $$. .$$$$$$$. .$$$$$$.
$ $$ $$$ $ $$ $$$ $ $$$$$$. $$$$$ $$$$$$ $ $$ $$$ $ $$ $$ $ $$$$$$.
$ `$ $$$ $ `$ $$$ $ `$ $$$ $$' $ `$ `$$ $ `$ $$$ $ `$ $ `$ $$$'
$. $ $$$ $. $$$$$$ $. $$$$$$ `$ $. $ :' $. $ $$$ $. $$$$ $. $$$$$.
$::$ . $$$ $::$ $$$ $::$ $$$ $::$ $::$ . $$$ $::$ $::$ $$$$
$;;$ $$$ $$$ $;;$ $$$ $;;$ $$$ $;;$ $;;$ $$$ $$$ $;;$ $;;$ $$$$
$$$$$$ $$$$$ $$$$ $$$ $$$$ $$$ $$$$ $$$$$$ $$$$$ $$$$$$$$$ $$$$$$$$$'

WhatWeb - Next generation web scanner.
Version 0.4.7 by Andrew Horton aka urbanadventurer from Security-Assessment.com
Homepage: http://www.morningstarsecurity.com/research/whatweb

Usage: whatweb [options]

TARGET SELECTION:
Enter URLs, filenames or nmap-format IP ranges.
Use /dev/stdin to pipe HTML directly
--input-file=FILE, -i Identify URLs found in FILE, eg. -i /dev/stdin
--url-prefix Add a prefix to target URLs
--url-suffix Add a suffix to target URLs
--url-pattern Insert the targets into a URL. Requires --input-file,
eg. www.example.com/%insert%/robots.txt
--example-urls, -e Add example URLs for each selected plugin to the target
list. By default will add example URLs for all plugins.

AGGRESSION LEVELS:
--aggression, -a=LEVEL The aggression level controls the trade-off between
speed/stealth and reliability. Default: 1
Aggression levels are:
1 (Passive) Make one HTTP request per target. Except for redirects.
2 (Polite) Reserved for future use
3 (Aggressive) Triggers aggressive plugin functions only when a
plugin matches passively.
4 (Heavy) Trigger aggressive functions for all plugins. Guess a
lot of URLs like Nikto.

HTTP OPTIONS:
--user-agent, -U=AGENT Identify as AGENT instead of WhatWeb/0.4.7.
--user, -u= HTTP basic authentication
--header, -H Add an HTTP header. eg "Foo:Bar". Specifying a default
header will replace it. Specifying an empty value, eg.
"User-Agent:" will remove the header.
--follow-redirect=WHEN Control when to follow redirects. WHEN may be `never',
`http-only', `meta-only', `same-site', `same-domain'
or `always'. Default: always
--max-redirects=NUM Maximum number of contiguous redirects. Default: 10

SPIDERING:
--recursion, -r Follow links recursively. Only follow links under the
path Default: off
--depth, -d Maximum recursion depth. Default: 10
--max-links, -m Maximum number of links to follow on one page
Default: 250
--spider-skip-extensions Redefine extensions to skip.
Default: zip,gz,tar,jpg,exe,png,pdf

PROXY:
--proxy <hostname[:port]> Set proxy hostname and port
Default: 8080
--proxy-user Set proxy user and password

PLUGINS:
--plugins, -p Comma delimited set of selected plugins. Default is all.
Each element can be a directory, file or plugin name and
can optionally have a modifier, eg. + or -
Examples: +/tmp/moo.rb,+/tmp/foo.rb
title,md5,+./plugins-disabled/
./plugins-disabled,-md5
-p + is a shortcut for -p +plugins-disabled
--list-plugins, -l List the plugins
--info-plugins, -I Display information for all plugins. Optionally search
with keywords in a comma delimited list.
--custom-plugin Define a custom plugin called Custom-Plugin,
Examples: ":text=>'powered by abc'"
":regexp=>/powered[ ]?by ab[0-9]/"
":ghdb=>'intitle:abc \"powered by abc\"'"
":md5=>'8666257030b94d3bdb46e05945f60b42'"
"{:text=>'powered by abc'},{:regexp=>/abc [ ]?1/i}"

LOGGING & OUTPUT:
--verbose, -v Increase verbosity, use twice for plugin development.
--colour,--color=WHEN control whether colour is used. WHEN may be `never',
`always', or `auto'
--quiet, -q Do not display brief logging to STDOUT
--log-brief=FILE Log brief, one-line output
--log-verbose=FILE Log verbose output
--log-xml=FILE Log XML format
--log-json=FILE Log JSON format
--log-json-verbose=FILE Log JSON Verbose format
--log-magictree=FILE Log MagicTree XML format
--log-object=FILE Log Ruby object inspection format
--log-mongo-database Name of the MongoDB database
--log-mongo-collection Name of the MongoDB collection. Default: whatweb
--log-mongo-host MongoDB hostname or IP address. Default: 0.0.0.0
--log-mongo-username MongoDB username. Default: nil
--log-mongo-password MongoDB password. Default: nil
--log-errors=FILE Log errors

PERFORMANCE & STABILITY:
--max-threads, -t Number of simultaneous threads. Default: 25.
--open-timeout Time in seconds. Default: 15
--read-timeout Time in seconds. Default: 30
--wait=SECONDS Wait SECONDS between connections
This is useful when using a single thread.

HELP & MISCELLANEOUS:
--help, -h This help
--debug Raise errors in plugins
--version Display version information. (WhatWeb 0.4.7)

EXAMPLE USAGE:
whatweb example.com
whatweb -v example.com
whatweb -a 3 example.com
whatweb 192.168.1.0/24

Changelog
  • Added unit testing with rake @bcoles
  • Added Elastic Search output @SlivTaMere
  • Source code formatting cleanup @Code0x58
  • Thread reuse and logging through a single thread @Code0x58
  • Fixed max-redirection bug @Code0x58
  • Fixed bug when using a proxy and HTTPS (unknown user)
  • Fixed timeout deprecation warning @iGeek098
  • New plugins and plugin updates @guikcd @bcoles @andreas-becker
  • Added proxy and user-agent to logging @rdubourguais
  • Updated Alexa top websites lists
  • Updated update-alexa script
  • Updated IP to Country database
  • Updated man page
  • Updated Mongo DB output for Mongo 2.x

WhatWeb v0.4.9 - Next Generation Web Scanner


CrunchRAT currently supports the following features:
  • File upload
  • File download
  • Command execution
It is currently single-threaded (only one task at a time), but multi-threading (or multi-tasking) is currently in the works. Additional features will be included at a later date.

Server
The server-side of the RAT uses PHP and MySQL. The server-side of the RAT has been tested and works on the following:
  • Ubuntu 15.10 (Desktop or Server edition)
  • Ubuntu 16.04 (Desktop or Server edition)
Once the latest RAT code has been downloaded, there will be three directories:
  • Client - Contains implant code (ignore for the this section)
  • Server - Contains server code
  • Setup - Contains setup files

Dependencies Setup
  1. Within the Setup directory, there are two dependencies setup shell scripts. If you are using Ubuntu 15.10 run sh 15_10_dependencies.sh, and if you're using Ubuntu 16.04 run sh 16_04_dependencies.sh. Note: This needs to be run as root. Failure to run with root privileges will result in an error.
  2. When asked for a new MySQL root password, please choose one that is complex. This information is needed at a later step.

HTTPS Setup
  1. CrunchRAT uses a self-signed certificate to securely communicate between the server and implant. Run the https_setup.sh shell script with the Setup directory to automate the HTTPS setup. Note: This needs to be run as root. Failure to run with root privileges will result in an error. When asked to fill out the certificate information (Country Name, etc), please fill out all information. Snort rules already exist to alert on the dummy OpenSSL certificates. Don't be that guy that gets flagged by not filling out this information.

Database Setup
  1. Run the database_setup.sh shell script within the Setup directory to setup the MySQL database.
  2. CrunchRAT creates a default RAT account with the admin:changeme credentials. Please log into the web end of the RAT and change the default password. Once logged into the web end of the RAT, go to Account Management--> Change Password to successfully change the default password to something more complex. Additional RAT users can be provisioned using Account Management --> Add Users.

Miscellaneous Setup
  1. Copy all files from the Server directory to the webroot.
  2. You will want to create a downloads directory as well. Note: It is absolutely critical that you don't put this folder in the webroot. I typically create this directory in the /home/<USERNAME> directory. You will want to make sure that www-data can access this directory with the following command sudo chown www-data:www-data downloads. This directory will store all of the files downloaded from the infected system(s).
  3. In the webroot, open the config/config.php file. This is the main RAT configuration file. Make sure that you update all of the variables (downloadsPath, dbUser, dbPass, etc) to match your environment.

Client
CrunchRAT is written in C# for simplicity. The C# binary does not have a persistence mechanism in place, but plans to write a C++ stager are currently in the works.
Targeted Framework: .NET Framework 3.5 (enabled by default on Windows 7 systems)
  1. Create a new console project in Visual Studio
  2. Copy implant.cs code from Client directory and add it to the project.
  3. Change Output Type to Windows Application (this will hide the command window) (Project --> Properties --> Output Type).
  4. Make sure Target Framework is .NET Framework 3.5.
  5. In the actual code, there will be a variable called c2 - Change this variable to the IP address or domain name of the C2 server
  6. Compile and your implant executable is ready to run.


CrunchRAT - HTTPS-based Remote Administration Tool (RAT)

The Port Scan Attack Detector psad is a lightweight system daemon written in is designed to work with Linux iptables/ip6tables/firewalld firewalling code to detect suspicious traffic such as port scans and sweeps, backdoors, botnet command and control communications, and more. It features a set of highly configurable danger thresholds (with sensible defaults provided), verbose alert messages that include the source, destination, scanned port range, begin and end times, TCP flags and corresponding nmap options, reverse DNS info, email and syslog alerting, automatic blocking of offending IP addresses via dynamic configuration of iptables rulesets, passive operating system fingerprinting, and DShield reporting. In addition, psad incorporates many of the TCP, UDP, and ICMP signatures included in the Snort intrusion detection system. to detect highly suspect scans for various backdoor programs (e.g. EvilFTP, GirlFriend, SubSeven), DDoS tools (Mstream, Shaft), and advanced port scans (SYN, FIN, XMAS) which are easily leveraged against a machine via nmap. psad can also alert on Snort signatures that are logged via fwsnort, which makes use of the iptables string match extension to detect traffic that matches application layer signatures. As of the 2.4.4 release, psad can also detect the IoT default credentials scanning phase of the Mirai botnet.
The complete feature list is below.

Features
  • Detection for TCP SYN, FIN, NULL, and XMAS scans as well as UDP scans.
  • Support for both IPv4 and IPv6 logs generated by iptables and ip6tables respectively.
  • Detection of many signature rules from the Snort intrusion detection system.
  • Forensics mode iptables/ip6tables logfile analysis (useful as a forensics tool for extracting scan information from old iptables/ip6tables logfiles).
  • Passive operating system fingerprinting via TCP syn packets. Two different fingerprinting strategies are supported; a re-implementation of p0f that strictly uses iptables/ip6tables log messages (requires the --log-tcp-options command line switch), and a TOS-based strategy.
  • Email alerts that contain TCP/UDP/ICMP scan characteristics, reverse dns and whois information, snort rule matches, remote OS guess information, and more.
  • When combined with fwsnort and the iptables string match extension, psad can generate alerts for application layer buffer overflow attacks, suspicious application commands, and other suspect layer 7 traffic.
  • Icmp type and code header field validation.
  • Configurable scan thresholds and danger level assignments.
  • Iptables ruleset parsing to verify "default drop" policy stance.
  • IP/network danger level auto-assignment (can be used to ignore or automatically escalate danger levels for certain networks).
  • DShield alerts.
  • Auto-blocking of scanning IP addresses via iptables/ip6tables and/or tcpwrappers based on scan danger level. (This feature is NOT enabled by default.)
  • Parsing of iptables/ip6tables log messages and generation of CSV output that can be used as input to AfterGlow. This allows iptables/ip6tables logs to be visualized. Gnuplot is also supported.
  • Status mode that displays a summary of current scan information with associated packet counts, iptables/ip6tables chains, and danger levels.

Visualizing Malicious Traffic
psad offers integration with gnuplot and afterglow to produce graphs of malicious traffic. The following two graphs are of the Nachi worm from the Honeynet Scan30 challenge. First, a link graph produced by afterglow after analysis of the iptables log data by psad:
"Nachi Worm Link Graph"

The second shows Nachi worm traffic on an hourly basis from the Scan30 iptables data:
"Nachi Worm Hourly Graph"

Configuration Information
Information on config keywords referenced by psad may be found both in the psad(8) man page, and also here:
http://www.cipherdyne.org/psad/docs/config.html

Methodology
All information psad analyzes is gathered from iptables log messages. psad by default reads the /var/log/messages file for new iptables messages and optionally writes them out to a dedicated file (/var/log/psad/fwdata). psad is then responsible for applying the danger threshold and signature logic in order to determine whether or not a port scan has taken place, send appropriate alert emails, and (optionally) block offending ip addresses. psad includes a signal handler such that if a USR1 signal is received, psad will dump the contents of the current scan hash data structure to /var/log/psad/scan_hash.$$ where "$$" represents the pid of the running psad daemon.
NOTE: Since psad relies on iptables to generate appropriate log messages for unauthorized packets, psad is only as good as the logging rules included in the iptables ruleset. Hence if your firewall is not configured to log packets, then psad will NOT detect port scans or anything else. Usually the best way setup the firewall is with default "drop and log" rules at the end of the ruleset, and include rules above this last rule that only allow traffic that should be allowed through. Upon execution, the psad daemon will attempt to ascertain whether or not such a default deny rule exists, and will warn the user if not. See the FW_EXAMPLE_RULES file for example firewall rulesets that are compatible with psad.
Additionally, extensive coverage of psad is included in the book "Linux Firewalls: Attack Detection and Response" published by No Starch Press, and a supporting script in this book is compatible with psad. This script can be found here:
http://www.cipherdyne.org/LinuxFirewalls/ch01/

Installation
Depending on the Linux distribution, psad may already be available in the default package repository. For example, on Debian or Ubuntu systems, installation is done with a simple:
apt-get install psad
If psad is not available in the package repository, it can be installed with the install.pl script bundled in the psad sources. The install.pl script also handles upgrades if psad is already installed. psad requires several perl modules that may or may not already be installed on your Linux system. These modules are included in the deps/ directory in the psad sources, and are automatically installed by the install.pl script. The list of modules is:
  • Bit::Vector
  • Date::Calc
  • IPTables::ChainMgr
  • IPTables::Parse
  • NetAddr::IP
  • Storable
  • Unix::Syslog
psad also includes a whois client written by Marco d'Itri (see the deps/whois directory). This client does better than others at collecting the correct whois information for a given IP address.

Firewall Setup
The main requirement for an iptables configuration to be compatible with psad is simply that iptables logs packets. This is commonly accomplished by adding rules to the INPUT and FORWARD chains like so:
iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG
The rules above should be added at the end of the INPUT and FORWARD chains after all ACCEPT rules for legitimate traffic and just before a corresponding DROP rule for traffic that is not to be allowed through the policy. Note that iptables policies can be quite complex with protocol, network, port, and interface restrictions, user defined chains, connection tracking rules, and much more. There are many pieces of software such as Shorewall and Firewall Builder, that build iptables policies and take advantage of the advanced filtering and logging capabilities offered by iptables. Generally the policies built by such pieces of software are compatible with psad since they specifically add rules that instruct iptables to log packets that are not part of legitimate traffic. Psad can be configured to only analyze those iptables messages that contain specific log prefixes (which are added via the --log-prefix option), but the default is for psad to analyze all iptables log messages for evidence of port scans, probes for backdoor programs, and other suspect traffic.

Platforms
psad generally runs on Linux systems, and is available in the package repositories of many major Linux distributions. If there are any operational issues with psad, please open an issue on psad

psad - Intrusion Detection and Log Analysis with iptables