Hacking Basics Tutorial

9.1 Intro to Penetration Testing

Even though the title of this Virtual Training Company course is wireless hacking and security. We're really to talk about penetration testing for this course. Let's make a distinction between penetration testing and hacking. Now, although penetration testing is sometimes called ethical hacking, penetration testing is a formal assessment of a system, whereas hacking basically could be intruding, or interfering with a system, or stealing data, or something of that nature, for malicious purposes. It could also be for non malicious purposes, maybe curiosity, Maybe hacking for a cause or whatever but we try to make a professional distinction with penetration testing versus hacking. Now, vulnerability assessments basically are used to look at a system and say that a system has a particular set of vulnerability. And those are very notional and typically they're proven vulnerabilities, the basics of a vulnerability assessment is that it says well these are the possibilities that could happen, these are things that could go wrong. A penetration test, typically takes it one step further and attempts to exploit those vulnerabilities so that you can determine what the true risk is to the system. Because obviously, some vulnerabilities really aren't exploitable or have mitigations in place that will. Prevent them from being exploited. A penetration test will try to exploit vulnerabilities to determine which ones really are exploitable, so it gives you a better risk picture. Another thing that distinguishes penetration testing is its formality, the legal standing that a penetration tester has with the system owner and the law. Also ethics are a good discriminator for penetration testers versus hackers. Methodology is another discriminator. Frequently hackers are very all over Over the map and do things in a very disorderly fashion. Penetration testing requires a formal methodology. All these things separate through penetration testers, professionals, from mere hackers. Now let's talk about what wireless pen testing involves. We're probably going to look at scanning wireless networks obviously to determine what's out there We'll also capture traffic. And when we capture traffic, we're going to take this traffic and look at it and analyze it for weaknesses to determine if we can crack WEP keys or WPA keys and so forth. So we'll exploit those weaknesses as well. But we'll also report these findings to an authority such as the manager, the system owner, or whatever. Whoever's designated in our penetration testing agreement. Speaking of the agreement, Penetration testing typically requires written permission from the system owner. We don't just arbitrarily hack into a system just to prove it's secure and then show up own the system owner's doorstep and say, hey we hacked your system. And it doesn't look that good. You have to have permission to do these things. Otherwise, it could be considered against the law. Wireless pen testing also requires formal methodologies, processes and practices. They're developed well beforehand before the test. Penetration testers also develop a plan for test execution and a plan for contingencies and we'll talk about that a little bit later but contingency is essentially mean Things like what happens if the system unexpectedly goes down while we're testing it, what happens if the user suddenly need it and we're on the system testing it. Things like that. We have to be able to plan for those contingencies appropriately. Penetration testing processes and results are always very well documented We document everything we do on this system. The tools we use the actions we take and the results of those actions. Penetration testing is also distinguished by using acknowledge professionals that are both qualified and if required certified. We will use these kinds of people that have had proven ethics and proven skills and experience To perform penetration testing. We don't just go on a street and hire a 14 year old hacker who happens to know how to use a few cool tools. One important other thing about penetration testing, and this may be the most important thing of all, is penetration testing is performed with the mind set that we want to contribute To the security posture of the system in a very positive way. We want to perform testing on the system and let the system owners know what's wrong with it and what they can do to fix it. We don't want to contribute to the vulnerability of the system by simply just hacking it and destroying it, destroying data Damaging equipment, so forth. We want to contribute to this in a very positive manner. And that's what Penetration Testing is all about in general. We're also going to talk about here, in the next few sessions, Wireless Penetration Testing technologies, specifically how we test wireless networks. We'll also talk about some of the Tools, the planning, and other things that go into a successful penetration test. [BLANK_AUDIO]

9.2 Wardriving and Warchalking

Before we get into the details of wireless hacking hacking methods, preparation and so forth, let's discuss a couple of terms you've probably heard while doing Research for wireless hacking. Now these are techniques that are used by hackers, by casual Internet surfers and even sometimes by penetration testers. These terms are war driving and war chalking. And I'll I'll define them and then we'll talk a little bit more about them in depth. Now, war driving refers to searching for unsecured wireless access points, or wireless access points that aren't secured very well at all. And they usually are searched for by driving around with a laptop and a wireless antenna in your car really slowly Or even by walking around with a PDA or a tablet in your hand, searching for these access points. Now, once you find them, you would use what's called war chalking. Now, war chalking refers to the practice of marking these unsecured access points. With certain marks with chalk on the sidewalk or building nearly access point to tell others that they're there. Now, people war drive in the first place? For several reasons, but the big one is to get free Internet access. Everyone wants something for free. Malicious users or hackers also use war driving obviously to Finance secure wireless access points for more notorious purposes. Now, you drive by this wireless access points and when you get to arrange them, you're equipment will detect them, it will tell you they are unsecured, completely open Or even have weak security measures, like for example if they're using WEP. Now you're probably going to find a lot of unsecured sites in a very short distance, even within a city block, you'll probably find several that are either using WEP. Or, no security at all. Now, this is probably more prevalent several years ago than it is now, because people are getting more aware of using security with their wireless access points than they used to be. Typically, you'll ind wardriving and warchalking in larger cities or suburban ares, You typically won't find it in the countryside because wireless is far away from each other, and people aren't going to drive all that far out just to find a unsecured wireless access point. War chalking, as well, is also more prevalent in cities. And what happens is these war drivers or war walkers, however their mode of transportation is They mark unsecure access point with special symbols and other war drivers or war chalkers know what these symbols mean. They indicate to the other folks who are looking for unsecured wireless access points, that the points there, that it's not very secure. It may indicate the type, the speed of the access point, any security measures that exist. And in the other relevant info about the wireless access point itself, that way others don't have to do the war driving or war chalking, they can just look at the symbol and know that there is a free wireless access point there. Now again we don't see this as often as we used to when wireless networks first came out and most of them were unsecured. Or using something like WEP. We still see it every now and then, and wireless pen testers can use this, a, to see if people are scanning your networks and looking for that kind of thing. You might walk along outside of a business and determine if someone has war drove your network or war chalked your network. And you may also try to scan and see what you can see to determine. If they were able to detect your wireless access point and determine what security measures it has. Here's an example of some Warchalking Symbology here. And this is a picture courtesy of Wikipedia. But it basically tells you what the war chalk notation would look like. It have things that would indicate open node where there is open authentication, close node or even WEP and what the SSID might be and what is bandwidth might be. So you might see this symbology On sidewalks or buildings. You may have seen it before and not realized what it means. But if you're a penetration tester, look for these kinds of things and then you'll know if someone has been doing reconnaissance on your wireless network or your client's wireless network. You can also use these same techniques as well to determine How secure from the outside their wireless network is. [BLANK_AUDIO]

9.3 Methodology

