|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Cpp Httplib||10,815||a day ago||1||August 03, 2022||26||mit||C++|
|A C++ header-only HTTP/HTTPS server and client library|
|Easy_profiler||1,978||22 days ago||90||mit||C++|
|Lightweight profiler library for c++|
|Enterprise application server for Node.js and Metarhia private cloud ⚡|
|Fxkeychain||570||92||5 years ago||10||May 23, 2015||18||other||Objective-C|
|Googlereporter||474||4 years ago||4||October 22, 2018||1||mit||Swift|
|Easily integrate with Google Analytics in your iOS app|
|Brookframework||188||8 months ago||9||lgpl-2.1||Pascal|
|Microframework which helps to develop web Pascal applications.|
|Dali||156||13 hours ago||15||apache-2.0||Rust|
|An image processor service|
|Robust Services Core||135||a year ago||45||gpl-3.0||C++|
|Robust applications framework in C++. Includes a static analysis tool and two applications.|
|Maxlock||131||4 years ago||19||gpl-3.0||Java|
|Powerful app locker for Android, with a root and no-root implementation|
|Spawning||118||11 years ago||15||mit||Python|
|Spawning is a wsgi server which supports multiple processes, multiple threads, green threads, non-blocking HTTP io, and automatic graceful upgrading of code|
Easily turn single threaded command line applications into a fast, multi-threaded application with CIDR and glob support.
$ python3 setup.py install
Dependencies will then be installed and Interlace will be added to your path as
|(stdin)||Pipe target lists from another application in comma-delimited format, CIDR notation, or as an individual host|
|-t||Specify a target or domain name either in comma-delimited format, CIDR notation, or as an individual host|
|-tL||Specify a list of targets or domain names|
|-e||Specify a list of targets to exclude either in comma-delimited format, CIDR notation, or as an individual host|
|-eL||Specify a list of targets to exclude|
|-threads||Specify the maximum number of threads to run at any one time (DEFAULT:5)|
|-timeout||Specify a timeout value in seconds for any single thread (DEFAULT:600)|
|-c||Specify a single command to execute over each target or domain|
|-cL||Specify a list of commands to execute over each target or domain|
|-o||Specify an output folder variable that can be used in commands as _output_|
|-p||Specify a list of port variable that can be used in commands as _port_. This can be a single port, a comma-delimited list, or a range using dash notation|
|-pL||Specify a list of proxies|
|--proto||Specify protocols that can be used in commands as _proto_|
|-rp||Specify a real port variable that can be used in commands as _realport_|
|-random||Specify a directory of files that can be randomly used in commands as _random_|
|--no-bar / --sober||If set then progress bar be stripped out|
|--no-cidr||If set then CIDR notation in a target file will not be automatically be expanded into individual hosts|
|--no-color||If set then any foreground or background colours will be stripped out|
|--silent||If set then only important information will be displayed and banners and other information will be redacted|
|-v||If set then verbose output will be displayed in the terminal|
|1-80||Dash notation, perform a command for each port from 1-80|
|80,443||Perform a command for both port 80, and port 443|
-tL will be processed the same. You can pass targets the same as you would when using nmap. This can be done using CIDR notation, dash notation, or a comma-delimited list of targets. A single target list file can also use different notation types per line.
Alternatively, you can pass targets in via STDIN and neither -t or -tL will be required.
The following variables will be replaced in commands at runtime:
|_target_||Replaced with the expanded target list that the current thread is running against|
|_cleantarget_||Replaced with target cleaned from http:// or https://|
|_safe-target_||Replaced with target automatically quoting for commands, stopping subcommands running|
|_host_||Works the same as _target_, and can be used interchangeably|
|_output_||Replaced with the output folder variable from Interlace|
|_port_||Replaced with the expanded port variable from Interlace|
|_realport_||Replaced with the real port variable from Interlace|
|_proxy_||Replaced with the proxy list from Interlace|
|_random_||Replaced with the randomly chosen file from Interlace|
Interlace also makes the use of two additional features for controlling execution flow within a command file:
_block:<name>_. Blockers prevent execution of commands listed after them, until all commands before them have completed, and blocks can be used to force sequential execution of commands listed within a block, for a target.
These are run on a per-target level. If there are threads available and a blocker is in the way for the current target, Interlace will start commands from the next target within a target list in order to maximise efficiency.
Using these features will allow you to control the execution flow for individual targets more directly in order to prevent commands from running out of order.
Blockers prevent anything below them from executing until all commands above them have completed (for the currently active host). For example, in the following:
mkdir -p _output_/_target_/scans/ _blocker_ nmap _target_ -oA _output_/_target_/scans/_target_-nmap
The use of a blocker here prevents nmap from running on a target before the base folder structure has been created, preventing nmap from throwing an exception.
Blocks force everything within them to run sequentially. You can also use multiple blocks per command file. For example, in the following:
_block:nmap_ mkdir -p _target_/output/scans/ nmap _target_ -oN _target_/output/scans/_target_-nmap _block:nmap_ nikto --host _target_
In this example, the block would run the same as before, but assuming the thread count is high enough then nikto would begin to run immediately, passing results back to the terminal (whilst nmap and file creation happened in the background).
Let's assume that you have a file
targets.txt that has the following contents:
You could use Interlace to run over any number of targets within this file using: bash
➜ /tmp interlace -tL ./targets.txt -threads 5 -c "nikto --host _target_ > ./_target_-nikto.txt" -v ========================================================================= Interlace v1.0 by Michael Skelton (@codingo_) & Sajeeb Lohani (@sml555_) ========================================================================= [14:33:23] [THREAD] [nikto --host hackerone.com > ./hackerone.com-nikto.txt] Added to Queue [14:33:23] [THREAD] [nikto --host bugcrowd.com > ./bugcrowd.com-nikto.txt] Added to Queue
This would run Nikto over each host and save to a file for each target. Note that in the above example since we're using the
> operator, the results won't be fed back to the terminal; however this is desired functionality as otherwise we wouldn't be able to attribute which target Nikto results were returning for.
For applications where you desire feedback, simply pass commands as you normally would (or use
Using the above example, let's assume you want independent scans to be run for both ports
443 for the same targets. You would then use the following:
➜ /tmp interlace -tL ./targets.txt -threads 5 -c "nikto --host _target_:_port_ > ./_target_-_port_-nikto.txt" -p 80,443 -v ========================================================================= Interlace v1.0 by Michael Skelton (@codingo_) & Sajeeb Lohani (@sml555_) ========================================================================= [14:33:23] [THREAD] [nikto --host hackerone.com:80 > ./hackerone.com-nikto.txt] Added to Queue [14:33:23] [THREAD] [nikto --host bugcrowd.com:80 > ./hackerone.com-nikto.txt] Added to Queue [14:33:23] [THREAD] [nikto --host bugcrowd.com:443 > ./bugcrowd.com-nikto.txt] Added to Queue [14:33:23] [THREAD] [nikto --host hackerone.com:443 > ./hackerone.com-nikto.txt] Added to Queue
Often with penetration tests, there's a list of commands you want to run on nearly every job. Assuming that list includes testssl.sh, nikto, and sslscan, you could save a command list with the following in a file called
nikto --host _target_:_port_ > _output_/_target_-nikto.txt sslscan _target_:_port_ > _output_/_target_-sslscan.txt testssl.sh _target_:_port_ > _output_/_target_-testssl.txt
If you were then given a target
example.com, you could run each of these commands against this target using the following:
interlace -t example.com -o ~/Engagements/example/ -cL ./commands.txt -p 80,443
This would then run nikto, sslscan, and testssl.sh for both port 80 and 443 against example.com and save the files into your engagements folder.
Interlace automatically expands CIDR notation when starting threads (unless the
--no-cidr flag is passed). This allows you to pass CIDR notation to a variety of applications:
To run a virtual host scan against every target within
192.168.12.0/24 using a direct command you could use:
interlace -t 192.168.12.0/24 -c "vhostscan _target_ -oN _output_/_target_-vhosts.txt" -o ~/scans/ -threads 50
This is despite VHostScan not having any in-built CIDR notation support. Since Interlace expands the notation before building a queue of threads, VHostScan for all intents is only receiving a list of direct IP addresses to scan.
Interlace automatically expands glob ranges when starting threads. This allows you to pass glob ranges to a variety of applications:
To run a virtual host scan against every target within
192.168.12.* using a direct command you could use:
interlace -t 192.168.12.* -c "vhostscan _target_ -oN _output_/_target_-vhosts.txt" -o ~/scans/ -threads 50
Yet again, VHostScan does not have any inbuilt glob range format support.
Interlace automatically expands dash ranges when starting threads. This allows you to pass glob ranges to a variety of applications:
To run a virtual host scan against every target within
192.168.12.1-15 using a direct command you could use:
interlace -t 192.168.12.1-15 -c "vhostscan _target_ -oN _output_/_target_-vhosts.txt" -o ~/scans/ -threads 50
Yet again, VHostScan does not have any inbuilt dash range format support.
Run a virtual host scan against each host in a file (
target-lst.txt), whilst also limiting scans at any one time to 50 maximum threads.
This could be done using a direct command:
interlace -tL ./target-list.txt -c "vhostscan -t _target_ -oN _output_/_target_-vhosts.txt" -o ~/scans/ -threads 50
Or, alternatively, to run the same command as above, but using a command file:
interlace -cL ./vhosts-commands.txt -tL ./target-list.txt -threads 50 -o ~/scans
This presumes that the content of the command file is:
vhostscan -t $target -oN _output_/_target_-vhosts.txt
This would output a file for each target in the specified output folder. You could also run multiple commands simply by adding them into the command file.
Interlace automatically excludes any hosts provided when specified via the
-eL arguments. These arguments are also compatible with the range notations mentioned above (CIDR, glob, and dash)
To run a virtual host scan against every target in the CIDR range
192.168.12.0/24 but not for the targets in the range
192.168.12.0/26, using a direct command, you could use:
interlace -t 192.168.12.0/24 -e 192.168.12.0/26 -c "vhostscan _target_ -oN _output_/_target_-vhosts.txt" -o ~/scans/ -threads 50
Using the above example, let's assume you want independent scans to be via different proxies for the same targets. You would then use the following:
➜ /tmp interlace -tL ./targets.txt -pL ./proxies.txt -threads 5 -c "nikto --host _target_:_port_ -useproxy _proxy_ > ./_target_-_port_-nikto.txt" -p 80,443 -v
Originally written by Michael Skelton (codingo) and Sajeeb Lohani (sml555) with help from Charelle Collett (@Charcol0x89) for threading refactoring and overall approach, and Luke Stephens (hakluke) for testing and approach.
Contributions to this project are very welcome. If you're a newcomer to open source and would like some help in doing so, feel free to reach out to us on Twitter (@codingo_) / (@sml555_) and we'll assist wherever we can.