Changelog recon-ng v4.9.0:
+ Updated the REQUIREMENTS file to remove specifc versions. Resolves issue #232.
+ Updated the sleep duration for the ipinfodb module to prevent rate limiting errors. Resolves issue #235.
+ Removed unnecessary key resource names.
+ Added additional error information to verbose level output. (@teosoft123)
+ Modified the bing_linkedin_cache module to parse the profile’s username from the end of the profile URL. (@mrbbking)
+ Updated the bing_linkedin_cache module to use new Bing search API. (@mrbbking)
+ Fixed a typo in the youtube pushpin module.
+ Fixed the Github API logic and all affected modules to properly paginate. (@dkasak)
+ Refactored the key management system to provide runtime notification of missing keys.
+ Added the recon-web analytics and reporting tool.
+ For recon-web, added a console welcome message, removed uneeded configuration variables, and changed the page title.
+ Added summary information to recon-web.
+ Added the xlsx and proxy export options to recon-web.
+ Made slight changes to the aesthetics of recon-web.
+ Added streaming responses to the proxify export option within recon-web.
+ Updated the shodan pushpin module to account for resource changes.
+ Added workspace-level pushpin reporting to recon-web.
+ Added workspace-level xlsx reporting to recon-web.
+ Improved the organization of the recon-web code.
+ Added tooltips and dynamic height summaries to recon-web.
Recon-ng is a full-featured Web Reconnaissance framework written in Python. Complete with independent modules, database interaction, built in convenience functions, interactive help, and command completion, Recon-ng provides a powerful environment in which open source web-based reconnaissance can be conducted quickly and thoroughly.
Recon-ng has a look and feel similar to the Metasploit Framework, reducing the learning curve for leveraging the framework. However, it is quite different. Recon-ng is not intended to compete with existing frameworks, as it is designed exclusively for web-based open source reconnaissance.
+ All 3rd party libraries/packages should be installed prior to use. The framework checks for the presence of the following dependencies at runtime and disables the modules affected by missing dependencies.
– dnspython – http://www.dnspython.org/
– dicttoxml – https://github.com/quandyfactory/dicttoxml/
– jsonrpclib – https://github.com/joshmarshall/jsonrpclib/
– lxml – http://lxml.de/
– mechanize – http://wwwsearch.sourceforge.net/mechanize/
– slowaes – https://code.google.com/p/slowaes/
– XlsxWriter – https://github.com/jmcnamara/XlsxWriter/
Installation - Kali Linux
apt-get update && apt-get install recon-ng
Installation Using Source:
git clone https://LaNMaSteR53@bitbucket.org/LaNMaSteR53/recon-ng.git
pip install -r REQUIREMENTS
git pull origin master
Below are a few helpful nuggets for getting started with the Recon-ng framework. While not all features are covered, the following notes will help make sense of a few of the frameworks more helpful and complex features.
+ Users will likely create and share custom modules that are not merged into the master branch of the framework. In order to allow for the use of these modules without interfering with installed package, the framework allows for the use of a custom module tree placed in the user’s “home” directory. In order to leverage this feature, a directory named “modules” must be created underneath the “.recon-ng” directory, i.e. “~/.recon-ng/modules/”. Custom modules that are added to the “~/.recon-ng/modules/” directory are loaded into the framework at runtime. Where the modules are placed underneath the “~/.recon-ng/modules/” directory doesn’t affect functionality, but things will look much nicer in the framework if the proper module directory tree is replicated and the modules are placed in the proper category.
+ Modules are organized to facilitate the flow of a penetration test, and there are separate module branches within the module tree for each methodology step. Reconnaissance, Discovery, Exploitation and Reporting are steps 1, 3, 4 and 5 of the Web Application Penetration Testing Methodology. Therefore, each of these steps has their own branch in the module tree. It is important to understand the difference between Reconnaissance and Discovery. Reconnaissance is the use of open sources to gain information about a target, commonly referred to as “passive reconnaissance”. Discovery, commonly referred to as “active reconnaissance”, occurs when packets are explicitly sent to the target network in an attempt to “discover” vulnerabilities. While Recon-ng is a reconnaissance framework, elements from the other steps of the methodology will be included as a convenient place to leverage the power of Python.
+ After loading a module, the context of the framework changes, and a new set of commands and options are available. These commands and options are unique to the module. Use the “help” and “show” commands to gain familiarity with the framework and available commands and options at the root (global) and module contexts.
+ The “info” and “source” subcommands of “show” (available only in the module context) are particularly helpful ways to discover the capabilities of the framework. The “show info” command will return detailed information about the loaded module, and the “show source” command will display its source code. Spend some time exploring modules with the “show info” and “show source” commands to get a sense for how information flows through the framework.
+ The “query” command assists in managing and understanding the data stored in the database. Users are expected to know and understand Structured Query Language (SQL) in order to interact with the database via the “query” command. The “show schema” command provides a graphical representation of the database schema to assist in building SQL queries. The “show schema” command creates the graphical representation dynamically, so as the schema of the database changes, so will the result of the command.
+ Pay attention to the global options, as they have changed over time and have a large impact on the performance of the framework. Many of the online tutorials regarding Recon-ng are outdated and misrepresent the purpose of Global options as they stand now. Global options are the options that are available at the root (global) context of the framework and have a global effect on how the framework operates. Global options such as “VERBOSE” and “PROXY” drastically change how the modules present feedback and make web requests. Explore and understand the global options before diving into the modules.
+ The modular nature of the framework requires frequently switching between modules and setting options unique to each one. It can become taxing having to repeatedly set module options as information flows through the framework. Therefore, option values for all contexts within the framework are stored locally and loaded dynamically each time the context is loaded. This provides persistence to the configuration of the framework between sessions.
+ Workspaces help users to conduct multiple simultaneous engagements without having to repeatedly configure global options or databases. All of the information for each workspace is stored in its own directory underneath the “~/.recon-ng/workspaces/” folder. Each workspace consists of its own instance of the Recon-ng database, a configuration file for the storage of configuration options, reports from reporting modules, and any loot that is gathered from other modules. To create a new workspace, use the “workspaces” command, workspaces add <name>. Loading an existing workspace is just as easy, workspaces select <name>. To view a list of available workspaces, see the “workspaces list” command or the “show workspaces” alias. To delete a workspace, use the “workspaces delete” command, workspaces delete <name>. Workspaces can also be created or loaded at runtime by invoking the “-w <workspace>” argument when executing Recon-ng, ./recon-ng -w bhis.
+ The “search” command provides the capability to search the names of all loaded modules and present the matches to the user. The “search” command can be very helpful in determining what to do next with the information that has been harvested, or identifying what is required to get the desired information. The “recon” branch of the module tree follows the following path structure: recon/<input table>-<output table>/<module>. This provides simplicity in determining what module is available for the action the user wants to take next. To see all of the modules which accept a domain as input, search for the input table name “domains” followed by a dash: search domains-. To see all of the modules which result in harvested hosts, search for the output table name “hosts” with a preceding dash: search -hosts.
+ The entire framework is equipped with command completion. Whether exploring standard commands, or passing parameters to commands, tap the “tab” key several times to be presented with all of the available options for that command or parameter.
+ Even with command completion, module loading can be cumbersome because of the directory structure of the module tree. To make module loading easier, the framework is equipped with a smart loading feature. This feature allows modules to be loaded by referring to a keyword unique to the desired module’s name. For instance, use namechk will load the “recon/contacts-contacts/namechk” module without requiring the full path since it is the only module containing the string “namechk”. Attempting to smart load with a string that exists in more than one module name will result in a list of all possible modules for the given keyword. For example, there are many modules whose names contain the string “pwned”. Therefore, the command use pwned would not load a module, but return a list of possible modules for the user to reference by full module name.
+ Every piece of information stored in the Recon-ng database is a potential input “seed” from which new information can be harvested. The “add” command allows users to add initial records to the database which will become input for modules. Modules take the seed data, transform it into other data types, and store the data in the database as potential input for other modules. Each module has a “SOURCE” option which determines the seed data. The “SOURCE” option provides flexibility in what the user can provide to modules as input. The “SOURCE” option allows users to select “default”, which is seed data from the database as determined by the module developer, a single entry as a string, the path to a file, or a custom SQL query. The framework will detect the source and provide it as input to the module. Changing the “SOURCE” option of a module does not affect how the module handles the resulting information.
+ While the “shell” command and “!” alias give users the ability to run system commands on the local machine from within the framework, neither of these commands is necessary to achieve this functionality. Any input that the framework does not understand as a framework command is executed as a system command. Therefore, the only time that “shell” or “!” is necessary is when the desired command shares the same name as a framework command.
+ A recorded session of all activity is essential for many penetration testers, but built-in OS tools like “tee” and “script” break needed functionality, like tab completion, and muck with output formatting. To solve this dilemma, the framework is equipped with the ability to spool all activity to a file for safe keeping. The “spool” command gives users the ability to start and stop spooling, or check the current spooling status. The destination file for the spooled data is set as a parameter of the “spool start” command, spool start <filename>. Use help spool for more information on the “spool” command.
+ Backing up data at important points during the reconnaissance process helps to prevent the loss or corruption of data due to unexpected resource behavior. The “snapshots” command gives users the ability to backup and restore snapshots of the database. Use help snapshots for more information on the “snapshots” command.