No Tech Hacking

Great video!
http://video.google.com/videoplay?docid=-2160824376898701015&ei=-Q-eSMDXGpCYrALU77Qf&q=no+tech+hacking
http://video.google.com/videoplay?docid=-2160824376898701015&ei=-Q-eSMDXGpCYrALU77Qf&q=no+tech+hacking
WIP:
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
Comments
i hack stuff
MCSA:03/08/12/16 MCSE:03s/EA08/Core Infra
CCNA
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
Forum Admin at www.techexams.net
--
LinkedIn: www.linkedin.com/in/jamesdmurray
Twitter: www.twitter.com/jdmurray
Oh, that wasn't what I was getting at. I just meant if you liked that video, you'd probably like the other stuff there.
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
Forum Admin at www.techexams.net
--
LinkedIn: www.linkedin.com/in/jamesdmurray
Twitter: www.twitter.com/jdmurray
-Larry Ellison, CEO, Oracle
Studying: SCJA
Occupation: Information Systems Technician
http://video.google.com/videoplay?docid=-6271800786378394176
38 mins long, but well worth it!
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
Wow this was very good as well.
I'm going to blockbuster after my class tonight to pick up "Catch me if you can" never saw it but have heard of it.
Thank you. Keep posting these interesting videos!!
-Larry Ellison, CEO, Oracle
Studying: SCJA
Occupation: Information Systems Technician
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
http://www.trutv.com/video/?id=870&link=truTVshlk
Chris is a pretty cool person as I've had the pleasure of speaking with him and he's extremely knowledgeable when it comes to security PERIOD. The methods used by Lares are often overlooked (social engineering, dumpster diving, etc.) Definitely worth seeing if you consider yourself a security engineer. I tried to mentor under him but he sadly reversed it on me and told me there would be nothing he could teach me via pentesting/technology... Bastid!. Seriously, he'd be one of the top guys I'd like on my team.
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
Social engineering isn't always something that can be taught. I believe someone needs to have it kind of ingrained in them to understand it. For example I went through a scenario as follows for an idea...
Upon being called to audit a company, while sitting in the client's conference room, we'd ask for the names of the IT personnel and ask to speak to them individually. We'd have the CSO call them in individually while telling the CSO NOT TO DISCLOSE who we were and why we were there...
Upon arriving in the conference room, either myself or a colleague would grab our portfolio out of our bag (see this link to understand why: http://tinyurl.com/NSAportfolio). We'd then begin to tell him that we were looking for a specific file in our investigation. Now mind you, nothing said or done is illegal, we haven't identified ourselves as anyone. We merely had the CSO bring individuals in. We'd then ask them to log into their account via OUR machines which were rigged.
Gone in sixty seconds I can guarantee you that I'd be able to get at lowest, 80% of people to comply with logging in through our machine. How insane, simple, quick would that be. People are and will forever be the weakest link in the security chain.
So ask yourself, your most senior person in IT calls you into a conference room. You have zero idea why, he doesn't tell you and you meet a half dozen or so complete strangers with legal pads telling you "you haven't done anything wrong, and we're not accusing you of anything. We're doing an investigation to find a particular file and we'd like you to log into your account. If you feel uncomfortable doing so we can also get HR if your CSO who just left wasn't sufficient" You're alluding to something sure, but never offering anything identifying you which WOULD BE illegal (impersonation). Guarantee you most would fold.
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
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.
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
really, really bad idea, that is a federal offense.
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.
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff
+1.
And as far as social engineering being ingrained rather than taught, well that applies to any carreer, doesn't it? You could place me under the best auto mechanic in the world to try and teach me that stuff, but if I am not mechanically inclined or if I have no interest, I certainly won't get much out of it.
Anyone remember a great movie on social engineering called "The Sting"?
http://www.answers.com/topic/the-sting
Firstly prior to anything being done, contractual agreements would be laid out. I disagree with it being "important" to have an agreement, an agreement is mandatory period. There is no in-between, no contract, no work period.
As for IT staffers/admins tightening up their security beforehand, either way it doesn't make a difference to me. The tighter the system, the more challenging it is from the pentester perspective. There is a misconception commonly about auditing/pentesting which sends fears down the spines of admins who know they're being audited. Everyone turns on their "Cover Their Ass" mode. As a pentester, I feel its best to take the NSA IAM approach and remind those involved that placing blame won't accomplish much. Far better to consolidate the energy and time spent on the blame game securing/addressing any issues found. Just an opinion.
As for causing issues doing a pentest, there is that possibility however, due care and properly trained penetration testing can avoid these issues. Its called education. The sloppy pentester will fire off dozens of tools and attempt unstructured attacks. In the end many will try to create an overblown report often generated by one of their tools. "We've found vulnerability X!". These are what I call the unprofessional inexperience pentesters. Toolmonkeys.
Depending on the type of pentest one is performing - Blind, Double Blind, Gray Box, Double Gray Box, Tandem, Reversal ... I personally prefer ISECOM's methods - these issues are to be addressed way before any kind of testing is done... However, let me take it a few steps back for those others reading this as well...
Prior to anything being done on any system, prior to any tools being discussed, even thought of, parameters MUST be in order before proceeding. Parameters include the type of testing to be done, contracts signed, points of contact addressed, etc., for this portion I PREFER the NSA IAM method: Pre-Assessment - Post Assessment - On Site. The pre-assessment phase will address all issues before any technical work is done. This includes specifying what kind of testing will be done.
Most companies I've dealt with prefer Grey Box tests:
Grey Box testing as defined by OSSTM: The auditor engages the target with limited knowledge of its defenses and assets and full knowledge of channels. The target is prepared for the audit knowing in advance all the details of the audit. A gray box audit tests the skills of the auditor and the preparedness of the target to unknown variables of agitation. The nature of the test is efficiency. The breadth and depth depends upon the quality of the information provided to the auditor before the test as well as the auditor's applicable knowledge.
Most companies with the budgets to allocate for penetration testing - which is costly - aren't exactly concerned with what a black hat would consider a risk, they're mainly concerned with the management, analysis, assessment and mitigation of risks. Their bottom line is effective security governance as opposed to what is new in 0day land and are we vulnerable to it. Most prefer executive reports detailing baselines, common core logics and topic. Speak with any CSO about 0day versus governance and you will find many CSO's will look like deers looking at headlights when it comes to 0day. They mainly deal with financial aspects of security versus the technical side.
As a pentester/security professional, its up to you to explain the differences in testing methodologies to your client during the Pre-Assessment phase. Your client must be made aware of what the possibilities are including a potential Denial of Service (and this does not mean ping of death) on their infrastructure. They have to be made aware of potential risks, this falls on you the pentester/security salesman/etc._in_your_company to make know. Even if your client asks for a Blind test (aka Blackhat/zero knowledge), they need to be aware of the risks beforehand. Whether the information is trickled down to their employees is another story. As long as you've made the issues known, you've got the contract signed, come to agreements, your job is to do as specified under contract. Blind/Blackhat... Sure. Oh, I took out your database, wasn't intentional, maybe now you can also look into your DRM. Anyhow, enough rambling from me
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.
There is no reading the part I want to read, there are facts, its not important to have agreements without limits, most of the times its mandatory when performing a black hat test. Its important to be happy, doesn't mean it's always achievable, its MANDATORY that you will have to deal with whatever you are dealt, important or unimportant. So when hired to perform these (what are supposed to be) realistic tests, a client should either know, or be informed as to the best extent you can perform this test. Sometimes it isn't even about technology most of the times. At times it may be best to emphasize the need for social engineering, in fact, as a business strategy it would make sense if you had intentions on offering training atop your testing.
As for your methods of choosing which test you want your pentesting team to perform, for me it's all spelled out beforehand, before I begin anything. Seems you prefer to hire out Blackhat/zero_knowledge like tests, yet you state "but they can cause a denial of service" if I read it correctly beforehand:
So what kind of realistic testing are the guys you hired performing? Your wording to me makes me infer an image of a martial arts expert who was hired to perform his fighting skills against someone yet he steps in the ring and says "ok wait, don't hit me too hard".
Personally, I prefer structured pentest in fact via the patenting process I have a patent coming out on a method to perform pentesting. To me there is outside and there is inside, many forget this little tidbit. When we perform our tests, we prefer to perform dual gray hat tests (one inside and one outside). We use the information correlated and prepare a variety of scoring methodologies to risks. Its often a mixture of CVSS combined with other practices used in the industry. We've had much success in getting a realistic view of what a malicious hacker would see attacking from outside of the network as well as inside the network. We've tested servers down to C2 level security when asked to do so and have pentested C2 level machines down to the physical locations.
I understand what kind of testing you prefer, and maybe its just my inference but it sounds unrealistic. If you're asking for a tiger team full scale test, zero knowledge, me being a hacker trying to get in, I will do my best to find a way in. I would have also explained to you beforehand the issues surrounding the testing (again), machines potentially becoming inoperable, and would have likely developed a strategy to test during optimal times. Optimal timing is also crucial in order to perform realistic testing. For example, I know many an admin who have time based rules who keep things rather lax during working hours. 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.
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.
The method going through patenting is based on how the test is conducted which is similar to performing grey, black and white hat tests all in one or intermingled. My inference on his words were based on his statements, re-read them, on the one hand he prefers a realistic test with zero knowledge, at the same time his wording eludes to him preferring to "avoid" certain systems out of fear they will be subject to a DoS (taken offline). How can a realistic test be performed if machines will be skipped. What kind of scope is gathered when a machine isn't tested, what realistic results do you have. Are the pentesters guessing whether or not the machine he doesn't want tested is vulnerable.
On the one hand he wrote:
On the other he stated:
So here I inferred: "We test all the machines without admins knowing because we want to see a real world view... BUT, because some machines can be taken offline during the course of the pentest, the customer might not want this. Bottom line, if you're not going to test them in this fashion, you're going to have skewed results, how realistic of a pentest is it.
Analogy time... Someone calls a plumber to check for specific leaks, there are certain pipes that might be more fragile than others. During the testing of the pipes, say the plumber had to use a certain tool to detect a leak. Before he begins his test to find the leak, you tell him not to test those fragile pipes even though THEY might be the cause of the leak.
So what did you really get for your money? Now if I were the plumber, I would explain to you the need for me to test those pipes anyway - as they could be the source of the problem. I would explain to you that I would do my best to ensure nothing happened during the course of my testing however, by not testing them, what am I actually doing for you at the end of the day.