In this part of the corse we are going to discuss wireless penetration testing methodologies. Now. we're really going to talk about this under the broader scope of penetration methodologies in general, because most of the same principles that you would use apply to a wireless penetration test. And you"ll find that Most of your thing, most of your events that you're going to participate in in terms of wireless penetration testing, aren't going to be focused on just that. Most of the time, wireless is going to be a portion Of a larger penetration test, and you may determine if you can access the wired network, and it's resources through the wireless entry points in the network, So, it's probably not going to be just going to be wireless, you may have those occasionally, especially if you are the system owner and you just want to test the different segments of your network at different times You might test server security one month and wireless the next month and so forth. Or you may have a full on penetration test for a client that involves several different levels and aspects. Eitherway, the testing methodology that we'll talk about is very generic and what you're going to have to do is some research And look at industry standard methodologies and come up with your own unique methodology that works for you and your clients. If you're the system owner, it's got to work for your system. Otherwise you could create a methodology that works for your specific clients. As long as you have one, that's the most important thing. Methodologies provide structure. They provide a framework for your testing, and procedures, and penetration testing activities. You typically just don't walk into a penetration test, and willy nilly start scanning around, just to see what you can see. That's a big mistake of a lot of novice penetration testers, is they plug in, And start scanning just to see what they can see. There's actually a method to the madness and this method will allow you to conduct a formal assessment to make sure you don't overlook different Avenues of attack and possible vulnerabilities that you might otherwise miss in an unstructured test. The methodologies that we talk about provides for comprehensive testing from end to end, from the beginning to end. So you want to use a methodology or a form of methodology whenever possible. Now there's some basic steps to all the different methodologies that are out there. And you'll find some variations. It depends upon which book you read, which professional publication, whether it's application penetration testing or network penetration testing. But they all have some very basic steps to them. And that's what we're going to discuss, is the basic steps And you can adjust this and use these as you see fit for your methodology. We have Preparation, obviously, and that's where you prepare for the test and make sure all the things you need to do to get ready for it are done. Your documentation, your equipment, personnel and so forth. And then there's Reconnaissance and that's where you actually Perform reconnaissance on the target network. And this could be done several different ways, obviously scanning, doing vulnerability scans, doing network scanning. You could also perform reconnaissance by looking up information on the network from public information sources.. Vulnerability testing is where you would actually scan for vulnerabilities, and determine what versions of operating systems you have on the network, what versions of configurations you have on the network, and form those versions, you would then look at vulnerabilities to see what are inherent to those different versions of things. Say, a different version of a Operating system may have different vulnerabilities or version of an HTTP server maybe have certain vulnerabilities that you're going to target. So it would do your research during this phase and then you proceed. To the next phase, actually attacking the system, penetrating or infiltrating it and accessing its resources. So, pretty much everything up to that pont is research, reconnaissance, testing, and then you'd actually do the attacks. Now as I mentioned, penetration involves a lot of different things. The main thing it involves is getting permission to test from the system owner. You'd also define your scope during that time, you'd get your tools together, define whatever goals you and the system owner have for the test. Reconnaissance again is determining information about the target network. And this could be done through passive and active means. Passive may mean researching on the Internet or doing social engineering to determine information about the network. Active would obviously mean things like scanning. We can also include foot printing and enumerating wireless networks. And that would mean that you might scan and determine where access points are, what frequencies they use, what SSIDs are out there. And even what clients attach to them. Now, as we mentioned, vulnerability testing involves scanning the networks for the vulnerabilities themselves, determining what vulnerabilities different operating systems and versions of software have. And then the penetration and access portion, where you actually attack, access the network. You can do things like elevate your privileges crack passwords use resources on the network and so forth. And in terms of wireless networks you may not be doing all of this on the wireless network itself. You may be trying to infiltrate the wireless network. To get to a wired network, so you can access these resources. For a wireless network you're typically concerned with getting the WEP keys, or WPA keys, so you can authenticate to a wireless system and then further extend your access into the network. So that might be your basic penetration testing methodology. And again, You're going to have to do some research and determine what your particular methodology is based upon your clients, your needs, the tools you're familiar with and so forth. [BLANK_AUDIO]

9.4 Goals

