HoneyPy – A Low To Medium Interaction Honeypot

A low interaction honeypot with the capability to be more of a medium interaction honeypot.HoneyPy is written in Python2 and is intended to be easy to:install and deployextend with plugins and loggersrun with custom configurationsFeel free to follow the QuickStart Guide to dive in directly. The main documentation can be found at the HoneyPy Docs site.Live HoneyPy data gets posted to:Twitter: https://twitter.com/HoneyPyLogWeb service endpoint and displayed via the HoneyDB web site: https://riskdiscovery.com/honeydbLeave an issue or feature request! Use the GitHub issue tracker to tell us whats on your mind.Pull requests are welcome! If you would like to create new plugins or improve existing ones, please do.NOTE: HoneyPy has primarily been tested and run on Debian and Ubuntu using Python 2.7.9.OverviewHoneyPy comes with a lot of plugins included. The level of interaction is determined by the functionality of the used plugin. Plugins can be created to emulate UDP or TCP based services to provide more interaction. All activity is logged to a file by default, but posting honeypot activity to Twitter or a web service endpoint can be configured as well.Examples:Plugins: ElasticSearchSIPetc.Loggers: HoneyDBTwitteretc.Download HoneyPy

Link: http://www.kitploit.com/2019/02/honeypy-low-to-medium-interaction.html

Fibratus – Tool For Exploration And Tracing Of The Windows Kernel

Fibratus is a tool which is able to capture the most of the Windows kernel activity – process/thread creation and termination, context switches, file system I/O, registry, network activity, DLL loading/unloading and much more. The kernel events can be easily streamed to a number of output sinks like AMQP message brokers, Elasticsearch clusters or standard output stream. You can use filaments (lightweight Python modules) to extend Fibratus with your own arsenal of tools and so leverage the power of the Python’s ecosystem.InstallationDownload the latest release (Windows installer). The changelog and older releases can be found here.Alternatively, you can get fibratus from PyPI.Install the dependenciesDownload and install Python 3.4.Install Visual Studio 2015 (you’ll only need the Visual C compiler to build the kstreamc extension). Make sure to export the VS100COMNTOOLS environment variable so it points to %VS140COMNTOOLS%.Get Cython: pip install Cython >=0.23.4.Install fibratus via the pip package manager:pip install fibratusDocumentationSee the wiki.Download Fibratus

Link: http://feedproxy.google.com/~r/PentestTools/~3/_sRsUUcl2vU/fibratus-tool-for-exploration-and.html

SSRFmap – Automatic SSRF Fuzzer And Exploitation Tool

SSRF are often used to leverage actions on other services, this framework aims to find and exploit these services easily. SSRFmap takes a Burp request file as input and a parameter to fuzz.Server Side Request Forgery or SSRF is a vulnerability in which an attacker forces a server to perform requests on their behalf.Guide / RTFMBasic install from the Github repository.git clone https://github.com/swisskyrepo/SSRFmapcd SSRFmap/python3 ssrfmap.pyusage: ssrfmap.py [-h] [-r REQFILE] [-p PARAM] [-m MODULES] [–lhost LHOST] [–lport LPORT] [–level LEVEL]optional arguments: -h, –help show this help message and exit -r REQFILE SSRF Request file -p PARAM SSRF Parameter to target -m MODULES SSRF Modules to enable -l HANDLER Start an handler for a reverse shell –lhost LHOST LHOST reverse shell –lport LPORT LPORT reverse shell –level [LEVEL] Level of test to perform (1-5, default: 1)The default way to use this script is the following.# Launch a portscan on localhost and read default filespython ssrfmap.py -r data/request.txt -p url -m readfiles,portscan# Triggering a reverse shell on a Redispython ssrfmap.py -r data/request.txt -p url -m redis –lhost=127.0.0.1 –lport=4242 -l 4242# -l create a listener for reverse shell on the specified port# –lhost and –lport work like in Metasploit, these values are used to create a reverse shell payload# –level : ability to tweak payloads in order to bypass some IDS/WAF. e.g: 127.0.0.1 -> [::] -> 0000: -> …A quick way to test the framework can be done with data/example.py SSRF service.FLASK_APP=data/example.py flask run &python ssrfmap.py -r data/request.txt -p url -m readfilesModulesThe following modules are already implemented and can be used with the -m argument. Name Description fastcgi FastCGI RCE redis Redis RCE github Github Enterprise RCE < 2.8.7 zaddix Zaddix RCE mysql MySQL Command execution docker Docker Infoleaks via API smtp SMTP send mail portscan Scan ports for the host networkscan HTTP Ping sweep over the network readfiles Read files such as /etc/passwd alibaba Read files from the provider (e.g: meta-data, user-data) aws Read files from the provider (e.g: meta-data, user-data) digitalocean Read files from the provider (e.g: meta-data, user-data) socksproxy SOCKS4 Proxy smbhash Force an SMB authentication via a UNC Path Inspired byAll you need to know about SSRF and how may we write tools to do auto-detect - AuxyHow I Chained 4 vulnerabilities on GitHub Enterprise, From SSRF Execution Chain to RCE! - Orange TsaiBlog on Gopherus Tool -SpyD3rGopherus - GithubSSRF testing - cujanovicDownload SSRFmap

Link: http://feedproxy.google.com/~r/PentestTools/~3/sNJOEPAhpEU/ssrfmap-automatic-ssrf-fuzzer-and.html

Pompem – Exploit and Vulnerability Finder

Pompem is an open source tool, designed to automate the search for Exploits and Vulnerability in the most important databases. Developed in Python, has a system of advanced search, that help the work of pentesters and ethical hackers. In the current version, it performs searches in PacketStorm security, CXSecurity, ZeroDay, Vulners, National Vulnerability Database, WPScan Vulnerability Database …ScreenshotsSource codeYou can download the latest tarball by clicking here or latest zipball by clicking here.You can also download Pompem directly from its Git repository:$ git clone https://github.com/rfunix/Pompem.gitDependenciesPompem works out of the box with Python 3.5 on any platform and requires the following packages:Requests 2.9.1+InstallationGet Pompem up and running in a single command:$ pip3.5 install -r requirements.txtYou may greatly benefit from using virtualenv, which isolates packages installed for every project. If you have never used it, simply check [this tutorial] (http://docs.python-guide.org/en/latest/dev/virtualenvs) .UsageTo get the list of basic options and information about the project:$ python3.5 pompem.py -hOptions: -h, –help show this help message and exit -s, –search text for search –txt Write txt File –html Write html FileExamples of use:$ python3.5 pompem.py -s WordPress$ python3.5 pompem.py -s Joomla –html$ python3.5 pompem.py -s “Internet Explorer,joomla,wordpress" –html$ python3.5 pompem.py -s FortiGate –txt$ python3.5 pompem.py -s ssh,ftp,mysqlDownload Pompem

Link: http://www.kitploit.com/2019/02/pompem-exploit-and-vulnerability-finder.html

UEFI Firmware Parser – Parse BIOS/Intel ME/UEFI Firmware Related Structures: Volumes, FileSystems, Files, Etc

