How to Hack and Not Get Caught
blog.spiderlabs.com
blog.spiderlabs.com
I guess as someone who would be responsible for their network's general well-being, I'd probably rather have some checked boxes saying nothing on my internal network was listening with trivially exploitable (i.e. non-patched or badly configured) services and my passwords are at least a certain complexity and not variations of the 1000 most common as of $SOMEDATE.
That said, it should be pretty easy to setup the usual suspects for scan tools to be performed in a scoped manner to satisfy the need for checked boxes after an operator spends some time getting up close and personal with the target system. Those type of attacks are going to reveal more information about user training (looking at Joe User with important\ passwords.docx in My\ Documents) than simple network scans are likely to.
I wonder what the qualifications are these days for a pen tester at a commerical company...
Most people are looking for someone to perform a cover-your-arse paperwork exercise. By paying someone to port-scan their network, they can say "we receive regular security audits".
The fact that they haven't done a proper penetration test is immaterial.
We have no way of knowing this. If a blackhat smashes your system to crap, you won't know what caused it. Maybe things just broke. I once permanently lost a machine to the ping of death (the hard reboot was the straw that broke the camel's back) and only knew about it because the entire dorm got hit by the ping of death. If I had been targeted it would have just been the machine dying on me. Which happens to me anyway. [1]
But if the whitehat scans your system at 4:52AM and your system breaks at 4:52AM, then you will know exactly what happened.
And knowing exactly what ports are open is information that is really valuable to a client. An external audit can find what insiders are too busy to pay attention to.
I disagree. Port scanning, even externally, can be messy and still raise flags. Most are done as a single nmap shotgun effect. It is better to obfuscate better than i've seen most do. (eg: I'ts better to do common normal port ranges (and smart variants), distributed network, over a long period time).
I think it's kind of messy, and firewalls definitely can flag it. And I think over the next year as things like Storm will be more tightly wrapped into log analysis and firewalls for real time processing. (Think smarter honey pots and smarter / real time customized pattern recognition).Yes. Appstack is totally the way to go if you're an app pen guy. Shocking.
Portscanning not too useful in a whitebox pen assessment, sure.
Don't do it at all because blackhats "don't do that"? Not really. Just make sure instrumentation and response exists for both of these cases.
Pen guys don't want to perform an assessment of the environment to gauge targets but instead just break out the same kit for each engage? Sounds fine if it works for them and leaves more things to discover to the next crew that wanders through.
Sounds like more "pentesting isn't compliance" drum beating, which is both good and bad.
This is a write up of attacking LANs from the inside, privilege elevation stuff. Only relevant for large networks obviously.
.. Tongue in cheek commentary aside, the title comes off more like the content would be on par with the grugq's presentation on Opsec for hackers (http://www.slideshare.net/grugq/opsec-for-hackers).
The argument to never modify anything only holds true for pentesting, for a slightly more nefarious attacker it's not unheard of to actually do some system maintenance & configuration fixing to close holes behind them to prevent other attackers from gaining access through the same entry point. Increasing the system stability has a tendency to make people look the other way, it's far less likely that someone would say "Hey, that server has been performing better, let's see if it's been compromised."