Now let's discuss wireless penetration testing goals. And the reason I think it's a good idea to discuss these things is when you're conducting a test, when you're planning it and executing it and even completing it, there are certain goals that you should have. You should go into this test knowing what your goals are and what they are not. So let's discuss those briefly. Wireless penetration testers have several overall goals, and they also have goals that they need to look at completing for each phase and stage of their methodology. Now these overall goals should be fairly common sense, and fairly easy to comprehend. One of the overall goals you should have is accessing the true risk of the system for the benefit of the organization You're doing this because you want them to know what the security vulnerabilities are and how they could be exploited. In other words, what the risk to the systems are, so they can fix those risks and make their system more secure. Another goal along those same lines would be to act in the best interest of the system. Its owners, its users and the entire organization you are working for whether that's your organization or the client's organization. So you always want to act in their best interest and don't do anything stupid, or anything of harmful to the system or the people in the organization. Another goal should be providing a comprehensive accurate risk assessment report. Obviously your report is the way you're communicate what's wrong with the network, the wireless network or the rest of the infrastructure And how they can fix it. So you want to fully disclose all the findings that you come up with. Don't leave anything out. Don't discount anything as minor. And also don't discount anything that you think that maybe they don't need to know. So full disclosure of all the findings. You also want to provide mitigations For any discovered risks that you find. Frequently most managers want the penetration testing team to come in with the problems and the solutions. So really you shouldn't just come in and say that the network is bad, you need to come in and say The network is bad but here's how you can fix it. You probably get more work that way from the organization if you do that. Now just as we talked about what the goals should be, let's talk about what the goals should not be and do not include And, the reason we go into this is because, some people have different ideas of what penetration testing is about. So, we need to tell you what it's not about, and what the goals should not be. You do not want to expose organization to further risk, so, don't do anything foolish or stupid that would compromise the security of the systems or the users That use them. So don't hack on the things you shouldn't, don't leave damage to the systems. Don't change things that shouldn't be change just because you think you can. Also another goal is not to make the organization look foolish or stupid. That's where professionalism intact come into play when you're communicating with the organizational personnel, with the managers, the systems owners and users even. You don't try to do things to make them look stupid or foolish. If the security of the system is not that great you figure out a way to tactfully tell them that. Another thing you don't do as a penetration tester is just hacking Willy-nilly into the network only for the sake of hacking. Your job is to discover vulnerabilities and risks to the system. Your job is not to prove that you're a super-hacker. So display your elite hacker skills is not one of the reasons why you are there. There is an old saying in the hacker world, if you are a good hacker everyone knows who you are. If you are great hacker no one knows you exist. So kind of keep to that particular rule and you'll be just fine. Always be humble with your client You also don't want to do damage to resources that you don't need to. obviously penetration has some lists that are associated with it. But you do as little damage as you can to the system within the scope that you've been given by the system owners. Now some penetration tests may happen where the system owner says I want you to do as much as you can To show me what the true risks are, and you need to let them know there could be system damage involved. But don't just do it for the sake of doing it. Let's talk about some methodology goals. And we're not going to get really into the methodology phases like reconnaissance and so forth. What their goals are we can pretty much figure those out. just through common sense and we've already discusses some. Lets talk about what some of the more detailed goals should be. Scanning for example. When you're scanning a wireless network, your goal should be to detect the wireless networks and their characteristics. You want to try to detect things like the BSSIDs Frequencies, channels, any security protocols such as WEP or WPA that they're using, and even the hardware addresses of access points and clients. Those are your goals from scanning. That's the information you want to get out of that phase. As far as capturing traffic, your goal is to capture enough traffic So that you can discern different things about it. You can discern what encryption is being used and possibly capture some WEP or WPA keys so you can analyze them later. You also want to try to capture unencrypted traffic if possible and any wireless access point management traffic such as beacon frames and so forth. You also have a goal of analyzing the traffic. And your goal out of that is to be able to analyze this captured traffic to break any keys that you get to pick out any information that might help you in the attack. And obviously unencrypted traffic if possible. So those would be your goals for this type of testing for this methodology.

9.5 Planning the Test

