Blog

Famous detectives throughout history have always been thrown into cases. That’s the nature of their job—the situation to create the case occurred, and it’s up to Sherlock Holmes to follow a trail of clues to determine the solution. When you perform an internal network pen test, the nature of the work is similar, but there are a few things you can do to help these cyber “detectives” maximize your knowledge gained and action items moving forward. Schellman’s Pen Test Team is experienced, and we often get asked to perform this specific type of evaluation. Having gone into these sorts of engagements many times before, we want to share some helpful insight specific to this kind of test.

When it comes to cybersecurity, you can never be too careful—especially when it comes to placing your trust in those who help you understand and secure your environment.

Some might say a good decision is based on knowledge and not on numbers. 

Whether you’re considering engaging Schellman for a penetration test of some kind or you’ve already signed a contract with us for such, you’d probably agree that transparency benefits everyone.

Benjamin Franklin once said, “an investment in knowledge always pays the best interest.”

These days, Mac-based corporate environments can be likened to the Tooth Cave Spider.

Once again, we need to talk about Burp. At Schellman, we’ve talked about this tool before—on our penetration testing team, we use it a lot and it serves us well, including in our work with mobile applications. But that doesn’t mean there still aren’t situations where extra effort is required in order to get the job done. Our fellow pen testers all know that things evolve so quickly in our field that sometimes we must improvise a new technique to properly solve to the problems we run into. Stop me if you’ve heard this one before, but one such issue that we are seeing crop up more and more during mobile penetration tests has to do with intercepting traffic from an application. Each time we watch some of that traffic escape our data flow, we’ve found each instance difficult and puzzling, because it’s not a static problem—when it comes to intercepting traffic from mobile applications, the issues can range from common to complex. One of those trickier ones to troubleshoot as a tester is when you can see most of the general web traffic from the mobile device being tested as it goes to Burp, but you also see that none, or very little, of the traffic from the actual mobile app under test follows. When that happens, you probably also note that there are no TLS errors for the domain in scope in the Event log from the Burp dashboard, and that, at the same time, the app seems to be working well, performing requests and receiving data as expected—there’s no other problem, it’s just that some of that traffic has decided to shoot off to the Great Unknown rather than where you know it should be. Does that sound familiar? If you’ve been frustrated by this same problem before, welcome to the club. This article will seek to understand why this even occurs in the first place before laying out a potential solution we worked up to curb any traffic trying to escape your proxy. Read on, and next time said traffic tries to get away from you, you’ll be ready.

(And Why I Did It) For those of you who work in web application security, maybe you’re familiar with Burp.