Information Security News
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:
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.
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.
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:
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:
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.
We received information this port could be use by Web Service on Devices API (WSDAPI) or potentially various version of DVRs and NVRs.