We had a reader who sent an email to us tonight asking for some guidance when tearing into packets. They are wanting to expand their skills at packet analysis. Since Guy was asking for packets earlier in the evening, it was a timely question. For many of people, packets are a mystery. I think back many, many (its been a while) years ago when I first started looking at packets. I was so anxious to learn it and become really good at it but had no idea where to start. Over my years of looking at packets, I have become completely convinced that packet analysis is well and truly art form (and alot of learning). Each person will have their own style and approach to looking at packets and traffic. However, there are some fundamental things to start with.
The reader submitted an question and initial list of things he/she thought they should look at first. Im going to include that question and list, then add to it.
Question submitted from reader: What are the top 10 or so questions (what why ask) you would ask yourself when looking at packets you suspect contain evil? Two things with this question. First, the indicators you received, alerts, users calling, etc. are a good way to point yourself in the right direction of things to look at initially. Start narrow and work your way wider when looking at the packets. Second, I would modify the thought process when looking at packets. Dont automatically assume evil! Why you might ask? Because I have watched people try to force packets into being malicious in nature to support their theory, when in reality something was just broke or it was normal behavior! Yet they were convinced something evil was going on and had management all spun up. Look at packets from a clean slate of what are they telling you! Dont assume one way or other. The packets are innocent until proven guilty:) Heres a past diary example of suspicious behavior being normal:
Here is what the reader submitted:
- Look for what IP went to an IP of interest -- Who followed a link, uploaded some data, etc.
- Look for a file that was downloaded -- Looking for malicious files to see if machine got infected
- Look for when (time) a file was downloaded -- To see if data exfiltration or strange behavior started soon after
- Look for the dst IP and port used -- To review the data going out the door
- Check DNS TTL -- Low TTLs might be an indication of malicious intent or Flux botnet
This is really tough, because there are so many things that you can look for in packets. First and foremost, I cant stress the importance of learning normal!!! Once you learn normal, the abnormal just jumps out at you. The RFCs are a great place, but have coffee handy. There are alot of website that have good information about packets, but beware, I have ran across incorrect data too. Here are a few more things to look at. I can tell you why I look at it, but its the totality of information that helps you figure out what is going on.
- What protocol is being used? Are we dealing with TCP, UDP, ICMP? It will help focus where to start based on why you went looking in the first place. What made you suspect the traffic and what protocol would it use.
- Do you think the issue is at the application layer or is something going on in the transport layer? What are your indicators to help narrow your focus?
- Look at the source port -- Is it staying constant or is it changing? A source port should stay constant for each session, but change (usually incremental) for the next session. A constant source port can indicate a poor coding (or deliberate) in a tool or malware. It is a characteristic that might eventually help you ID what tool/malware it might be.
- Look at the sequence numbers -- Are they changing like they should or are they staying constant. etc), IPID/fragID (fixed or changing), flag fields (IP and TCP headers), etc. Any of the packet fields to see if the traffic is behaving normally. (if its a large capture, this is much more difficult and time consuming)
- If you use wireshark to do your packet analysis, it has some great features to give you statistics about your packet capture. This can help you find interesting pieces of traffic to start your analysis.
- Whats in the payload is always of interest. Sometimes, you find glaringly obvious things like: This program cannot be run in DOS mode which is a good indicator for an executable being downloaded.
As a note for my analysis approach, I like to line up fields up as much as possible. Sometimes a little work up front to do this pays off in a quick visual inspection of the data. You can see anomalies better.
Packet analysis is such a amazing, interesting and fun field of interest. I really enjoy seeing and understanding how other people approach the analysis. If you have any tips or advice for becoming good at packet analysis, please send them in! There are alot of young and old analysts out there who would appreciate it.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
(credit: Ron Amadeo)
Over the past half-decade, a growing number of ordinary people have come to regard virtual private networking software as an essential protection against all-too-easy attacks that intercept sensitive data or inject malicious code into incoming traffic. Now, a comprehensive study of almost 300 VPN apps downloaded by millions of Android users from Google's official Play Market finds that the vast majority of them can't be fully trusted. Some of them don't work at all.
According to a research paper that analyzed the source-code and network behavior of 283 VPN apps for Android:
- 18 percent didn't encrypt traffic at all, a failure that left users wide open to man-in-the-middle attacks when connected to Wi-Fi hotspots or other types of unsecured networks
- 16 percent injected code into users' Web traffic to accomplish a variety of objectives, such as image transcoding, which is often intended to make graphic files load more quickly. Two of the apps injected JavaScript code that delivered ads and tracked user behavior. JavaScript is a powerful programming language that can easily be used maliciously
- 84 percent leaked traffic based on the next-generation IPv6 internet protocol, and 66 percent don't stop the spilling of domain name system-related data, again leaving that data vulnerable to monitoring or manipulation
- Of the 67 percent of VPN products that specifically listed enhanced privacy as a benefit, 75 percent of them used third-party tracking libraries to monitor users' online activities. 82 percent required user permissions to sensitive resources such as user accounts and text messages
- 38 percent contained code that was classified as malicious by VirusTotal, a Google-owned service that aggregates the scanning capabilities of more than 100 antivirus tools
- Four of the apps installed digital certificates that caused the apps to intercept and decrypt transport layer security traffic sent between the phones and encrypted websites
The researchers—from Australia's Commonwealth Scientific and Industrial Research Organization, the University of South Wales, and the University of California at Berkeley—wrote in their report:
Read 3 remaining paragraphs | Comments
Starting Sunday (22 Jan 17), there was a huge spike this week against TCP 5358. If anyone has logs o r packets (traffic) that might help identify what it is can submit them via our contact page would be appreciated. This is a snapshot as to what was reported so far this week in DShield.
width:500px" />
Update 1
We received information this port could be use by Web Service on Devices API (WSDAPI)[2] or potentially various version of DVRs and NVRs.
[1] https://isc.sans.edu/contact.html
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa823078(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa385800(v=vs.85).aspx
-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