The UEFI firmware parser is a simple module and set of scripts for parsing, extracting, and recreating UEFI firmware volumes. This includes parsing modules for BIOS, OptionROM, Intel ME and other formats too. Please use the example scripts for parsing tutorials. InstallationThis module is included within PyPy as uefi_firmware$ sudo pip install uefi_firmwareTo install from Github, checkout this repo and use:$ sudo python ./setup.py installRequirementsPython development headers, usually found in the python-dev package.The compression/decompression features will use the python headers and gcc.pefile is optional, and may be used for additional parsing. UsageThe simplest way to use the module to detect or parse firmware is through the AutoParser class.import uefi_firmwarewith open(‘/path/to/firmware.rom’, ‘r’) as fh: file_content = fh.read()parser = uefi_firmware.AutoParser(file_content)if parser.type() != ‘unknown’: firmware = parser.parse() firmware.showinfo()There are several classes within the uefi, pfs, me, and flash packages that accept file contents in their constructor. In all cases there are abstract methods implemented:process() performs parsing work and returns a True or Falseshowinfo() print a hierarchy of information about the structuredump() walk the hierarchy and write each to a file ScriptsA Python script is installed uefi-firmware-parser$ uefi-firmware-parser -husage: uefi-firmware-parser [-h] [-b] [–superbrute] [-q] [-o OUTPUT] [-O] [-c] [-e] [-g GENERATE] [–test] file [file …]Parse, and optionally output, details and data on UEFI-related firmware.positional arguments: file The file(s) to work onoptional arguments: -h, –help show this help message and exit -b, –brute The input is a blob and may contain FV headers. –superbrute The input is a blob and may contain any sort of firmware object -q, –quiet Do not show info. -o OUTPUT, –output OUTPUT Dump firmware objects to this folder. -O, –outputfolder Dump firmware objects to a folder based on filename ${FILENAME}_output/ -c, –echo Echo the filename before parsing or extracting. -e, –extract Extract all files/sections/volumes. -g GENERATE, –generate GENERATE Generate a FDF, implies extraction (volumes only) –test Test file parsing, output name/success.To test a file or directory of files:$ uefi-firmware-parser –test ~/firmware/*~/firmware/970E32_1.40: UEFIFirmwareVolume~/firmware/CO5975P.BIO: EFICapsule~/firmware/me-03.obj: IntelME~/firmware/O990-A03.exe: None~/firmware/O990-A03.exe.hdr: DellPFSIf you need to parse and extract a large number of firmware files check out the -O option to auto-generate an output folder per file. If parsing and searching for internals in a shell the –echo option will print the input filename before parsing.The firmware-type checker will decide how to best parse the file. If the –test option fails to identify the type, or calls it unknown, try to use the -b or –superbrute option. The later performs a byte-by-byte type checker.$ uefi-firmware-parser –test ~/firmware/970E32_1.40~/firmware/970E32_1.40: unknown$ uefi-firmware-parser –superbrute ~/firmware/970E32_1.40[…]FeaturesUEFI Firmware Volumes, Capsules, FileSystems, Files, Sections parsingIntel PCH Flash DescriptorsIntel ME modules parsing (ME, TXE, etc)Dell PFS (HDR) updates parsingTiano/EFI, and native LZMA (7z) [de]compressionComplete UEFI Firmware volume object hierarchy displayFirmware descriptor [re]generation using the parsed input volumesFirmware File Section injectionGUID InjectionInjection or GUID replacement (no addition/subtraction yet) can be performed on sections within a UEFI firmware file, or on UEFI firmware files within a firmware filesystem.$ python ./scripts/fv_injector.py -husage: fv_injector.py [-h] [-c] [-p] [-f] [–guid GUID] –injection INJECTION [-o OUTPUT] fileSearch a file for UEFI firmware volumes, parse and output.positional arguments: file The file to work onoptional arguments: -h, –help show this help message and exit -c, –capsule The input file is a firmware capsule. -p, –pfs The input file is a Dell PFS. -f, –ff Inject payload into firmware file. –guid GUID GUID to replace (inject). –injection INJECTION Pre-generated EFI file to inject. -o OUTPUT, –output OUTPUT Name of the output file.Note: when injecting into a firmware file the user will be prompted for which section to replace. At the moment this is not-yet-scriptable.IDA Python supportThere is an included script to generate additional GUID labels to import into IDA Python using Snare’s plugins. Using the -g LABEL the script will generate a Python dictionary-formatted output. This project will try to keep up-to-date with popular vendor GUIDs automatically.$ python ./scripts/uefi_guids.py -husage: uefi_guids.py [-h] [-c] [-b] [-d] [-g GENERATE] [-u] fileOutput GUIDs for files, optionally write GUID structure file.positional arguments: file The file to work onoptional arguments: -h, –help show this help message and exit -c, –capsule The input file is a firmware capsule, do not search. -b, –brute The input file is a blob, search for firmware volume headers. -d, –flash The input file is a flash descriptor. -g GENERATE, –generate GENERATE Generate a behemoth-style GUID output. -u, –unknowns When generating also print unknowns.Supported VendorsThis module has been tested on BIOS/UEFI/firmware updates from the following vendors. Not every update for every product will parse, some may required a-priori decompression or extraction from the distribution update mechanism (typically a PE).ASRockDellGigabyteIntelLenovoHPMSIVMwareAppleDownload UEFI Firmware Parser

Link: http://feedproxy.google.com/~r/PentestTools/~3/vrw7ce1SeJ0/uefi-firmware-parser-parse-biosintel.html

Hontel – Telnet Honeypot

HonTel is a Honeypot for Telnet service. Basically, it is a Python v2.x application emulating the service inside the chroot environment. Originally it has been designed to be run inside the Ubuntu environment, though it could be easily adapted to run inside any Linux environment.Documentation:Setting the environment and running the application requires intermmediate Linux administration knowledge. The whole deployment process can be found “step-by-step" inside the deploy.txt file. Configuration settings can be found and modified inside the hontel.py itself. For example, authentication credentials can be changed from default root:123456 to some arbitrary values (options AUTH_USERNAME and AUTH_PASSWORD), custom Welcome message can be changed from default (option WELCOME), custom hostname (option FAKE_HOSTNAME), architecture (option FAKE_ARCHITECTURE), location of log file (inside the chroot environment) containing all telnet commands (option LOG_PATH), location of downloaded binary files dropped by connected users (option SAMPLES_DIR), etc.Note: Some botnets tend to delete the files from compromised hosts (e.g. /bin/bash) in order to harden itself from potential attempts of cleaning and/or attempts of installation coming from other (concurent) botnets. In such cases either the whole chroot environment has to be reinstalled or host directory where the chroot directory resides (e.g. /srv/chroot/) should be recovered from the previously stored backup (recommended).Download Hontel

Link: http://feedproxy.google.com/~r/PentestTools/~3/7Qv62zGn_mo/hontel-telnet-honeypot.html

RedELK – Easy Deployable Tool For Red Teams Used For Tracking And Alarming About Blue Team Activities As Well As Better Usability In Long Term Operations

Red Team’s SIEM – easy deployable tool for Red Teams used for tracking and alarming about Blue Team activities as well as better usability for the Red Team in long term operations.Initial public release at BruCON 2018:Video: https://www.youtube.com/watch?v=OjtftdPts4gPresentation slides: https://github.com/outflanknl/Presentations/blob/master/MirrorOnTheWall_BruCon2018_UsingBlueTeamTechniquesinRedTeamOps_Bergman-Smeets_FINAL.pdfGoal of the projectShort: a Red Team’s SIEM.Longer: a Red Team’s SIEM that serves three goals:Enhanced usability and overview for the red team operators by creating a central location where all relevant operational logs from multiple teamservers are collected and enriched. This is great for historic searching within the operation as well as giving a read-only view on the operation (e.g. for the White Team). Especially useful for multi-scenario, multi-teamserver, multi-member and multi-month operations. Also, super easy ways for viewing all screenshots, IOCs, keystrokes output, etc. \o/Spot the Blue Team by having a central location where all traffic logs from redirectors are collected and enriched. Using specific queries its now possible to detect that the Blue Team is investigating your infrastructure.Out-of-the-box usable by being easy to install and deploy, as well as having ready made views, dashboards and alarms.Here’s a conceptual overview of how RedELK works.RedELK uses the typical components Filebeat (shipping), Logstash (filtering), Elasticsearch (storage) and Kibana (viewing). Rsync is used for a second syncing of teamserver data: logs, keystrokes, screenshots, etc. Nginx is used for authentication to Kibana, as well as serving the screenshots, beaconlogs, keystrokes in an easy way in the operator’s browser.A set of python scripts are used for heavy enriching of the log data, and for for Blue Team detection.Supported tech and requirementsRedELK currently supports:Cobalt Strike teamserversHAProxy for HTTP redirector data. Apache support is expected soon.Tested on Ubuntu 16 LTSRedELK requires a modification to the default haproxy configuration in order to log more details.In the ‘general’ section:log-format frontend:%f/%H/%fi:%fp\ backend:%b\ client:%ci:%cp\ GMT:%T\ useragent:%[capture.req.hdr(1)]\ body:%[capture.req.hdr(0)]\ request:%rAt ‘frontend’ section:declare capture request len 40000http-request capture req.body id 0capture request header User-Agent len 512InstallationFirst time installationAdjust ./certs/config.cnf to include the right details for the TLS certificates. Once done, run: initial-setup.sh This will create a CA, generate necessary certificates for secure communication between redirs, teamserver and elkserver and generates a SSH keypair for secure rsync authentication of the elkserver to the teamserver. It also generates teamservers.tgz, redirs.tgz and elkserver.tgz that contain the installation packages for each component. Rerunning this initial setup is not required. But if you want new certificates for a new operation, you can simply run this again.Installation of redirectorsCopy and extract redirs.tgz on your redirector as part of your red team infra deployment procedures. Run: install-redir.sh $FilebeatID $ScenarioName $IP/DNS:PORT$FilebeatID is the identifier of this redirector within filebeat.$ScenarioName is the name of the attack scenario this redirector is used for.$IP/DNS:PORT is the IP or DNS name and port where filebeat logs are shipped to.This script will set the timezone (default Europe/Amsterdam), install filebeat and dependencies, install required certificates, adjust the filebeat configuration and start filebeat.Installation of teamserverCopy and extract teamservers.tgz on your Cobalt Strike teamserver as part of your red team infra deployment procedures. Run: install-teamserver.sh $FilebeatID $ScenarioName $IP/DNS:PORT$FilebeatID is the identifier of this teamserver within filebeat.$ScenarioName is the name of the attack scenario this teamserver is used for.$IP/DNS:PORT is the IP or DNS name and port where filebeat logs are shipped to.This script will warn if filebeat is already installed (important as ELK and filebeat sometimes are very picky about having equal versions), set the timezone (default Europe/Amsterdam), install filebeat and dependencies, install required certificates, adjust the filebeat configuration, start filebeat, create a local user ‘scponly’ and limit that user to SSH key-based auth via scp/sftp/rsync.Installation of ELK serverCopy and extract elkserver.tgz on your RedELK server as part of your red team infra deployment procedures. Run: install-teamserver.sh This script will set the timezone (default Europe/Amsterdam), install logstash, elasticsearch, kibana and dependencies, install required certificates, deploy the logstash configuration and required custom ruby enrichment scripts, download GeoIP databases, install Nginx, configure Nginx, create a local user ‘redelk’ with the earlier generated SSH keys, install the script for rsyncing of remote logs on teamservers, install the script used for creating of thumbnails of screenshots, install the RedELK configuration files, install crontab file for RedELK tasks, install GeoIP elasticsearch plugins and adjust the template, install the python enrichment scripts, and finally install the python blue team detection scripts.You are not done yet. You need to manually enter the details of your teamservers in /etc/cron.d/redelk, as well as tune the config files in /etc/redelk (see section below).Setting up enrichment and detectionOn the ELK server in the /etc/redelk directory you can find several files that you can use to tune your RedELK instance for better enrichments and better alarms. These files are:/etc/redelk/iplist_customer.conf : public IP addresses of your target, one per line. Including an address here will set a tag for applicable records in the redirhaproxy-* index./etc/redelk/iplist_redteam.conf : public IP addresses of your red team, one per line. Convenient for identifying testing done by red team members. Including an address here will set a tag for applicable records in the redirhaproxy-* index./etc/redelk/iplist_unknown.conf : public IP addresses of gateways that you are not sure about yet, but don’t want to be warned about again. One per line. Including an address here will set a tag for applicable records in the redirhaproxy-* index./etc/redelk/known_sandboxes.conf : beacon characteristics of known AV sandbox systems. One per line. Including data here here will set a tag for applicable records in the rtops-* index./etc/redelk/known_testsystems.conf : beacon characteristics of known test systems. One per line. Including data here here will set a tag for applicable records in the rtops-* index./etc/redelk/alarm.json.config: details required for alarms to work. This includes API keys for online services (Virus Total, IBM X-Force, etc) as well as the SMTP details required for sending alarms via e-mail.If you alter these files prior to your initial setup, these changes will be included in the .tgz packages and can be used for future installations. These files can be found in ./RedELK/elkserver/etc/redelk.To change the authentication onto Nginx, change /etc/nginx/htpasswd.users to include your preferred credentials. Or ./RedELK/elkserver/etc/nginx/htpasswd.users prior to initial setup.Under the hoodIf you want to take a look under the hood on the ELK server, take a look at the redelk cron file in /etc/cron.d/redelk. It starts several scripts in /usr/share/redelk/bin/. Some scripts are for enrichment, others are for alarming. The configuration of these scripts is done with the config files in /etc/redelk/. There is also heavy enrichment done (including the generation of hyperlinks for screenshots, etc) in logstash. You can check that out directly form the logstash config files in /etc/logstash/conf.d/.Current state and features on todo-listThis project is still in alpha phase. This means that it works on our machines and our environment, but no extended testing is performed on different setups. This also means that naming and structure of the code is still subject to change.We are working (and you are invited to contribute) on the following features for next versions:Include the real external IP address of a beacon. As Cobalt Strike has no knowledge of the real external IP address of a beacon session, we need to get this form the traffic index. So far, we have not found a true 100% reliable way for doing this.Support for Apache redirectors. Fully tested and working filebeat and logstash configuration files that support Apache based redirectors. Possibly additional custom log configuration needed for Apache. Low priority.Solve rsyslog max log line issue. Rsyslog (default syslog service on Ubuntu) breaks long syslog lines. Depending on the CS profile you use, this can become an issue. As a result, the parsing of some of the fields are properly parsed by logstash, and thus not properly included in elasticsearch.Ingest manual IOC data. When you are uploading a document, or something else, outside of Cobalt Strike, it will not be included in the IOC list. We want an easy way to have these manual IOCs also included. One way would be to enter the data manually in the activity log of Cobalt Strike and have a logstash filter to scrape the info from there.Ingest e-mails. Create input and filter rules for IMAP mailboxes. This way, we can use the same easy ELK interface for having an overview of sent emails, and replies.User-agent checks. Tagging and alarming on suspicious user-agents. This will probably be divided in hardcoded stuff like curl, wget, etc connecting with the proper C2 URL’s, but also more dynamic analysis of suspicious user-agents.DNS traffic analyses. Ingest, filter and query for suspicious activities on the DNS level. This will take considerable work due to the large amount of noise/bogus DNS queries performed by scanners and online DNS inventory services.Other alarm channels. Think Slack, Telegram, whatever other way you want for receiving alarms.Fine grained authorisation. Possibility for blocking certain views, searches, and dashboards, or masking certain details in some views. Useful for situations where you don’t want to give out all information to all visitors.UsageFirst time loginBrowse to your RedELK server’s IP address and login with the credentials from Nginx (default is redelk:redelk). You are now in a Kibana interface. You may be asked to create a default index for kibana. You can select any of the available indices, it doesn’t matter which one you pick.There are probably two things you want to do here: look at dashboards, or look and search the data in more detail. You can switch between those views using the buttons on the left bar (default Kibana functionality).DashboardsClick on the dashboard icon on the left, and you’ll be given 2 choices: Traffic and Beacon.Looking and searching data in detailClick on the Discover button to look at and search the data in more detail. Once there, click the time range you want to use and click on the ‘Open’ button to use one of the prepared searches with views.Beacon dataWhen selecting the search ‘TimelineOverview’ you are presented with an easy to use view on the data from the Cobalt Strike teamservers, a time line of beacon events if you like. The view includes the relevant columns you want to have, such as timestamp, testscenario name, username, beacon ID, hostname, OS and OS version. Finally, the full message from Cobalt Strike is shown.You can modify this search to your liking. Also, because its elasticsearch, you can search all the data in this index using the search bar.Clicking on the details of a record will show you the full details. An important field for usability is the beaconlogfile field. This field is an hyperlink, linking to the full beacon log file this record is from. Its allows you to look at the beacon transcript in a bigger windows and use CTRL+F within it.ScreenshotsRedELK comes with an easy way of looking at all the screenshots that were made from your targets. Select the ‘Screenshots’ search to get this overview. We added two big usability things: thumbnails and hyperlinks to the full pictures. The thumbnails are there to quickly scroll through and give you an immediate impression: often you still remember what the screenshot looked like.KeystrokesJust as with screenshots, its very handy to have an easy overview of all keystrokes. This search gives you the first lines of cententi, as well as again an hyperlink to the full keystrokes log file.IOC dataTo get a quick list of all IOCs, RedELK comes with an easy overview. Just use the ‘IOCs’ search to get this list. This will present all IOC data from Cobalt Strike, both from files and from services.You can quickly export this list by hitting the ‘Reporting’ button in the top bar to generate a CSV of this exact view.Logging of RedELKDuring installation all actions are logged in a log file in the current working directory.During operations, all RedELK specific logs are logged on the ELK server in /var/log/redelk. You probably only need this for troubleshooting.Authors and contributionThis project is developed and maintained by:Marc Smeets (@smeetsie on Github and @mramsmeets on Twitter).Mark Bergman (@xychix on Github and Twitter)Download RedELK

Link: http://feedproxy.google.com/~r/PentestTools/~3/v3TIGlliuHU/redelk-easy-deployable-tool-for-red.html

Fwknop – Single Packet Authorization & Port Knocking

fwknop implements an authorization scheme known as Single Packet Authorization (SPA) for strong service concealment. SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to connect to services such as SSH in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) more difficult. Because there are no open ports, any service that is concealed by SPA naturally cannot be scanned for with Nmap. The fwknop project supports four different firewalls: iptables, firewalld, PF, and ipfw across Linux, OpenBSD, FreeBSD, and Mac OS X. There is also support for custom scripts so that fwknop can be made to support other infrastructure such as ipset or nftables.SPA is essentially next generation Port Knocking (PK), but solves many of the limitations exhibited by PK while retaining its core benefits. PK limitations include a general difficulty in protecting against replay attacks, asymmetric ciphers and HMAC schemes are not usually possible to reliably support, and it is trivially easy to mount a DoS attack against a PK server just by spoofing an additional packet into a PK sequence as it traverses the network (thereby convincing the PK server that the client doesn’t know the proper sequence). All of these shortcomings are solved by SPA. At the same time, SPA hides services behind a default-drop firewall policy, acquires SPA data passively (usually via libpcap or other means), and implements standard cryptographic operations for SPA packet authentication and encryption/decryption.SPA packets generated by fwknop leverage HMAC for authenticated encryption in the encrypt-then-authenticate model. Although the usage of an HMAC is currently optional (enabled via the –use-hmac command line switch), it is highly recommended for three reasons:Without an HMAC, cryptographically strong authentication is not possible with fwknop unless GnuPG is used, but even then an HMAC should still be applied.An HMAC applied after encryption protects against cryptanalytic CBC-mode padding oracle attacks such as the Vaudenay attack and related trickery (like the more recent “Lucky 13" attack against SSL).The code required by the fwknopd daemon to verify an HMAC is much more simplistic than the code required to decrypt an SPA packet, so an SPA packet without a proper HMAC isn’t even sent through the decryption routines.The final reason above is why an HMAC should still be used even when SPA packets are encrypted with GnuPG due to the fact that SPA data is not sent through libgpgme functions unless the HMAC checks out first. GnuPG and libgpgme are relatively complex bodies of code, and therefore limiting the ability of a potential attacker to interact with this code through an HMAC operation helps to maintain a stronger security stance. Generating an HMAC for SPA communications requires a dedicated key in addition to the normal encryption key, and both can be generated with the –key-gen option.fwknop encrypts SPA packets either with the Rijndael block cipher or via GnuPG and associated asymmetric cipher. If the symmetric encryption method is chosen, then as usual the encryption key is shared between the client and server (see the /etc/fwknop/access.conf file for details). The actual encryption key used for Rijndael encryption is generated via the standard PBKDF1 key derivation algorithm, and CBC mode is set. If the GnuPG method is chosen, then the encryption keys are derived from GnuPG key rings.Use CasesPeople who use Single Packet Authorization (SPA) or its security-challenged cousin Port Knocking (PK) usually access SSHD running on the same system where the SPA/PK software is deployed. That is, a firewall running on a host has a default-drop policy against all incoming SSH connections so that SSHD cannot be scanned, but a SPA daemon reconfigures the firewall to temporarily grant access to a passively authenticated SPA client: "Basic SPA usage to access SSHD"fwknop supports the above, but also goes much further and makes robust usage of NAT (for iptables/firewalld firewalls). After all, important firewalls are usually gateways between networks as opposed to just being deployed on standalone hosts. NAT is commonly used on such firewalls (at least for IPv4 communications) to provide Internet access to internal networks that are on RFC 1918 address space, and also to allow external hosts access to services hosted on internal systems.Because fwknop integrates with NAT, SPA can be leveraged to access internal services through the firewall by users on the external Internet. Although this has plenty of applications on modern traditional networks, it also allows fwknop to support cloud computing environments such as Amazon’s AWS: "SPA usage on Amazon AWS cloud environments"User InterfaceThe official cross-platform fwknop client user interface fwknop-gui (download, github) is developed by Jonathan Bennett. Most major client-side SPA modes are supported including NAT requests, HMAC and Rijndael keys (GnuPG is not yet supported), fwknoprc stanza saving, and more. Currently fwknop-gui runs on Linux, Mac OS X, and Windows – here is a screenshot from OS X:  "fwknop-gui on Mac OS X" Similarly, an updated Android client is available as well.TutorialA comprehensive tutorial on fwknop can be found here:http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.htmlFeaturesThe following is a complete list of features supported by the fwknop project:Implements Single Packet Authorization around iptables and firewalld firewalls on Linux, ipfw firewalls on *BSD and Mac OS X, and PF on OpenBSD.The fwknop client runs on Linux, Mac OS X, *BSD, and Windows under Cygwin. In addition, there is an Android app to generate SPA packets.Supports both Rijndael and GnuPG methods for the encryption/decryption of SPA packets.Supports HMAC authenticated encryption for both Rijndael and GnuPG. The order of operation is encrypt-then-authenticate to avoid various cryptanalytic problems.Replay attacks are detected and thwarted by SHA-256 digest comparison of valid incoming SPA packets. Other digest algorithms are also supported, but SHA-256 is the default.SPA packets are passively sniffed from the wire via libpcap. The fwknopd server can also acquire packet data from a file that is written to by a separate Ethernet sniffer (such as with tcpdump -w ), from the iptables ULOG pcap writer, or directly via a UDP socket in –udp-server mode.For iptables firewalls, ACCEPT rules added by fwknop are added and deleted (after a configurable timeout) from custom iptables chains so that fwknop does not interfere with any existing iptables policy that may already be loaded on the system.Supports inbound NAT connections for authenticated SPA communications (iptables firewalls only for now). This means fwknop can be configured to create DNAT rules so that you can reach a service (such as SSH) running on an internal system on an RFC 1918 IP address from the open Internet. SNAT rules are also supported which essentially turns fwknopd into a SPA-authenticating gateway to access the Internet from an internal network.Multiple users are supported by the fwknop server, and each user can be assigned their own symmetric or asymmetric encryption key via the /etc/fwknop/access.conf file.Automatic resolution of external IP address via https://www.cipherdyne.org/cgi-bin/myip (this is useful when the fwknop client is run from behind a NAT device). Because the external IP address is encrypted within each SPA packet in this mode, Man-in-the-Middle (MITM) attacks where an inline device intercepts an SPA packet and only forwards it from a different IP in an effort to gain access are thwarted.Port randomization is supported for the destination port of SPA packets as well as the port over which the follow-on connection is made via the iptables NAT capabilities. The later applies to forwarded connections to internal services and to access granted to local sockets on the system running fwknopd.Integration with Tor (as described in this DefCon 14 presentation). Note that because Tor uses TCP for transport, sending SPA packets through the Tor network requires that each SPA packet is sent over an established TCP connection, so technically this breaks the "single" aspect of "Single Packet Authorization". However, Tor provides anonymity benefits that can outweigh this consideration in some deployments.Implements a versioned protocol for SPA communications, so it is easy to extend the protocol to offer new SPA message types and maintain backwards compatibility with older fwknop clients at the same time.Supports the execution of shell commands on behalf of valid SPA packets.The fwknop server can be configured to place multiple restrictions on inbound SPA packets beyond those enforced by encryption keys and replay attack detection. Namely, packet age, source IP address, remote user, access to requested ports, and more.Bundled with fwknop is a comprehensive test suite that issues a series of tests designed to verify that both the client and server pieces of fwknop work properly. These tests involve sniffing SPA packets over the local loopback interface, building temporary firewall rules that are checked for the appropriate access based on the testing config, and parsing output from both the fwknop client and fwknopd server for expected markers for each test. Test suite output can easily be anonymized for communication to third parties for analysis.fwknop was the first program to integrate port knocking with passive OS fingerprinting. However, Single Packet Authorization offers many security benefits beyond port knocking, so the port knocking mode of operation is generally deprecated.Building fwknopThis distribution uses GNU autoconf for setting up the build. Please see the INSTALL file for the general basics on using autoconf.There are some "configure" options that are specific to fwknop. They are (extracted from ./configure –help): –disable-client Do not build the fwknop client component. The default is to build the client. –disable-server Do not build the fwknop server component. The default is to build the server. –with-gpgme support for gpg encryption using libgpgme [default=check] –with-gpgme-prefix=PFX prefix where GPGME is installed (optional) –with-gpg=/path/to/gpg Specify path to the gpg executable that gpgme will use [default=check path] –with-firewalld=/path/to/firewalld Specify path to the firewalld executable [default=check path] –with-iptables=/path/to/iptables Specify path to the iptables executable [default=check path] –with-ipfw=/path/to/ipfw Specify path to the ipfw executable [default=check path] –with-pf=/path/to/pfctl Specify path to the pf executable [default=check path] –with-ipf=/path/to/ipf Specify path to the ipf executable [default=check path]Examples:./configure –disable-client –with-firewalld=/bin/firewall-cmd./configure –disable-client –with-iptables=/sbin/iptables –with-firewalld=noDownload Fwknop

Link: http://www.kitploit.com/2019/02/fwknop-single-packet-authorization-port.html

Bolt – CSRF Scanning Suite

Bolt is in beta phase of development which means there can be bugs. Any production use of this tool discouraged. Pull requests and issues are welcome. I also suggest you to put this repo on watch if you are interested in it.WorkflowCrawlingBolt crawls the target website to the specified depth and stores all the HTML forms found in a database for further processing.EvaluatingIn this phase, Bolt finds out the tokens which aren’t strong enough and the forms which aren’t protected.ComparingThis phase focuses on detection on replay attack scenarios and hence checks if a token has been issued more than one time. It also calculates the average levenshtein distance between all the tokens to see if they are similar.Tokens are also compared against a database of 250+ hash patterns.ObservingIn this phase, 100 simultaneous requests are made to a single webpage to see if same tokens are generated for the requests.TestingThis phase is dedicated to active testing of the CSRF protection mechanism. It includes but not limited to checking if protection exsists for moblie browsers, submitting requests with self-generated token and testing if token is being checked to a certain length.AnalysingVarious statistical checks are performed in this phase to see if the token is really random. Following tests are performed during this phaseMonobit frequency testBlock frequency testRuns testSpectral testNon-overlapping template matching testOverlapping template matching testSerial testCumultative sums testAproximate entropy testRandom excursions variant testLinear complexity testLongest runs testMaurers universal statistic testRandom excursions testUsageScanning a website for CSRF using Bolt is as easy as doingpython3 bolt.py -u https://github.com -l 2Where -u is used to supply the URL and -l is used to specify the depth of crawling.Other options and switches:-t number of threads–delay delay between requests–timeout http request timeout–headers supply http headersCreditsRegular Expressions for detecting hashes are taken from hashID.Bit level entropy tests are taken from highfestiva’s python implementation of statistical tests.Download Bolt

Link: http://feedproxy.google.com/~r/PentestTools/~3/vu2sbgER-jY/bolt-csrf-scanning-suite.html

BEEMKA: Basic Electron Post-Exploitation Framework

PenTestIT RSS Feed
There are a lot of applications today that use Electron Framework, as it helps you build cross platform desktop apps with JavaScript, HTML, and CSS. Examples are applications such as Skype, Station, etc. A new post-exploitation framework – BEEMKA can now help you in maintaining access and exfiltration. What is BEEMKA? BEEMKA is a modular,Read more about BEEMKA: Basic Electron Post-Exploitation Framework
The post BEEMKA: Basic Electron Post-Exploitation Framework appeared first on PenTestIT.

Link: http://pentestit.com/beemka-basic-electron-exploitation-framework/