Now let's talk about planning the test. And planning actually is one of the most important steps you can take during a penetration test because if you don't adequately plan, things can go wrong or the test can turn out not quite as you expected. The planning involves several things and it's a coordination effort between you and the system owner and your team. The first and most important thing you have to do is get authorization from the person or entity or organization that owns the system. And this needs to be an upper level manager, someone with Legal authority to give you the authorization to perform a penetration test, because if you don't get that authority, basically, it's hacking and it's illegal and the right person has to be someone who can give you the authority to test. You can't or shouldn't be rather, just the low level system administrator o even a user, it needs to be a senior manager in the organization. Authorization. And when you get this authorization, it needs to be in writing. It needs to spell out several things. It needs to spell out the scope of the test. What you're actually going to be testing and not testing. Things that are off limits, things that you will be doing. It also may include things like time of day. You may be only allowed a test at certain hours Or at night when users are off the system or it's not performing business-related tasks. You also need to make sure this authorization covers liability. That's what's popularly called the get out of jail free card. And this liability clause in the authorization Will make sure that you can't be held liable if any damages result from the test because you're telling the system owner up front what damage could result and that they are not going to hold you liable because they know this up front. This will keep them from taking legal action against you or a court finding you legally liable for something. So make sure the authorization agreement covers this. You also need to negotiate with a customer and establish a good test plan. Now, you and your team will probably develop a test plan based upon the scope of the test that you and the system owner have agreed upon. And what you'll do is you'll list the systems, you'll list the order you're going to test the systems in, the tools you'll use. Typically i mean it may not go into great detail into how the test will go but it should be as close as possible. There will be variations obviously but it should get us close as we actually can to how the test you'll go, again the types of systems you'll test what you'll test what tools you use maybe the different attack techniques you'll use and so forth. And this plan is basically to guide you during the test, but it's also to give the system owner a little bit of, of a, reasonable idea of what's going to happen, because they may not know. Now, this test plan may be based upon full Knowledge of the network or very limited knowledge of the network or even no previous or disclosed network knowledge. It may be what's called a white box or gray box or black box test and those are varying degrees of knowledge a **** test team has about the network. And that's done basically to see if the pen test team can discover vulnerabilities and things about the network without knowledge of it. So, those kinds of tests are done all the time. You also want to prepare your equipment and your personnel, and that means making sure you have the right people and the right tools to do the job. The people testing should be professional. They should have certain levels of experience. Both with the tools are going to use and the systems that are going to be tested. They should also be qualified obviously with the right schools, the right degrees and if required, the right certifications. You should also make sure that you have all the right equipment, obviously. Now coordination is very important. You're going to have to coordinate with the site personnel and the system owner before starting the test. And that typically means coming on to the site, letting them know, hey we're about to start testing. Make sure that there any issues that are out there are ironed out before you start testing. Make sure you have full access to the system. You may want to plan for some system downtime occasionally. If there's scheduled downtime already on the books for the system. You also need to know when the system is not available for testing for whatever reason. Maybe peak hours, for example, when the customers need the system, or when it's running reports, for example. You need to know those things. Finally, before your test, you need to double-check all your plans, your authorizations, your Your equipment, your personnel, once again to make sure you have everything done, and all your i's are dotted and t's are crossed. You need to plan for contingencies, and that's very important in the planning process because unexpected things Things can happen. You may have unexpected system uptime requirements. Maybe the users need the system during the time you were going to test and now you can't have it, so you have to plan for that. Maybe your scope changes, you hope that it doesn't but at the last minute a manager or assistant administrator may come up to you and tell you that there's been a change a certain system or part of the system is not available Or even is available. And you may be required to test it. You may have to deal with unhappy customers or managers. Typically most people won't know that you're testing. But if they do or when they find out, they will find a way to blame you for everything that's happened on the network since you began testing or a month before that. So if they lose data for whatever reason, or if the system isn't responsible for whatever reason They're typically going to blame it on the penetration testing team. Just be prepared for that and document what you do and be able to respond to the system owners and customers about what you've done and how it should of affected the system. But, on the other hand, be prepared that sometimes you will do things that will affect the system. So that's a possibility as well. Watch out for it. You may also have to deal with things like. Unavailable personnel, someone gets sick and cant show up, or a piece of equipment gets lost in shipment, out to the side, or it stops working. So, there's all kinds of contingencies that can happen, and you need a plan for them. Extra equipment,trained personnel who can do multiple jobs, and so forth. So just be prepared for it, because things will go wrong, Even in the best planned out penetration test. [BLANK_AUDIO]

9.6 Conducting the Test

