Image
Reviewing a Client’s Web Traffic
If you’re using a proxy server to filter and secure your traffic (and you really should be!), you should hopefully already have logs of the web sessions that are leaving your organization. For scenarios where a proxy server isn’t available or practical, I’ve found web sniffing tools like Fiddler or mitmproxy particularly helpful. I’m confident that practically every security researcher has, at one time or another, tracked processes and associated web traffic using netstat and other similar tools (and/or used packet inspection tools which we’ll get to later). I’ve personally found that working slightly higher up the OSI model can deliver quick results that can help focus investigations. Using a web sniffing tool permits you to trace the specific web requests made by a host. Working off the back of an unexpected firewall alert with these tools can lead you to see in detail the unexpected web calls that could be leaking important data or insecurely sharing credentials – and having a log of behavior that you can easily evaluate can make identifying a responsible application and its activities that much easier. Whilst these tools aren’t primarily intended for security use, they are quick to set up and, since they may already be used by your DevOps team, there are benefits in the form of easier cross-team communication when verifying the behavior of an application.Simulating API Requests
A common point of egress for applications linked to the cloud comes in the form of an API request. While you can see web URLs in your firewall logs, it can be difficult to understand what is the expected behavior. This is where a web API testing application like SoapUI or Postman can come in handy. These tools allow you to create sample packets to test external APIs. If you’ve been using something like Fiddler from the section above, you may already have a payload from an existing session, but if you need to verify the response consistency or explore an API calls functionality, using one of these testing/debug tools can offer added insight into what’s going on. One scenario in which I recently explored using these tools involved verifying session expiry. A lot of web applications depend on an initial authentication trigger event and an associated reply with a token being granted in response. This same token is then used for subsequent API calls. In most cases, these tokens will expire after a specific period of time or when the application responsible for the call logs out, but in some cases, a poorly implemented API or application will leave tokens in a “lingering” state, resulting in logins that stay open and thus reducing visibility into what an application is doing. Being able to simulate these sessions can help you spot exactly how that login and logout is behaving and help to ensure correlated logs for an application interaction can be tracked back to a specific integration point.Getting Deep Down into the Packets
WireShark, Microsoft Network Monitor and similar tools are yet another method for getting the “real picture” about what’s going on with a host’s traffic. By sniffing at the interface level, it’s possible to spot and understand traffic in far greater detail than the previous two processes we’ve discussed above. And although it’s easy to get lost when there’s a lot of network traffic, I’ve found that packet inspection tools really come into their own once you get comfortable with their filtering options or with using “post analysis” tools to assess packet dumps. Once again, this is a scenario where you may be able to leverage a network/system administrator’s existing expertise since such tools are commonly used for troubleshooting general issues within your infrastructure. Alternatively, it can also be a great opportunity for security team members with existing knowledge of such tools to share their experience to the benefit of other teams. I know a few Windows admins who were previously very reluctant to explore packet inspection tools until a security researcher showed them a few quick “tricks.” They suddenly found themselves with another tool in their toolkit that they couldn’t live without!The How’s, Why’s and When’s of Cloud Security
Many of these tools are likely familiar to the teams working to develop or support on-premises and offsite infrastructure, but leveraging them for security insight shouldn’t be a large stretch for many. When something suspicious is happening on your infrastructure, it’s critical to have the tools (and the human bandwidth – although that’s a topic for another day!) available to get the technical details and log data in order to both validate security events as well as to help inform how to act appropriately. When I’m with clients, I find that building a forensic response approach is a key part of improving the security team’s operational models. For many, detection is the starting point (leveraging tools like vulnerability management, file integrity monitoring and security configuration assessments), but closing the loop with a robust and reliable response to detection events helps reduce false positives (increasing trust in the security team’s efforts), tighten security (by stopping bad actors sooner rather than later) as well as giving security teams the chance to really understand the threats that can occur. This is something that can be highly rewarding for the team members who are working hard to keep your infrastructure secure every single day.
