Skip to content

McHughSecurity

  • Home
  • Blog
  • Security Operations
  • DFIR
    • Reverse Engineering
      • Dynamic Analysis
      • Static Analysis
  • Vuln. Mgmt
  • Intelligence
    • Open-Source Intelligence
    • Threat Intelligence
      • AIL Framework
      • MISP – Open Source Threat Intelligence Platform
      • OpenCTI
  • Threat Modelling
    • Attack Libraries
    • Attack Trees
    • Mitigating Techniques
    • SaaS Threat Modelling
    • Threat Models
    • Tools
    • Validating Threat Mitigations
  • Toggle search form
  • Extracting RAM from VirtualBox session Digital Forensics & Incident Response
  • [Part 4] Building a Threat Integration and Testing Lab – MISP Threat Intelligence Sharing Platform Build
  • Auto-updating Ubuntu 20.04 in less than 2 minutes Operate
  • OSINT for Threat Intelligence Blog
  • TheHive 4.1.0 Deployment and Integration with MISP Build
  • Building a Cuckoo Sandbox Build
  • Building Structured Threat Intelligence (STIX) from FBI notices MISP - Open Source Threat Intelligence Platform
  • Using the Course of Action Taxonomies in MISP MISP - Open Source Threat Intelligence Platform

Building CCCS’ AssemblyLine for Static Analysis

Posted on July 12, 2021 By A.McHugh No Comments on Building CCCS’ AssemblyLine for Static Analysis

System Requirements

For this build, I will be deploying AssemblyLine on my bare-metal hypervisor exposed to the Internet. This is not always a good idea, however, my build will be further hardened by additional controls which I will explain in subsequent articles within this series.

The virtual machine I will be using is Ubuntu 18.04 Server and has been allocated 8 vCPUs, 16GB of RAM, a 16GB Host partition, and a 128GB /var partition.

Partition layout for AssemblyLine

It is worth noting though, CCCS recommends a much beefier system configuration to run this platform. However, I have had success in operating it on a much smaller configuration.

Prerequisities

First of all, since I will be making this VM internet accessible, some very fundamental hardening must be performed on the host. For this, I will be using the following hardening script to provide a solid base Operating System.

sudo apt update -y && sudo apt upgrade -y
sudo apt-get install curl apt-transport-https ca-certificates software-properties-common cockpit firewalld -y

I tend to use Cockpit when it comes to system administration remotely, you can however choose to omit this requirement if you are not comfortable with using it.

Installing Docker

AssemblyLine relies on Docker and Docker-Compose to pull, build and run the platform. So we will need to install Docker-CE, Compose, and add the current user to the Docker user group.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update -y
sudo apt install docker-ce -y
sudo usermod -aG docker $USER
sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

After downloading and chmod’ing docker-compose, you may need to logout of the current user, and then re-login so that the appropriate permissions can be applied.

At this stage, this would be best achieved by rebooting Ubuntu gracefully using ‘sudo reboot’.

Installing AssemblyLine

AssemblyLine can be installed as a fully functional appliance once the Git repository has been cloned. In addition, an SSL/TLS certificate will be required to enable the HTTPS service. In the meantime, we will use a self-generated key and certificate, however in subsequent articles, we will be generating a LetsEncrypt key and certificate and having that key auto regenerate.

cd /etc/
sudo git clone https://github.com/CybercentreCanada/assemblyline-docker-compose.git
cd assemblyline-docker-compose/full_appliance
openssl req -nodes -x509 -newkey rsa:4096 -keyout ./config/nginx.key -out ./config/nginx.crt -days 365 -subj "/C=CA/ST=Ontario/L=Ottawa/O=CCCS/CN=assemblyline.local"

Further to this, the contents of .env and ./config/bootstrap.py will need to be updated with your intended hostnames, usernames, and passwords.

A word of warning: When setting the initial usernames and passwords for AssemblyLine, try to avoid using special characters. The build may fail when using special characters which are incorrectly parsed as part of the installation.

Now we can pull the containers, and start the services.

docker-compose pull
docker-compose up -d
docker-compose -f bootstrap-compose.yaml pull
docker-compose -f bootstrap-compose.yaml up -d 

Configuring AssemblyLine

Now that AssemblyLine is running, it can be logged into for the first time using the credentials you have configured within ./config/bootstrap.py.

First login for AssemblyLine

Out of the box, AssemblyLine is ready to start performing static analysis tasks. There are however some elements that should be considered for keeping this appliance operational, some of which are identified within the Troubleshooting AssemblyLine section of this article.

Troubleshooting AssemblyLine

Disk Full Errors

Eventually, your installation of AssemblyLine may start to consume disk space, at which point logging errors from Elasticsearch may occur (when you have less than 10% disk space left). These repeated errors are committed to logs, and actually accelerate disk space usage and cause Elasticsearch to fail eventually. Thus causing other docker containers to generate more logs pertaining to Elasticsearch not being contactable.

To alleviate this, we can implement log pruning for docker containers to keep those log sizes down.

Related

Static Analysis Tags:assemblyline

Post navigation

Previous Post: Hardening TheHive4 and Cortex for public deployment
Next Post: Deploying MISP on DigitalOcean or Vultr Cloud Hosting

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

ten + two =

Recent Posts

  • Auto-updating Ubuntu 20.04 in less than 2 minutes
  • Feeding Analysis Information Leak (AIL) Framework
  • An Introduction to Threat Intelligence
  • Deploying MISP on DigitalOcean or Vultr Cloud Hosting
  • Building CCCS’ AssemblyLine for Static Analysis

Search

Recent Posts

  • Auto-updating Ubuntu 20.04 in less than 2 minutes
  • Feeding Analysis Information Leak (AIL) Framework
  • An Introduction to Threat Intelligence
  • Deploying MISP on DigitalOcean or Vultr Cloud Hosting
  • Building CCCS’ AssemblyLine for Static Analysis

Archives

  • April 2022
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • September 2020
  • April 2020
  • March 2020
  • January 2020
  • May 2019
  • An Introduction to Threat Intelligence Threat Intelligence
  • Deploying MISP on DigitalOcean or Vultr Cloud Hosting Frameworks
  • Implementing Elastic Cloud and using Elastic Security Build
  • Building a Cuckoo Malware Analysis Server Digital Forensics & Incident Response
  • [Part 1] Building a Threat Integration and Testing Lab Build
  • [Part 4] Building a Threat Integration and Testing Lab – MISP Threat Intelligence Sharing Platform Build
  • Exporting Maltego Graphs to MISP Intelligence
  • Using MISP in a TraceLabs Missing Persons engagement Blog

Categories

  • AIL Framework
  • Blog
  • Build
  • Design
  • Digital Forensics & Incident Response
  • Frameworks
  • Intelligence
  • MISP – Open Source Threat Intelligence Platform
  • Open-Source Intelligence
  • Operate
  • Security Operations
  • Static Analysis
  • Threat Intelligence

Copyright © 2022 McHughSecurity.

Powered by PressBook News Dark theme