~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Security Automation (Pre-AI). The Code. | ⚙️ AI Automation. The Code.

🔒 Related Stories: Cybersecurity | Penetration Tests

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm just getting this off my mind today because it came up. It made me think I need to rewrite some information about how I perform penetration tests and write reports.

The minimum time I generally spend on a penetration test is 3–4 weeks. In some cases it was more like three months. That timeframe doesn't mean I'm full on testing for 3–4 weeks or whatever the length of the engagement is. My minimum is 60 hours (It really should be at least 80 and more like 120 to get good coverage on most typical small to mid-sized SAAS applications, but I try to work with client budgets). The extra time allows me to complete other things I'm working on which are helping me improve on all penetration tests and possibly writing a specific tool for a particular customer engagement.

However, when I write a tool to get better coverage for a particular customer or hone in on a particular objective, typically that tool is one that I know I'll use again later. I don't feel right charging the customer for all the time to build a tool that is going to be reusable later, but I still need that tool for their particular test so I can do a better job in some cases. So that's one reason why I usually have some cushion.

The other reason I leave myself some time is that — I am one person. Things happen. I have to pay bills, answer the phone, have a few meetings, deal with appointments that can only be done during business hours, and do all the business overhead things myself. I might also get sick (it happens) or have some other emergency question come up from a prior client. I also have to spend a bit of time setting up the next project. There are only so many hours in a day and I don't charge clients for the time I'm not spending on their test.

But most of that doesn't take up too much time and I'm a workaholic. Generally I work over 8 hours a day when I'm on a project — and even when I'm not — so those things don't usually cause too much disruption. I tend to work long hours into the wee hours of the morning. Like now. Because there's something I want to finish or something that is on my mind.

The real reason I want the extra time is that it helps if I have some breaks to go off and do other things and noodle over how I am going to achieve the objective. I'm not going to just spend 40 hours straight and call it good. I generally spend some time testing and then step away to do other things and while I'm doing those other things I'm thinking about the goal I'm trying to reach on the current aspect of test — account takeover, file upload attacks, get past a particular security control…and so on. Sometimes I need to sleep on it. Sometimes I'm researching, listening to related podcasts, and reading various materials to help me solve a particular problem.

Then there's the report. And this is where I started thinking I might have given the wrong impression with some of the things I have written. I generally break things down like this when I explain my process:

• Set up time
• Recon time
• Test Time
• Report Time
• And if time allows deeper reverse engineering and exploit writing

The last one depends on how well secured the customer's site is and how much time I have to spend documenting the basic problems versus focusing on advanced attacks. Some customers I've had for years are getting better and better and I spend most of my time on the advanced work.

But the thing is, I don't do all my time for those tasks in sequential order. I might do some recon, try to perform some attacks, do some additional recon with a different tool on a different aspect of the architecture, perform some attacks, generate the initial report, review it, perform some validation, get some ideas for some new attacks, carry out the new attacks, add them to the report, do some advanced attacks, add them to the report, then clean up the report, find something I missed, go validate it or perform some other attack, then add it to the report and finalize the report.

It's not like I just do x hours of recon in a row, x hours of testing in a row, x hours of report writing in a row — which is the way I felt like it was presented to me in classes. I don't really work that way. If a client has a particular need for a specific timeframe and structure I can certainly work within whatever parameters they give me.

As you can imagine if I spend x hours of recon, x hours of testing and in the middle of testing realize I forgot some aspect of recon — well you're not going to get as good of a report as you would with my actual approach where I work in a more iterative fashion, going back and forth between tasks focusing on the objective — which is not a report —it it so ensure the system is secure.

My goal is always to get as much coverage as possible testing as many different aspects of the system as I can with as many potential attacks as possible (aligned with the objective) in the time I have.

I can focus better if I perform recon on a particular aspect of a site, then the research and attacks related to what I discovered. Then when I'm through with that aspect of the site and testing, I dive into some other aspect of the site and try to wrap my brain fully around that. After that I might review the cloud architecture focusing on misconfigurations that expose data or cause security problems, etc.

For example, in a particular site I was just testing I started with a black box try to hack the authentication system with no credentials. Then I moved to attacking the authentication system with credentials evaluating the configuration of the authentication technology. Next, I determined there was a particular type of authorizer behind the authentication system and spent some time focused on that.

