Get best of the week

How to successfully pass any pentest (bad advice)

If you urgently need to conduct a pentest,
while you do not want to get a nape,
then quickly see the
List of amazing tips prepared for you - it will certainly save you.


This post is written in a humorous manner to demonstrate that even pentesters , whose work should be interesting and fascinating, can suffer from excessive bureaucracy and customer disloyalty.

Imagine a situation: you are an information security specialist and you know that the protection you built is complete rubbish. Perhaps you don’t know this, but you don’t really want to check, because who wants to leave the comfort zone and additionally do something, introduce protective equipment, mitigate risks, and report to the budget?

Suddenly, in your kingdom of the Far Far Away, in the kingdom of the thirties, there is a need to conduct a pentest against your will, for example, something has become strange to the authorities, or a new requirement of the law has come up. It is obvious to you that it is worthwhile to find a “Sharashkin office”, which will do an imitation of work and write that everything is fine and the matter is over, but the situation is becoming more complicated. Your company decides to play a contest and do it as efficiently as possible: write a reasonable technical specification, present high demands on the Pentester team (certificates, participation in the Bug bounty), etc. In general, they did everything for you, and your responsibility is only to oversee the work.

So, the team was found, the contract was signed, persuading specialists to conduct a pentest after the sleeves did not work. Smart guys, they will start work on Monday and blast your information security, after which you grab a hat and your incompetence will be revealed. The situation seems to you the most deplorable, but there it was! Here are some bad tips on how to eliminate or at least minimize this headache.

Tip 1: coordinate each step


Coordinate everything: what tools can Pentesters use, what attacks will they conduct, what risks will this turn out for your IS system. Even better, request a detailed (almost hourly) test plan for each day. Rest assured: Pentesters will hate you. They think that they have creative work, but you will tell them that nothing is required of them except the trivial performance of work. And remember: your weapon is time, pull coordination as much as possible at every step. Reason this with the fact that you have a large company, and you need to get a lot of approvals: from system owners, from IT, from security officers, etc. Even if there are none, you can embellish something.

Was it real?


Yes, a large and mature business, and especially effective managers, not wanting to do it themselves, go too far with approvals so often that it demotivates the whole team. People don’t have a “drive” to work, a desire to be creative and really hack something. It is especially strange when only the “elevation of privileges” stage is agreed on a specific server on Tuesday from 15:00 to 18:00 (this is so easy and natural).

Tip 2: add more restrictions


Add restrictions on the work performed: by the number of simultaneous scans, by the allowed IP addresses, by operation and by acceptable attacks. Do not scan random IP addresses from subnets, explaining this as a risk to disrupt important business processes. Or, on the contrary, allow only some addresses to be scanned and claim that the results of scanning of one of the services can be extrapolated to all the others in the subnet.

Was it real?


Very often, at the internal pentest, instead of allowing pentesters to go through all local subnets (192.168 / 16, 172.16 / 12, 10/8), customers are asked to exclude that host, that subnet and this segment: “Here you need to test only one of 500 hosts as typical, and these hosts only from 5 pm to 9 am - no more than 300 TCP sessions per second per host. ” The fact that the work is designed for 5 days does not bother anyone. For the performer, this looks terrible: you can’t do normal automation, you need to constantly monitor that the tools do not go beyond the permitted boundaries, and you have to twist a bunch of “crutches” to all the tools. While scanning somewhere and collecting a list of services, it turns out that the lion's share of the time has already been spent. Also during development over the network you see: here it is - a service,which supposedly has a privileged account ... But he was excluded from the scan.

Tip 3: ask for more reporting


Alignment has already been discussed, but what about reporting? To enable people to calmly do work and provide a report at the end? No! Request reports every week, day, half day. Refer to the negative experiences of previous years and the desire to control the process for which they paid. Wow, how does it "put the sticks in the wheels."

Was it real?


This often happens. Even after 5 minutes, they begin to approach from behind a shoulder and ask: "Well, is that already hacked?" In the messenger, the status of the work is pulled every hour, and by the end of the day they are waiting for the final result for the manual, beautifully designed in a Word document. As a result, the specialist focuses on how to write a report, and not on the quality of testing.

Tip 4: ask to record traffic dump and write screen


Additionally, require the pentesters to record a screen and write a dump of network traffic. Justify this because you worry about leaking confidential information or leaving a backdoor.

Was it real?


Some customers turn on the paranoid mode and control every step you take. In truth, if it is really necessary, the pentester will definitely find how to get around the screen recording or generate the necessary traffic, and there is little sense in these measures, but they really interfere with the work.

Tip 5: communicate through three managers


Communicate through 3+ managers, thereby playing on a broken phone and increasing the time. Try not to bring the requirements directly to real performers, communicate through intermediaries, especially without experience in the applied part. As a result, we get such a steam locomotive that the information will either change or will go on for a very long time.

Was it real?


