Cuckoo - Phoenix

Justin Borland, Greg Olmstead

Justin Borland

• Atomic Energy
• IT Security
• SparkIT Solutions
• Principal Operator, Partner
• BlackBerry
• Sr. SOC Analyst
• Equifax
• Technical Lead
• Barclays
• VP Cyberz

Greg Olmstead

• Software engineer for 13 years
• AECL Engineering Tools group
• Document and wiring management
• Citi Global Credit
• Real-time risk apps
• RBC Capital Markets
• Led global sales and credit trading engineering
• SparkIT Solutions
• Principal engineer, co-founder
• Thomson Reuters
• Lead engineer for Eikon Apps Development Framework

​

Some of our projects

• Salesbook/Tradebook
• Main sales and credit trading platform for all RBC salespeople and traders worldwide
• VLR
• Log consolidation, collection, and routing appliance for collection of logs and delivery to RSA Envision
• UVModbus
• Raspberry Pi-based device for long term collection of logs and data from Atlantium UV systems, with custom touchscreen interface for collection by site operators
• Used in 6 power plants across Canada & US
• Phoenix
• Cuckoo based malware analysis platform
• The subject of our discussion today!

​

Cuckoo Background

• Started using Cuckoo in mid 2011 at BlackBerry
• Spent a lot of time triaging binaries, finding C2, and then sinkholing the C2
• Infected systems would call home to the sinkhole, memory analysis was performed
• Mo binaries, mo problems
• Started working at Equifax October 2012
• Deployed Cuckoo within 2 months of starting

Why Cuckoo?

• Pros:
• Speed up the OODA loop
• Lower the bar for malware analysis
• Raise the cost to our adversaries
• Ability to track malware data over time
• Cons:
• Rich data was being wasted
• Correlation and integration was lacking
• Certain fundamentals were missing
• There was a good foundation to build on

Why Phoenix?

• Data wasn't being used to its' full potential
• You owe it to your data to analyze it
• Analysts were already at a workbench
• Why not do more with the data?
• Why not test and create controls where your malware and packets already are?
• Write controls for campaigns & families
• Decrease total time from malware sighting, to control triage, to control implementation
• Bring macro views to micro analysis views

Solving the underpants gnome problem

What's it look like?

Analyst workflow

• Malware is sent to Cuckoo (programmatically or manually)
• Malware is detonated, indicators are harvested
• Indicators are compared against existing production controls (Yara, Snort, Bluecoat, Tanium, Gold builds, etc…)
• If detect/prevent controls don’t exist, new controls should be created and tested within Phoenix
• Additional controls can be created for defence in depth
• Indicators are sent to TIP for actor/campaign mapping

Key new features

• TLP – auth & trust groups using Django
• Yara & Suricata hunting (honours TLP)
• Moloch integration (honours TLP)
• Per user Virus Total integration (downloading samples)
• TLDR – API to correlate host and network indicators
• 33 OpenVPN circuits in 23 countries
• Advanced Searching
• 31 different observable types mapped to 1 or more backend fields each
• Ability to perform host based searches and pivot to moloch network traffic

TLDR – Means what you think

TLDR Ctd.

Recents page

Advanced Search

Advanced Search Ctd

Advanced Search Ctd.

Advanced Search Ctd.

Send Search to Moloch

Analyze data in Moloch

Analyze data in Moloch Ctd.

Analyze data in Moloch Ctd.

Submit from VT to Cuckoo without touching the files

Start hunting your adversaries

• Use ReversingLabs / VT to Yara hunt families of malware/tradecraft
• Detonate their malware/tradecraft
• Map their delivery infrastructure
• Look for patterns, TTPs
• Write controls for builders, not samples
• Ensure that when your adversaries change, you are aware and adapt
• Collect, measure, & analyze data

Ubuntu Easy-button

• Installing dependencies
• Copying OpenVPN configs
• Installing Virtualbox
• Importing Vbox OVAs
• Adding Vbox interface
• Adding cuckoo user
• Setting up Fail2Ban
• Creating HTTPD certs
• Setting up Apache
• Setting up Docker Containers & Networks
• Setting up ES template
• Setting up init.d scripts
• Installing Moloch
• Editing user & root crontabs

Roadmap

Fast forward to Phase 3

Profit

Docker

• Containerized analyses for hunting
• Multi-processing
• Demonstrable performance improvements over standard multi-threading in Suricata and YARA
• Orchestration
• Potential to cluster and federate hunting nodes for scaling
• Enables easier move to different platforms, or cloud processing
• Separation of hunter dependencies from Cuckoo dependencies
• py-yara

​

Cuckoo in Docker

• Dockerizing Cuckoo modules
• Processing
• Web
• Etc.
• Orchestration of Docker containers
• Distribution of modules to cluster
• Centralized file orchestration for analyses
• Load balancing, High availability, High resiliency

​

Scaling

• Currently, Cuckoo is very single-system biased
• Some distributed functionality but largely undocumented and limited
• Our Roadmap includes dockerizing Cuckoo and plugins
• Potential serverless technologies for processing
• AWS Lambda, Google Cloud Functions
• Leverage cloud power without expensive heavy EC2 instances constantly running
• Requires function decomposition
• Migration can be done piecemeal

​

Contribution

• Github fork - now
• https://github.com/SparkITSolutions/cuckoo
• Contributing to legacy Cuckoo branch
• Upgrade to 2.0

​

​

Get rid of stuff like this...

Other Roadmap Items

• Improving UI
• Integration with MISP
• Integration with ES/Splunk
• Gamification
• Rewards for contributed controls
• Sponsored challenges

​

Your boss after your pitch

Q&A

Thank you!