Name | Last modified | Size | Description | |
---|---|---|---|---|
Parent Directory | - | |||
README.html | 2023-01-21 11:47 | 17K | ||
README.md | 2023-01-21 11:47 | 12K | ||
botnet-capture-20110818-bot.html | 2015-05-14 12:34 | 357K | ||
botnet-capture-20110818-bot.json | 2015-05-14 12:34 | 7.0K | ||
botnet-capture-20110818-bot.pcap | 2011-08-18 15:37 | 66G | ||
bro/ | 2017-04-17 12:52 | - | ||
capture20110818.binetflow.2format | 2017-05-08 20:39 | 308M | ||
capture20110818.pcap.netflow.labeled | 2016-08-02 08:42 | 489M | ||
capture20110818.truncated.pcap.bz2 | 2015-07-21 10:22 | 596M | ||
detailed-bidirectional-flow-labels/ | 2016-08-02 09:11 | - | ||
ralabel-flowfilter.conf.generic | 2014-07-18 10:21 | 714K | ||
rbot.exe.zip | 2015-12-16 10:28 | 106K | ||
Probable Name: RBot
MD5: 2467b3c8b259cecd6ce2d5c31009df10
SHA1: 915934b43d63dc4040af3ea1ee6c80913288ff3b
SHA256: dcf50510efec16ff10c5aed91c8e386aba114e63842caa16ea40cac776c60816
Password of zip file: infected
Duration: 5 hours, 8 minutes and 0 seconds
RobotHash
capture20110818.pcap
It is a pcap capture with all the traffic (background, normal and botnet)
This pcap file was not made public because it contains too much private information about the users of the network.
This file was captures on the main router of the University network.
botnet-capture-20110818-bot.pcap
Capture with only the botnet traffic. It is made public.
This file was captured on the interface of the virtual machine being infected.
capture20110818.pcap.netflow.labeled
This file has the netflows generated by a unidirectional argus. The labels were assigned as this:
- First put Background to all the flows.
- Put LEGITIMATE to the flows that match some filters.
- Put Botnet to the flows that come to or from the infected IP addresses
bro
detailed-bidirectional-flow-labels
*.html
*.json
*truncated.pcap.bz2
- Infected hosts
- 147.32.84.165: Windows XP English version Name: SARUMAN. Label: Botnet. Amount of bidirectional flows: 9579
- 147.32.84.191: Windows XP English version Name: SARUMAN1. Label: Botnet. Amount of bidirectional flows: 10454
- 147.32.84.192: Windows XP English version Name: SARUMAN2. Label: Botnet. Amount of bidirectional flows: 10397
- 147.32.84.193: Windows XP English version Name: SARUMAN3. Label: Botnet. Amount of bidirectional flows: 10009
- 147.32.84.204: Windows XP English version Name: SARUMAN4. Label: Botnet. Amount of bidirectional flows: 11159
- 147.32.84.205: Windows XP English version Name: SARUMAN5. Label: Botnet. Amount of bidirectional flows: 11874
- 147.32.84.206: Windows XP English version Name: SARUMAN6. Label: Botnet. Amount of bidirectional flows: 11287
- 147.32.84.207: Windows XP English version Name: SARUMAN7. Label: Botnet. Amount of bidirectional flows: 10581
- 147.32.84.208: Windows XP English version Name: SARUMAN8. Label: Botnet. Amount of bidirectional flows: 11118
- 147.32.84.209: Windows XP English version Name: SARUMAN9. Label: Botnet. Amount of bidirectional flows: 9894
- Normal hosts:
- 147.32.84.170 (amount of bidirectional flows: 10216, Label: Normal-V42-Stribrek)
- 147.32.84.134 (amount of bidirectional flows: 1091, Label: Normal-V42-Jist)
- 147.32.84.164 (amount of bidirectional flows: 3728, Label: Normal-V42-Grill)
- 147.32.87.36 (amount of bidirectional flows: 99, Label: CVUT-WebServer. This normal host is not so reliable since is a webserver)
- 147.32.80.9 (amount of bidirectional flows: 651, Label: CVUT-DNS-Server. This normal host is not so reliable since is a dns server)
- 147.32.87.11 (amount of bidirectional flows: 4, Label: MatLab-Server. This normal host is not so reliable since is a matlab server)
Please note that the labels of the flows generated by the malware start with “From-Botnet”. The labels “To-Botnet” are flows sent to the botnet by unknown computers, so they should not be considered malicious perse. Also for the normal computers, the counts are for the labels “From-Normal”. The labels “To-Normal” are flows sent to the botnet by unknown computers, so they should not be considered malicious perse.
We started the overall capture. Bandwidth is limited to 10000kbps on every vm.
We started the bot capture.
We started saruman
We started saruman1
We started saruman2
We started saruman3
We started saruman4
We started saruman5
We started saruman6
We started saruman7
We started saruman8
We started saruman9
I connected to the C&C irc channel from my non-public IP.
We infected saruman9
We infected saruman8
We infected saruman7
We infected saruman6
We infected saruman4
We infected saruman2
We infected saruman
We infected saruman1
We infected saruman3
We infected saruman5
We login and get some info. .login zarasa48 .sysinfo .netinfo
We started the UDP attack agains 147.32.96.69 .udpflood 147.32.96.69 100000 1500 10 161
We stopped the udp flood. Because we were getting too much fragmented packets. .udpstop
We started the UDP flood again using only 1000 bytes per packet. .udpflood 147.32.96.69 100000 1000 10 161
We changed the bandwidth to 100000kbps.
We stopped the attack.
We started the UDP flood again using only 1000 bytes per packet. .udpflood 147.32.96.69 100000 1000 10 161
We erase the bandwidth limit. But not change in the amount of packets was seen.
We stopped the attack.
We tried .synflood, ddos.syn and ddos.ack but they did not worked.
We used .icmpflood 147.32.96.69 1000
We put the bandwidth again in 100000kpbs
We stopped the icmp flood. It was successful! I can not ping the victim nor connect with ssh.
We start to stop all the vms.
We end stopping the vms.
—- 1 hour later… —-
We start to start the vms again. Bandwidth is still in 100000kpbs The vms are already infected with the rbot
We end starting the vms.
We login in the vms using IRC. .login zarasa48
We started the UDP flood attack again.
We changed the bandwidth to 1000000kpbs
We started the UDP flood attack again.
We stopped the attack because it seems not to be using the whole bandwidth
We started the UDP flood attack again.
We stopped the attack because it seems not to be using the whole bandwidth
We started the UDP flood attack again.
We stopped the attack because it seems not to be using the whole bandwidth
We changed the bandwidth to 10000000kpbs
We started the UDP flood attack again.
We stopped the attack because it seems not to be using the whole bandwidth
We changed the burst to 100kb and keep the bandwidth in 10000000kpbs
We started the UDP flood attack again.
We stopped the attack because it seems not to be using the whole bandwidth
We changed the burst to 100kb and the bandwidth to 100000000kpbs
We started the UDP flood attack again.
We stopped the attack because it seems not to be using the whole bandwidth
We changed the burst to 100kb and the bandwidth to 1000000kpbs
We started the ICMP flood attack again.
We stopped the attack because was using to much bandwidth i think. I can not ping the victim. I’m not sure that the attack really stopped…
We start to power off the vms.
We ended to power off the vms.
We start the vms again.
We end starting the vms again.
We changed the burst to 100kb and the bandwidth to 10000kpbs
We login into the vms.
We started the ICMP flood attack again. The attack is working but i can ping the victim without problem.
We stopped the attack by the IRC.
We start to power off the vms.
We ended to power off the vms.
We changed the burst to 100kb and the bandwidth to 100000kpbs
We start to start the vms.
We ended starting the vms.
We login into the vms.
We started saruman7 with the ICMP flood attack. 1000 seconds
We started saruman1 with the ICMP flood attack. 300 seconds only
We started saruman2 with the ICMP flood attack. 300 seconds only
I think here the attack was successful. No ping any more.
We started saruman5 with the ICMP flood attack. 300 seconds only
We started saruman with the ICMP flood attack. 300 seconds only
We started saruman4 with the ICMP flood attack. 300 seconds only
I manually restarted saruman7 because was going to continue sending packets. The rest of the bots stopped after 300 seconds.
We started saruman1 with the ICMP flood attack. 300 seconds only
We started saruman2 with the ICMP flood attack. 300 seconds only
We started saruman5 with the ICMP flood attack. 300 seconds only
At this point the attack was successful!!!!!!!! no ssh and no ping!!
The attack stopped by timeout.
We stopped all the vms
WARNING!! I think that due to a disk space outrun in the computer, the overall capture file ended early.
These files were generated in the Stratosphere Lab as part of the Malware Capture Facility Project in the CVUT University, Prague, Czech Republic.
The goal is to store long-lived real botnet traffic and to generate labeled netflows files.
Any question feel free to contact us:
Sebastian Garcia: sebastian.garcia@agents.fel.cvut.cz
You are free to use these files as long as you reference this project and the authors as follows:
Garcia, Sebastian. Malware Capture Facility Project. Retrieved from https://stratosphereips.org