Blog

  •

    Create an AD sign-in honeytoken with Teams alerting

    5.00 of 39 votes

    This post aims to provide some insight into a new approach at tackling a particular type of phishing, and guidance on how to self-host your own honeytoken to help defend against it. Click here to skip to the self-host honeytoken generator AitM (Adversary in the Middle) attacks targeting companies is nothing new. Attackers will typically recon to identify a company Azure Entra ID login page, such as the one we're commonly familiar with at https://login.microsoftonline.com, and then clone or proxy this page including all the cosmetic assets responsible for custom branding. After cloning or proxying the page, attackers will attempt to serve this in phishing campaigns against unsuspecting employees. These cloned/proxied pages are tailored to harvest employee AD credentials and MFA tokens by means of interception, which can then be used to compromise company accounts. A solution? What if you could receive an immediate alert before any phishing could start? An alert that tells you the domain and IP the cloned page is hosted on? This would enable you to block access to that domain/IP before any phishing campaigns could even begin. I recently came across an interesting blog post by Thinkst, a trusted and reputable deception technology supplier that specialises in detection engineering. They provide a number of free canarytokens, which includes the new release of an Azure Entra ID token, aimed at producing high quality alerts to help with this exact problem. I got straight into testing this myself. In summary, the way it works is you add a piece of code to your Azure Entra ID sign-in page, then when an attacker clones and hosts that page on their own server your code detects this and sends you an alert. For anyone interested in a simple deployment, Thinkst certainly have the best offering, and I'm a strong supporter of pretty much their whole product line. That being said, I did notice a few ways to improve the efficacy of this particular concept through a self-hosted solution. Below were my observations. Thinkst Azure Entra ID Canarytoken Pros Super simple to deploy Reputable supplier Free Token can be easily managed Cons Token pattern is consistent which may be easier for an adversary to identify than a self-hosted asset Common privacy extensions strip the token out Customer remains reliant on Thinkst to maintain hosting responsibility My Self-Host Token Pros A bit harder for an adversary to detect No detection from privacy tools (from my testing anyway) Always free Easier to hook directly into sending automated MS Teams alerts Cons A few more steps to deploy No ability to easily manage the token Requires a web server running PHP If you're interested in self-hosting your own token, I have created a form below which will automatically create the necessary files for you to self-host. All you need to do is: Input your company name. This is used to make the token characteristics a little more convincing. Input the directory path of where you want to host your static asset on your company website. I recommend creating a custom folder just for this purpose. Input a Microsoft Teams webhook URL, which you can create by following the Create Incoming Webhooks guide. Once you submit the form, the necessary files will be created in your browser, and can then be hosted as per the guidance provided once you submit the form. Please note: The form below executes client-side only. Files are dynamically generated by your browser using the values you submit in the form, and your browser then makes those files available for download. No submitted values, secrets, or files are sent to nor stored by my server at any time. When you close this page, any files you created but did not download while it was open will be lost. Company Name: Web Host Path: Webhook: Submit   Step 1   Download the above 3 files, and host them at your specified URL path here: Step 2   Download the above CSS file. Navigate to your Azure Entra ID login customisation page. Choose Layout, scroll down to Custom CSS, click Browse and choose the downloaded file. Here is a summarised breakdown of the files created, which you are welcome to review yourself: The PNG image This is a small transparent image, which my code generates using randomised size dimensions. The reason the image uses randomised dimensions is to evade privacy focused browser extensions, which commonly flag 1px images as tracking pixels and strip them out to prevent them being served to the browser. The filename also incorporates the specified company name in a dynamic format to make it look more natural to an adversary should they clone your Azure Entra ID login page. The PHP file This contains the core code responsible for detection and alerting. First it ensures the image is served without delay, then it executes a number of functions responsible for checking the HTTP referer. If the referer domain is anything other than the host upon which the .php file resides or the two official domains expected from Microsoft for legitimate AD login, it will proceed to fire an alert to the MS Teams webhook you specified in the form. This alert will contain the unexpected refer domain and the IP address of that domain. The .htaccess file This contains a forced redirect to the PHP file for any browsers which attempt to render the PNG image. The PHP file is responsible for serving the image, and then executing the remainder of its code. The CSS file This contains a CSS 'background' call to fetch the PNG image from your specified web host directory path. Once this is uploaded to your Azure Entra ID login page as custom CSS, it will execute every time the page is loaded in a browser. An example MS Teams alert when the honeytoken triggers can be seen below:

  • How to carry out mobile app risk assessments

    5.00 of 91 votes

    If you work for a large organisation, the chances are that a requirement may occasionally surface for a new mobile app to be deployed on company-issued mobile devices for staff usage. This post is to help guide security analysts and engineers on how they can use MobSF to carry out basic internal security reviews of any mobile applications that their respective organisation may intend to deploy for their end users. Please note that this blog post is high-level, intended for moderately technical audiences, and is limited in scope to only static analysis of Android apps. I may cover more involved assessment methodologies via dynamic analysis in a future post. Requirements A Linux OS (in this guide I'll be using Kali) Some basic CLI experience A dedicated Android device which is rooted (optional)   Installing and deploying MobSF To get started we can leverage the open-source Mobile Security Framework, more commonly known as MobSF, to automate static analysis and generate a report. Install MobSF using: git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.gitcd Mobile-Security-Framework-MobSF./setup.sh Update MobSF using: git pull origin master. venv/bin/activatepip install --no-cache-dir --use-deprecated=legacy-resolver -r requirements.txtpython manage.py makemigrationspython manage.py makemigrations StaticAnalyzerpython manage.py migratedeactivate Deploy MobSF using: ./run.sh 127.0.0.1:8000 Obtain an APK file for analysis: To interrogate the compiled binaries and functionality for analysis, MobSF requires the raw APK file of the desired app. APK files can be obtained a number of ways, and the process can differ between free and paid-for apps. I plan to create a separate blog post in the future which helps guide through the process I've standardised for myself involving a rooted Android device. For now I might recommend trying third-party services such as APK Pure. Upload an APK file for analysis: From here you can upload any .apk binary for static analysis. Note, any uploaded file should be a raw .apk and not the compressed .zip container or .xapk package in which the .apk files usually reside.If an .xapk package is sourced, you can extract the raw .apk files from this by renaming the filename to a .zip extension. For example, if the filename is com.riggsmobileapp.xapk, rename this to com.riggsmobileapp.zip, open the .zip, then pull out the .apk file(s) you wish to analyse and submit them into MobSF for analysis. Third-party app providers also reserve the ability to supply these files and may do so upon request. Review the generated report: Once static analysis is complete, MobSF will produce a report detailing its findings. These can be interactively navigated using the categories listed within the left sidebar, or exported into a PDF file using the PDF Report button. What should your assessment of the MobSF report aim to cover? This will largely depend on the mobile app and on your organisational risk appetite for introducing new mobile apps into their environment. Below I will expand on some key areas I think are worth reviewing, but please note that these should not be considered exhaustive. Application permissions The functionality and access of an app are determined by its permissions. These permissions vary, spanning from the ability to retrieve data stored on the mobile device, such as contacts and media files, to operating certain hardware components like the device's camera or microphone.This information can be found in the following location of the report: Permissions The Permissions tab provides detailed information about permissions extracted from the AndroidManifest.xml file. This file in an Android application is responsible for declaring the permissions the app needs, along with many other settings. Within this tab you should see a list of permissions the app has requested and brief descriptions of what those permissions allow the app to do. You should pay particular attention to any permissions which do not align with the app's described purpose and that can potentially compromise user privacy or the device security. Network traffic In static analysis, it's useful to assess specific destinations, or servers, to which an app dispatches data and the sources from where it extracts data. This means it's useful to consider the server's credibility, the integrity of the connections (whether they're all secured or only a fraction of them), and the nature of information returning via these links (for example, whether malware or phishing attacks are originating from a previously considered safe URL).This information can be found in the following locations of the report: Reconnaissance > Hardcoded Secrets Check for any URLs which might be hardcoded as destination servers. Assess if any shown are unexpected (in the context of the application purpose) and consider manual review of their IP reputation and conduct reverse-lookups to identify any anomolies. Malware Analysis > Domain Malware Check Check for any URL domains within the report which indicate a suspicious status. This may indicate that the app communicates with a server domain that is known to have been associated with malicious activities in the past. While the report can offer some information about the usage of secure data transfer protocols, it may not provide a complete picture. The application could make decisions at runtime about which protocols to use, or it could use different protocols in different circumstances. For a more thorough analysis, you might need to intercept and inspect the application's network traffic using a tool like Burp Suite. Secure data transmission Android platforms by default employ TLS to protect all data transmitted to or from an Android device. However, developers have the discretion to modify their app's network security settings to permit unencrypted connections. For this reason it's useful to validate that any network configurations observed are optimised to leverage secure protocols.This information can be found in the following locations of the report: Scan Options > View AndroidManifext.xml The report will provide a detailed analysis of the AndroidManifest.xml file, which could include usage of insecure protocols, if they are declared. Security Analysis > Code Analysis Here, you can find the analysis of the .java or .kt files. Look for usage of HTTP/HTTPS calls in this section. It might show insecure HTTP calls (http://) if the application is using them, which would indicate that it is not using secure SSL/TLS protocols for those calls. Application components It's useful to inspect the fundamental components of the application, including the programming language, techniques, libraries, frameworks etc, to ensure that the application employs safe elements devoid of known vulnerabilities.This information can be found in the following locations of the report: Components > Services This displays a list of all the services used by the Android application. A service is an application component that can perform long-running operations in the background, and it does not provide a user interface. It can continue running even if the application's main process is not active, or the application is in the background. These services can be important from a security perspective because they can perform actions without direct user interaction. For example, a service could be used to periodically sync data with a server, or to run some computation in the background. Components > Libraries This section offers a detailed view of the native libraries that the app includes, which can be helpful in the security analysis of the application, as by knowing which third-party libraries are used, you can check if these libraries have known vulnerabilities. If the version of the library used by the application is known to have security vulnerabilities, then the application might be vulnerable as well. App store records It may be useful to conduct a thorough analysis of the data available on the app store. This includes information like the identity of the developer, the number of app installations, the frequency of updates, the presence of a process for reporting bugs, and any negative or fraudulent app reviews. Additionally, it's worth examining the developer's credibility for indications of fraudulent activities. Warning signs may include nonfunctional 'contact us' links, irrelevant information on FAQ pages, or a collection of unrelated or suspicious apps within their portfolio. Third-party intelligence It can also be useful to consider looking for assessments or reports shared by other researchers to gain additional insight. For example, you could try submitting search queries to Google such as "[INSERT APP NAME HERE] vulnerability" or "[INSERT DEVELOPER NAME HERE] data breach" to identify if any evidence exists within the public domain to suggest that your organisation's adoption of the app could introduce risk. My risk report template Below I have included a copy of a Microsoft Word document template I drafted to help with documenting the appropriate risk report findings. My recommendation is to consider using a document like this to evidence your analysis and archive it, along with the full MobSF output, within your organisation's filesystem for auditable reference. This should help the business understand any associated point-in-time risk a particular mobile app may carry, and can be relied upon as evidence when required to demonstrate that you have exercised a reasonable degree of due diligence. Mobile App Risk Report Template (.DOCM) Mobile App Risk Report Template (.PDF)   Please note that the Microsoft Word .docm file made available above includes a small VBA macro script I added which basically allows for the risk level ratings to be easily selected from within an interactive drop-down menu in the document. The script then auto-populates the corresponding cell with an appropriate background colour. This was added purely for convenience. If you have any concerns, you can still use the file as a template without permitting the macro functionality, which in most cases should be blocked by default anyway. The key is to present your report findings in a clear, concise manner, offering a complete picture of the potential risks, while also giving actionable recommendations for mitigating these risks. Remember to adjust and customise the template as necessary to best suit the requirements of your organisation and the specific nature of the app that you're assessing.

  •

    Configuring Burp to proxy traffic from mobile apps

    4.92 of 100 votes

    In this blog post, I'll explore how to configure Burp to proxy traffic from mobile apps to assist with the security testing of mobile applications. Getting started To get started, there are a few pre-requisites needed: Windows OS An up-to-date Windows OS with Android Debug Bridge (adb) installed. Kali VM An up-to-date Kali VM with Android Debug Bridge (adb) installed (run sudo apt-get install adb) Burp Suite An up-to-date Burp Suite. Mobile Device A rooted Android device (in this example I'm using a rooted Nexus 5X running LineageOS). Configuring the Burp listener Open up Burp Setup listener Navigate to Proxy > Proxy settings > Proxy listeners then Add a new proxy listener and bind it to port 8081 across All interfaces Connecting the mobile device Connect mobile device via USB Connect the Android mobile device (in this example I'm using a rooted Nexus 5X running LineageOS) via a USB data cable. Configure the USB connection On the device, navigate to Settings > Connected devices > USB and select Transfer files Mirroring the mobile device to desktop Download and install Vysor You can download Vysor from here. Run Vysor Open Vysor and select the View Device button with a play icon. Your Android mobile device should not be mirrored to your computer screen. If Vysor cannot find your device, follow the steps below: (a) Restart your mobile device and restart your computer. (b) Make sure you are using a USB data cable. Charge cables will not always allow data transfer over USB. (c) On Windows, download the Universal ADB Drivers. If that doesn't work, try installing your manufacturer's drivers. (d) Enable ADB debugging on the mobile device. (e) Set your mobile device USB mode to PTP (it is usually MTP or Charge Only).   Configuring the mobile device proxy Configure the mobile device network On your Android mobile device, navigate to Settings > Network & Internet > Wi-Fi > and select the access point you wish to connect to. Then select Advanced options and set the Proxy to ManualIf you're already connected to the access point before starting this step, ensure you first select Forget network Configure the mobile device proxy The proxy settings should be set as follows: (a) Proxy hostname = The IP address of the device using Burp which you wish to proxy traffic through (b) Proxy port = The port we set earlier which is 8081 Example: (c) Now click CONNECT Exporting the CA Certificate Now Burp is configured to intercept the Android mobile device traffic, but without a valid CA Certificate in place will be unable to decrypt HTTPS traffic. Export the CA certificate Open Burp and navigate to Proxy > Proxy settings > Proxy listeners then select the Import / export CA certificate button Select the CA certificate format Export the CA Certificate in DER format. In this example we will name it cacert.der Converting the CA certificate format Convert the DER file into PEM Now we need to convert the DER file into PEM format for Android and have the filename equal to the subject_hash_old value appended with a .0. To achieve this, we can move the cacert.der file over to a Kali VM and execute the following commands: openssl x509 -inform DER -in cacert.der -out cacert.pemopenssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1mv cacert.pem [hash].0 Example: Move the PEM file to the mobile device Now we need to move the newly created PEM file over to the Android mobile device /system filesystem. To achieve this we can leverage the following adb commands: adb rootadb remountadb push [cert].0 /sdcard/ adb shellmv /sdcard/[cert].0 /system/etc/security/cacerts/chmod 644 /system/etc/security/cacerts/[cert].0exit adb reboot Example: Verifying the CA certificate is installed Verify the certificate installation Once restarted, the CA Certificate should be installed on the Android mobile device. This can be verified by navigating to Settings > Security & privacy > Encryption & credentials > Trusted credentials and searching in the System directory to validate the CA Certificate from PortSwigger is present.

  • Setting up an API pentesting environment

    4.92 of 92 votes

    This is my go-to reference documentation for setting up a fresh dedicated API pentesting environment within Kali. Setting up Burp Download Jython Head over to https://www.jython.org/download.html and download the latest Jython standalone installer. Set the Python Environment path Set the downloaded Jython installer as the Python Environment path. Install the Autorize extension Within Burp, navigate to Extender > BApp Store > search for Autorize and install the extension. Install FoxyProxy With Firefox open, press Ctrl + Shift + A to open the add-ons menu. Search for FoxyProxy Standard Add FoxyProxy to Firefox Navigate to FoxyProxy options Add Burp to FoxyProxy Add Postman to FoxyProxy Configure Burp Suite Certificate Start Burp With Burp Suite enabled in FoxyProxy, navigate to http://burpsuite and click the CA Certificate to download the certificate. In Firefox, open Preferences and use the search bar to look for certificates. Import the downloaded certificate. In Chrome, open Settings > Privacy and security > Certificates managed by Chrome and import the downloaded certificate (may need to change the file type options to 'All Files'). Postman Download Postman sudo wget https://dl.pstmn.io/download/latest/linux64 -O postman-linux-x64.tar.gz Extract and install Postman sudo tar -xvzf postman-linux-x64.tar.gz Link the postman command sudo ln -s ~/Postman/Postman /usr/bin/postman mitmproxy2swagger Install mitmproxy2swagger sudo pip3 install mitmproxy2swagger Git Install Git sudo apt install git Docker Install Docker sudo apt install docker-composesudo apt install docker.io Golang Install Golang sudo apt install golang-go At this point a restart may be required. JWT Tool Pull down the JWT Tool repo sudo git clone https://github.com/ticarpi/jwt_tool.git Install JWT Tool cd jwt_toolpython3 -m pip install termcolor cprint pycryptodomex requestssudo chmod +x jwt_tool.pysudo ln -s ~/jwt_tool/jwt_tool.py /usr/bin/jwt_tool Kiterunner Pull down the Kiterunner repo sudo git clone https://github.com/assetnote/kiterunner.git Install Kiterunner cd kiterunnersudo make buildcd distsudo ln -s ~/kiterunner/dist/kr /usr/bin/kr Arjun Pull down the Arjun repo sudo git clone https://github.com/s0md3v/Arjun.git Install Arjun cd Arjunsudo python3 setup.py install ZAProxy Install ZAProxy sudo apt install zaproxy Update OpenAPI add-on

  • How to access and trade on darknet markets

    5.00 of 89 votes

    Welcome to my first counter-economics walkthrough, featuring the darknet. The darknet is not just a domain for illicit activities, it also serves as a space that offers unparalleled opportunities for discourse, free market trade, and collective and communal discovery. It’s occupied by people from all walks of our complex and layered lives - from outright criminals and troublemakers, to journalists, dissidents, and security researchers (like myself). Whilst I can appreciate that the darknet is widely associated with illegal activity, it’s important to note that simply accessing the darknet is perfectly legal. There’s a lot of advanced cryptographic protocols and processes behind the workings of what I’m about to explain, but for the purpose of keeping this post short and tailored for a wide audience, I’m going to simplify everything as best I can. 1. Tor To access the darknet you’ll need to download and install the Tor (the onion routing) browser. This is an open source purpose-built and completely free browser based on Firefox that enables anonymous web surfing, by ensuring that all traffic it processes is heavily protected against traffic analysis. Download Tor Tor establishes a secure network circuit for each browser session, which connects Tor nodes deployed around the world at random. These nodes encrypt your browser traffic in layers at each node hop on its way to/from the source (your browser) and the destination (a hosted hidden service). 2. Darknet markets With Tor installed, you’ll next need to find a darknet marketplace domain to visit. The Tor network mandates that Tor clients (such as the Tor browser) can only access sites using the .onion TLD. However, these domains are not easy to distinguish, and are usually represented in long, often randomly generated alpha-numeric strings. Finding the correctly represented URL for a particular domain in the first instance can be a challenge. There are hundreds of marketplaces to choose from, each with their own set of communities, politics, and socio-economic motivations. I wont list them all here, as unfortunately not all survive long enough to outgrow the impulse of real-world influence and fallible human desires. Some get hacked, some get shut down by law enforcement, and some succumb to their own greed - whereby the operators 'exit scam' entire communities. This is why there’s no specific endorsement for any particular marketplace I can make, but I’ll include a few of the most common below for reference. Please beware of the many fake .onion addresses that frequently circulate the web and are set up as convincing phishing sites. The above hidden service URLs were validated as accurate at the time of this blog post being made, though may require further validation if they are to be relied upon in the future.   3. What you can buy Most darknet marketplaces have a large selection of categories populated with listings from reputable vendors. These are varied, and can include both legal and illegal listings.In no particular order, I’ve added a table featuring some of the most common categories I’ve observed below: Drugs Doxxing Malware Hacking Software Hosting Electronics Ebooks Firearms Graphics Databases VPNs Jewellery Fraud Passports Programming 4. Buying Bitcoin (BTC) The first step, if you’re new to this space and want to facilitate a trade, is to buy yourself some cryptocurrency.This process, in summary, is to trade a value of what you own in digital fiat currency (GBP, USD, AUD, etc) for a value of what you desire in BTC, and can most easily be achieved by registering to a centralised platform, like one of those I’ve included below. Coinbase Binance Bitfinex Poloniex Many darknet marketplaces employ the use of specific cryptocurrencies (such as XMR) that use technologies such as stealth addressing and ring signatures to evade traceability. However, these currencies, due to their decentralised and counter-economic nature, are often restricted by centralised platforms from purchase and practical use. This means it’s sometimes possible to buy these currencies (such as XMR) in exchange for fiat (GBP, USD, AUD, etc), but you may find yourself prevented from transferring such currencies outside of the platform you’ve purchased them from. 5. Exchanging Bitcoin (BTC) for Monero (XMR) A logical and convenient method I’ve seen adopted to get around this problem is to purchase another mainstream currency (such as BTC) via a centralised platform, then to use a third-party service to facilitate an exchange into a darknet marketplace supported currency like XMR.Below I've added an embedded interactive exchange utility that runs off a secure third-party API, and connects each transaction request with the best real-time market rates offered across a wide number of centralised trading platforms. If you'd like to use it to exchange currencies, please feel free. 6. Making a purchase Most reputable darknet marketplaces employ the use of escrow systems for mutual buyer and seller protection, with step-by-step client-side encryption features leveraging PGP to ensure end-to-end privacy and anonymity is preserved. This usually (but not always) means that when you supply potentially identifiable information, such as an email address or postal address to receive goods, the marketplace usually auto-encrypts your data to the vendor’s public key in your browser at the point of sale. This is to prevent your data being inadvertently disclosed at any time in the future to anyone other than yourself and the vendor, and ensures that trade participants can remain confident that marketplace transactions are provably private.Understanding PGP usage in this context is important, but can be overwhelming for newcomers. A while back I made another blog post on PGP keys which helps explain what PGP is and how it works.

  •

    How to integrate Nuclei with Interactsh and Notify

    4.96 of 94 votes

    This is my walkthrough for installing Nuclei from ProjectDiscovery and how to integrate a suite of tools to assist with automation tasks. This includes subfinder for subdomain discovery, httpx for probing to validate live hosts, setting up your own self-hosted Interactsh server for OOB (out-of-band) testing, and how to install and configure Notify for the convenience of alerting on any identified vulnerabilities via external channels such as email, Slack, Discord, and Telegram. Throughout this guide I'll be using a standard Kali image, though you can of course use whichever flavour of Linux you prefer.   Prerequisites Install Golang sudo apt install golang Update Golang git clone https://github.com/udhos/update-golangcd update-golangsudo ./update-golang.sh Set the golang environment module to auto go env -w GO111MODULE=auto Install go wget https://go.dev/dl/go1.17.5.linux-amd64.tar.gzsudo tar -C /usr/local/ -xzf go1.17.5.linux-amd64.tar.gz Set the path variable within the bashrc file echo 'export GOROOT=/usr/local/go' >> .bashrcecho 'export GOPATH=$HOME/go' >> .bashrcecho 'export PATH=$GOPATH/bin:$GOROOT/bin:$HOME/.local/bin:$PATH' >> .bashrc Refresh the bashrc file source ~/.bashrc Install the following suite of tools (these are my baseline for optimal automation). Interactsh We need to set up a self-hosted Interactsh server to enable secure testing of OOB (out-of-band) vulnerabilities. To get started we need our own remote VPS. For this guide I’ll be using a Digital Ocean droplet. Install Interactsh go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest First, create a Digital Ocean account if you don’t have one already. Then in the top-right of your account dashboard, click to create a droplet. Choose a droplet image (for this example I've opted to use Debian). Select a droplet plan (for this example I’ve opted to go with basic). Select a CPU (for this example I've opted for a single CPU). Select the region where your desired VPS will reside (for this example I’ve opted for London). Select an authentication protocol for droplet access (for this example I’ve selected a root password). Now we can create our droplet. Once the droplet is created, we should take note of the public IP address, as we’ll need this later. Now we can click the three dots to access the droplet console. Then proceed to access the console via our web browser and login as root, using the password we defined earlier (in step 7). Install Interactsh on remote VPS droplet sudo apt updatesudo apt install golang go env -w GO111MODULE=auto wget https://go.dev/dl/go1.17.5.linux-amd64.tar.gzsudo tar -C /usr/local/ -xzf go1.17.5.linux-amd64.tar.gz echo 'export GOROOT=/usr/local/go' >> .bashrcecho 'export GOPATH=$HOME/go' >> .bashrcecho 'export PATH=$GOPATH/bin:$GOROOT/bin:$HOME/.local/bin:$PATH' >> .bashrc source ~/.bashrc Register and configure the desired domain Next we need to register our desired domain name with our preferred domain registrar. In this guide I’ll be demonstrating the process using GoDaddy with my domain I selected for my OOB testing: oobtest.com First we need to login to GoDaddy, navigate to our account home page, and then scroll down to our domains and click Set up to configure the desired domain DNS settings. Now we click on Add and navigate to Host Names. Now we add our desired hostnames, which in this case will be directing NS1 and NS2 to the public IP address of our droplet. Now we can navigate back to our DNS Management page and scroll down to Nameservers. As these are configured to the default GoDaddy nameservers, we want to change them. Now we can enter our custom nameservers for our domain. Once the nameserver configuration is saved, we will need to wait for DNS propagation to complete in the background, which usually takes a few hours. Once this is done, our OOB testing server is ready to deploy. Afterwards, we can login to our droplet, and start the server. interactsh-server -domain oobtest.com At this stage the server is live and listening for any OOB interactions. To configure the server for secure communication with the client, we can leverage the -auth flag to generate an authentication token, which will remain valid for the duration of the session. interactsh-server -domain oobtest.com -auth Nuclei Install Nuclei go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest Run nuclei for the first time to install the templates. Subfinder Install Subfinder go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest Now we need to add API keys to the Subfinder configuration file. Run subfinder for the first time to generate the default config file. Now we can open and edit the configuration file. sudo nano ~/.config/subfinder/config.yaml Scroll to the bottom of the file and add your API keys for the corresponding third-party service providers. If you do not yet have API keys for the named service providers, you will need to register an account at each one and copy over the API key they issue you. Once completed, your configuration file should look something like this: Save and exit. httpx Install httpx go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest Notify In this example I’ll be demonstrating how to set up Notify for Discord. These steps are similar for the alternative channels which are currently supported such as Slack and Telegram. Install Notify go install -v github.com/projectdiscovery/notify/cmd/notify@latest Set up the Notify configuration file sudo mkdir ~/.config/notifycd ~/.config/notify Create a Discord server Choose a server name Edit channel within server Change channel name to notifications Navigate to Integrations and create a web hook for the channel Enter the desired bot name and copy the web hook URL to clipboard Now open and edit the configuration file sudo nano provider-config.yaml Enter the following: discord:     - id: "Discord Server for Nuclei Alerts"       discord_channel: "notifications"       discord_username: "Notify Bot"       discord_format: "{{data}}"       discord_webhook_url: "[PASTE WEBHOOK URL HERE]" Save and exit. Ready to go Now we can begin using the suite of tools together. First we want to initialise our Interactsh client. interactsh-client -v -server https://oobtest.com -token [INTERACTSH SERVER TOKEN] The client communicates with the server to generate a unique subdomain ‘payload’ for OOB testing. This will listen for OOB interactions, and with the -v flag present will provide verbose logging within the terminal window for any requests it receives. With the Interactsh client generated subdomain, and the Interactsh server generated auth token, we can feed these values into our Nuclei command to include OOB testing in our scans. For example: subfinder -d jacobriggs.io -o subdomains.txt | httpx -list subdomains.txt | nuclei -stats -l subdomains.txt -t takeovers/ -t cves/ -iserver "https://c6u975tmtn7kpis0l360cg6j8fayyyyyn.oobtest.com" -itoken "ac3dc1c75be69feb5a6a2d4bf126cff3b1a4fb4f8cf2f28fb8a827745302ceaf" -o vulns.txt; notify -data vulns.txt -bulk I will briefly break down the arguments in this command below: subfinder will enumerate the subdomains of the designated target domain and write all the subdomains it finds to a subdomains.txt file. httpx will then probe the subdomains to validate which ones are alive. Nuclei will then ingest the alive subdomains, run each subdomain URL through the defined template scans (in this case to check for subdomain takeovers and any vulnerabilities corresponding to known CVEs), and then output any logged findings to a vulns.txt file. With the self-hosted Interactsh instance specified, Nuclei will auto-correlate the requests it makes with any OOB interactions it identifies on the listening Interactsh server. Once the Nuclei scanning is complete, Notify will then parse the vulns.txt file and send a bulk alert over the webhook to the corresponding notification channel (in this case alerts will arrive in the Discord channel we set up earlier).