How to Hack and Not Get Caught(blog.spiderlabs.com)
blog.spiderlabs.com
How to Hack and Not Get Caught
http://blog.spiderlabs.com/2012/12/how-to-hack-and-not-get-caught.html
18 comments
I'm not really surprised at that reaction.
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.
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.
"our site can't be hacked, it has an SSL cert!"
A company I worked for got pentested by QinetiQ, both pentesters were thoroughly nice guys and could probably have been blackhatters. They were very efficient, they left zero traces and avoid just going "We exploited X attack vector" and actually dug around the systems to see what they could get. If you hire a pentester get guys like that, as it's the closest you ever want to get to a real world attack.
But isn't it ironic that blackhats bent on data theft so rarely cause system outages?
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.
[1] http://news.ycombinator.com/item?id=4900688
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.
[1] http://news.ycombinator.com/item?id=4900688
For external interfaces I don't see a need to avoid portscans - they're popular enough on the open internet that it's not going to attract attention or deviate much from standard traffic.
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).[deleted]
[deleted]
[deleted]
Vilification of discovery scans in 2012. Weird.
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.
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.
<i> Assuming you've done the prep-work to ensure you get placed on a well-populated user desktop network</i>
This is a write up of attacking LANs from the inside, privilege elevation stuff. Only relevant for large networks obviously.
This is a write up of attacking LANs from the inside, privilege elevation stuff. Only relevant for large networks obviously.
sound more like "How to crack and Not Get Caught"
Step 1: Don't post to Hackernews that you hack into places
.. 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."
.. 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."
This seems to written for penetration testers who are actually paid to "hack into places" and have the consent of the system owner therefor are not breaking the law.
I'm sure he didn't even read the article.
I'm sure I did, but couldn't resist being a smartass
Ah, I thought perhaps this was going to be another link to this story: http://news.ycombinator.com/item?id=4910212
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...