In large projects, this is more likely the rule than the exception. The security officer orders the work, the security officer oversees, and the manager communicates with the pentester, sometimes even not directly, but through his manager. As a result, even removing all other factors, any request reaches the goal after half a day and returns the answer to some other question.

Tip 6: hit the vanity


Remember that the main thing is people. Therefore, to reduce the quality of work, it is best to hit directly at them, or rather, at their vanity. Ask how they would test a little-known technology, and then say that they expected more. Add that a couple of years ago previous pentesters hacked your company in 2 hours. It doesn’t matter that the system was different then and there was no SZI, and you worked elsewhere. The main thing is the fact itself: since the pentesters did not crack in 2 hours, then there is nothing to respect them. You see that the pentesters sailed, - demand a replacement team without increasing the time.

Was it real?


We really often hear stories about old hacks, and this has nothing to do with the current infrastructure and information security processes. Questions about how secure this “know-how" technology is, are also not uncommon, you have to quickly understand and give a concise answer, which is not always enough.

Another interesting case: we have a pentester girl in our team, and when she comes to do an internal pentest, the customers are initially distrustful, and then go to look at her as an exhibit. Not everyone will want to work in such conditions.

Tip 7: Reduce Convenience


Work in a dark closet, where cell phone doesn’t catch? Work in noisy coworking? Broken and creaky chair? Broken air conditioner? In order to go to the toilet and drink water, you need an attendant? I think you already understood what to do.

Was it real?


Yes, and yes again. There were few desperate cases, but there are enough situations when you think not about work, but about how to quickly get out of here due to external conditions.

Tip 8: leave all proactive defenses on


We pass to technical jokes. Let PCI DSS and other methodologies recommend disabling some proactive SZI for more testing testing - you need to do the opposite. Let people suffer in search of a solution, how to quickly test a corporate network, where they are blocked all the time.

Immediately extinguish the port on the switch into which the pentester is stuck. And then scream loudly that the pentest is failed and chase the hated hackers from the object.

Was it real?


We are already accustomed to testing when proactive SIS (IPS, WAF) is enabled. It’s bad that in this case the lion's share of the time is spent on checking the information security system, and not on testing the infrastructure itself.

Tip 9: put in a special vlan


Provide unrealistic network access that does not match typical user access. Let there be nothing and no one in that subnet. And filtering rules will be deny \ deny or close to it.

Was it real?


Yes, somehow we were given access to a subnet with one printer and in network isolation from other networks. All work came down to testing the printer. As technical experts, we, of course, reflected everything in the report, but this did not change anything. There was a reverse situation when we hacked half of the company through a printer, but this is a completely different story.

Tip 10: work through a VPN


Conducting an internal pentest in a real room where the pentester can get a bunch of additional information (settings of a corporate phone, printer, eavesdrop on a lively conversation of employees, see the equipment through their eyes) is not your case. You need to carry out work, as if emulating an "internal intruder", and this "how to" interpret how it suits you. Therefore, provide access only through the VPN, and it’s better not to use the shortest route. In addition, make only L3 access, because network attacks at the L2 level are not relevant [sarcasm]. You can justify this by saving money: why should people go to you once again, take jobs, interfere with employees, if that's normal.

Was it real?


Yes, it’s quite normal to conduct an organization pentest through an under-VPN L3. Everything hangs, the channel becomes clogged, the tools perceive delays as unavailability of services, and there’s nothing to say about the impossibility of broadcast attacks and MITM. Yes, and after normal internal pentests with a Pentest on VPN, like running on the sand in the skates.

Tip 11: no gray box


Pentesters should not be given any accounts, any documentation, or any additional information, even if this is required by the contract. What good, it will come in handy for them to achieve results faster. Justify the fact that a real hacker (an image imposed in the media) will come and immediately crack everything. Bother - give the documentation ten years ago.

Was it real?


It seems that all the people “in the subject” understand that an attacker who is serious, will not sit down and try to hack into the system clumsily, he will first conduct reconnaissance, collect available information, communicate with people. If this is an internal intruder, then he already knows who, what, and where. The employee is inside the processes and has knowledge. But still, 80% of the pentests is a “black box”, where you have to come in 5 minutes, figure it out and crack it yourself, otherwise it’s not a “labor hacker”.

Tip 12: do not allow the exchange of information between different areas (internal, external and social)


Regulate disparate work, better by different specialists and strictly without transferring information between directions. Justify this by the fact that you need to accurately determine the risks for each area.

If “insider” information (obtained from inside) was used on the external perimeter for hacking, then in no case count such works, say that this is not interesting to you and does not correspond to the declared works. If the information obtained after "social engineering" came in handy for the internal pentest, also say that it does not count.

Was it real?


This is actually the approach of the classic pentest, the results of each testing are really required independently, as if a real attacker really does. But in fact, APT groups do not work like that.

Tip 13: tell everyone in the company that you have a pentest


Announce to the whole company that you have a pentest. Let everyone remove the stickers with credentials, no one opens the attachments in the mail and does not insert the found flash drives into USB. Employees with privileged access rights should go on vacation or study and turn off their computers, but most importantly, they will change their qwerty password to a random one (at least during the pentest). In general, activity within the company should be minimized as much as possible, and vigilance increased. Thus, you will significantly reduce the possibility of attacks aimed at workers and development within the network.

Was it real?


Well of course it was. You start work and you see that people are warned, recently changed passwords, they are suspicious of you. Some computers cannot be checked, because people in training are a “pure coincidence”.

Tip 14: Monitor Pentesters


Drop all your routine and just monitor the pentesters. Even if you do not have monitoring, try. As soon as you see that they have found something, immediately block access, change permissions, delete accounts, extinguish ports. If you really need to - fire people.

Was it real?


Oh, this is generally a "favorite." You tell the customer: “we will conduct a pentest and inform you about everything critical, only you don’t change anything, we are helping to find not just a specific flaw, but to reveal bad processes.” And as soon as you inform something, right there in the short term it “accidentally” changes. Here are a few real cases.

  1. SMB-, 5 , « » . , — , .
  2. , -. , « ». , , . « ».
  3. , RCE , , .

15: !


If for some reason the pentesters still managed to find a vulnerability, and they ask you for approval for its operation, do not agree; justify the violation of accessibility. This presentation laptop is a critical business service!

Was it real?


Yes, this also happens all the time. It can be seen that the server has critical data and there is a vulnerability, and the customer does not coordinate the operation. As a result, the contractor loses the entry point, which could pull a whole bunch of problems along with him, until the entire company is compromised. And if they haven’t agreed, the report simply says: “operation is not agreed upon,” and there is actually nothing interesting in the report.

Tip 16: pause work more often


For all IT incidents, say it's because of the pentest, and pause the work. If there is no incident, then come up with it. Ask to provide the logs of everything that the pentester did the day before yesterday from 2:00 p.m. to 3:00 p.m. - let it parse its traffic and remember which of the hundreds of checks with which tool and where it was launched.

Was it real?


Not only pentesters, but information security as a whole suffer from this. As soon as you begin to carry out work, any incident in the organization immediately leads to the need to stop and sort it out. The server became unavailable - these are pentesters; the virus got out of the user - these are pentesters; the coffee maker in the cupboard broke - these are pentesters. We relate to this with humor and patience, but time is conspicuously eating up.

Tip 17: prevent file disks and mail from being analyzed


Prevent Pentesters from gaining access to file disks and mail to analyze their contents. Justify it with "well, very confidential information."

Was it real?


Of course, there are 20 administrators mailboxes, but you can’t read letters. However, in practice, we repeatedly extracted additional passwords in the mail, and they greatly helped in compromising the company. And yes, a real hacker, of course, would have unloaded all the mail and asked no one.

Tip 18: ask to analyze vendor software


Say that from the whole infrastructure as a whole, you would like specialists to analyze vendor software, especially if it is very widespread and it is almost a “boxed version” without additional configuration.

Was it real?


It happens that they ask to crack a pure Cisco ASA or something similar. We say that this product is widespread and, most likely, has been tested by many people, we can check the “misconfiguration”, but there is no point in fuzzing everything during the pentest. This is actually a 0day search, and it is better to test on a stand in conjunction with reverse reverse engineering. Customers nod and still ask to be tested during the pentest, which will be in time. It is almost always a waste of time.

Tip 19: adjust the final report


The sweetest thing: if, after all, the hacking has been completed and the pentesters have presented you with the first version of the report, just ask to remove critical moments from it. This is a business, and you should be given a report for which you paid.

Was it real?


There are funny moments that make you want to laugh and cry. Either “remove the CEO’s mail from the report”, ““ this server needs to be removed ”,“ “who asked you to enter the IS service computers - quickly remove it”. Sometimes the wording corrects, thanks to which one and the same fact from the terrible becomes completely acceptable.

Tip 20: set up fierce game on network devices


Why not? If you have steel fist eggs and have the technical ability, then create chaos. For example, let every 27 tcp packet returned to the pentester come in broken. The main thing is that no one notices.

Was it real?


Not yet, but that's not accurate. Maybe the abnormal behavior of the scanner in one of 100 cases was the consequence of such measures.

Conclusion


No one writes in the report about a million problems that arose during the work: that access was granted for 5 hours, that they agreed on the operation for 2 days, that there was a chair without a back, a muzzle from a window leaf, etc. All this remains behind the scenes, and based on the results of the work, a dry technical report is issued, looking at it, an independent person simply won’t understand how much pain is behind him.

At the Information Security Center "Jet Infosystems" we work with medium and large businesses. Some of these tips are carried out by customers in the background due to the internal characteristics of the organization, the criticality of information systems and a large number of those responsible. These are normal processes to minimize the risk of the impact of security analysis work on business processes. However, for the most part, our hands are untied and friendly relations with customers are built. We ourselves can offer the right approaches and interaction convenient for both parties. Even in complex bureaucratic organizations, you can always find a flexible solution and carry out quality work, if you agree correctly with interested people.

More articles:


All Articles