Now let's talk about actually conducting the test. We've planned for it, we've got our methodology, we've got our personnel and our equipment and we've got our agreement with the system owner. So now we just have to do it. The first thing you need to do is actually carry out your test plan from beginning to end. The reason I say that is, often plans are made and then penetration test arrive on site and the plan goes out the window. Either because of something on the customer's end or the penetration test lead simply doesn't feel like the plans are adequate and they watch changes at the last minute. Try to resist that urge if at all possible, carry out the test plan as written. Now, obviously it's not in stone. You are going to have to adjust as you need to. You're going to have to adjust with a personnel obviously, with the networks you 're going to test, with customers and so forth. Things are going to happen but try to carry out the test plan as written. Another thing that's very important to test is, you have to document all of the tools used, the actions you took, any exploit attempts. You need to timestamp these actions and, most importantly, you need to be able to document the results, whether they were successful or unsuccessful in terms of the attack. [BLANK_AUDIO] Now you need to check with systems personnel occasionally to make sure that the test is progressing as expected. They need to know that it is. They need to get that warm fuzzy that the test is going fine and everything is going the way that it was planned and they need to know of anything unusual that's happened that you've observed. Because sometimes things happen during a penetration test and they may cause things like system reboots and so forth. Or they may cause a system hang up or network utilization to go to the ceiling or just things like that. You need to be able to communicate with those folks and let them know what you're doing. And vice versa they will communicate with you to tell you if they see anything unusual on the network. Network. Another good practice to get into when you're conducting a test, even actually before it starts, is to backup configurations of systems that you're going to test. And typically that will be up to the system owner to do, but you may remind them of that. Or any files that may be altered during the test. You do this so that if things go wrong and you can't turn the original configurations back to the way they were, then you can restore them after the test completion. And that may be you doing it, or it may be the system owner that's doing that. But make sure that happens As we mentioned before communication with the site personnel, the system owner, the system administrators is very important. Let them know if anything I expected or possibly damaging happens to the system. the other thing with communication is, you probably need to ask occasionally if you need to make changes to the test plan, if something happens or if something comes up that you need to test out of scope. An additional system that you weren't aware of. Or system that was available and now its not, or was unavailable before and now it is and they want you to test it. And that obviously requires more resources, time, personnel, and so forth. So if there needs to be changes to the test plan. Coordinate that not only with system administrators your working, but with the managers as well. Some other little tidbits about conducting the test that will help make it very successful. This sounds like common sense and it is but not everyone practice this common sense. And that's put everything back the way you found it. And I don't mean just tables and chairs and things like that on the side, although that's important to I mean things like computer configurations, passwords that were reset, accounts that were created. If you did things like create an account on the system during the course of your penetration testing to elevate your privileges, you need to let someone know that so they can undo that or you need to undo that if you're given permission to. The bottom line is put all the configurations to all the systems back the way you found it. Typically a penetration tester is not there to fix problems. They're there to identify problems and recommend solutions but not to actually fix them. You maybe requested to provide an outbrief to the system's personnel and their management And if so be prepared to do that and an outbrief is usually something not very formal something quick prior to the data analysis you know just general observations. They may ask for this because they simply want to know how they did. You might want to be prepared to do that without going into great detail [INAUDIBLE] As far as the detail goes, that's going to come later when you provide written report to managers and systems personnel. You probably want to include an executive summary in there so that the managers can understand it and make it so it's not too technical. But, you also want to add a section in there that is technical that discusses. Findings obviously details or actions on what the result were. Most penetration testers that get asked to return do more work. Other ones that also offer solutions were appropriate. Again you're not there to fix the problems but you are there to recommend solutions. So as part of your report, offer those mitigations for the problems you found. And lastly, it's probably a good idea to schedule a re-test, after any problems you found are fixed or any mitigations are applied. And the system owner will typically take care of that and ask you to come back if you did a good job, and they were Place with your work. So, that's why professionalism is very important and we'll discuss that a little bit later. But obviously, you want to try to get back with the customer and follow up as much as you can. [BLANK_AUDIO]

9.7 Professional Conduct

