Book now with code EOY2025
the_Grinch wrote: Sorry for the double post and thanks for that site!
JDMurray wrote: Actually, this video is from Defcon 15 in 2007. I would be nice if a few TE members were to look through the last few years of Defcon videos and post their "must watch" recommendations.
dynamik wrote: I'm in for that! I've been wanting to go through that ever since you posted it anyway. I just need to wrap this class up first
the_Grinch wrote: Not from DefCon, but great video that shows the power of social engineering!http://video.google.com/videoplay?docid=-6271800786378394176 38 mins long, but well worth it!
the_Grinch wrote: Weakest link in the chain is the person who sits behind the computer. I've always had an interest in social engineering. Sadly, not many schools out there that teach it! One of my professors wrote a course for it, but the college refused to allow it to be run.
the_Grinch wrote: You could in theory identify yourself as law enforcement and run that entire scenario.
dtlokee wrote: the_Grinch wrote: Also going outside of the previously agreed upon limits of a pen test is also illegal and could get you a heap of trouble. I try to advise clients it's in their best interest to not limit the test (an attacker would not have such constraints) but there are typically going to be systems they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens. My scenario is perfectly legal period, no mention of myself outright identifying myself as an LEA nor would this be performed if it wasn't spelled out. As for "unpentestable" systems. There isn't such a thing period. I find anyone who would label something that wouldn't be a true pentester. I've done work on mission critical systems running live taps which couldn't afford to be disturbed and were flaky. We were still able to modify our timing, methods to find the same holes we would have during the course of a normal machine. It all depends on your methods. Timing values could be adjusted, number or connections, or solely doing a bit by bit copy, then taking that copy and creating a replica would suffice most of the time. Its EXTREMELY important to look SPECIFICALLY at those systems since they're so invaluable. An attacker would never take a glimpse at a machine labeled gas-pipeline-mission-critical-machine.utility.com and say "Gee better pass this up, too mission critical for me" for any client whose concern was the availability, we'd work with it, but to get a full scope of the security posture, we'd need to see that machine, no ifs ands or butts
the_Grinch wrote: Also going outside of the previously agreed upon limits of a pen test is also illegal and could get you a heap of trouble. I try to advise clients it's in their best interest to not limit the test (an attacker would not have such constraints) but there are typically going to be systems they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens.
dtlokee wrote: I would really hope no one in an IT role would fall for that, plus I'm not sure if it is a good example of social engineering as it requires the CSO to initiate it. People always want to keep their boss happy. The oldest trick in the book is to simply put a key logger on your machine and call for tech support, wait for the admin to come out and log in with his/her credentials.
sexion8 wrote: dtlokee wrote: the_Grinch wrote: Also going outside of the previously agreed upon limits of a pen test is also illegal and could get you a heap of trouble. I try to advise clients it's in their best interest to not limit the test (an attacker would not have such constraints) but there are typically going to be systems they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens. My scenario is perfectly legal period, no mention of myself outright identifying myself as an LEA nor would this be performed if it wasn't spelled out. As for "unpentestable" systems. There isn't such a thing period. I find anyone who would label something that wouldn't be a true pentester. I've done work on mission critical systems running live taps which couldn't afford to be disturbed and were flaky. We were still able to modify our timing, methods to find the same holes we would have during the course of a normal machine. It all depends on your methods. Timing values could be adjusted, number or connections, or solely doing a bit by bit copy, then taking that copy and creating a replica would suffice most of the time. Its EXTREMELY important to look SPECIFICALLY at those systems since they're so invaluable. An attacker would never take a glimpse at a machine labeled gas-pipeline-mission-critical-machine.utility.com and say "Gee better pass this up, too mission critical for me" for any client whose concern was the availability, we'd work with it, but to get a full scope of the security posture, we'd need to see that machine, no ifs ands or butts I didn't say your scenario was illegal, but the subsequent one that was proposed (identifying oneself as a LEA would be.) Also many pen tests do have limits, period. I have advised clients against this but there are times when they just won't budge. If a company identifies a system or method outside the scope of the agreed upon pen test, and you use that method or preform a pen test against that system it now falls under illegal access/use of a computer system. Legally this is subject to the same laws as "hacking" into a system of a company that you don't have a pen test agreement with, period. I agree it is important to have an agreement without limits since an attacker will not have such constraints, but when you are working with people with little technical skill it can be an impossible sell if they are afraid a test will impact business operations. You also need to admit that when doing a pen test it is possible to cause issues with the system you are testing regardless of how careful you are. It's a double edged sword because the people who are best suited to provide an acceptable scope are the IT staff/administrators but they are the same people we don't want to be aware of a pen test because they will inevitably go and tighten their security policies.
dtlokee wrote: Also many pen tests do have limits, period. I have advised clients against this but there are times when they just won't budge. If a company identifies a system or method outside the scope of the agreed upon pen test, and you use that method or preform a pen test against that system it now falls under illegal access/use of a computer system. Legally this is subject to the same laws as "hacking" into a system of a company that you don't have a pen test agreement with, period. I agree it is important to have an agreement without limits since an attacker will not have such constraints, but when you are working with people with little technical skill it can be an impossible sell if they are afraid a test will impact business operations. You also need to admit that when doing a pen test it is possible to cause issues with the system you are testing regardless of how careful you are. It's a double edged sword because the people who are best suited to provide an acceptable scope are the IT staff/administrators but they are the same people we don't want to be aware of a pen test because they will inevitably go and tighten their security policies.
dtlokee wrote: Keep reading the part you want to read and ignoring the parts you don't. I said it is "important to have an agreement without limits", but I agree it is absolutely mandatory to have one otherwise your actions are now illegal. I am involved in the initial customer engagements and contract negotiation, I don't do pen tests. We do not bring in the team that is responsible for the pen tests to meet with the customers so there is no possibility of them being recognized during later pen test activities. We choose not to tip off the admins because if they are on heightened alert and securing their systems it does not represent a true measure of normal operating conditions. It's not a matter of making it less challenging for our team, just to ensure the results represent normal conditions. We noticed known security issues would be removed and then reapplied after the completion. Because these conditions didn't exist when the tests were done they didn't make it into the reports, and security policies could not be updated appropriately. Just how we choose to approach it, I am not saying it is the only way to do it. That is all I have to say about it.
dtlokee wrote: they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens.
sexion8 wrote: Personally, I prefer structured pentest in fact via the patenting process I have a patent coming out on a method to perform pentesting.
sexion8 wrote: To me, there is no cookie cutting what you spelled out was a black hat test, sorry it either is as realistic as possible, or its a skewed method of testing security.
sprkymrk wrote: So you have a patent pending for a structured process of pentesting, isn't that a cookie cutter method? And if it's not, then how does it differ with dtlokee's preferred method? Having a "preferred method" as a guideline from which to perform a pen test does not necessarily make it a cookie-cutter method, provided you allow for personal actions based upon findings. I'm not sure how you drew the conclusions you did on dtlokee's method based upon what he wrote.
We choose not to tip off the admins because if they are on heightened alert and securing their systems it does not represent a true measure of normal operating conditions.
but there are typically going to be systems they cannot afford to have compromised or the potential for a pen test against to take it offline which sometimes happens.
Use code EOY2025 to receive $250 off your 2025 certification boot camp!
