Spam, Recon or ??: You make the call!!
One of my favorite things to see come in to the handlers list are packets. You gotta love packets! Doing packet analysis is like trying to solve a puzzle, but without all the pieces and not knowing what you are supposed to build. One of the things that you do have to be careful of is thinking that you've seen it all before. What do I mean by that? Well, what I mean is looking at traffic and you immediately tend to classify it into a category based on protocol and/or ports etc. For instance maybe its UDP traffic on port 53, just DNS right? Well, are you sure that's all that it is? I know it's not feasible to look at everything, but when alerts/flags are raised I think we have a tendency to go "oh that just......we see it all the time". But, did you actually look at it to be sure?
It has often been said that if you want to hide something, hide it in plain sight. It makes perfect sense. If you want traffic to get through, make it look close enough to something else that no one bothers to take a second look at it.
Today we got some logs submitted to us with some questions on the ICMP traffic. Even though it's not a packet capture, there was enough data to do some analysis. Here are the links to the files for your viewing pleasure:
http://isc.sans.org/diaryimages/icmpType3.log
http://isc.sans.org/diaryimages/icmpType11.log
It is interesting to note that several handlers looked at the traffic and many conclusions were reached. I won't share with you our conclusions at this time, but I would like to see what the rest of you come up with. Maybe you don't have an answer as to what it is (something you have to learn to accept when you analyze network traffic), but maybe you notice something unique about the traffic. Here is a short summary. ICMP error messages arrived at a host. However, that host did not have any outbound traffic that would have generated the ICMP error messages. Each of the error messages does contain the rough headers of the packet that caused the ICMP error messages. I'll post later the analysis done by some of the handlers and the results that everyone else came up with.
So, get ready to have fun and do some analysis!
It has often been said that if you want to hide something, hide it in plain sight. It makes perfect sense. If you want traffic to get through, make it look close enough to something else that no one bothers to take a second look at it.
Today we got some logs submitted to us with some questions on the ICMP traffic. Even though it's not a packet capture, there was enough data to do some analysis. Here are the links to the files for your viewing pleasure:
http://isc.sans.org/diaryimages/icmpType3.log
http://isc.sans.org/diaryimages/icmpType11.log
It is interesting to note that several handlers looked at the traffic and many conclusions were reached. I won't share with you our conclusions at this time, but I would like to see what the rest of you come up with. Maybe you don't have an answer as to what it is (something you have to learn to accept when you analyze network traffic), but maybe you notice something unique about the traffic. Here is a short summary. ICMP error messages arrived at a host. However, that host did not have any outbound traffic that would have generated the ICMP error messages. Each of the error messages does contain the rough headers of the packet that caused the ICMP error messages. I'll post later the analysis done by some of the handlers and the results that everyone else came up with.
So, get ready to have fun and do some analysis!
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments