Maltrail - Malicious Traffic Detection System
Maltrail is a malicious traffic detection system, utilizing publicly available (black)lists containing malicious and/or generally suspicious trails, along with static trails compiled from various AV reports and custom user defined lists, where trail can be anything from domain name (e.g.
zvpprsensinaix.com for Banjori malware), URL (e.g. http://109.162.38.120/harsh02.exe for known malicious executable ) or IP address (e.g. 103.224.167.117 for known attacker). Also, it has (optional) advanced heuristic mechanisms that can help in discovery of unknown threats (e.g. new malware).The following (black)lists (i.e. feeds) are being utilized:
alienvault, autoshun, badips, bambenekconsultingc2, bambenekconsultingdga, binarydefense, bitcoinnodes, blocklist, botscout, bruteforceblocker, ciarmy, cruzit, cybercrimetracker, dshielddns, dshieldip, emergingthreatsbot, emergingthreatscip, emergingthreatsdns, feodotrackerdns, feodotrackerip, greensnow, malwarepatrol, malwareurlsnormal, maxmind, myip, nothink, openbl, openphish, palevotracker, proxylists, proxyrss, proxy, riproxies, rutgers, sblam, snort, socksproxy, sslipbl, sslproxies, torproject, torstatus, voipbl, vxvault, zeustrackerdns, zeustrackerip, zeustrackermonitor, zeustrackerurl, etc.
alureon, android_stealer, angler, aridviper, axpergle, babar, balamid, bamital, bankpatch, bedep, black_vine, bubnix, carbanak, careto, casper, chewbacca, cleaver, conficker, cosmicduke, couponarific, crilock, cryptolocker, cryptowall, ctblocker, darkhotel, defru, desertfalcon, destory, dorifel, dorkbot, dridex, dukes, dursg, dyreza, emotet, equation, evilbunny, expiro, fakeran, fareit, fbi_ransomware, fiexp, fignotok, fin4, finfisher, gamarue, gauss, htran, jenxcus, kegotip, kovter, lollipop, lotus_blossom, luckycat, mariposa, miniduke, modpos, nbot, nettraveler, neurevt, nitol, nonbolqu, nuqel, nwt, nymaim, palevo, pdfjsc, pift, plugx, ponmocup, powelike, proslikefan, pushdo, ransirac, redoctober, reveton, russian_doll, sality, sathurbot, scieron, sefnit, shylock, siesta, simda, sinkhole_1and1, sinkhole_abuse, sinkhole_blacklistthisdomain, sinkhole_certpl, sinkhole_drweb, sinkhole_fbizeus, sinkhole_fitsec, sinkhole_georgiatech, sinkhole_kaspersky, sinkhole_microsoft, sinkhole_shadowserver, sinkhole_sinkdns, sinkhole_zinkhole, skyper, smsfakesky, snake, snifula, sofacy, stuxnet, teerac, teslacrypt, torpig, torrentlocker, unruy, upatre, vawtrak, virut, vobfus, volatile_cedar, vundo, waterbug, zeroaccess, zlob, etc. Architecture
Maltrail is based on the Sensor <-> Server <-> Client architecture. Sensor (s) is a standalone component running on the monitoring node (e.g. Linux platform connected passively to the SPAN/mirroring port or transparently inline on a Linux bridge) or at the standalone machine (e.g. Honeypot) where it "sniffs" the passing traffic for blacklisted items/trails (i.e. domain names, URLs and/or IPs). In case of a positive match, it sends the event details to the (central) Server where they are being stored inside the appropriate logging directory (i.e.
LOG_DIR described in the Configuration section). If Sensor is being run on the same machine as Server (default configuration), logs are stored directly into the local logging directory. Otherwise, they are being sent via UDP messages to the remote server (i.e. LOG_SERVER described in the Configuration section). 
Server 's primary role is to store the event details and provide back-end support for the reporting web application. In default configuration, server and sensor will run on the same machine. So, to prevent potential disruptions in sensor activities, the front-end reporting part is based on the "Fat client" architecture (i.e. all data post-processing is being done inside the client's web browser instance). Events (i.e. log entries) for the chosen (24h) period are transferred to the Client , where the reporting web application is solely responsible for the presentation part. Data is sent toward the client in compressed chunks, where they are processed sequentially. The final report is created in a highly condensed form, practically allowing presentation of virtually unlimited number of events.
Note: Server component can be skipped altogether, and just use the standalone Sensor . In such case, all events would be stored in the local logging directory, while the log entries could be examined either manually or by some CSV reading application.
Quick start
The following set of commands should get your Maltrail Sensor up and running (out of the box with default settings and monitoring interface "any"):
sudo apt-get install python-pcapy git clone https://github.com/stamparm/maltrail.git cd maltrail sudo python sensor.py 
