Our customized threat modeling
identifies vulnerabilities within your
security posture that puts your
most valuable organizational and
client data — the crown
jewels — at risk.
Our security audits and vulnerability
assessments are based on industry
standards and best practices to assess
weaknesses in your cloud environment
and network, as well as mobile
and web-based apps.
Our sophisticated testing services
delve into your network, smart
devices and other systems
to expose critical security
deficiencies.
My standard testing process takes some a little work upfront, but I’ve found it’s easy to work with after the initial setup and is the most efficient way for me to manage different projects.
First off, I typically funnel my traffic through a single egress point. Depending on the project, that might be a Kali box deployed at a client site, in a cloud instance, in my office lab, or even locally. Having multiple options available means I can be prepared for firewall restrictions or other networking requirements.
While I use the command line over SSH for most of my interactions with the attack box, I prefer to run any thick clients on my workstation with the network traffic still flowing through the attack box. For Kali programs, such as DirBuster, I leverage the X Window System (X11 / X) to tunnel the GUI over SSH to my local system. To do this, I simply connect to my kali box like this:
$ ssh brkr19@kali -XC
The -X
parameter enables the X tunneling and the -C
option compresses the data to hopefully speed it up a little. No matter what you do though, it’s still going to lag quite a bit.
I use Firefox for most of my web testing, but proxy everything through Burp so I have a record of it and can easily replay attacks or modify requests. Everything from Burp is then proxied over an SSH port-forwarded connection to a Kali box, which then makes the HTTP connection directly to the system I’m assessing.
The proxy connection is simple:
$ ssh brkr19@kali -D 8081 -fN
The -D 8081
parameter just sets what port will be listening on your localhost and the -fN
parameters run the whole command in the background and then returns back to your command line.
Burp can then be configured to use this SOCKS proxy in the Project Options tab (be sure to use localhost for the host):
Finally, in order to get Firefox to use Burp as its proxy, I use the FoxyProxy plug-in and send traffic to localhost on port 8080 (the default listener in Burp).
All browsing through Firefox will now be captured in Burp, and appear to have originated from the Kali box!
Please share this post if you found it useful and reach out if you have any feedback or questions!
You might not know how at-risk your security posture is until somebody breaks in . . . and the consequences of a break in could be big. Don't let small fractures in your security protocols lead to a breach. We'll act like a hacker and confirm where you're most vulnerable. As your adversarial allies, we'll work with you to proactively protect your assets. Schedule a consultation with our Principal Security Consultant to discuss your project goals today.
© 2024 FRACTURE LABS, LLC ALL RIGHTS RESERVED