I tried to envision what that architecture looked like through reverse engineering and what sort of attacks would apply and have my desired ( the customer's undesired) outcome. Then I moved on to different pages and features in the site one by one — basic injection like XSS and SQLi and different types of encoding. Then I focused on SSRF. RCEs. Next I tried to find all the pages with file uploads. And I proceed like that through all the pages, features, and potential attacks.

I try to make sure I hit each page, option, input in a fast manner, and then a more detailed approach as much as time allows, understanding and evaluating all angles and functionality of particular features including studying documentation and reverse engineering and evaluating any code I have. If my time is limited I'll focus on what I think poses the greatest risk.

I make a pass over each page with the basic fuzzing and testing without knowing too much about the site. Then I dive deeper into understand the site, the APIs, and any features of functionality I may have missed. When I feel like I'm going to need to start wrapping things up — sometimes earlier than later — I start generating the report. That gives me time to work out any kinks in the report generation process.

The report is a combination of generated data that would be a waste of time to reproduce manually on every report, and then the customized data where I insert my own documentation, analysis and images for each finding. As I'm working I might come across a finding from a tool I haven't explored thoroughly yet and go off and work on that and then come back and do more on the report.

In reality, I'd like to have the report shell generated on day 1 but I haven't gotten my process to that point yet. And no I don't want to buy your pentest reporting tool. I get asked that all the time. I have my own reporting tool that merges all my data from various tools and custom inputs to generate my reports. I also need to set up and test the client credentials right away and want to improve upon that and have a lot of ideas around ai, fuzzing, and coverage. So many ideas…so little time.

But at the end of the day the point is not to be fancy with the tools. The point is to spend as much time as possible testing the customer applications and infrastructure to help them secure their resources. As I already mentioned, my objective is not a report. It is to know that I have tested as much of the infrastructure and application as I could in the time I was given and feel fairly confident that I have found the most glaring issues.

Of course, the customer's objectives take precedence over any objectives I may personally have. If a customer wants me to work in a certain way they tell me up front and if I can, I will. If for some reason I can't work that way, I'll tell them right away.

But so far I have always been able to meet customer requests with these exceptions:

I don't work through third parties and some of them wanted me to bill hourly but I don't do that. Most could not meet my billing and scheduling requirements. Or they said they had clients and I signed referral agreements but not once did I actually get a referral after spending time on that so I don't do that anymore. If I have work to refer, I will recommend people if I know any who do that. I am hopeful that others will reciprocate.

I work for a project fee. It's based on hours but it's a flat fee with a minimum price to take on the project. I bill half up front and half at the end. I have learned that if it is a project over a month I need to also bill in additional increments (progress payments).

I also need a schedule. One company wanted me to work through them with no defined dates in the contract. I can't work like that because I need to know what dates and times a customer needs me so I can schedule other customers in the open slots. I can't have someone randomly come back to me and say they want me to start when I'm in the middle of another project.

I also can't have them tell me it's going to start in March and then I block out the time and then they don't start until April and I've got not income for March. A company that was scheduling me as a trainer did that to me and I had no income for a month as a result. I can't just go out and find new work when someone changes the schedule the week before the start date. And one year I immediately got booked in about February until November. That doesn't always happen but it can, so I need a date and time for the test in the signed contract.

And the reason I'm explaining all that is because when I have a scheduled, the report is delivered at the end of that project. The length of time may be a few weeks and if you want to know what percentage of the report is done on a 4 week project and we're on week 2 — it's 50%. To date I have always worked more hours than I bill but I know I will work at a minimum the quoted hours. If I have some extra free time I will do more at no additional charge. If I don't I won't but so far I have always planned it so I'm not cutting a customer short in any way.

I'm always afraid I have missed something when the end of my time is nearing. I tend to cram at the end. There is always more to do, but at some point I have to cut myself off. Sometimes there's something I really want to test and a customer is not in a hurry and gives me more time. Sometimes they don't. In any case, I try to meet their objectives first and foremost and if possible, my own as well.

I know how impossible it is to find everything. But I do my best! And that's how I operate. I just wanted to write that down for future reference so that people will understand the way I work before hiring me to do a test — and that way if they have any other particular requirements they can tell me in advance. And hopefully our expectation are fully aligned.

Follow for updates

Teri Radichel | © 2nd Sight Lab 2025

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books | Substack: teriradichel.substack.com
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero Former SANS, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests & Security Research ~ 2nd Sight Lab
Cloud, SAAS, and Application Penetration Testing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test
Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ X, Threads, Blusky, Instagram, AWS BuildID: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab