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.
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
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.
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).
With many security professionals now working remotely from home, some are looking at ways in which they can improve their home environment network and endpoint security. Commercial SIEM solutions are often considered too costly and complicated to deploy, but free lightweight open-source solutions offering minimal overhead such as Wazuh provide a good compromise for those of modest means aiming to mature the security of their home or small business environment.This is my walkthrough on how to install the Wazuh server manager onto a Raspberry Pi 4B as an all-in-one deployment. I noticed there was no clear guidance online on how to go about doing this for a Raspberry Pi 4B, only a significant number of online posts outlining the installation and deployment difficulties people have faced. So here I've decided to document the process I took, tested and validated from start to finish, with clear directions anyone can follow.By following this guide you can run your own open-source SIEM solution on a Raspberry Pi 4B at home. This is great not only for existing security professionals looking to improve the resiliency of their home setup, but also for those new to the information security industry seeking to gain hands-on experience in SIEM deployment, management, and other SIEM/SOC related activities. Getting started To get started, I used a Raspberry Pi 4B with 8GB RAM and a 128GB SanDisk Extreme SD card for storage. Whilst the Raspberry Pi 4B I used for this project was custom built from TurboPi with high-end hardware for this particular purpose, any Raspberry Pi 4B with adequate hardware capable of running Raspbian OS (buster or greater) leveraging the AArch64 64-bit extension of the ARM architecture should be sufficient. Walkthrough Install a Raspberry Pi 64-bit ARM OS First download and install the official Raspberry Pi Imager. Now download the latest Raspi OS ARM64 .zip image from the official repo (make sure it's the latest version). Open the Raspberry Pi Imager application. Select the CHOOSE OS button and in the dropdown list select the Use custom option. Select the Raspi OS ARM64 .zip file you just downloaded. Select the SD storage card to write this to. Proceed with the prompted erasure, formatting, and writing activities to install the OS to your SD card. The last step here is to write an empty text file named 'ssh' (no file extension) to the root of the directory of the SD card. When the device boots and sees the 'ssh' file present, it will automatically enable SSH, which will allow us to remotely access the device command line in a headless state. Identify your Raspberry Pi local IP address For this I use a Kali VM in VirtualBox, but any flavour of Linux distro can acheive the same. As the guest VM is not visible to the host under the default VirtualBox NAT settings, you need to change your VM network settings to bridge the network adapter between your host machine and the guest VM. Once the network adapter is bridged, we need to identify the Raspberry Pi IP address on the network. There are a few ways to do this (such as logging directly into the router), but we can also use an arp command with the -na flag to display the local network address translation tables and pipe the output using grep to pull any MAC addresses that begin with identifiers we're interested in.arp -na | grep -i dc:a6:32 Raspberry Pi MAC addresses always use the same OUI (Organizational Unique Identifier) in their MAC address (b8:27:eb for all Raspberry Pi devices except Raspberry Pi 4B which uses dc:a6:32). Connecting to the Raspberry Pi Now we have the device IP address (in this example mine is assigned 192.168.1.93), we can SSH into it using default credentials ssh pi@192.168.1.93 with the default password raspberry and get started. Change hostname and update First you may wish to change the hostname from raspberry to wazuh (or something else). To do this run the command sudo raspi-config and navigate to System Options > Hostname using the GUI.Type in your desired hostname and hit Enter, then return to the main menu of the GUI and select Update. Once the device has finished updating, navigate to the to Finish button to save your new raspi-config settings.For the hostname change to take effect, reboot the device using the command sudo reboot, then SSH back in using the same credentials ssh pi@192.168.1.93 with the default password raspberry once the reboot is complete. Enable login as root Then if you want to login as root using SSH or WinSCP you need to edit the config of SSHD. Login, and edit the sshd_config file using sudo nano /etc/ssh/sshd_configFind the line containing PermitRootLogin prohibit-passwordEdit this to reflect PermitRootLogin yes Close and save the file, then reboot or restart sshd service using /etc/init.d/ssh restartSet a root password if there isn't one already using sudo passwd rootNow you can login as root (I recommend using a strong password or SSH keys). Now proceed to sudo up using sudo su and continue the next steps as root. Update the Raspberry Pi packages To update the Raspberry Pi, first ensure the VM you're connecting from over SSH into has an Internet connection and then run the command apt update && apt upgrade -y Once the update and upgrade process is complete, pull down the required packages for the next steps using:apt-get install apt-transport-https zip unzip curl gnupg wget libcap2-bin software-properties-common lsb-release -y Install Java 11 echo 'deb http://deb.debian.org/debian stretch-backports main' > /etc/apt/sources.list.d/backports.list apt update -y apt install openjdk-11-jdk -y Install Elasticsearch OSS Fetch the Elasticsearch OSS arm64 installation package:wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-oss-7.10.2-arm64.deb Install the Elasticsearch OSS package:dpkg -i elasticsearch-oss-7.10.2-arm64.deb Install Open Distro for Elasticsearch Download and add the signing keys for the repositories:wget -qO - https://d3g5vo6xdbdb9a.cloudfront.net/GPG-KEY-opendistroforelasticsearch | sudo apt-key add - wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add - Add the repository definitions:echo "deb https://d3g5vo6xdbdb9a.cloudfront.net/apt stable main" | sudo tee -a /etc/apt/sources.list.d/opendistroforelasticsearch.list Update the packages:apt-get update -y Install the Open Distro for Elasticsearch package:apt install opendistroforelasticsearch -y Configure and run Elasticsearch Run the following command to download the configuration file /etc/elasticsearch/elasticsearch.yml:curl -so /etc/elasticsearch/elasticsearch.yml https://packages.wazuh.com/resources/4.2/open-distro/elasticsearch/7.x/elasticsearch_all_in_one.yml Now we need to add users and roles in order to use the Wazuh Kibana properly. Run the following commands to add the Wazuh users and additional roles in Kibana:curl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/roles.yml https://packages.wazuh.com/resources/4.2/open-distro/elasticsearch/roles/roles.ymlcurl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/roles_mapping.yml https://packages.wazuh.com/resources/4.2/open-distro/elasticsearch/roles/roles_mapping.ymlcurl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml https://packages.wazuh.com/resources/4.2/open-distro/elasticsearch/roles/internal_users.yml Remove the demo certificates:rm /etc/elasticsearch/esnode-key.pem /etc/elasticsearch/esnode.pem /etc/elasticsearch/kirk-key.pem /etc/elasticsearch/kirk.pem /etc/elasticsearch/root-ca.pem -f Download the wazuh-cert-tool.sh:curl -so ~/wazuh-cert-tool.sh https://packages.wazuh.com/resources/4.2/open-distro/tools/certificate-utility/wazuh-cert-tool.shcurl -so ~/instances.yml https://packages.wazuh.com/resources/4.2/open-distro/tools/certificate-utility/instances_aio.yml Run the wazuh-cert-tool.sh to generate the certificates:bash ~/wazuh-cert-tool.sh Move the Elasticsearch certificates to their corresponding location for deployment:mkdir /etc/elasticsearch/certs/mv ~/certs/elasticsearch* /etc/elasticsearch/certs/mv ~/certs/admin* /etc/elasticsearch/certs/cp ~/certs/root-ca* /etc/elasticsearch/certs/ Enable and start the Elasticsearch service:systemctl daemon-reloadsystemctl enable elasticsearchsystemctl start elasticsearch Run the Elasticsearch securityadmin script to load the new certificates information and start the cluster:export ES_JAVA_HOME=/usr/share/elasticsearch/jdk/ && /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/ -nhnv -cacert /etc/elasticsearch/certs/root-ca.pem -cert /etc/elasticsearch/certs/admin.pem -key /etc/elasticsearch/certs/admin-key.pem Run the following command to ensure the installation is successful:curl -XGET https://localhost:9200 -u admin:admin -k An example response should look as follows: The Open Distro for Elasticsearch performance analyzer plugin is installed by default and can have a negative impact on system resources. The official Wazuh documentation recommends removing this with the following command /usr/share/elasticsearch/bin/elasticsearch-plugin remove opendistro-performance-analyzer and restarting the Elasticsearch service afterwards. Install and run the Wazuh manager Install the GPG key:curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - Add the repository definition:echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list Update the Wazuh packages:apt-get update -y Install the Wazuh manager package:apt-get install wazuh-manager Enable and start the Wazuh manager service:systemctl daemon-reloadsystemctl enable wazuh-managersystemctl start wazuh-manager Run the following command to check if the Wazuh manager is active:systemctl status wazuh-manager An example response should look as follows: Install and configure Filebeat Add the repository definition:echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list Fetch the Filebeat arm64 installation package:wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-oss-7.12.1-arm64.deb Install the Filebeat package:dpkg -i filebeat-oss-7.12.1-arm64.deb Download the pre-configured Filebeat config file used to forward Wazuh alerts to Elasticsearch:curl -so /etc/filebeat/filebeat.yml https://packages.wazuh.com/resources/4.2/open-distro/filebeat/7.x/filebeat_all_in_one.yml Download the alerts template for Elasticsearch:curl -so /etc/filebeat/wazuh-template.json https://raw.githubusercontent.com/wazuh/wazuh/4.2/extensions/elasticsearch/7.x/wazuh-template.jsonchmod go+r /etc/filebeat/wazuh-template.json Download the Wazuh module for Filebeat:curl -s https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.1.tar.gz | tar -xvz -C /usr/share/filebeat/module Copy the Elasticsearch certificates into /etc/filebeat/certs:mkdir /etc/filebeat/certscp ~/certs/root-ca.pem /etc/filebeat/certs/mv ~/certs/filebeat* /etc/filebeat/certs/ Enable and start the Filebeat service:systemctl daemon-reloadsystemctl enable filebeatsystemctl start filebeat To ensure that Filebeat has been successfully installed, run the following command:filebeat test output An example response should look as follows: Install and configure Kibana Install the Kibana package:apt-get install opendistroforelasticsearch-kibana Download the Kibana configuration file:curl -so /etc/kibana/kibana.yml https://packages.wazuh.com/resources/4.2/open-distro/kibana/7.x/kibana_all_in_one.yml Create the /usr/share/kibana/data directory:mkdir /usr/share/kibana/datachown -R kibana:kibana /usr/share/kibana Install the Wazuh Kibana plugin. The installation of the plugin must be done from the Kibana home directory as follows:cd /usr/share/kibanasudo -u kibana /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/4.x/ui/kibana/wazuh_kibana-4.2.5_7.10.2-1.zip Copy the Elasticsearch certificates into the Kibana configuration folder:mkdir /etc/kibana/certscp ~/certs/root-ca.pem /etc/kibana/certs/mv ~/certs/kibana* /etc/kibana/certs/chown kibana:kibana /etc/kibana/certs/* Link Kibana’s socket to privileged port 443:setcap 'cap_net_bind_service=+ep' /usr/share/kibana/node/bin/node Enable and start the Kibana service:systemctl daemon-reloadsystemctl enable kibanasystemctl start kibana Check the Kibana service status to ensure it's running:systemctl status kibana An example response should look as follows: Open the Kibana interface Visit the Raspberry Pi 4B device IP address in your browser (e.g my interface is reachable at https://192.168.1.93). Upon the first access to Kibana, the browser shows a warning message stating that the certificate was not issued by a trusted authority. An exception can be added in the advanced options of the web browser or, for increased security, the root-ca.pem file previously generated can be imported to the certificate manager of the browser. Alternatively, a certificate from a trusted authority can be configured. Login to Kibana using the default user credentials admin with the password admin. For security purposes I recommend these credentials are changed. Change the default passwords To change the default credentials for all users residing in the internal_users.yml file, run the following command:bash wazuh-passwords-tool.sh -a An example response should look as follows: Remember to take note of these credentials or save them into a password manager if you have one. Next we need to also also update the credentials for Filebeat and Kibana (if these were not already covered by the wazuh-passwords-tool.sh script). Open and update the Filebeat configuration file:nano /etc/filebeat/filebeat.yml Change the associated password: value. Make sure you make a record of this, then save and exit. Open and update the Kibana configuration file:nano /etc/kibana/kibana.yml Change the associated elasticsearch.password: value. Make sure you make a record of this, then save and exit. Restart all services for the changes to take effect:systemctl restart wazuh-managersystemctl restart filebeatsystemctl restart kibana Congratulations, you've now installed the Wazuh server manager onto your Raspberry Pi. Now you can install the Wazuh agents on any devices you want to onboard to monitor security related events from within the server manager interface. The Wazuh agent installation guide is relatively simple and can be found here. I hope this tutorial helped.
Understanding how to cover your tracks during a pen test is important. The MITRE ATT&CK matrix defines this as defensive evasion, which consists of methods and techniques that an attacker may use to help avoid detection through network monitoring. Below are some defensive evasion techniques that can be used in practice during a pen test engagement. Clearing Command History (ID: T1146) Both Linux and Mac operating systems keep track of the commands users type in the terminal. The BASH shell will record keystrokes in the $home/ .bash_history file. During a pentest, once you obtain access to a Unix/Linux/Mac operating system, it is usually best practice to unset the history file to prevent the user/administrator from knowing what commands you were executing, as well as not commingling your dirty/malicious commands with a user's history. Unsetting the history file is as easy as shown here: unset HISTFILE - The temporary history will not be written to disk. export HISTFILE=0 - The temporary history will not be written to disk. history -c - This will clear the temporary history file. set +o history - Prevents commands from recording to the temporary history. Administrators can counter the defense evasion attack by setting the variable read-only to help preserve the contents of the history file for forensic purposes. Timestomping (ID: T1099) A technique used to modify the timestamps of a file (the modify, access, create, and change times) is called timestomping. This technique can be executed by an attacker against files/directories that were modified. The timestomp feature in a meterpreter shell can be a good way to limit the digital footprint of reading/writing data on the file system. To see a list of options, you can use the following syntax: timestomp -v - Display the UTC MACE values of the file. timestomp -m - Set the last written time of the file. timestomp -a - Set the last accessed time of the file. timestomp -c - Set the creation time of the file. You can see what the date timestamps look like before and after, then change it back to the before look. Imagine you wanted to change the contents of a user's logon script or even a scheduled task that points to a PowerShell file in the administrator's home directory called riggs-script.ps1 and add some arbitrary code to the file to assist with persistence. Once you modify the file, you can use timestomp to change the file back to the original values. This way your modification doesn't set off any red flags when looking at the date timestamp. Let's say you are on a Windows database server after successfully exploiting an SQL injection vulnerability through the customer's web server. You want to remove your nefarious actions from the www.log and db.log files and timestomp them to a period of time prior to the attack. After you remove your malicious entries in the log, you can use PowerShell to change the file properties LastWriteTime, LastAccessTime, and CreationTime for each log file. To do this, you could use the Get-Item cmdlet to identify the item (file) you want to modify, define the date you want to set the files to (the format is MM/DD/YYYY HH:MM am/pm), and apply the new timestamp to each file property. This can help conceal your entry and allow you to continue with your testing objectives and not draw as much attention to yourself. If you modify the contents of a file that a customer is monitoring with integrity checking software (like Tripwire), the change will still be identified and will likely trigger an alert. Integrity monitoring software compares a cryptographic hash of the file from the time the file was last inspected. These tools can be set to run at various times through scheduled tasks. There is a difference between changing the last written/accessed/creation time and creating a cryptographic hash of the target file. File Deletion (ID: T1107) Malware, tools, or other non-native files dropped or created on a system may hadd to the attacker's digital footprint. Metasploit is a great way of avoiding this hurdle when exploiting and executing code from within the framework, as there are automated mechanisms for cleaning up tools and anything residing in memory. The attacker may also clean the contents from /var/log/* on Linux/Unix/Mac operating systems, or wipe out the Event Viewer database on Microsoft systems. To mitigate, organisations can leverage logging servers (e.g, SYSLOG) to send security-relevant messages and information to a central host. This will help make the attacker's job harder when covering their tracks if the log events are stored on another system or part of the network that they don't have access to.