The next top we'll discuss [SOUND] to conclude our penetration testing methodology, and preparation discussion, is professional conduct. Now this may seem like an unnecessary thing to discuss in a wireless hacking and security Course, but it's actually very important. Obviously you want to treat your customers with respect and you want to be hired back again to do more work, so professional conduct is probably the key to all that. The technical portion, knowing what to do, and when to do it, and how to do it, and what tools to use, is very important as well, but how you conduct yourself professionally Is probably as important or maybe even more important. So let's talk about this a little bit. The first thing I would tell you above all else, do no harm. And that means basically don't do any damage to data equipment, networks and so forth On purpose although anymore that is absolutely necessary during the test. Obviously the penetration test can cause issues and the customers need to be aware of that up front. But that doesn't mean the permission to try to go all out and try to destroy everything. The next thing I will tell you is be professional at all times, sometimes its difficult because you will have difficult Customers. The test will run all day, things will not go as expected but you gotta keep your cool about you and be professional. Another important thing is be discreet with your findings both the expected ones and the unexpected ones and by that I mean keep those things to yourself, only share things with the team. And if you're the team lead, only share those things with the people who need to know, the senior managers that hired you or any other designated personnel that you're authorized to discuss the findings with. Because understand this is sensitive information. Information. Frequently you may find things that you did not expect to find. Maybe a user that's doing something they should not have been or something like that. So you want to be discreet about those things and report those to the appropriate. Managers, not discuss those outside of the scope of the test. You also need to adhere to the test agreement. And by that I mean the agreement itself, the plan and the scope. Follow that test plan and that test agreement to the letter. Don't test things you're not supposed to be testing. Don't get outside that scope. Don't do things that you didn't tell the customer you were going to do. If social engineering was off-limits and the customer said that up front and it's not in the plan, Don't go behind their back and perform social engineering just to get the web password out of someone. Another thing I'll tell you is, nobody likes to show off and in keeping with professional conduct, we may be very technical. Testers, we know a great bit but we don't get out there and show off our skills. We try to be humble because ultimately we want to be asked back to do more work for the customer and show off to not to get return engagements. in a same token my advice is also to don't be arrogant or adversarial with the customers. And that includes the users who may not know what you're there for. It may include system administrators who haven't been briefed on it. Or it may even be managers, or team mates, whatever. Try to keep that relationship professional at all times and don't be adversarial with anyone. Don't get into an argument over the security of the system. Try to work very closely and carefully with the systems personnel during all phases of the test, before, during and after because that's where you're going to be getting your support and your coordination from. And again, it's all about being professional. Try to remember what your goals are for the test and what they are not. They're not to make you look like the greatest hacker in the world. They are to keep the system secure and to improve it's security by identifying risks. Though that mind, you should keep the security in mind At all times. Finally I would tell you also to create a professional looking report to turn in to the customer, make sure that it looks good, make sure it's edited for grammar, for spelling, style and make sure theres no mistakes and there mistakes are fact particularly. If you didn't do it, don't say that you did. If you did it, own up to it. So those are the things are professional that will help you get a return engagement. Make sure you return your reports in in a timely manner. That is expected because a lot of these things need to be fixed. Quickly so that the vulnerabilities don't stay out there forever. And if you don't turn in the report, the organization can't fix it. Be prepared to professionally brief and defend your report to any organizational customers, such as managers, system administrators, and so forth. Obviously, there's going to be some disagreement. They may say the risk isn't that grave or nah you can have possibly have done that. Be able to defend it was facts and show that what you believe to be the risk of the system is in fact the risk. So understand there's going to be some disagreement and understand that it's not up to you as the penetration tester it's up to the organization to take your report for what it's worth and act on it. Also follow up is a good thing when acting professionally. Make sure you follow up with the organization to make sure they continually understand the findings and the mitigations they have to implement to get those findings fixed. And obviously they may have further questions or need follow up work from you so that they understand these things and so they can fix the problems that they have. So all of this is part of being a professional penetration tester, in a wireless network or any other type of network really, for your own organization or for other clients or customers. So the goal is to treat the customer with respect Keep the system's security in mind and to get hired back again. So, if you act professionally you will achieve those things.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy